On Mon, Apr 23, 2007 at 10:43:10AM -0400, Brian Padalino wrote: > On 4/23/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote: > >I don't know :) What kind of problem should I expect when trying to go > >from simulation to reality ? > > I'd run more simulations where there are a massive number of packets > waiting to be sent, schedule things too close to each other, make the > entire thing error out. You really want to test every aspect of the > code that you can. Make things happen that seem impossible. Make > things happen that you think will have a specific outcome and verify > it works.
That sounds like the voice of experience ;) > You should have a testbench that pretends it's an FX2 and is trying to > write these packets into the FPGA. From the FX2's perspective, the > FPGA is just a set of RX and TX FIFOs. > > I would write a testbench that would read data packets from a file. > Maybe output some complex waves at 2 different frequencies within > these packets? Talk with George to maybe setup a file sink attached > to the message block components to get the packets that would go over > USB. Capture a few hundred of them and then use your testbench to > write the values into your system. On the output of your simulation, > you should be able to view the complex waves. > > Do you guys think you'll be able to do that? > > In ModelSim, if you add the I and Q signals to the Wave window, you > can right-click on them, change their radix to decimal and change > their type to Analog. There is a scale factor associated with it, but > you can always just fiddle with that to make it look nice. > > >Yes it solves the problem, and is much simpler. I will do that. > > Sounds good. Changing less things decreases our chances of completely > breaking the entire system. > > >> > >> > >> I don't necessarily understand why those pins, especially the > >> have_space pin, are no longer relevant. Could you explain this > >> please? > > > >I though that because we report all these informations to host in the > >header of the packets I don't need to use those signals anymore, but I > >guess I am wrong... :) > > The have_space pin is used by the FX2 to know if the FPGA FIFO can > store AT LEAST one more packet. This signal is pretty much required > as you don't have FIFOs with infinite depth. > > As for the tx_empty and tx_underrun - those should still be there, > otherwise how are you going to know when those things happen? Just > because they're being sent up through the message header doesn't mean > they get created out of thin air. > > I think the consensus was to OR all the tx_underruns from all the > channels to one pin that would represent that an underrun occured - > not necessarily worry about where it occured. > > I am not sure about tx_empty - that may be required to start stuffing > 0's to flush the TX pipe, control automatic TX/RX switching, ramping > up/down the output RF power, etc. It's probably still important to > other functions - not necessarily the inband stuff. Correct. > When it comes to this sort of stuff, it is always nicer to be able to > have too much information and just not connect those wires than have > too little information and try to wing it. > > I hope this all helps you guys out. You're both doing a bang up job so far. > > Brian Brian, thanks for all your input. George and Thibaud, I think you need to think about how you're going to test the live combination of the host + FPGA a bit. How are you going to know if it's working? What kind of a test can you design that gives you a repeatable "yes" / "no" result? Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
