[En-Nut-Discussion] SRAM speed

Fri Sep 13 04:17:26 CEST 2002

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