On 4/23/07, Thibaud H. email@example.com 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
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
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.
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