[En-Nut-Discussion] Ideas from an outsider

[David Armstrong]

if this route is adopted , my thoughts are to use the Zilnix coolpowerII
at least the tools are free !
Atmel seems to tie you in knots, as well as unreliable , a total nightmare

Dave
----- Original Message -----
From: <deoxy at u.washington.edu>
To: <en-nut-discussion at egnite.de>
Sent: Monday, October 28, 2002 10:01 PM
Subject: [En-Nut-Discussion] Ideas from an outsider


> 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
>
>
>
>
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo/en-nut-discussion