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 <[EMAIL PROTECTED]> 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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
