cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
rdemara
Adventurer
Adventurer
733 Views
Registered: ‎05-29-2015

FIR Compiler and TUSER latency

Jump to solution

Page 16 of pg149 (TUSER OPTIONS) The documentation states:

"When User Field is selected on the input channel it is automatically selected for the output channel, as this User Field, like ‘packet-based’ tlast is a facility whereby the User Field is passed through the core, but subject to the same latency delay as the tdata path from input to output. This is intended to ease system design..."

Are there caveats to this? I have a multi channel design and I'm not seeing the output latency (including group delay) of the TUSER field equal to that of the data channels. I'd expect TUSER and TDATA to be in sync w/ each other, but it looks like TUSER actually isn't delayed at all. I would like the TUSER field to have the same group delay through the FIR filter, so I don't have to use an external delay line. Is that not possible w/ the FIR filter? Does the latency referenced in the documentation take into account the group delay through the filter?

0 Kudos
1 Solution

Accepted Solutions
olupj
Explorer
Explorer
620 Views
Registered: ‎01-27-2008

Hey @rdemara 

>>Would it make sense to assert the the enable line of the ADC demuxing core when the FIR input TREADY goes high or something?

I think the only TREADY that would matter is on your output (an input to the FIR). Any backpressure there? Facing the ADC, unless it can queue data for bursting, it will probably drop samples.

There's a couple error flags that I've checked out too - they might be enabled if you use TLAST and TREADY on the output - and TUSER with channel ID. They also might show if you're using multirate

On the S_AXIS_DATA side (upstream) you might just monitor for the event where TREADY goes low...

 

>>Does the latency referenced in the documentation take into account the group delay through the filter?

Sure and relative sample to processing clock rate.

Jerry

 

View solution in original post

5 Replies
olupj
Explorer
Explorer
713 Views
Registered: ‎01-27-2008

Hi @rdemara 

I'd look at the simulation carefully. I've been able to have TUSER represent some arbitrary metadata (channel number for instance) regularly with filters having up to 8 interleaved, but identical rate, channels.However I haven't verified the "Interleaved Channel Specification" beyond "basic" configuration - it can support multiple, basic,fractional interleaving.

Perhaps run an impulse through(one channel) the filter for easiest identification of a channel - or run different signals (different freq tones, impulse) to verify behavior.

I'm sorry to not give a clean solution but I have experience with this working. Just letting you know how I've functionally checked this out. It's most likely something in how it's used/configured.

Good luck,

Jerry

 

Tags (2)
0 Kudos
rdemara
Adventurer
Adventurer
630 Views
Registered: ‎05-29-2015

@olupjThanks for the response... I got tied up working on some other stuff and I'm getting back into the groove of this. I am going to simulate this today. it's really odd behavior. Must be something I'm doing. Do you do anything w/ the input TREADY signal? In my design the input of the FIR is attached to an ADC core, so there is no notion of back-pressure, samples stream in at a low rate of around 30kHz. Would it make sense to assert the the enable line of the ADC demuxing core when the FIR input TREADY goes high or something?

0 Kudos
olupj
Explorer
Explorer
621 Views
Registered: ‎01-27-2008

Hey @rdemara 

>>Would it make sense to assert the the enable line of the ADC demuxing core when the FIR input TREADY goes high or something?

I think the only TREADY that would matter is on your output (an input to the FIR). Any backpressure there? Facing the ADC, unless it can queue data for bursting, it will probably drop samples.

There's a couple error flags that I've checked out too - they might be enabled if you use TLAST and TREADY on the output - and TUSER with channel ID. They also might show if you're using multirate

On the S_AXIS_DATA side (upstream) you might just monitor for the event where TREADY goes low...

 

>>Does the latency referenced in the documentation take into account the group delay through the filter?

Sure and relative sample to processing clock rate.

Jerry

 

View solution in original post

rdemara
Adventurer
Adventurer
600 Views
Registered: ‎05-29-2015

@olupj 

So from my sim it looks like TUSER has the same latency as the core but does not have the same group delay as the filter. For example, if the latency through the core is 100 clock cycles then the tuser port is mirrored every 100 clock cycles and is in-sync w/ the core output - this makes sense to me.

I was trying to be cleaver about resources and use the FIR Compiler's TUSER port to also "delay" some extra data to avoid having to use another, external delay line to compensate for the filter's group delay. For example if my filter group delay is 200 samples, my tuser field is NOT also delayed by 200 samples, which is what I want. This actually makes sense to me now that I think about it, I think I made some pretty dumb assumptions and didn't think about how the core works.

I appreciate the help and I will accept your answer!

0 Kudos
olupj
Explorer
Explorer
596 Views
Registered: ‎01-27-2008

@rdemara 

Glad it's working out.

Have fun,

Jerry

0 Kudos