Packets to the usrp and loopback

I’m starting to work out some test code regarding the host end, and I
was wondering how
hard it will be when done testing to actually put a packet on the bus?
I assume we can
reuse some of the previous interface.

Question from Thibaud: is the loopback interface working on the USRP,
and how to enable it?

We want to test out using the loopback eventually, and overall I’m
wondering how much time
from when I finish the test code to putting a packet on the interface so
I can plan out
this week. :slight_smile:

  • George

On Thu, Apr 19, 2007 at 05:17:06PM -0400, George N. wrote:

I’m starting to work out some test code regarding the host end, and I was
wondering how hard it will be when done testing to actually put a packet on
the bus? I assume we can reuse some of the previous interface.

Not very hard.

Question from Thibaud: is the loopback interface working on the USRP, and
how to enable it?

There is a loopback interface in the current FPGA code. It’s enabled
by writing to the FR_MODE register. Grep the verilog for “loopback”,
and look at fpga_regs_common.{h,v}

We want to test out using the loopback eventually, and overall I’m
wondering how much time from when I finish the test code to putting a
packet on the interface so I can plan out this week. :slight_smile:

I don’t know. When will you have the rest of the host code written?

I suggest that you treat this like it’s “your project”, not “Eric’s
project”. I’m available to answer questions, respond to requests,
etc., but don’t assume that the cavalry is coming :wink:

What’s your next step?

I’m working on mblock timeouts :wink:

Eric

Eric B. wrote:

Not very hard.
Awesome.

There is a loopback interface in the current FPGA code. It’s enabled
by writing to the FR_MODE register. Grep the verilog for “loopback”,
and look at fpga_regs_common.{h,v}
Thanks :smiley:

We want to test out using the loopback eventually, and overall I’m
wondering how much time from when I finish the test code to putting a
packet on the interface so I can plan out this week. :slight_smile:

I don’t know. When will you have the rest of the host code written?

Ahh that wasn’t a question, it was me explaining my question. More like
“when i
finish the host code, since you know the interface to the USRP better
than me,
how long would it take me to interface to it?” Was asking so I can
gauge how
much time from when i finish the host code to actually putting them on
the USRP
so I can warn Thibaud to be ready.

I suggest that you treat this like it’s “your project”, not “Eric’s
project”. I’m available to answer questions, respond to requests,
etc., but don’t assume that the cavalry is coming :wink:

Of course, I think you just misunderstood my wording :smiley:

What’s your next step?

Writing up some test code for my host code, starting on that now.

I’m working on mblock timeouts :wink:

sweet

  • George

On 4/20/07, Thibaud H. [email protected] wrote:

Hi,

I moved all my small testing blocks from ModelSim to the Quartus source
tree. I am writing the glue code between the modules so we should have
the basic Tx functionality working relatively soon. But before that, I
would like to simulate to whole Tx block in ModelSim, so I need some
information about how the tx_chains work.

There should be absolutely no glue logic between the modules within a
top entity possibly called mblock_processing. The inputs should feed
the specialized USB FIFOs, and the outputs should feed the separate
CIC channel filters (complex).

Everything else from there should be straight forward with strobing
samples in and out.

A what rate should I send the samples to the tx_chains? Every 4 clock
cycles? They seems to be controlled by tx_strobe, but I failed to
understand what this signal actually mean.

The minimum interpolation rate is 4 due to the CIC filter limitations,
so once every 4 will yield one side of the spectrum. I believe 128 is
the other end of the spectrum, but you should set a constant for the
rate so we can test with different ones.

The tx_strobe happens once every rate clock cycles - with which it
will send in a new sample. That strobe sends a new value down the TX
stream and reads a new one ready for the next tx_strobe.

What is the point of the bus_reset and the clear_status signal? They are
both input to current tx_buffer.

I am not sure of this - but I am assuming to stop/reset the transmit
path and clear any status messages respectively. :slight_smile: I’ll try to have
a look at the code and find out more later.

As we report overrun/underrun in packet header, are we gonna get rid of
the tx_empty, have_space and tx_underrun signal ?

have_space is used by the feeding FX2 to know if the FPGA can handle
one more packet. This signal shouldn’t go anywhere. The other
signals should probably stick around for now.

Comments on the code I checked in are welcome…

I’ll look it over this weekend and give comments and feedback.

Brian

Hi,

I moved all my small testing blocks from ModelSim to the Quartus source
tree. I am writing the glue code between the modules so we should have
the basic Tx functionality working relatively soon. But before that, I
would like to simulate to whole Tx block in ModelSim, so I need some
information about how the tx_chains work.

A what rate should I send the samples to the tx_chains? Every 4 clock
cycles? They seems to be controlled by tx_strobe, but I failed to
understand what this signal actually mean.

What is the point of the bus_reset and the clear_status signal? They are
both input to current tx_buffer.

As we report overrun/underrun in packet header, are we gonna get rid of
the tx_empty, have_space and tx_underrun signal ?

Comments on the code I checked in are welcome…

Thibaud

Brian P. wrote:

There should be absolutely no glue logic between the modules within a
top entity possibly called mblock_processing. The inputs should feed
the specialized USB FIFOs, and the outputs should feed the separate
CIC channel filters (complex).

Everything else from there should be straight forward with strobing
samples in and out.

Yes, that’s what I wanted to say :slight_smile:

A what rate should I send the samples to the tx_chains? Every 4
clock

cycles? They seems to be controlled by tx_strobe, but I failed to
understand what this signal actually mean.

The minimum interpolation rate is 4 due to the CIC filter
limitations,
so once every 4 will yield one side of the spectrum. I believe 128
is
the other end of the spectrum, but you should set a constant for the
rate so we can test with different ones.

Ok, so my usb_chan_reader needs some more work to handle that. I will
try to get this and some of the missing functionalities like reporting
overrun/underrun done tomorrow.

The tx_strobe happens once every rate clock cycles - with which it
will send in a new sample. That strobe sends a new value down the TX
stream and reads a new one ready for the next tx_strobe.

What is the point of the bus_reset and the clear_status signal? They
are

both input to current tx_buffer.

I am not sure of this - but I am assuming to stop/reset the transmit
path and clear any status messages respectively. :slight_smile: I’ll try to have
a look at the code and find out more later.

Thanks.

As we report overrun/underrun in packet header, are we gonna get rid
of

the tx_empty, have_space and tx_underrun signal ?

have_space is used by the feeding FX2 to know if the FPGA can handle
one more packet. This signal shouldn’t go anywhere. The other
signals should probably stick around for now.

Comments on the code I checked in are welcome…

I’ll look it over this weekend and give comments and feedback.

That would be awesome :slight_smile:

Brian

Thibaud

Brian P. wrote:

I am not sure this is where the tx_strobe is supposed to occur. I
think it’s in whatever reads your individual channel FIFOs and feeds
the CIC filters (unless usb_chan_reader is the module, and is just
named very strangely).

Yes, it’s this module. Any suggestion for a better name?

Basically wherever you do the compare to the current_time count to
figure out if the sample stream should start or not is where you need
to figure out the tx_strobing stuff. I think we should have a strobe
for each complex channel, that way we can treat them independently
from each other on when they start sending data.

What do you think of this idea?

I have not really understood this strobing thing. From the current
tx_buffer code, I understood that I can independently feed one sample
per channel between each strobe. But you just said they were not
independent so I am confused…

Brian

Thibaud

On Fri, Apr 20, 2007 at 05:17:36PM -0400, Brian P. wrote:

On 4/20/07, Thibaud H. [email protected] wrote:

Ok, so my usb_chan_reader needs some more work to handle that. I will
try to get this and some of the missing functionalities like reporting
overrun/underrun done tomorrow.

I am not sure this is where the tx_strobe is supposed to occur. I
think it’s in whatever reads your individual channel FIFOs and feeds
the CIC filters (unless usb_chan_reader is the module, and is just
named very strangely).

It’s currently generated in master_control.v and is a function of the
value in FR_INTERP_RATE.

Basically wherever you do the compare to the current_time count to
figure out if the sample stream should start or not is where you need
to figure out the tx_strobing stuff. I think we should have a strobe
for each complex channel, that way we can treat them independently
from each other on when they start sending data.

I concur. Separate strobes per channel.

Eric

On 4/20/07, Thibaud H. [email protected] wrote:

Ok, so my usb_chan_reader needs some more work to handle that. I will
try to get this and some of the missing functionalities like reporting
overrun/underrun done tomorrow.

I am not sure this is where the tx_strobe is supposed to occur. I
think it’s in whatever reads your individual channel FIFOs and feeds
the CIC filters (unless usb_chan_reader is the module, and is just
named very strangely).

Basically wherever you do the compare to the current_time count to
figure out if the sample stream should start or not is where you need
to figure out the tx_strobing stuff. I think we should have a strobe
for each complex channel, that way we can treat them independently
from each other on when they start sending data.

What do you think of this idea?

Brian

Eric,

Could you check over the Makefile.am and just base template that I
checked in to my
developer branch to make sure I am not missing anything? I checked that
it successfully
builds, but I just want to make sure I’m not missing anything major
before beginning to
write tests.

Also, is there a way to run only a single test? That way I can just run
my inband test
instead of waiting for all of the tests.

Thanks!
George

On Fri, Apr 20, 2007 at 07:09:19PM -0400, George N. wrote:

Eric,

Could you check over the Makefile.am and just base template that I checked
in to my developer branch to make sure I am not missing anything? I
checked that it successfully builds, but I just want to make sure I’m not
missing anything major before beginning to write tests.

Looks good to me.

Also, is there a way to run only a single test? That way I can just run my
inband test instead of waiting for all of the tests.

You can run “make check” in the lib directory (that is, one up from
inband.)

Eric

separate.
Ok, I move the FIFOs outside next time I refactor this.

bandwidth and rates of each of the complex channels. This allows for
all sorts of interesting and different schemes to work.

Does that make sense?

Yes, it makes much more sense. In the current design, the strobes are
generated by a separated block; would it be more logical to make the
strobes be generated by the tx_chan_fifo_reader, so they are generated
only when needed (i.e. when there are samples to feed into the transmit
chain)?

Brian

Thibaud

On 4/21/07, Thibaud H. [email protected] wrote:

Ok, I move the FIFOs outside next time I refactor this.

Perfect.

Yes, it makes much more sense. In the current design, the strobes are
generated by a separated block; would it be more logical to make the
strobes be generated by the tx_chan_fifo_reader, so they are generated
only when needed (i.e. when there are samples to feed into the transmit
chain)?

Yes - please. Because each channel is completely separate from each
other channel, we want to be able to start sending a packet through
the chain at any arbitrary time rather than start all of them at the
same time.

Moving the tx_strobe from the outer module into the
tx_chan_fifo_reader is a good idea - and for the future, we may even
want to be able to have different interpolation rates for each of the
channels - so the rate value should be fed into the tx_chan_fifo.
Later, we can make more registers for the different channel
interpolation rates.

Brian

Brian P. wrote:

I have just refactored the code so that the fifos are out of the
readers. I also added samples format handling (only 16 bits interleaved
complex so far). I am looking forward to testing this; George told me he
will be able to send usb packets on Tuesday.

want to be able to have different interpolation rates for each of the
channels - so the rate value should be fed into the tx_chan_fifo.
Later, we can make more registers for the different channel
interpolation rates.

To do that I will need to modify the master_control block, so I will
make new master_control_inband. The strobe generators are cascaded in
there, what’s the point of this setup?

have_space, tx_empty and tx_underrun are no longer relevant, but they
are still used by the FX2, right? Can I just force them to (true, false,
false) all the time?

Brian

Thibaud

On 4/22/07, Thibaud H. [email protected] wrote:

Brian P. wrote:

I have just refactored the code so that the fifos are out of the
readers. I also added samples format handling (only 16 bits interleaved
complex so far). I am looking forward to testing this; George told me he
will be able to send usb packets on Tuesday.

Sounds fun. Are you sure you’re ready for a live test?

To do that I will need to modify the master_control block, so I will
make new master_control_inband. The strobe generators are cascaded in
there, what’s the point of this setup?

You don’t need to do this. Just don’t connect up the tx_strobe -
doesn’t that solve the problem? You shouldn’t necessarily have to
make a master_control_inband - just feed the rate register into the
module and generate it yourself.

have_space, tx_empty and tx_underrun are no longer relevant, but they
are still used by the FX2, right? Can I just force them to (true, false,
false) all the time?

I don’t necessarily understand why those pins, especially the
have_space pin, are no longer relevant. Could you explain this
please?

Brian

On 4/20/07, Thibaud H. [email protected] wrote:

Yes, it’s this module. Any suggestion for a better name?

According to your diagram here:
http://gnuradio.org/trac/wiki/UsrpTxModifications

Maybe we should have a tx_usb_fifo, tx_usb_fifo_reader, tx_chan_fifo,
tx_chan_fifo reader, tx_cmd_fifo_reader (the tx_chan_fifo and
tx_cmd_fifo are essentially the same thing, but the tx_cmd_fifo_reader
should figure out I2C, SPI, and other settings that may go down the
command FIFO).

Putting all of this within an mblock_processing module would be nice.

A potential hierarchy:

  • mblock_processing
    • tx_usb_fifo
    • tx_usb_fifo_reader
    • tx_chan_fifo
    • tx_chan_fifo_reader
    • tx_cmd_fifo_reader

You currently have it where the FIFOs are sitting inside of the
readers, which I could be OK with - but would prefer if the FIFOs were
separate.

Since we’re just talking data and no command yet, I’ll limit it to
that, but we should be aware of all the things the tx_cmd_fifo_reader
should be able to parse and do. Specifically, everything listed here:
http://gnuradio.org/trac/browser/gnuradio/branches/features/inband-usb/usrp/doc/inband-signaling-usb

I have not really understood this strobing thing. From the current
tx_buffer code, I understood that I can independently feed one sample
per channel between each strobe. But you just said they were not
independent so I am confused…

On the input side of the interpolating CIC filter, we input samples at
a rate of 1/rate. On the output side of the interpolating CIC filter,
samples come out every clock cycle. It’s just the rate at which the
samples are supposed to be fed into the interpolating CIC filters to
get upconverted.

In the current design, everything is set to a single interpolation
rate and a single decimation rate for all TX or RX channels. In the
mblock design, we want to be able to independently control the
bandwidth and rates of each of the complex channels. This allows for
all sorts of interesting and different schemes to work.

Does that make sense?

Brian

Brian P. wrote:

Sounds fun. Are you sure you’re ready for a live test?

I don’t know :slight_smile: What kind of problem should I expect when trying to go
from simulation to reality ?

You don’t need to do this. Just don’t connect up the tx_strobe -
doesn’t that solve the problem? You shouldn’t necessarily have to
make a master_control_inband - just feed the rate register into the
module and generate it yourself.

Yes it solves the problem, and is much simpler. I will do that.

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… :slight_smile:

Brian

Thibaud

Brian P. wrote:

On 4/22/07, Thibaud H. [email protected] wrote:

Brian P. wrote:

I have just refactored the code so that the fifos are out of the
readers. I also added samples format handling (only 16 bits interleaved
complex so far). I am looking forward to testing this; George told me he
will be able to send usb packets on Tuesday.

Sounds fun. Are you sure you’re ready for a live test?

Hopefully! I’m writing some test code for the usrp server that I hope
to finish
tonight, then I can start trying to figure out how to put the packets on
the
bus, but based on Erics response it shouldn’t take too long. So maybe
Tuesday
or Wednesday. A live test can’t hurt :slight_smile:

  • George

On 4/23/07, Thibaud H. [email protected] wrote:

I don’t know :slight_smile: 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.

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… :slight_smile:

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

Brian

On Mon, Apr 23, 2007 at 10:43:10AM -0400, Brian P. wrote:

On 4/23/07, Thibaud H. [email protected] wrote:

I don’t know :slight_smile: 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 :wink:

you should be able to view the complex waves.
Sounds good. Changing less things decreases our chances of completely

guess I am wrong… :slight_smile:
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