Re: FPGA for PCI based servo control board

["Dave Engvall" <dengvall-at-charter.net>]

OK....so do I hear correctly...that you want one board in the CPU box and
another out in the real world...ie more complexity to deal with.
IMHO ... do an ethernet version of Jon's board...or firewire....but either
keep it inboard or put it outboard.

Just my viewpoint, just couldn't resist rocking the boat.

Dave Engvall

----- Original Message -----
From: "John Sheahan" <jrsheahan-at-optushome.com.au>
To: "Multiple recipients of list" <emc-at-nist.gov>
Sent: Friday, April 04, 2003 4:21 PM
Subject: Re: FPGA for PCI based servo control board


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