[En-Nut-Discussion] Ideas from an outsider

[deoxy at u.washington.edu]

Hi Ethernut Developers,

I stumbled across your discussion list archives last Thursday, and read through the thread discussing Ethernut 2.0.  I am currently working on a project similar to Ethernut as it involves an ATmega128 driving a NIC on a board with SRAM, but my project adds a CPLD and the capability to drive a graphical LCD from a bitmap stored in SRAM.  Your possible addition of a CPLD to Ethernut 2.0 is a great idea in my opinion, adding much more flexibility for a hardware developer or someone using your board to add DMA support, LCD controlling capability, or many other things that wouldn't be thought of until after the hardware design is finished.

An example application I thought of this morning is to have a 4x4 matrix keypad that is scanned using the CPLD logic, the status is read in from memory-mapped registers in the CPLD, and an interrupt could be generated by the CPLD to wake up the mega128 from power-down when a key is pressed. This would require only one AVR I/O pin for the interrupt, instead of 4 or 8 for scanning the keypad.  My opinion is, if CPLD support is added in, it will be used by developers, possibly in ways that suprise you.  

While my project would not be able to be directly compatible with the Ethernut 1.0 board and software, if CPLD support is added, I could add the LCD bitmaps in the paged RAM, and implement a DMA LCD driver in the CPLD.  By the way, my design is going to be open source/hardware, and I'm doing this for my own benefit, not for a company.

I've made a list of things I would consider if I were developing the Ethernut 2.0 reference board, and I hope this helps in your development some way.  I hope you do decide on going the CPLD route, as I would be able to contribute hardware and software modules to the project, instead of making modules only compatible with my specific hardware.

I'm currently using a Xilinx XC9500 CPLD in my design, and will be trying to implement a very basic DMA controller in the next week, so I will report back on that, along with more details and HDL source on my website later.

As a side note, I am fairly new to electronic design, having only recently graduated with a BSEE degree.  I don't have any actual experience with DMA, other than what is required to get a packet from the RTL8019AS NIC, so if some of my comments may seem trivial to an experienced developer, that's why.

CPLD Issues
-----------
For DMA support, the CPLD should probably have its own address and data bus, replacing the HC573 with a latch inside the CPLD, so the mega128 will not directly interface with anything except the CPLD over the external SRAM interface.  For DMA, the CPLD will have to put an address on the bus, and also drive the data bus, and control the SRAM and the other peripheral's read, write, and chip select lines.

What will clock the CPLD?  A buffer could be used to drive the CPLD from the mega128's XTAL input, at whatever clock speed is driving the mega 128.  If a DMA cycle could be done on the CPLD in two AVR clock cycles (can it? I'm not sure), this would still be a major improvement over read a packet byte-by-byte from SRAM, and writing out to the NIC.  Even at three or more cycles it is still an improvement.  A faster clock could of course be added, but this would effect the EMC characteristics, something I'm not experienced with measuring, as well as requiring a faster SRAM.

Programming the CPLD:  Putting the mega128 and the CPLD on a shared JTAG chain sounds like a good idea, with programming software being the major gotcha.  If nothing comes out soon, I would be interested in writing software to program AVRs with JTAG support.  Because all the CPLDs compilers that I've seen and the AVR software has the ability to create SVF files, it may not be that difficult to do.  Another problem is sharing the 4 ADC pins with JTAG, can this be done with an analog multiplexer, or do the pins have to be assigned to JTAG or ADC, not both?  I know the mega128 data sheet says using the external reset line can enable a normally disabled JTAG port (proveded fuses are programmed prior), but the CPLD JTAG lines should be separated from the analog lines somehow.

I like the idea of using the mega128 to reprogram the CPLD in a bootloader fashion.  If the external SRAM and the NIC are separated from the mega128 through the CPLD, even by as little as chip selects controlled by the CPLD, access to these parts will not be available during programming, so the entire CPLD fuse pattern must be stored in internal memory.  This seems possible, as these parts are not as complicated as a FPGA for example, but I need to do more research on this.

Making a CPLD board compatible with a non-CPLD board:  The DMA features should be completely optional, selected at compile time.  For a design that doesn't ever need a CPLD, or for backwards-compatibility with Ethernut 1.0 boards, the SRAM start and end addresses for non-paged RAM should be defineable, and because the NIC is mapped at a certain offset, this could be decoded in discrete parts (I think this was already discussed on the list).  The paged RAM size and address range should also be selected at compile time, and be completely optional.  Using this type of software implementation, most of the discussion on the board on where to map certain things in RAM does not have to be resolved, just make it implementation specific.


Practical Issues
----------------
SRAM selection: While support for varying amounts of SRAM should be done using paging and external logic, the practical aspect of adding support for various size SRAMs into the PCB can also be done.  There is a standard pinout used by several SRAM manufacturers, it's the pinout supported on the Atmel STK501 board.  I'm using a Cypress CY7C1019 128kx8 chip on my STK501 board, and the CY7C1049 512kx8 chip adds two more address lines, one at the top of the chip and another at the bottom with the same pinout in the middle.  By making the PCB pad the 512kx8 size and running the two extra lines back to the CPLD, two SRAM sizes could be supported, with really nothing lost if the 128kx8 RAM is selected.  I will be doing this with my LCD controller board allowing support for the range of 128kx64 displays that need very little RAM, to 640x480 displays that need all of it.

I don't know about purchasing outside the US, or in quantity, but it seems like SRAM prices have really dropped as of late, as well as most vendors moving to 10/15/20/25ns parts instead of 60/70ns.  Using a faster part would allow for better DMA, as a read cycle could even be as small as the low duty-cycle of a 16MHz clock, allowing for a read, wait, write to happen in two clock cycles.  Also, if the SRAM and peripherals are completely separated from the mega128 through the CPLD, and a 3.3V CPLD is chosen, the SRAM could be a low-power 3.3V part, and non-5V-compatible parts can be placed on the bus.

CPLD vendor selection: I only have experience with Atmel and Xilinx CPLDs.  My Xilinx experience is more limited, only working with their software for two weeks now, though overall I am impressed and have no complaints.  My Atmel experience was developing with WinCupl, which I would not recommend to my worst enemy.  The WinCupl software is horrible, and crashes so much I ended up making a shortcut to the software in my Windows taskbar, and using it often.  There were also outright errors in the fitter software, where adding a flip-flop to the design, completely unrelated to another module, would cause the module to fail.  Pin-locking support was also basically not implemented, either your design fit completely as is, or it reassigned all the pins for you.  I can't speak for the prochip designer software, but you want to allow any developer for your board to program the CPLD, it should not require any expensive development software.  I have no Altera experience, but if develo!
pment can be done on their free software and a compiled file can be converted to Atmel's CPLDs, this sounds fine to me, giving more flexibility to the board designer, and the cheaper CPLD can be chosen.  If anyone knows where Altera CPLDs can be bought in small quantity in the US, please let me know, I'd like to give their software/hardware a try.

Power over Ethernet:  I don't know much about this, but apparently a lot of wireless access points have been adding PoE support, and it's now an IEEE standard.  Because your board may be used in an area where putting a DC adapter nearby may not be practical, support for this might be considered.  Bothhand sells a Ethernet RJ-45 jack with integrated magnetics, and support for PoE.  This could be added to your board with the option to use it by moving two jumpers.
http://www.bothhand.com/products/rj45/PLU1S041A-XX-A2-02.04.13.pdf


---------

Well, that's what I have for now, I hope this at least provides some food for thought,

Louis Beaudoin

louis at embedded-creations.com
www.embedded-creations.com