signal tap data error when depth increased more than 512b

[Rk_Athram]

Hi,

i am facing data corruption when depth is increased to more than 512.

 i am adding signals which are having a maximum width of 132,128  and 160 with a depth of 512.

If i increase the depth to 1k/2k , data captures are getting currupted.
As per my understanding it should not happen. 
Please help me with where i am going wrong.

Regards,

Rajesh

[sstrell]

Unfortunately, your screenshot doesn't really show anything pertinent to the issues you mention other than the fact that it looks like you are trying to capture 1060 signals/channels.  What size and setup is the buffer (not shown in your screenshot)?  Are you able to successfully compile the design and program the device?  Any error or warning messages?  How full is your device?  What leads you to believe you have corrupted captured data?

[Rk_Athram]

Hi, 
Please see i have attached .stp file.

<Are you able to successfully compile the design and program the device? >
Yes, i am ble to program the device.

<Any error or warning messages?  >

No error messages.

<How full is your device?  >

 less than 10% of device resources 

+--------------------------------------------------------------------------+
; Fitter Summary ;
+-----------------------------+--------------------------------------------+
; Fitter Status ; Successful - Wed Nov 2 19:07:24 2022 ;
; Quartus Prime Version ; 20.1.0 Build 177 04/06/2020 SC Pro Edition ;
; Revision Name ; A10_LFPS_PMA_02 ;
; Top-level Entity Name ; pcs_pma_top ;
; Family ; Arria 10 ;
; Device ; 10AX115S2F45I1SG ;
; Timing Models ; Final ;
; Power Models ; Final ;
; Device Status ; Final ;
; Logic utilization (in ALMs) ; 18,392 / 427,200 ( 4 % ) ;
; Total registers ; 24823 ;
; Total pins ; 54 / 960 ( 6 % ) ;
; Total virtual pins ; 0 ;
; Total block memory bits ; 543,744 / 55,562,240 ( < 1 % ) ;
; Total RAM Blocks ; 29 / 2,713 ( 1 % ) ;
; Total DSP Blocks ; 0 / 1,518 ( 0 % ) ;
; Total HSSI RX channels ; 1 / 72 ( 1 % ) ;
; Total HSSI TX channels ; 1 / 72 ( 1 % ) ;
; Total PLLs ; 3 / 144 ( 2 % ) ;
+-----------------------------+--------------------------------------------+


< What leads you to believe you have corrupted captured data>
Its known data/pattern.
512 depth NO corruption, 1k depth same file only modified stp data is corrupted(not matching to actual data).

[sstrell]

Reason why you increased the pipeline factor to 5?  It shouldn't affect anything but curious.

What frequency is your sampling clock?

And I'm assuming that after you adjust the buffer size to make it bigger, you are recompiling the design and re-programming the device.

[SyafieqS]

Hi,

May I know if there is any update from previous reply

In signaltap, you need to recompile if there is any config changes stp thus the data able to be tapped.

[Rk_Athram]

Hi,
After any change in config I am Recompiling design.
Sampling clock is 250mhz.
I am using design clock as sampling clock.

[Rk_Athram]

Pipeline factor increased to 5 as the daa width is 132bits for many signals

[sstrell]

Is your design meeting timing?  250MHz is a pretty fast sampling rate for this.  If your design is not meeting timing or you have not fully constrained it for timing, I could see that causing data corruption.

[SyafieqS]

Rajesh,

Does previous post able to solve the issue?

Timing is not closed will cause the data corruption. Please set your constraint and run the timing analyzer for timing analysis

[Rk_Athram]

Hi,
In console and timing analyzer I am not getting any timing violations. All paths it is meeting all kinds of timings.
For signals tap do i need to give any specific timing constraints?

[SyafieqS]

Hi Rajesh,

Signaltap is bound by the same constraints for the rest of the design - so if you have specified the clock constraints, the Timing analyzer report will list any failed paths into signaltap 

If there are no errors here, and you're still getting errors - then is it possible you are sampling the signals with the wrong clock?

Also, SignalTap is just like any other logic in your design and follows the same rules. If you sample signals from other clock domains with the 250MHz clock then you will get timing violations unless you tell TimeQuest to ignore timing on those paths. 

[SyafieqS]

Rajesh,

Let me know if there is any update or concern at your end

[SyafieqS]

 As we do not receive any response from you on the previous question/reply/answer that we have provided. Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

p/s: If any answer from community or Intel support are helpful, please feel free to mark as solution, give Kudos and rate 10/10 survey