open-sdr / openwifi-hw

open-source IEEE 802.11 WiFi baseband FPGA (chip) design: FPGA, hardware
GNU Affero General Public License v3.0
677 stars 233 forks source link

Simulation of 'openofdm_tx' and 'openofdm_rx'. #47

Closed kirateys closed 2 years ago

kirateys commented 2 years ago

Hello,

I am trying to simulate 2 projects separately, the 'openofdm_tx' and the 'openofdm_rx' modules in Vivado 2018.3. I wanted to run some tests for the legacy type packets. So I have a file that consists of a packet in the legacy format and I feed that to the 'openofdm_tx' project simulation. It captures the IQ data in: /openofdm_tx/openofdm_tx/openofdm_tx.sim/sim_1/behav/xsim/dot11_tx.txt I then take this IQ file and apply as an input to the 'openofdm_rx' module.

***ISSUE: for small legacy type packet, the entire packet including the CRC on the receive side on signal 'byte_out' in 'dot11.v' matches ('fcs_ok' pulse can be seen coming out) but, if I modify the data in the packet, the data part on the RX side matches but the last 4 Bytes of CRC on the 'byte_out' signal does not match (causing 'fcs_ok' to not come out).

  1. Our image is used directly or you build your own image? YES, your image is used directly.

  2. What is your own modification? Only the memory input files for the simulation.

  3. Versions: OS, Vivado, openwifi/openwifi-hw repo branch and commit revision UBUNTU 14.04 VIVADO 2018.3 Latest GitHub commit: 868aad30fe3cc1bee141fb21e2aa9a7cc51d8b12

  4. Board/hardware type 'ADRV9361-Z7035 + ADRV1CRR-BOB'

  5. WiFi channel number TX1A/RX1A

  6. Steps to reproduce the issue, and the related error message, screenshot, etc.

    WORKING PART:

    • In the 'openofdm_tx' project, copy the legacy packet (79 Bytes length) to the file 'tx_intf.mem' from: tx_legacy_pkt.txt
    • Run the simulation, check the 4 Bytes of CRC generated: 32'h10F11AA1 tx_orig_crc

Can you please help me understand why would this happen? What can be done to receive the correct data on the receive side in its entirety (including the CRC)? NOTE: In some cases for simulation, there are times where the last 4 Bytes of the CRC plus some (last 1 to 4) Bytes of the data does not match.

  1. Describe your debug efforts by Linux native tools, such as tcpdump and "cat /proc/interrupts"

  2. Describe your debug efforts by: https://github.com/open-sdr/openwifi/blob/master/doc/README.md#Debug-methods

  3. Any other thing we need to know for helping you better?

JiaoXianjun commented 2 years ago

What do you mean by "that is now modified, increased length to 304 Bytes randomly" ? Can you describe exactly how do you modify the tx_intf.mem to "increased length to 304 Bytes randomly"?

According to: https://www.candelatech.com/downloads/802.11-2016.pdf 17.3.2 PPDU format: When you extend the PSDU in tx_intf.mem, you should also change the LENGTH (12bit) field in the PHY header (also in tx_intf.mem), and possibly also the Parity (1bit) field in the PHY header.

kirateys commented 2 years ago

Hello @JiaoXianjun

Only the data field is a random data used for simulation. The PHY header follows the format as I modified the 12-bits length field: Originally it was 64'h0000_0000_0000_09EB length field bits [16:5] = 12'h04F = 79 Bytes

Now it is 64'h0000_0000_0000_260b length field bits [16:5] = 12'h130 = 304 Bytes

The parity bit is zero as there are even numbers of 1's in the field [16:0].

mmehari commented 2 years ago

Hello @lewiz-kiratey,

I have simulated (using the latest dot11zynq branch) the IQ samples you provided for the non-working part and I get a positive result (fcs=OK). simulation

Which branch and commit did you use for the openofdm_rx repo?

kirateys commented 2 years ago

Hello @mmehari

Thank you for your response. Yes, for you it seems to be working correctly. The 4-Bytes of CRC part is also correct.

I was working on the dot11zynq branch. Still, I re-tried to git clone it again today and here is the commit: f83d179cbe0496dd1db1c46c2ab8f737b668f07d and it still doesn't work for me for the IQ samples provided in the non-working part.

Can you please give me the steps you followed to make it work? Although, it should not affect the functioning, for the Vivado project, I tried it with both: 'openofdm_rx.tcl' and 'openofdm_rx_ultra_scale.tcl'.

Thanks

mmehari commented 2 years ago

You are also using the latest commit as I do and the only difference I see between the two of us is the OS version which in my case is UBUNTU 18.04.

I don't know why your system is behaving the way it is but you can do a bit of debugging by comparing your part with mine.

For doing that, find attached the VCD file of my simulation and download the file locally as the link expires within a week period. https://we.tl/t-Lqn4r5jHuq

You can use GTKWave to view the content. Mine looks the following image

JiaoXianjun commented 2 years ago

@lewiz-kiratey when you do simulation with https://github.com/open-sdr/openwifi-hw/files/7523173/dot11_tx_legacy_iq_mod.txt, you have changed the line in https://github.com/open-sdr/openofdm/blob/dot11zynq/verilog/dot11_tb.v:

`define SAMPLE_FILE "../../../../../testing_inputs/simulated/iq_11n_mcs7_gi0_100B_openwifi.txt"

to

`define SAMPLE_FILE "../../../../../testing_inputs/simulated/dot11_tx_legacy_iq_mod.txt"
kirateys commented 2 years ago

Thank you very much @mmehari and @JiaoXianjun for your help. The VCD was really helpful. It was the problem of NUM_SAMPLE in the testbench that wasn't letting all the IQ samples come in and hence, corrupting last few Bytes.

Thanks again!

JiaoXianjun commented 2 years ago

You mean this: `define NUM_SAMPLE 8560

To simulate your iq correctly, what should be the minimum value of NUM_SAMPLE?

@lewiz-kiratey

kirateys commented 2 years ago

Hello @JiaoXianjun

Yes, its the `define NUM_SAMPLE 8560 My IQ Sample file has 9740 samples. I set the value to 10000 and it worked for me.

JiaoXianjun commented 2 years ago

@mmehari when you do the simulation, you never change `define NUM_SAMPLE 8560 ?

mmehari commented 2 years ago

I did change the definition to a larger value above 9740 and indeed that makes the difference