[En-Nut-Discussion] CPLD (was SRAM speed)

[matt]

The Altera EPM3064ATC100-10 you have is a good choice in my view
because not only is a mainstream part but also has a pin compatible
replacement
from Atmel. The Atmel part has the same pinout, same number of macrocells
and a
slightly more flexible and more powerful structure for its macrocells .
Atmel
also has a converter from Altera to atmel . If you don't like the MAxII
Altera
software , Atmel uses a different approach ,you have a choice ,WinCUPL or
schematic entry  . The schematic entry uses Protel99se schematic capture
plus
the CPLD tool only with new libraries (as opposed to the full blown
Protel99se
which has crappy pld libraries).

If we could come up with a set of functional specs for the mega128 +CPLD
board
the rest is relatively easy... (or at least an all inclusive wish list if
not clear specs ).

REgarding the ram to ethernet transfer options, any kind of hardware
improvement
would be great. Doubling the xfer rate means a lot , it would be like
getting a 32MHz
mega128 for that piece of code. If it can be achieved by recycling a few
logic gates
inside an already existing cpld, then it's even better because it's free .
The only cost
would be the hardware development effort but that would be in the noise
level
compared to the whole hardware project . The hardware costs would be the
same
so why not ? Even if it only allows more time for other tasks and allows you
faster
and sloppier code development for other projects it's still a gain.

Best Regards,

Matt Tudor , MSEE
http://www.gigahertzelectronics.com

-----Original Message-----
From: Alastair Jeremy (E-mail) <ethernut at dotaussie.com.au>
To: en-nut-discussion at egnite.de <en-nut-discussion at egnite.de>
Date: Thursday, September 12, 2002 7:14 PM
Subject: RE: [En-Nut-Discussion] SRAM speed


>
>For the approvals, I wasn't so worried about the choice of chip, more the
>total design. ie. if Ethernut radiated too much (for whatever reason), then
>you'd be stuck. On the topic of these approvals (CE/FCC/other), can you
>recommend any guides on how to design to meet these requirements?
>
>For the CS8900 is 16 bit mode, I had a (brief) look at using a CPLD latch
to
>capture the high-order byte. I don't think it would actually increase the
>bandwidth, since you still need 2 external memory cycles of the AVR itself
>to get the data. It only helps if the access-cycle to the ethernet chip
>needs to be very slow. $3 is quite attractive though, so hopefully the
'bug'
>does not exist (although I'd like some indication from the manufacturer)
>
>If you did a DMA-style access using the AVR between the ethernet chip and
>the SRAM, I think you'd probably double the throughput (minus additional
>setup time). If you use the indirect with pre/post increment instructions
>you only need two instructions (read, then write) per byte, plus looping. A
>partially unrolled assembly code loop should be pretty quick. The
>AVR-controlled DMA style would need one external 'dummy read' instruction
>per loop.
>
>While double throughput is pretty quick, I'm not sure that it would
>necessarily be worth the extra pain in getting the DMA hardware to work? Of
>course, that's only my opinion, which is perhaps a little biased due to my
>lack of experience with implementing DMA circuits. If you want to go to DMA
>without using the AVR, then the complexity will jump again, and I would
also
>presume that the AVR would have to work inside it's internal SRAM while the
>DMA was occurring. This would start placing limits on what the OS could do,
>etc. etc.
>
>I would be guessing that an application that _required_ the DMA would
>probably need so much power for whatever is was doing with the data once it
>received (or transmitted) it that a 16bit microcontroller with inbuilt DMA
>would probably be more applicable (which would also immediately improve the
>ethernet chip access time because of native 16 bit accesses anyway).
>
>Do you have any tips or traps from your experience using the Altera CPLD
>parts? (my choice of EPM3064ATC100-10 samples to test with was based on
>simplicity in obtaining them for me, so if they are a crap choice, please
>let me know!)
>
>Regards,
>
>Alastair
>
>
>-----Original Message-----
>From: en-nut-discussion-admin at egnite.de
>[mailto:en-nut-discussion-admin at egnite.de]On Behalf Of matt
>Sent: Friday, 13 September 2002 2:10 PM
>To: ajeremy at dotaussie.com.au; en-nut-discussion at egnite.de
>Subject: Re: [En-Nut-Discussion] SRAM speed
>
>
>1- All Ethernet chips which we could buy through distributors are used in
>mass produced computer cards, and have no specific features prohibiting
them
>from CE , FCC etc approval . I haven't done any CE recently, have done FCC
>approvals and for unintentional radiators (which is what all computing
>devices are classified under) the requirements are not difficult. In
essence
>, any decent design will pass , regardless of what ethernet chip is used.
>The important things are to have good board layout, good power supply and
>power filtering design , etc . Avr chips are used in cellphones , laptops
>and other CE and FCC approved products.
>
>2- crystal 8900a comes in industrial temp, that's why I mentioned it. It
>might not be the only one though. Even if it has the 8 bit mode interrupt
>bug, maybe it can be patched with an extra latch on the data bus to convert
>to 16 bits. Same latch might be used for other purposes if it's inside a
>cpld/fpga , especially when the ethernet controller is not selected. Since
>the address decode logic would be in the same cpld, things might fall in
>place wihtout too much additional circuitry. This would also improve (x2)
>bandwidth .
>
>cs8900a was quoted to me at around $3 which makes adding Ethernet to
mega128
>based products a very inexpensive project if the micro has enough idle time
>to handle the throughput. DMA is just a thought , doesn't need to be fancy
.
>It could be designed as a very minimal subset of a real DMA controller, no
>need for lots of fancy modes that will not get used. Could be just a couple
>of latches for the base address for source and destination, then a counter
>that could be common for both source and destination, plus some logic. This
>would allow the mega128 to do something else while blocks of data are being
>transferred. It doesn't need to transfer blocks of 64kb, even 256bytes
would
>be a vast speed improvement versus reading the data into a register ,
>changing another output port for the destination address and output the
data
>by the mega128. Or it could be just a simple combinational logic circuit to
>handle the wr , rd and cs signals for the ram and ethernet controller , the
>micro is generating the addresses with dummy reads but it doesn't care what
>it reads, because the cpld logic generates wr pulses for the ram . Tis way
>data goes straight from the ethernet chip to ram without having to go
>through internal mega128 registers. The micro won't be able to do other
>things in the meanwhile but the transfer will take only one instruction
>versus several , it would be at least a threefold improvement. As always,
>it's a tradeoff, less complexity means less performance but even the
>simplest implementation is a huge improvement compared to the bare avr .
>
>3- cpld's with 64, 72 or 128 macrocells are common, inexpensive and not
>really that dumb. With a little care they can do a lot before going to a
>large package . The problem with most large cpld's and fpga's is the
>correlation between the number of gates/cells and i/o pins. At 128 and
above
>macrocells, they're all in large fine pitch tqfp/pqfp etc packages (100+
>pins) or even worse , bga's . 64 macrocells are available in smaller
>packages , same technology as the mega128 so manufacturing would require no
>changes versus the mega128 only board. Xilinx coolpld's are the lowest
power
>consumption if that's important , the design tools are free.
>
>
>Matt Tudor , MSEE
>http://www.gigahertzelectronics.com
>
>-----Original Message-----
>From: Alastair Jeremy (E-mail) <ethernut at dotaussie.com.au>
>To: en-nut-discussion at egnite.de <en-nut-discussion at egnite.de>
>Date: Thursday, September 12, 2002 4:12 PM
>Subject: RE: [En-Nut-Discussion] SRAM speed
>
>
>>
>>I agree with (1) regarding IC's available in industrial temperature
ranges.
>>Although once you are in those sort of applications, you probably also
>>should be considering things such as CE mark, FCC & UL issues. I am NOT
>>actually suggesting that the Ethernut should be listed, but just try to
>>avoid a design feature that would preclude an Ethernut-based device from
>>ever being able to gain listing. On this topic I must profess that I am no
>>expert! So please, if anyone has any pointers, please let me know (ie...
>how
>>DO you design to meet these requirements?).
>>
>>Also agree with (2), and looking at the OS structure, it would appear that
>>such drivers should be reasonably easy to slot in (although I'm sure
Harald
>>would know more here). Also, Harald, you mentioned that you had previously
>>considered the 8900, but chose to go with another chip because of presumed
>>interrupt problems. I also previously investigated the 8900, and I assume
>>you are talking about the datasheet which says interrupts don't work in
>>8-bit mode (which is pretty much a killer if you want performance, since
>you
>>would need to poll the ethernet chip - ouch!). I have seen unofficial
>>suggestions that the interrupts _do_ actually work in 8 bit mode - do you
>>know what the reality is?  I think 10/100 (in a different chip entirely)
is
>>a great idea, provided it is not too expensive.
>>
>>I have never built a DMA circuit myself, but I was of the impression that
>it
>>would push the design requirements towards a FPGA, rather than a CPLD? Or
>>maybe I have been looking at the 'dumb' end of CPLDs.
>>
>>Since you obviously have a fair bit of experience with the CPLD's, I have
a
>>few more questions there too, but I will wait until I have them in a more
>>structured order...
>>
>>Regards,
>>
>>Alastair
>>
>>
>>
>>-----Original Message-----
>>From: en-nut-discussion-admin at egnite.de
>>[mailto:en-nut-discussion-admin at egnite.de]On Behalf Of matt
>>Sent: Friday, 13 September 2002 3:55 AM
>>To: en-nut-discussion at egnite.de; Harald Kipp
>>Subject: Re: [En-Nut-Discussion] SRAM speed
>>
>>
>>I wouldn't rely on the very proprietary structure of FPSLIC . It is way
too
>>expensive to survive , just a mega128 plus FPGA or CPLD adds up to less
>>money . IF and when the AVR core and peripherals get changed the changes
>are
>>small compared to what would happen to the system architecture if the
>FPSLIC
>>goes away so it doesn't look safe .
>>
>>My company is interested in adopting Ethernut for embedded Ethernet
>>applications, and we're willing to assist with hardware development . I
saw
>>another company showed a similar interest recently. Maybe we can come up
>>together with a relatively flexible solution that will benefit all
Ethernut
>>users . We are open to discussion both on the list or private .
>>
>>IF the Ethernet chip changes, would it be possible to:
>>-1- select IC's which are made in extended temperature range . Embedded
>>systems exist in industrial , communications and consumer products. Very
>few
>>consumer and a lot more industrial/communications though, so extended temp
>>makes sense at least as an option. This way even if regular boards were
>made
>>with commercial grade chips, extended temp would be possible by using the
>>same chip in industrial version. Atmel micros come in industrial and
>>commercial , Realtek doesn't . Crystal 8900a does for example .
>>
>>-2- if several such Ethernet controllers are contemplated, what about a
>>dedicated driver for each, selected at compile time ?
>>
>>-3- attempt to implement some sort of rudimentary DMA scheme going through
>>the FPGA/CPLD between the external RAM and the Ethernet controller ? This
>>would speed up transfers and throughput , and most of the time people
don't
>>use up 100% of their FPGA/CPLD so it would come almost free (hardware
extra
>>costs minimal) .
>>
>>-4- regarding the CPLD/FPGA, we are familiar with the chips and devtools
>>from Atmel , Alterra, Xilinx, Lattice . They all make in circuit
>>programmable cpld's , and it would be possible to use a portion of the
cpld
>>for the board address decoding, dma, etc and leave some free for the user
.
>>Give the user the option of loading the programming file either directly
>>through ISP or JTAG , or through the mega128 itself , in which case it
>might
>>be in the form of an include file .
>>
>>Best Regards,
>>
>>Matt Tudor , MSEE
>>http://www.gigahertzelectronics.com
>>
>>
>>-----Original Message-----
>>From: Harald Kipp <harald.kipp at egnite.de>
>>To: en-nut-discussion at egnite.de <en-nut-discussion at egnite.de>
>>Date: Thursday, September 12, 2002 4:52 AM
>>Subject: RE: [En-Nut-Discussion] SRAM speed
>>
>>
>>>
>>>>Oh yes, and were you planning to have in-system programmable CPLD, to be
>>>>programmed by the ATmega? Or is that just a silly idea.
>>>
>>>Definitely this is _NOT_ a silly idea.
>>>
>>>Just in case somebody will now come up with
>>>FPSlic: Are you sure, that Atmel will continue
>>>to offer them to the public?
>>>
>>>Harald
>>>
>>>_______________________________________________
>>>En-Nut-Discussion mailing list
>>>En-Nut-Discussion at egnite.de
>>>http://www.egnite.de/mailman/listinfo/en-nut-discussion
>>
>>_______________________________________________
>>En-Nut-Discussion mailing list
>>En-Nut-Discussion at egnite.de
>>http://www.egnite.de/mailman/listinfo/en-nut-discussion
>>
>>
>>_______________________________________________
>>En-Nut-Discussion mailing list
>>En-Nut-Discussion at egnite.de
>>http://www.egnite.de/mailman/listinfo/en-nut-discussion
>
>_______________________________________________
>En-Nut-Discussion mailing list
>En-Nut-Discussion at egnite.de
>http://www.egnite.de/mailman/listinfo/en-nut-discussion
>
>
>_______________________________________________
>En-Nut-Discussion mailing list
>En-Nut-Discussion at egnite.de
>http://www.egnite.de/mailman/listinfo/en-nut-discussion