WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2015-Dec-16 01:49:39

crimechb
Member
Registered: 2010-Sep-01
Posts: 205

About viterbi decoder source code

Dear Sir,

Do you have any documentation for the viterbi decoder?

vb_decoder_top.v
vb_decoder_rest.v

Best Regards,
Paul

Offline

 

#2 2015-Dec-16 09:32:37

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: About viterbi decoder source code

Unfortunately we don't have any additional documentation for these files.

Offline

 

#3 2015-Dec-16 19:26:53

crimechb
Member
Registered: 2010-Sep-01
Posts: 205

Re: About viterbi decoder source code

Dear murphpo,

Thanks for your help.
We still have some questions and please help us ,thanks.

1.In signal decode block ,Why add 4 (Ufix_3_0) to last_bytes_ind output ?
https://www.dropbox.com/s/pnyu8uu50jr17 … 1.png?dl=0


2.In decoder's ctrl block ,Why the signal bytes subtract 2 bits?
Why add 14 bits before the vin out?
https://www.dropbox.com/s/88k1kzw9wzs4v … 2.png?dl=0

Best Regards,
Paul

Offline

 

#4 2015-Dec-16 20:25:01

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: About viterbi decoder source code

1.In signal decode block ,Why add 4 (Ufix_3_0) to last_bytes_ind output ?

The SIGNAL.LENGTH field specifies the number of bytes in the MAC payload. This payload starts with the MAC header and runs through the checksum. But the actual PHY packet contains a 5-byte header (3 bytes for SIGNAL, 2 bytes for SERVICE) plus the MAC payload. That LENGTH+4 operation calculates the index of the total number of bytes in the packet. It is +4 instead of +5 because the byte index starts at 0.


2.In decoder's ctrl block ,Why the signal bytes subtract 2 bits?

The early_trace input to the decoder triggers a traceback earlier than normal. For actual payload the decoder gathers enough coded bits to run a full-length traceback (42 bits, I think, but am not positive). But when decoding the SIGNAL field the PHY must decode the RATE/LENGTH fields very quickly in order to begin processing the data symbols immediately after the SIGNAL field. The early_trace signal causes the decoder to use the small number of bits it already has (i.e. the coded SIGNAL field) to start the first traceback. The decoder logic requires the early_trace signal to assert in the same clock cycle as the final bits that will be included in the early trace. The SIGNAL field is 24 bits (3 bytes). The early trace logic asserts after bit[22] is written so that it is high when bit[23] (the last bit of the SIGNAL field) is written.

Why add 14 bits before the vin out?

Hmm. I don't recall. I'll figure this out and update tomorrow.

Also, based on these screenshots you're using an old version of the PHY. Please consider upgrading to the latest version of the 802.11 Reference Design. v1.3 has some important fixes/features. v1.4 (coming this week) has additional improvements.

Offline

 

#5 2015-Dec-28 02:13:44

crimechb
Member
Registered: 2010-Sep-01
Posts: 205

Re: About viterbi decoder source code

Dear Sir,

Please see link below:

https://www.dropbox.com/s/lv20r5fthund6 … 1.png?dl=0

Do you have any introduction/info about those numbers.  (Red frame)

Best Regards,
Paul

Last edited by crimechb (2015-Dec-28 02:16:39)

Offline

 

#6 2015-Dec-28 05:14:42

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: About viterbi decoder source code

The purpose of this subsystem is to generate addresses for the packet buffer and to define which bits correspond to which part of the packet payload.

The payload in each packet consists of:
SIGNAL - 24 bits
SERVICE - 16 bits (always 0)
DATA - Arbitrary length
FCS - 32 bits
TAIL - 6 bits (always 0)
PAD - Enough bits (possibly none) to fill last OFDM symbol (always 0)

Refer to IEEE 802.11-2012 section 18.3.2.1 for more info on this packet format.

The Tx packet buffer contains the SIGNAL, SERVICE and DATA bytes.

SIGNAL is tx_pkt_buf[2:0]
SERVICE is tx_pkt_buf[5:4]
DATA starts at tx_pkt_buf[8]

The bytes in between ([3], [7:6]) are reserved and ignored by the Tx PHY. These offsets simplify the byte indexing in the MAC code.

The 'Addr Gen' subsystem generates a bit index for the Tx packet buffer for each bit in the payload described above. These bit indexes must skip over the reserved bytes in the packet buffer. The bit indexes are generated by the Accumulator. The accumulator usually increments by 1 bit, but jumps by 9 or 17 when transitioning from the SIGNAL->SERVICE and SERVICE->DATA fields.

The SIGNAL_LENGTH field defines the number of bytes in the DATA+FCS fields. (SIGNAL_LENGTH - 4) computes the byte index where the FCS starts.

Offline

 

#7 2016-Jan-14 19:55:59

crimechb
Member
Registered: 2010-Sep-01
Posts: 205

Re: About viterbi decoder source code

Dear Sir,

802.11a/g ,the FFT are 64 points and sub-carrier are 48 datas and 4pilot.
If we would like to change FFT 64 points to 256 points.(sub-carrier are 192 data and 8 pilots)
Do I need to change the parameter of viterbi decoder?

https://www.dropbox.com/s/r8f93npx4oadr … 1.png?dl=0


As here (because the first signal packet only 24bits, if using 256 points and 192  subcarrier, pad's bit number will be increase)

parameter               BITM = 48 ;
parameter               BITM_EARLY = 24 ;
parameter               BITN = 8 ;
parameter               LW = 7 ;

https://www.dropbox.com/s/wi2sguivhhp4e … 2.png?dl=0

Best Regards,
Paul

Offline

 

#8 2016-Jan-15 13:41:35

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: About viterbi decoder source code

Changing the number of subcarriers will require many changes to the Tx and Rx PHY designs. For example, the interleaver and de-interleaver designs operate on all the bits in one OFDM symbol. If the number of subcarriers changes, the number of bits changes, requiring new interelaving/de-interelaving vectors.

The decoder doesn't care how many bits are in an OFDM symbol. The decoder operates on a stream of coded bits, outputting decoded bits (as bytes). The only exception to this is the "early_trace" control, which is used to trigger an early decoding of the first 24 data bits. In the ref design these 24 bits come from the SIGNAL field, contained in the first data-bearing OFDM symbol. If you change the number of subcarriers, you will need to redefine the SIGNAL field, or possibly design the first OFDM symbol to only carry 24 data bits.

Offline

 

#9 2016-Jan-20 20:01:01

crimechb
Member
Registered: 2010-Sep-01
Posts: 205

Re: About viterbi decoder source code

Dear Sir,

About rx decoder block(tx using bpsk & code rate 1/2)
After decoder and 2 FFT signals are not output signals. Is it correct?

https://www.dropbox.com/s/luopzmqo119nv … 3.png?dl=0

Best Regards,
Paul

Offline

 

#10 2016-Jan-20 21:00:52

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: About viterbi decoder source code

That is the expected behavior. The decoder operates with a finite traceback length (42 bits, if I recall correctly). The first OFDM symbol triggers an early traceback (the first burst of VOUT) so the SIGNAL rate/length fields can be decoded. For the following OFDM symbols, the decoder waits until enough coded bits have arrived to begin outputting decoded bits.

Offline

 

#11 2016-Jan-21 06:31:23

crimechb
Member
Registered: 2010-Sep-01
Posts: 205

Re: About viterbi decoder source code

Dear murphpo,

The 24 bits of signal and 16 bits of service are all in first packet.
The first packet has 64 bits FFT signals, in accordance with the above, the remaining 24 bits are all zero and 16 bits of service will be ignored due to early trace?

Best Regards,
Paul

Offline

 

#12 2016-Jan-21 08:41:31

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: About viterbi decoder source code

The first OFDM symbol contains only the SIGNAL field. The OFDM symbol has 48 data-bearing subcarriers. Each subcarrier carries 1 BPSK symbol, representing 1 coded data bit. The 48 coded bits are decoded by the early trace to produce the 24-bit SIGNAL field. The SERVICE field (always 0x0000) is the first 2 bytes of the payload and is contained in the second OFDM symbol. The SERVICE field is modulated at the same rate as the DATA field. The SERVICE field is used to initialize the descrambler. Since only the DATA field is scrambled, it is not necessary to decode the SERVICE field early.

Offline

 

Board footer