cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
deepwavebill
Adventurer
Adventurer
428 Views
Registered: ‎08-09-2018

DDS compiler COS SIN LUT shortened output length

I am using the DDS compiler to generate a COS SIN LUT only with 16 bits of phase input and 16 bits of output for cosine/sine values. The issue I am seeing is that the core is shortening the length of the burst that I send in.

I send in a burst of 256 samples signaled by the tvalid input. On the output the cosine/sine outputs and tvalid signal are only valid for 251 clock cycles. Any suggestions? I have included my version of the DDS compiler core. Thanks.

 

Bill

0 Kudos
5 Replies
nathanx
Moderator
Moderator
380 Views
Registered: ‎08-01-2007

I have tried to run DDS demo test bench in 2021.1, by upgrading your xci file to 2021.1, No issues are observed.

To debug it, you can check the assertion and deassertion time of tvalid input in the demo TB and compare to your own TB. 

As for how to get demo tb, refer to PG141 -> ch. 6 Test Bench.

0 Kudos
deepwavebill
Adventurer
Adventurer
350 Views
Registered: ‎08-09-2018

Thank you for your response. I did as you suggested and I still see the issue. Below is a snippet of the waveform display for the simulation.

You can see that the output tvalid period is 6 clock cycles shorter than the input tvalid period.

deepwavebill_0-1626442861412.png

 

0 Kudos
deepwavebill
Adventurer
Adventurer
342 Views
Registered: ‎08-09-2018

I forgot to mention that I am using Vivado 2020.2. Also I notice that the shortened output tvalid period only occurs for the first frame of input data. After the first frame the output tvalid period is the same as the input period, however it is not delayed relative to the input which does not make sense as there should be some pipeline delay. The core says the pipeline delay should be 6. Thanks.

 

Bill

deepwavebill
Adventurer
Adventurer
271 Views
Registered: ‎08-09-2018

Here is the answer I got by submitting a service request.

The explanation for this case is that the output tvalid immediately follows the input tvalid. The output data appears after the latency from the  core and here on the input data valid is immediately followed by the output tvalid. So when the input tvalid goes low, the output tvalid goes low and the rest of the output samples remain in the pipeline. The pipeline is not flushed without valid data at the input.
 
The IP guide PG141 describes the following about the input and output tvalid behavior :
 
"Likewise a starvation of input data on the PHASE channel (deassertion of TVALID) propagates to become a deassertion of TVALID on the output channels."
 
Hence a new frame also takes effect with a latency of 6 cycles in this case. It appears the behavior is as expected based on the description given in the pg.

This is very poor design practice since it means that I must add additional logic to select the proper outputs related to the inputs.

 

Bill

 

0 Kudos
nathanx
Moderator
Moderator
243 Views
Registered: ‎08-01-2007

This behavior is expected.

The DDS has a peculiar problem in that it is often a signal source. When it is a signal source, it cannot be allowed to free-run and only be sampled by m_axis_tready, so the clock enable to the phase generator had to be stalled when stalled by m_axis_tready so as not to have ‘bubbles’ in the pipeline. While this does not apply to the sin/cos generator in isolation since it has no phase generator, so could have a simpler pipeline, having different behaviour for different configurations of the DDS might also be considered confusing.

0 Kudos