Changed Output Behavior

[neosatuseracc]

Hello,
I'm simulating the dvb_fpga core in the Vivado Simulator and when I compare the waveform to the ones in the Wiki, it seems that the output behavior is different. In my simulation the core starts immediately to output the encoded frame, whereas in the wiki waveform the output starts only after the input has ended and its tlast is raised.

Could you please tell me if this has changed since the wiki entry was created and if it is expected behavior now or if that is an error in my simulation design?

Thank you for your help in advance.

Vivado waveform

Waveform in the Wiki

[suoto]

Can you check if you run has dummy frames enabled? Also, the behavior changes slightly based on the configuration, the waveform in the wiki shows normal frame, QPSK and code rate 1/2, could you check if that's what you're running with?

[neosatuseracc]

The screenshot was taken with a code rate of 1/4 but with code rate 1/2 the core shows the same behavior. Dummy frames are disabled, I have not changed the reset value of the config register and checked it (0x1).

Encoding with coding rate 1/2:

In the previous picture are some blue markers. I noticed that the output frequency changes there, e.g.:

[suoto]

Is it possible to zoom in on the encoder's data input? I see your tvalid is toggling, maybe that's propagating to the output.

We regards to the frequency change in the output after a certain point of the frame, this is introduced by the LDPC encoder due to how the tables are set. For example, for short frame, code rate 2/5, it looks like this:

5650, 4143, 8750, 583,  6720, 8071, 635,  1767, 1344, 6922, 738,  6658
5696, 1685, 3207, 415,  7019, 5023, 5608, 2605, 857,  6915, 1770, 8016
3992, 771,  2190, 7258, 8970, 7792, 1802, 1866, 6137, 8841, 886,  1931
4108, 3781, 7577, 6810, 9322, 8226, 5396, 5867, 4428, 8827, 7766, 2254
4247, 888,  4367, 8821, 9660, 324,  5864, 4774, 227,  7889, 6405, 8963
9693, 500,  2520, 2227, 1811, 9330, 1928, 5140, 4030, 4824, 806,  3134
1652, 8171, 1435
3366, 6543, 3745
9286, 8509, 4645
7397, 5790, 8972
6597, 4422, 1799
9276, 4041, 3847
8683, 7378, 4946
5348, 1993, 9186
6724, 9015, 5646
4502, 4439, 8474
5107, 7342, 9442
1387, 8910, 2660

The 6 first rows have 12 coefficients, while the 12 last rows have only 3. The LDPC encoder's implementation is naive, it will literally accumulate the very first bit received 12 times, then do the same with the 2nd bit, 3rd bit, etc until I think the 360th bit, after which it moves to the next row. From the 7th row onward, the encoder only needs to accumulate each bit 3 times, which makes it faster to run through 360 bits and in turn increases the output data rate.

This means the actual data rate is not really dependent on the data width. There's probably smarter ways of doing this but I haven't been able to explore much!