discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] packets to the usrp and loopback


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] packets to the usrp and loopback
Date: Mon, 23 Apr 2007 07:55:05 -0700
User-agent: Mutt/1.5.9i

On Mon, Apr 23, 2007 at 10:43:10AM -0400, Brian Padalino wrote:
> On 4/23/07, Thibaud Hottelier <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]