cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
5,829 Views
Registered: ‎10-21-2014

Resetting FIR compiler after coefficient reload but before data stream starts breaks the core

I have an FIR filter taking interleaved data channels, set up to use one reloadable coefficient set, and with aresetn set to reset the data vector. I am able to get this to work successfully:

  • When I load the full coefficient set, the reload_tready signal goes low.
  • I then apply config_tvalid for one clock cycle.
  • After a complete interleaved channel sequence has gone through the filter, reload_tready goes high again, and I'm able to repeat the process to load another filter set.

However, if I set aresetn low after applying config_tvalid, but before any data has arrived (which may be many seconds, as my application is shot-based data acquisition), the reload_tready signal never goes high after aresetn is set high again, even after many data samples have passed through the core. The only way to fix this is to reprogram the FPGA.

 

This behaviour was extremely difficult to spot, and I can't find any documentation which suggests that I should avoid resetting the core before reload_tready is high again (i.e. before a full interleaved sample has been processed). Is this a bug? If not, it should be made more clear in the FIR compiler product guide (PG149).

11 Replies
Highlighted
5,824 Views
Registered: ‎03-27-2014

Re: Resetting FIR compiler after coefficient reload but before data stream starts breaks the core

@jacklovell,

 

any particular reasons for using aresetn? just reload the coefficients like you do and wait for a full cycle (latency should be around the filter order), maybe discard corrupted samples at some point

G.W.,
NIST - Time Frequency metrology
0 Kudos
Highlighted
Visitor
Visitor
5,819 Views
Registered: ‎10-21-2014

Re: Resetting FIR compiler after coefficient reload but before data stream starts breaks the core

The shot-based acquisition terminates after a given number of output samples are received. However, due to the filter latency (and downsampling), a full sequence of interleaved output samples may occur half way through a full sample of interleaved input samples. This means the data stream may be stopped mid-way through a series of input samples.

 

When the data stream restarts, the first input is from the first channel, but the FIR compiler thinks it is part-way through an interleaved sequence. This means that my output channel ordering is wrong. Resetting the filter once an acquisition has finished guarantees that the samples will be in the correct order for the next shot.

 

This in itself isn't a particular problem. What I do have a problem with is the way the reload sequence can get stuck if a reset is applied at the wrong time, and this behaviour isn't documented anywhere that I can find.

0 Kudos
Highlighted
5,799 Views
Registered: ‎03-27-2014

Re: Resetting FIR compiler after coefficient reload but before data stream starts breaks the core


@jacklovell wrote:

The shot-based acquisition terminates after a given number of output samples are received. However, due to the filter latency (and downsampling), a full sequence of interleaved output samples may occur half way through a full sample of interleaved input samples. This means the data stream may be stopped mid-way through a series of input samples.


ok I understand the problem.

Have you thought about pushing dummy samples into the core while the burst has just stopped, so you can get the last interleaved outputs? I just had this idea, might be too hard to implement (keeping track of the amount of dummy samples that have been pushed & discard them in software).

 

does this problem show up in real implementation or we are just talking about simulation here

G.W.,
NIST - Time Frequency metrology
0 Kudos
Highlighted
Visitor
Visitor
5,784 Views
Registered: ‎10-21-2014

Re: Resetting FIR compiler after coefficient reload but before data stream starts breaks the core

In theory this would be possible, but I only know when a shot is active when the data_tvalid signal is high. The design is a plug-in module for a larger design, so it's not a simple task to modify the interface to provide additional information.

 

In any case, what I have now works, as long as I don't accidentally apply a reset after a reload and before a data stream. I'm happy to keep my design. But I would like to know from Xilinx if the reload/reset behaviour is intended, and if so it should be more clearly documented.

 

I saw the problem in real implementation first (trying to reload a second set of coefficients would stall the Zynq AXI bus and require power-cycling the board), but verified it with simulation after I discovered the cause.

0 Kudos
Adventurer
Adventurer
404 Views
Registered: ‎09-25-2007

Re: Resetting FIR compiler after coefficient reload but before data stream starts breaks the core


@jacklovell wrote:

However, if I set aresetn low after applying config_tvalid, but before any data has arrived (which may be many seconds, as my application is shot-based data acquisition), the reload_tready signal never goes high after aresetn is set high again, even after many data samples have passed through the core. The only way to fix this is to reprogram the FPGA.

I would like to thank you for making this post. I have been banging my head against the wall for several days trying to figure out why I could not reload my coefficients and what you described was exactly my problem.

I was also resetting my FIR between one-shot captures just like you, and for the same reasons as you.

It does seem very strange that asserting resetting causes reload_tready to never go high again. Especially since the datasheet for the FIR compiler says nothing about this being a potential issue.

TLDR below;

The following works:

  • Load new coefficients on RELOAD port (reload_tready deasserts after all coeffs loaded)
  • Assert tvalid for 1 cycle on CONFIG port (reload_tready still deasserted)
  • Run data through FIR on DATA port (reload_tready reasserts after several input samples pumped through)

The following does NOT work (i.e. reload_tready will stick low indefinitely until FPGA reprogramming):

  • Load new coefficients on RELOAD port
  • Assert tvalid for 1 cycle on CONFIG port
  • Assert aresetn to FIR (for minimum required 2 cycles)
  • Run data through FIR on DATA port (reload_tready never reasserts)

Thank you so much for your post. It really helped me out!

-- Jonathon
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
377 Views
Registered: ‎09-18-2018

Re: Resetting FIR compiler after coefficient reload but before data stream starts breaks the core

Hi @jacklovell ,

This behavior was recently noted by us internally too and it is under investigation. This seems to be a bug in the core.

The FIR core does not recover the reload_tready, when the reset signal is applied on the very next cycle after config_tvalid is applied. The reload channel is getting blocked.

However if the reset signal is applied after atleast two clock cycles following the config_tvalid, the relaod_tready goes high.

Attached are few simulation snapshots of the same.

Hope this helps.

 

config_delayed_reset.png
Config_reset.png
config_reset_2clkcyc.png
0 Kudos
Highlighted
Adventurer
Adventurer
367 Views
Registered: ‎09-25-2007

Re: Resetting FIR compiler after coefficient reload but before data stream starts breaks the core

My assertion of the FIR core's aresetn does not take place in the cycle immediately following the assertion of config_tvalid. My aresetn assertion occurs several seconds after assertion of config_tvalid. The reload_tready never recovers for me even in this case. I am not running a simulation, I am making the observation running in hardware with a System ILA core.

-- Jonathon
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
362 Views
Registered: ‎09-18-2018

Re: Resetting FIR compiler after coefficient reload but before data stream starts breaks the core

Hi @jwdonal ,

Could you share the FIR configuration through xci. I see that in your case, the config packet is applied and then reset is applied before the data vector is applied.

Let me check if this issue is similar to what is found already.

0 Kudos
Highlighted
Adventurer
Adventurer
355 Views
Registered: ‎09-25-2007

Re: Resetting FIR compiler after coefficient reload but before data stream starts breaks the core

Sure. I have attached the file.

-- Jonathon
0 Kudos
Highlighted
222 Views
Registered: ‎06-10-2019

Re: Resetting FIR compiler after coefficient reload but before data stream starts breaks the core

Hello everyone, same problem here, exactly as @jacklovell and @jwdonal described.

for what i've seen it really doesn't matter when the reset occurs: if no data has passed through the fir after reloading coefficients, the reload channel will get stuck (see figure FIR_RELOAD_LOCKED.PNG). this doesn't happen if a dummy sample is presented to the fir input after reloading coefficients, as in figure FIR_RELOAD_UNLOCKED.PNG (to be fair i still can't always see the correct behavior on hw, but i might be missing something. more investigation will follow...).

(edit: sorry for the picture size but the fir is quite deep. full-size pics are attached as zips)

@vkanchan , thanks for looking into this. i see in your simulations that the s_axis_data_tvalid line is always asserted. do you see the same behavior in your testbench if you try and clear the tvalid line?

i've attached my xci as well, if it might help. the ip is generated by SysGen 2018.1

thanks

Paolo

 

PS: the reset signal doesn't seem to be operating as a "traditional" reset, since it doesn't always returns the fir to a known state. in my opinion it can be a bit misleading to call this line reset, maybe a different naming convention could be used.

FIR_RELOAD_UNLOCKED.PNG
FIR_RELOAD_LOCKED.PNG
0 Kudos
Highlighted
181 Views
Registered: ‎06-10-2019

Re: Resetting FIR compiler after coefficient reload but before data stream starts breaks the core

actually, it's not that easy...

there seems to be cases when data input to the fir while the core is reloading coefficients (and after reset) causes the reload channel to get stuck (see FIR_RELOAD_LOCKED_wDATA_crcl.PNG).

masking the s_axis_data_tvalid line while reloading coefficients seems to solve the problem (see FIR_RELOAD_LOCKED_woDATA.PNG)

frankly i can't see why i shouldn't pass data to the filter input while the coefficients are being reloaded, i haven't found any indication in the product guide suggesting that...

 

this behavior is way too random and the only option to recover from this situation is to reload the bitstream, which of course can't be a viable option on the final project. to tell the truth, i'm afraid that more issues will arise on hw, where i won't always be able to control the flow of data coming into the filter. At this point i'm considering rolling back to a previous version of the ip (provided that pre-axi release of the ip can support ultrascale devices) or dropping the fir compiler altogether.

 

At least a clear bug description and  workaround procedure from xilinx would be appreciated.

Paolo

FIR_RELOAD_LOCKED_wDATA_crcl.PNG
FIR_RELOAD_LOCKED_woDATA.PNG
0 Kudos