Re: FPGA for PCI based servo control board

[John Sheahan <jrsheahan-at-optushome.com.au>]

On Fri, Apr 04, 2003 at 08:52:03AM -0500, jmkasunich-at-ra.rockwell.com wrote:
> 
> NO. Raw packets.  Point-to-point connection, no
> switches, hubs, or collisions.  Still need protection
> against noise corrupted packets (CRC errors).

Agree.  8019 class devices do crc. 

now the question of what happens when a packet is lost 
arises.  Its equivilant to what happens when the 
parallel port (choose favourite interface) glitches.
(this is the root cause of my parallel port phobia)

Generally the packet is lost. If the protocol is absolute 
or has feedback, thats just a kink. otherwise... 

ethernet will be no worse than anything else here. 
probably quite a bit better than most.

> 
> > if so - you need  the micro and a protocol stack.
> >
> > if not, the fpga can suck fixed formatted
> > packets straight out.
> 
> Can it assemble packets and stuff them into the
> ethernet chip too?  Gotta handle the inputs as
> well as the outputs. 

Hey - I'm on record as requiring a HDL for the fpga design
and a decent fpga.  State machines is _the main_ area
HDL designers dislike regressing to schematics.  no problem.


>  Also, do we use a fixed
> format packet that includes 8 axis and 128 bits
> of digital I/O regardless of the actual amount
> needed, or should the packet format be determined
> at boot time?  I agree that during run time, the
> packet format should be fixed.

sounds like a parameter for the fpga compile. A format that 
can obviously be  extended for more axis or more resolution 
as required.   Don't think its a big deal either way.

I'd vote for full duplex and some limit on max packet rate to keep
both sides happy.  The reverse channel has to work reliably. 

> 
> We might want a micro to handle the above issues,
> but definitely no protocol stack.

perhaps.  I wouldn't, but thats just me. The interface between the
micro and the fpga will be as complex as the fpga/ethernet-chip.
And has to be specified.
Let me throw in another thought - the ethernet mac is smaller than the
pci core, do that in the fpga too.  We need a new thread here :)
Mind you, the ability to download the fpga image from the host at 
startup would be pleasant, and that could maybe justify a PIC that 
goes away thereafter.


> 
> The hard part here is dealing with dozens of
> different NICs.  On the FPGA end, we choose
> the NIC.  On the PC end, it could be anything.

I don't really agree with this. Support for (the easy/documented) NIC's the 
developers have is required. Anyone else, the owner either 
writes their own/support the developer/buy the correct NIC.

Caal me unreasonable..  But why does everything have to be 
there at day one on an open project?