[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] problem with start/end of burst inband FPGA code
From: |
Jeff Brower |
Subject: |
Re: [Discuss-gnuradio] problem with start/end of burst inband FPGA code |
Date: |
Wed, 01 Aug 2007 16:25:08 -0500 |
George-
> We'd greatly appreciate any help, thanks!
I started to take a look at your Verilog code and see if I could find
something, then
stopped. Can you repost it with correct indent/alignment? It's hard to read
when
you've got something like this:
if (fifodata[`STARTOFBURST] == 1
&& fifodata[`ENDOFBURST] == 1)
burst <= 0;
else if (fifodata[`STARTOFBURST] == 1)
burst <= 1;
else if (fifodata[`ENDOFBURST] == 1)
burst <= 0;
//Check trash
if (trash == 1 && fifodata[`STARTOFBURST]
== 0)
begin
trash <= 1;
skip <= 1;
reader_state <= IDLE;
end
else
begin
payload_len <= fifodata[`PAYLOAD] ;
read_len <= 0;
reader_state <= TIMESTAMP;
rdreq <= 1;
end
end
which should be:
if (fifodata[`STARTOFBURST] == 1 && fifodata[`ENDOFBURST]
== 1)
burst <= 0;
else if (fifodata[`STARTOFBURST] == 1)
burst <= 1;
else if (fifodata[`ENDOFBURST] == 1)
burst <= 0;
//Check trash
if (trash == 1 && fifodata[`STARTOFBURST] == 0)
begin
trash <= 1;
skip <= 1;
reader_state <= IDLE;
end
else
begin
payload_len <= fifodata[`PAYLOAD] ;
read_len <= 0;
reader_state <= TIMESTAMP;
rdreq <= 1;
end
Maybe one of your guys is using tabs and another isn't, or something like that.
If
so it might help to establish some basic source code rules for a multi-person
project.
-Jeff
George Nychis wrote:
>
> Hey all,
>
> We're looking for someone to look over our shoulder on an inband FPGA
> problem we've been stuck on for a couple days now.
>
> The problem is that we never had code that throws out additional packets
> in a burst if the initial packet had a timestamp that expired. When an
> m-block message is fragmented into multiple USB packets, the packets are
> considered a single burst, where the first packet has the start of burst
> flag set and the last packet has the end of burst flag set. The first
> packet has the timestamp set to the desired timestamp, and each
> additional packet in the burst is given the 'NOW' timestamp.
>
> The problem was that our code would throw away the first packet if the
> timestamp expired, but the additional packets in the burst had a
> timestamp of 'NOW' so they would be sent... but they shouldn't be since
> they are part of an 'expired' burst.
>
> Ok, so on to the code:
> http://gnuradio.org/trac/browser/gnuradio/branches/developers/zhuochen/burst/usrp/fpga/inband_lib/chan_fifo_reader.v
>
> The logic needs to be "if the packet with the start of burst flag was
> thrown away, throw away all packets until we see the end of burst flag."
>
> If we see the start of burst flag, we set 'burst' to be 1.
> http://gnuradio.org/trac/browser/gnuradio/branches/developers/zhuochen/burst/usrp/fpga/inband_lib/chan_fifo_reader.v#L97
>
> If the timestamp has expired on the packet, set 'trash' to 1, and 'skip'
> set to 1:
> http://gnuradio.org/trac/browser/gnuradio/branches/developers/zhuochen/burst/usrp/fpga/inband_lib/chan_fifo_reader.v#L148
>
> Finally, if we get a packet that does not have start of burst set, it
> *must* be an intermediate packet or the last packet in a burst... either
> way it does not matter. If 'trash' is set to 1, we want to skip it:
> http://gnuradio.org/trac/browser/gnuradio/branches/developers/zhuochen/burst/usrp/fpga/inband_lib/chan_fifo_reader.v#L106
>
> If we see the end of burst flag, 'burst' is reset:
> http://gnuradio.org/trac/browser/gnuradio/branches/developers/zhuochen/burst/usrp/fpga/inband_lib/chan_fifo_reader.v#L102
>
> If the next packet has a correct timestamp, we set trash back to 0. We
> could just set trash to 0 when end of burst is read, but it doesn't
> really matter:
> http://gnuradio.org/trac/browser/gnuradio/branches/developers/zhuochen/burst/usrp/fpga/inband_lib/chan_fifo_reader.v#L137
>
> So... as you can guess, this doesn't work. This hasn't been our only
> attempt. We've trashed the code and re-written it a couple different
> times with no success.
>
> To test this we've been setting all packets to have a timestamp of 0.
> This means we should get no sine wave on an oscope when transmitting,
> regardless of the number of packet sin the burst. However, we see
> chunks of the wave here and there when the number of packets in the
> burst is greater than 1. If we set it so that a single m-block message
> only creates 1 USB packet, it works... everything is thrown away.
>
> We'd greatly appreciate any help, thanks!
>
> - George, Leo