[Discuss-gnuradio] Re: USB FIFO

[Thibaud Hottelier]

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
> > tx_chan_fifo_X.
>
> 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
> debugged.
>
> 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.

Ok.

> 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
> neat.

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

> Brian

Thibaud