Prev: Altera LP6 Logic Programming Card - Supplier
Next: XUPV5-LX110T, DDR2, and EDK (10.1 to be precise)
From: Kolja Sulimma on 16 Dec 2009 03:57
On 14 Dez., 23:58, "dlopez" <d...(a)designgame.ca> wrote:

>
> Now I only saw problems and corner cases with this approach. The PC, which
> is sending the data and commands, does not have easy visibility on the FPGA
> FIFO, so it doesn't really know the right mix of data/command to send.

I think you did not understand what I meant.
What you are talking about is having control and data in one stream.
This gives you
all the potential problems you describe.
I was talking about splitting the FIFO on a cycle by cycle basis and
wasting half of the
bandwidth of the fifo to tell the FPGA what stream a byte belongs to
by packing bytes
into 16 bit words.
Do the math: Half of 60MB/s is still more than the 25MB you get from
the async FIFO.
The handling of the streams should be implemented in the USB chips
firmware.
The PC should not need to know about this.


> Then one command,
> somewhere between my C# code and the FPGA, might get stuck in the pipeline
> since the FPGA won't grab more data from the USB chip.

In this approach the FPGA should allways empty the USB chip FIFO.There
is nothing
to loose because it does not matter which FIFO overflows if the sink
is stuck.
I believe that in this case the packet approach that you suggested is
save and it has even more
performance.

Kolja Sulimma
First  |  Prev  | 
Pages: 1 2 3
Prev: Altera LP6 Logic Programming Card - Supplier
Next: XUPV5-LX110T, DDR2, and EDK (10.1 to be precise)