[En-Nut-Discussion] Ideas from an outsider

[matt]

Harald,
You are right in one respect and it might be more important that
you think. You don't need to implement a CPLD system first.
A CPLD is just a tool which reduces package count and possibly
cost , at least in the speed range and complexity we're contemplating here .

An average to good CPLD might cost in the $2-4 range which buys
a lot of discrete ( 74xx ) logic . Board area is only an issue if your
design can't tolerate high density small packages as TSSOP discrete ic's .
Consequently ,a half dozen logic ic's in TSSOP would occupy
very little room and would cost just about the same as a CPLD.
You may use your favorite tools to debug and prototype your
discrete logic design quickly . Using a CPLD is not as straightforward
because you need to design it first, then simulate , then build and
debug , which takes more time than a discrete design . It also needs
programming for each board to be built.

I'd cast my vote in favor of you adding anything you need with discrete
logic , worst case scenario you'd use a few latches, buffers and gates .
Then you get your alpha/beta firmware running and after that you publish
it on your website for example. When and if the hardware reaches the
critical mass to benefit from a simple CPLD or from some more elaborate
FPGA, lots of people myself included could work to implement a CPLD
based version . This would be functionally equivalent to your (future)
enhanced discrete logic board and could be a superset of it .If you want
you may define some standard interface between the mega128 and the FPGA
like a dual ported memory or some memory mapped registers .
Beyond the basic funcitonality which you require, it would be up to the
user to fill up the FPGA with whatever junk and write the high level
application, you'd provide only the interface driver using the memory mapped
registers for commands and status .

I think you will see a decision by indecision, a well known phenomenon
in mid level management . The dilemma is which way to go ,and because
there are too many options (and too difficult to quantify their merits) the
analysis goes on and on and on, effectively blocking any decision .
Unfortunately ;-) there are a number of different ways to implement
a superset of your hardware using programmable logic :

(1) - use a dirt cheap CPLD in the $1-2 range just to replace your discrete
logic, a Xilinx Coolrunner , or equivalent Altera or Atmel .
(2) - use a more complex design with a larger CPLD , in the $2-5 range for
more extras. The question is, how do you select the extras because
everybody wants/needs something different. At this level you can't be
flexible
enough and the chip doesn't have enough resources to satisfy all needs but
the design complexity is there due to the required CAD tools which are the
same as for the much more complex stuff .
(3) - use a low cost FPGA in the $5-10 range for a lot of stuff, including
all the logic, possible LCD controller , possible extra RAM, extra UARTs etc
inside the FPGA. A suboption here would be to have a general purpose
piece of VHDL with the necessary (required) logic, and leave the rest to
the user to fill up the FPGA . Downside is each variation would require
individual debugging .
(4) - use a FPSLIC (yes, I know ;-(( do they really exist or is that from a
parallel
universe) and have all the logic, lcd controller, 4 uarts, a dsp and another
RISC
micro onboard. Then port the NutOs to that new RISC - just kidding .
(5) - use a larger FPGA like an Actel proAsic(plus) . If you use proasic ,
it
 includes the FLASH so it's a single chip solution and you can fit a 16 bit
RISC micro , DMA controller, LCD controller etc on one chip. Make them
instruction
set compatible with the mega128 but superscalar at 200mips .

Joke aside , there's no limit for what's doable in programmable logic other
than
immediate needs and common sense . Really doing some of the above would
be the same as porting Linux to the mega128 though , so where do we draw
the line ? Actually I'm having second thoughts about making a 200mips
superscalar mega128 and porting linux to it  .
 I knew there had to be a reason for calling this NUT os ;-)

So back to Earth, we need a set of clearly defined requirements in order
to be able to zero in on a solution . Yes, they can all be done but not all
are a good
investment of time and effort.

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>
Cc: <deoxy at u.washington.edu>
Sent: Tuesday, October 29, 2002 12:33 PM
Subject: Re: [En-Nut-Discussion] Ideas from an outsider


> Louis,
>
> Let me first tell you that I stumbled over your website
> recently and was impressed by the amazing microVNC.
>
> Thank you for the time you spend on these most valuable
> comments about a CPLD doped Ethernut. I do not have any
> experience with CPLD design. But from your suggestions
> and other messages posted to this list it becomes obvious,
> that the hardware flexibility such a design would offer
> makes it very attractive.
>
> Your mail certainly requires some time to think about.
> Anyway, a few comments in advance:
>
> - The AVR JTAG doesn't support daisy chaining.
> - It is possible to run Nut/OS routines without
>    external RAM access. I use it for an IDE interface,
>    where Ports A and C are used as I/O Ports _and_
>    Address/Data Bus.
> - Ethernut 1.3d offers some kind of PoE and we use it
>    in one of our products. But it's not following the
>    IEEE standard, which requires some additional
>    "intelligence". I'll check the Bothhand part.
>
> Beside that, it looks to me right now, that a CPLD
> doped Ethernut design would require at least a few
> weeks to be done. Not to mention all the required
> documentation.
>
> That's OK somehow, but my company really needs two
> enhancements as soon as possible (additional RAM and
> 100BaseT). Both requirements could be easily done
> with discrete logic. I'm now thinking about doing
> such an intermediate layout first and give us all
> some extra time for a really good CPLD design.
>
> Harald
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo/en-nut-discussion
>