cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
embedded
Advisor
Advisor
642 Views
Registered: ‎06-09-2011

RTL Co-Simulation stuck for axis interface of input and return arguments

Jump to solution

Hi,

I have designed a cross correlation core which gets two arrays of length 100 and calculates the cross correlation. It is a function like this MyCorrel(Ref[100], Rec[100], ret[199]);

I have a problem in Co simulation and that's when I use axis interface for input/return arrays(Ref, Rec, Ret) it never finishes. It goes very very slow as well. I receive below Warnings:

Note: WARNING: The latency is much larger than expected. Simulation may be stuck.
Time: 100000155 ns Iteration: 1 Process: /apatb_MyCorrel_top/gen_mLatcnterout_proc 

If I change it to use RAM_1P_BRAM, then it works very well.

I tried to find somewhere to decrease simulation resolution. I couldn't find it. I think if I decrease the simulation resolution steps from 1ps to 1ns  it will run faster. Where can I change the simulation resolution for HLS project?

Thanks,
Hossein
0 Kudos
1 Solution

Accepted Solutions
wenchen
Moderator
Moderator
502 Views
Registered: ‎05-27-2018

Hi @embedded 

Here we first make clear some CO-sim concepts. The CoSim is not a dynamic simulation, and the XSIM -debug option for xelab is meant for producing waveforms and describing the depth of signal exposure during the simulation. It does not enable the dynamic code debugger for the C code as you would find in C simulation with the compiler. So we must ensure the DEPTH option is specified on the INTERFACE directive.

For cases in which a pointer is read from or written to multiple times within a single transaction, the depth option is required for C/RTL co-simulation. The depth option is not required for arrays or when using the hls::stream construct. It is only required when using pointers on the interface.

If the depth option is set too small, the C/RTL co-simulation might deadlock as follows:

  • The input reads might stall waiting for data that the test bench cannot provide.
  • The output writes might stall when trying to write data, because the storage is full.

Wen

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.


**~ Got a minute? Answer our Vitis HLS survey here! ~**


-------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------

View solution in original post

5 Replies
wenchen
Moderator
Moderator
549 Views
Registered: ‎05-27-2018

Hi @embedded ,

I'm a little bit confused as the AXIS is the interface protocol but the RAM_1P_BRAM is a resource option for HLS. Could you please give us a coding template for your function?

In the Co-sim mode in HLS, we cannot change the simulation resolution. All that we can do to decrease the simulation time is to modify the testbench.

Wen

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.


**~ Got a minute? Answer our Vitis HLS survey here! ~**


-------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
embedded
Advisor
Advisor
530 Views
Registered: ‎06-09-2011

Hi @wenchen,

Thanks for your comment. Yes, they are from two different categories. But, as I said these two different directives for those input/output arguments of function impact co sim. I have noticed that I need to specify the depth parameter for the AXIS interface!. Otherwise, it will continue forever. I configured those two inputs to 100 - the depth of axis interface for my 100 sample correlation function - and for the output to 199. This made it work well. Now, I would appreciate if you can mention a little bit how does this depth parameter impact the co sim performance?

Another question - regarding your comment - raises up and that's which test bench? And, where is it?  

Thanks,
Hossein
0 Kudos
wenchen
Moderator
Moderator
503 Views
Registered: ‎05-27-2018

Hi @embedded 

Here we first make clear some CO-sim concepts. The CoSim is not a dynamic simulation, and the XSIM -debug option for xelab is meant for producing waveforms and describing the depth of signal exposure during the simulation. It does not enable the dynamic code debugger for the C code as you would find in C simulation with the compiler. So we must ensure the DEPTH option is specified on the INTERFACE directive.

For cases in which a pointer is read from or written to multiple times within a single transaction, the depth option is required for C/RTL co-simulation. The depth option is not required for arrays or when using the hls::stream construct. It is only required when using pointers on the interface.

If the depth option is set too small, the C/RTL co-simulation might deadlock as follows:

  • The input reads might stall waiting for data that the test bench cannot provide.
  • The output writes might stall when trying to write data, because the storage is full.

Wen

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.


**~ Got a minute? Answer our Vitis HLS survey here! ~**


-------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------

View solution in original post

embedded
Advisor
Advisor
389 Views
Registered: ‎06-09-2011

@sandrao  You are here to support members and help them to get the right answer?! Or, make a comment to be the solution by your authority? Very very weird!

Thanks,
Hossein
0 Kudos
sandrao
Community Manager
Community Manager
373 Views
Registered: ‎08-08-2007

Hi @embedded 

Apologies if there is any offense here. The Moderator of the board (@aoifem in this case) can make recommendations to the Community (Myself or another Manager) for a Reply that in their opinion should be the Solution. The motivation for this is to help the Community as the thread with the Accepted Solution should appear higher in the search results.  

Thanks,

Sandy


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub , Versal Blogs and the Versal Useful Resources .

------------------------------------------------------------------------------------------------