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

[matt]

P.S. the Atmel part that's pin compatible and functional superset of your
Altera is
Atf1504 in all sorts of versions (voltage, speed , power , some extra logic
and
packages).

It would be perhaps a good idea if Harald would post his future hardware
requirements (address decodes for RAm and ethernet). It would help if the
RAM
addressing is taken care of with a scheme that allows some future expansion
so
that there's no need to modify the firmware and the board+cpld . We could
have
the equations in the cpld for the largest amount of ram even if it's not
implemented
on the current board . This would allow a standard platform structure , I
hope I'm
not just dreaming here ... We have some products with a power up self check
where the micro tests to see what peripherals are present and decides it is
going to run as a different type of unit depending on what it finds. Nothing
too
fancy , just the simplest test for ram size and peripherals and the result
gets
stored in e2prom .

Best Regards,

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

-----Original Message-----
From: matt <mariusrf at bellsouth.net>
To: ajeremy at dotaussie.com.au <ajeremy at dotaussie.com.au>;
en-nut-discussion at egnite.de <en-nut-discussion at egnite.de>
Date: Wednesday, September 18, 2002 11:50 PM
Subject: Re: [En-Nut-Discussion] CPLD (was SRAM speed)


>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
>