Re: [Discuss-gnuradio] Re: USB FIFO

[Eric Blossom]

On Thu, Mar 29, 2007 at 10:56:09AM -0400, Thibaud Hottelier wrote:
> I CC'd the list, so Eric can participate to this discussion.

Thanks.

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

The FX2 definitely shouldn't strip the padding.  That'll be dog slow.

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

Thibaud and George, you guys are set up as committers.
Brian, I'll get you set up later today.

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

Please create a developer branch for yourself by copying
http://gnuradio.org/svn/gnuradio/branches/features/inband-usb
to a branch name of your choosing under
http://gnuradio.org/svn/gnuradio/branches/developers/thottelt

E.g.,

  $ svn cp http://gnuradio.org/svn/gnuradio/branches/features/inband-usb \
           http://gnuradio.org/svn/gnuradio/branches/developers/thottelt/inband


George and I will be working on the feature branch too.  That's where
I'll finish off the mblock development as well as work on the host
code for the inband signaling.

Just to ensure there's no misunderstanding, the idea is that the four
of us will each make developers branches by copying
features/inband-usb.  We'll merge our own changes into
features/inband-usb when we've got something that's stable (or at
least doesn't break anything).

If there's a need, I'll merge stuff from the trunk into the feature
branch, but I'd really like to avoid doing that.

When everything is working, I'll merge the feature branch into the
trunk and delete the feature branch.

Is this clear?  Any questions?

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

For the tx_usb_fifo and rx_usb_fifo, you can just tell Quartus to
generate the appropriate dual clock fifo "megacell" for you.  Matt did
that to generate the fifo_2k and fifo_4k blocks that we're currently
using.  See the Quartus manual and the "Cyclone Device Handbook" for
supported configurations.

Regarding "skip" for stripping padding on the rx_usb_fifo, I suggest
that you just handle it in your state machine.  You've got enough
cycles to do the work.  I think that'll be easier than trying to
reverse-engineer and modify the output of the megacell generator.
You could strip when writing or reading the rx_usb_fifo.  Not sure
which is better or easier.


For the *_chan_fifo_X's, I believe we will need to add the skip
function.  I see a couple of ways to do this.  Either (1) generate a
megacell for a simple dual-port mode mixed width fifo, and then look
at how it really built it, then modify, or (2) generate a megacell for
dual-port mixed width ram, and then build a module on top of that with
your own fifo control logic.  Both of these suggestions are "off the
cuff".  I haven't looked at the output of the megacell generator, so I
could be way off. YMMV.  

There's also an "endian" question with the mixed width ram.  I suggest
"little endian" so that stuff matches the format used in the spec and
across the USB.  I don't know if the megacell generator gives you a
choice.

Eric