bit file fpga to pc

Hello everyone,
I'm working on a project that requires sending pixel data from an fpga to
a PC,  RS232 would be fine but Ethernet is also considered. (need to create
a bit file to process the image in the PC).
Any VHDL code reference for the transmission process and any advice on
generating the bit file would be highly appreciated.
Thanks, 

On Fri, 07 Nov 2008 14:16:29 -0600, "wluiscam" <wluiscam@gmail.com>
wrote:

>Hello everyone,
>I'm working on a project that requires sending pixel data from an fpga to
>a PC,  RS232 would be fine but Ethernet is also considered. (need to create
>a bit file to process the image in the PC).
>Any VHDL code reference for the transmission process and any advice on
>generating the bit file would be highly appreciated.
>Thanks, 

RS-232 signaling are normally used with asynchronous serial data.
Maximum baud rate for most PCs is only 115200 baud.
Which is about 11KiB/s. It is simple to write your own VHDL
implementation of a transmitter.
Ethernet is up to 1000Gib/s. Implementing this is orders of magnitude
more complex. 
For any communications problem, you first need to know how much data
you want to send, in how much time. 

Regards
  Anton Erasmus

On Nov 7, 3:16 pm, "wluiscam" <wluis...@gmail.com> wrote:
> Hello everyone,
> I'm working on a project that requires sending pixel data from an fpga to
> a PC,  RS232 would be fine but Ethernet is also considered. (need to create
> a bit file to process the image in the PC).
> Any VHDL code reference for the transmission process and any advice on
> generating the bit file would be highly appreciated.
> Thanks,

If RS232 will handle your data rate that will certainly be a lot
simpler to get running.  The hardest part may be creating some sense
of packets or structure to your data so that you can identify the
start of each picture.  If you can reserve one byte value for a start
and make that illegal in the data, that may be the simplest -
otherwise you end up looking at either a time-based framing (hard from
a PC software perspective), escaping your start code, or something
that I pulled once - since data rate wasn't critical, I had the FPGA
send a hexadecimal representation in ASCII (2x overhead vs binary) and
then defined some start and stop characters.  Making the data human
readable in a terminal program was an added benefit!

Ethernet in practical terms requires something with "software" type
complexity on the embedded side to handle protocols.  I mean you can
do UDP-and-pray, but its nowhere near as reliable as running RS232
without handshaking.

On Nov 8, 12:24 pm, cs_post...@hotmail.com wrote:
> On Nov 7, 3:16 pm, "wluiscam" <wluis...@gmail.com> wrote:
>
> > Hello everyone,
> > I'm working on a project that requires sending pixel data from an fpga to
> > a PC,  RS232 would be fine but Ethernet is also considered. (need to create
> > a bit file to process the image in the PC).
> > Any VHDL code reference for the transmission process and any advice on
> > generating the bit file would be highly appreciated.
> > Thanks,
>
> If RS232 will handle your data rate that will certainly be a lot
> simpler to get running.  The hardest part may be creating some sense
> of packets or structure to your data so that you can identify the
> start of each picture.  If you can reserve one byte value for a start
> and make that illegal in the data, that may be the simplest -
> otherwise you end up looking at either a time-based framing (hard from
> a PC software perspective), escaping your start code, or something
> that I pulled once - since data rate wasn't critical, I had the FPGA
> send a hexadecimal representation in ASCII (2x overhead vs binary) and
> then defined some start and stop characters.  Making the data human
> readable in a terminal program was an added benefit!
>
> Ethernet in practical terms requires something with "software" type
> complexity on the embedded side to handle protocols.  I mean you can
> do UDP-and-pray, but its nowhere near as reliable as running RS232
> without handshaking.

Oh, one more idea - you can have the FPGA look at the RS232 data line
from the PC, not even to decode characters (though that's not hard)
but simply use any transition of it to trigger sending of a block of
data to the PC.   Then the PC simply sends an arbitrary single
character each time it wants a block of data.

Or you can go to 9-bit serial, but that makes it harder to have a PC
on the other end...

Or you can try to do something with the handshaking lines.

Thanks very much to everyone who took the time to respond.
As of right now, data rate and size is not critical.  I'm storing pixel
data from a line scan CCD in 8 bit grayscale.  So, if I can send so many
lines of data over serial interface, I should be able to generate an image
in a PC using Matlab.
Going back to the data bits transfer over RS232, I found the comment
bellow interesting for what I'm trying to achieve.  Does it mean that I
could output in hyperterminal the corresponding grayscale values (0 to 255)
corresponding to the pixel data values stored in the fpga memory?  
If that is the case, I think that I would need to define a state machine
that drives a UART that somehow transmit all values stored in fpga memory
continuously, once data is transferred I could copy and paste those values
into a bit file that I can open in Matlab.
Thanks,

   
 

>If RS232 will handle your data rate that will certainly be a lot
>simpler to get running.  The hardest part may be creating some sense
>of packets or structure to your data so that you can identify the
>start of each picture.  If you can reserve one byte value for a start
>and make that illegal in the data, that may be the simplest -
>otherwise you end up looking at either a time-based framing (hard from
>a PC software perspective), escaping your start code, or something
>that I pulled once - since data rate wasn't critical, I had the FPGA
>send a hexadecimal representation in ASCII (2x overhead vs binary) and
>then defined some start and stop characters.  Making the data human
>readable in a terminal program was an added benefit!

On Nov 9, 8:39=A0pm, "wluiscam" <wluis...@gmail.com> wrote:
> Thanks very much to everyone who took the time to respond.
> As of right now, data rate and size is not critical. =A0I'm storing pixel
> data from a line scan CCD in 8 bit grayscale. =A0So, if I can send so man=
y
> lines of data over serial interface, I should be able to generate an imag=
e
> in a PC using Matlab.
> Going back to the data bits transfer over RS232, I found the comment
> bellow interesting for what I'm trying to achieve. =A0Does it mean that I
> could output in hyperterminal the corresponding grayscale values (0 to 25=
5)
> corresponding to the pixel data values stored in the fpga memory? =A0
> If that is the case, I think that I would need to define a state machine
> that drives a UART that somehow transmit all values stored in fpga memory
> continuously, once data is transferred I could copy and paste those value=
s
> into a bit file that I can open in Matlab.
> Thanks,
>
> >If RS232 will handle your data rate that will certainly be a lot
> >simpler to get running. =A0The hardest part may be creating some sense
> >of packets or structure to your data so that you can identify the
> >start of each picture. =A0If you can reserve one byte value for a start
> >and make that illegal in the data, that may be the simplest -
> >otherwise you end up looking at either a time-based framing (hard from
> >a PC software perspective), escaping your start code, or something
> >that I pulled once - since data rate wasn't critical, I had the FPGA
> >send a hexadecimal representation in ASCII (2x overhead vs binary) and
> >then defined some start and stop characters. =A0Making the data human
> >readable in a terminal program was an added benefit!

Yes, that's a simple and straightforward way to go about it. To keep
things simple, you don't strictly need a UART on the FPGA side, just
choose a baud rate and fire away. Get a MAX232/MAX3232 for level
shifting and you'll be set in terms of hardware.