SystemC and latency simulation

[campo85 0]

Hi all,

I guess this is a basic question but I can't find the answer. I have a SystemC module that performs several complex arithmetic operation ( several multiplication ). When I simulate it I can see it performs all those operations in on clock cycle after I provided the input. I'm pretty sure that when I'll feed the HLS tool, the tool will pipeline the operation adding latency. Is there any way to manually add latency in order to match what I guess will be the result of the HLS ? I guess I can simulate the latency changing the SC_METHOD with a SC_THREAD and adding a sort of counter, but I was wondering if there is a more elegant and native way to do it.

Cheers.

[maehne 75]

You might find the following thread helpful to address your needs:

 

 

[Roman Popov 74]

Quote

Is there any way to manually add latency in order to match what I guess will be the result of the HLS ? 

No, there is no elegant way to simulate pipelines in SystemC.  Commonly you just write a separate thread for each pipeline stage. Like you will do in Verilog/VHDL. 

Quote

I guess I can simulate the latency changing the SC_METHOD with a SC_THREAD and adding a sort of counter, but I was wondering if there is a more elegant and native way to do it.

1) All HLS tools I've used do not convert SC_METHODs to pipelines. Only SC_THREADs can be converted to pipelines, if they follow some vendor-specific restrictions.

2) Yes, you can simulate latency by adding wait(N) to clocked SC_THREAD. However it will not simulate throughput. 

In general, this is a well known problem that HLS-generated code changes timing (expressed in clock cycles) of design. So HLS-generated code can even fail in tests that were working on input SystemC code. To avoid this, your inter-thread communication mechanisms should not depend on latency and throughput of generated hardware. You can also create latency/throughput constraints for HLS tool.

[Roman Popov 74]

If your pipeline is simple, like:  get data ->  process  data -> put data, without I/O operations on internal pipeline stages, then you can model latency while keeping throughput: just put output data into fifo-like channel that will delay output for N cycles.