Systemc with HLSlibs channels

[Diamantis]

Hey everyone,

so i am designing a simple RISCV processor using SystemC and HLSlib's latency insensitive channels. For every module i try to follow the same pattern, 1) read data from channels (Pop) -> 2) do something with data -> 3) Send data to the next modules (Push). The code looks something like the below.

FETCH STAGE

if (fetch_enable > 1) {
	// Mechanism for incrementing PC
	fetch_in = fetch_din.Pop();
	redirect = fetch_in.redirect;
	redirect_addr = fetch_in.address;
	freeze = fetch_in.freeze;
}else {
	fetch_enable++;
}

if (dmem_stall.PopNB(dmem_stall_d)) {
	dmem_freeze = dmem_stall_d.stall;
}else {
	dmem_freeze = false;
}

.
.
.
.
.
.
.
imem_din.Push(imem_in);
dout.Push(fe_out);

DECODE STAGE

tmp_fe_out = fetch_din.Pop();
		
if (dmem_stall.PopNB(dmem_stall_d)) {
	dmem_freeze = dmem_stall_d.stall;
}else {
	dmem_freeze = false;
}

.
.
.
.

fetch_dout.Push(fetch_out);
dout.Push(output);
imem_stall_out.Push(imem_stall_din);

 

and similarly for the other stages (modules) of the processor.

I am using various testing programs and everything is fine when running a C++ simulation.

But after creating the RTL and trying to simulate it with a testbench, the channels at some point seem to get stuck.

Would you have any ideas why that my happen? I think it might be a scheduling problem because some modules return some data to previous ones, creating backpressure.

Would you have and recommendations for best practises when dealing with multiple inputs and outputs using channels?

[David Black]

Not enough information.

1. Where does HLSlib come from? It's not part of the standard.
2. Are your processes SC_METHOD, SC_THREAD or SC_CTHREAD?
3. Can you put code on edaPlayground.com and share a link? Try to reduce code to bare minimum.
4. When you say RTL, do you mean Verilog or SystemC RTL?
5. What simulators are in use?

[StuartSwan]

Diamantis-

I suggest that you download the Matchlib examples kit on the Accellera website:

https://forums.accellera.org/files/category/2-systemc/

Then I recommend reading the PDF at 

matchlib_examples/doc/catapult_user_view_scheduling_rules.pdf

In particular note the section on "Avoiding Pre-HLS and Post-HLS Simulation Mismatches".
Note the recommendation to if possible avoid use of non-blocking message passing IO.

I think you should try to replace your stall signal that uses PopNB with a regular systemc signal.
I would imagine that the stall condition is "transient", ie. the writer might assert stall, but if the reader
never reads it until later, the stall condition might disappear. Signals are good for modeling this, message
passing interfaces are not, since messages are always reliably delivered between producer and consumer.

You probably should also explicitly test the stall condition in your pre-HLS SystemC model, even if that means
forcing the condition to occur.

Here are some papers on using HLS for RISCV processors that may be helpful:

http://www.cs.columbia.edu/~luca/research/mantovani_CICC20.pdf

https://webthesis.biblio.polito.it/6438/1/tesi.pdf

Thanks
Stuart Swan