[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Re: USB FIFO

From: Thibaud Hottelier
Subject: [Discuss-gnuradio] Re: USB FIFO
Date: Thu, 29 Mar 2007 10:56:09 -0400
User-agent: Thunderbird 2.0b2 (X11/20070319)

I CC'd the list, so Eric can participate to this discussion.

Brian Padalino wrote:
On 3/28/07, Thibaud Hottelier <address@hidden> wrote:
I noticed two things:

The fifo does not need to be dual clock because we only use it for the

The FX2 directly toggles the writing side, and the 64MHz clock will be
on the reading side.  This should require two clocks.

Yes but the only dual clock fifo is tx_usb_fifo, right? For this one we can use the Altera dual clock fifo. The only fifos that need the skip command are the tx_chan_fifo_X. I'm confused...

We need to be able to skip any amount of data as the packet is not fixed
size since the padding has been removed in the USB block. So we needs
one more input to the fifo for that; we cannot reuse write_data because
some other process might use it to fill in the fifo.

Because we are crossing clock domains, it will be difficult to figure
out if the FIFO is full, empty, etc.  It's easier to just keep all 512
bytes going back and forth.  It also doesn't change the way the
current FX2 code actually works - so less components will have to be

After you had asked before if the FPGA or FX2 strips the packet, I
think the FPGA should do it as per the aforementioned reason.  What do
you think?  Do you think the FPGA should strip it off, or do you think
the FX2 should do it?

I think that for now we should remove the padding in the FPGA, because it's easier. When everything will be working, then we can optimize it, if that can bring some substantial benefits, and remove the padding in the FX2.

On the other hand, it should be observed that we will have the same
clock for the command and channel FIFOs - which makes the entire
problem much easier since everything is synchronous on a single clock
instead of multiple clocks.

Is that all right? If yes, I will implements these modification tomorrow
and try to make a branch in svn so we can easily share code.

It could use a header file and a better testbench.  Making a branch
should be easy, but I am not an svn contributor yet since I haven't
received anything from the FSF yet.

Me neither. But we can create a branch, so we don't taint the GnuRadio code and we will merge once the legal issues will be solved.

I am wondering if we need some special code to tell the synthesizer to
use the M4K blocks and not the regular block for the fifo memory.

For the USB block, it isn't a problem - the synthesis tool should
actually infer the block RAM.  As for the dual port RAM with different
widths, that will require a primitive to be used which will make it
Altera specific.


If you have any other questions, you can feel free to ask.  I really
think a better file based or more procedural based testbench would be
nice.  We could then simulate the entire system which would be pretty

Yes, that would be great. And writing testing block is a good training for me.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]