Re: [Discuss OpenCPI] Single bit errors in output of fsk_filerw on Ettus N310

From: James Kulp <jek_at_parera.com>
Date: Thu, 10 Oct 19 15:31:19 -0400

Thanks Robert.

For those that don't know, this fsk mod/demod app is a digital loopback
without any transceiver or converter involved.

So if the matchstiq_z1 appears solid and the N310 does not, the
difference is really the Zynq part: (7020 vs. the 7100),
  the clocking set up, and of course the actual place+route of this
bitstream.

The next thing I would check/eliminate is the clocking setup.

First, what clock rates are produced by the PS/PL clock generator (as
programmed by the boot prom).  For example, using the ocpizynq tool:
On a zedboard, "ocpizynq clocks" says:

FCLK 0: source: IO PLL, divisor0:  5, divisor1:  2, throttling not
reset, throttling not started, mode: debug/static, frequency: 100.00 MHz
FCLK 1: source: IO PLL, divisor0: 24, divisor1:  1, throttling not
reset, throttling not started, last count: 1, mode: stopped/normal,
frequency: 41.67 MHz
FCLK 2: source: IO PLL, divisor0: 24, divisor1:  1, throttling not
reset, throttling not started, last count: 1, mode: stopped/normal,
frequency: 41.67 MHz
FCLK 3: source: IO PLL, divisor0: 24, divisor1:  1, throttling not
reset, throttling not started, last count: 1, mode: stopped/normal,
frequency: 41.67 MHz

Second, look at which of these clocks the platform worker is actually using.
In the zed.vhd file we see:

     clkbuf   : BUFG   port map(I => fclk(0),

I.e. the zed platform code uses FCLK 0, which is set up by the boot prom
to be 100MHZ

Third, look at the constraints file to see what the FPGA tools used when
it built the design.
For zed using Vivado, it is: zed.xdc

    # 10 ns period = 100000 KHz
    create_clock -name clk_fpga_0 -period 10.000 [get_pins
{ftop/pfconfig_i/zed_i/worker/ps/ps/PS7_i/FCLKCLK[0]}]

Finally, look at the timing report of the assembly/bitstream used for
this application, namely

projects/assets/hdl/assemblies/fsk_filerw/container-fsk_filerw_zed_base/target-zynq/timing.out

To see if there are any timing violations.

If that all looks good, then there is a different issue, which could
involve a typical divide and conquer approach.

This behavior is not something we have seen exactly.

Jim






On 10/10/19 12:20 PM, Munro, Robert M. wrote:
> The performance of the fsk_filerw application running on the Ettus N310 is being examined as a functional verification of integrated software and hardware using the OpenCPI framework runtime for loading and execution. The application runs without any errors output and completes the operations with the same binary output size at all times. The expected output file has been extracted from the input file, opencpi/projects/assets/applications/FSK/idata/Os.jpeg, by removing the 242 byte header and 2 byte tail. Binary comparison of multiple runs shows that there are randomly placed single bit errors in multiple places in the output file.
>
> The framework and application were built for the Matchstiq_Z1 using the OCPI 1.4 baseline and the output of the application matched the expected result over multiple runs.
>
> Attached are a golden expected output and outputs with single bit errors in varying numbers, locations, and conditions generated by running the fsk_filerw application on the N310. The application was run using the command 'ocpirun app_fsk_filerw.xml'. Runs were performed in a mixture of immediately following power cycles and repeatedly to see if it affected performance. The files were generated in the following manner:
>
> - Power N310
>
> - Generate run7
>
> - Generate run8
>
> - Reboot
>
> - Generate run9
>
> - Reboot
>
> - Generate run10
>
> - Reboot
>
> - Generate run11
>
> - Generate run12
>
> - Reboot
>
> - Generate run13
>
> Has this kind of issue been encountered before while using the framework? If so, what were the cause and resolution taken? What steps are necessary to debug the performance of this reference application?
>
> Thanks,
> Rob
>


Received on Thu Oct 10 2019 - 19:31:19 CDT