Dilan Manatunga

I'm sorry in my last post as I made some terminology assumptions that were unclear. I said pipeline latch from the computer architecture perspective, which is essentially synonymous with a register, as opposed to maybe an SR-latch. My calling an sc_signal as a 1-entry queue was also bad and unnecessarily confusing. I was just trying to illustrate that a consumer stage cannot count on the signal value remaining the same at the next cycle in the case where the consuming stage stalls. That is why I said sc_signal acts like a 1-entry queue, because at every positive edge when a consuming stage reads the sc_signal, that value is lost as the proceeding edge will always end up writing a new value. Again, calling this a queue was needlessly complicating on my part and I could have picked a better description. I feel I am re-iterating myself, but again my whole issue has been, and as you mentioned, the traditional method of doing pipelines is a set of processes (SC_METHOD/SC_THREAD) communicating via sc_signals. Yet going off that basis, I have not found an example, nor have I been able to construct a mechanism (with just standard SystemC components), that implement pipeline stalling, where the intermediate pipeline latches/registers are done similar to the circuit diagram in my previous comment.

Sorry if there is a loss of clarity in what I said, so let me try explaining some stuff again. From searching around the web, almost every example of a pipeline I have seen, as well as the one included in the SystemC examples, uses this on positive edge sensitivity for the SC_METHOD that represents a given stage. Now, this might be a misconception on my part, but in these pipelines, I view the connecting sc_signals between stages as representing pipeline latches. So, when I think of stalling, I would expect the sc_signal to retain its old value if the stage that reads that value decides to stall. Something similar to picture below. I understand the issues of why a back-propagation signal (in the way I implemented it) does not work when SC_METHOD is sensitive to the positive edge. To put into my own words, the sc_signals now are more akin to a 1-entry queue, where once a stage has read that value, it is the stage's responsibility to keep that internal value if it plans to stall. And I have ideas how I could implement something similar to the picture. The thing is my current ideas involve many more modules (a module for each stage, and a module for each latch), with different sensitives (latches sensitive to positive clock, stage sensitive to latch output). I was more just wondering if there were better, more recommended ways for this approach that might hew closer to the non-stalling pipeline examples.

Ok, my goal here was to create a 3 stage pipeline that essentially should stall infinitely when the number 2 reaches the third stage. It is again, a modification of the pipe example. class Stage0 : sc_module { public: sc_in<bool> clk; sc_out<int> out; SC_CTOR(Stage0) { SC_METHOD(Tick); dont_initialize(); sensitive << clk.pos(); } void Tick() { static int i = 0; out.write(++i); } }; class Stage1 : sc_module { public: sc_in<bool> clk; sc_in<int> in; sc_in<bool> stall; sc_out<int> out; SC_CTOR(Stage1) { SC_METHOD(Tick); dont_initialize(); sensitive << clk.pos(); } void Tick() { if (!stall.read()) { out.write(in.read()); } } }; class Stage2 : sc_module { public: sc_in<bool> clk; sc_in<int> in; sc_out<bool> stall; sc_out<int> out; SC_CTOR(Stage2) { SC_METHOD(Tick); dont_initialize(); sensitive << clk.pos(); } void Tick() { stall.write(false); out.write(in.read()); if (in.read() == 2) { stall.write(true); } } }; And this was my test suite: int sc_main(int, char *[]) { //Signals sc_signal<int> in1; sc_signal<int> in2; sc_signal<int> out2; sc_signal<bool> stall; //Clock sc_signal<bool> clk; sc_trace_file *vcd = sc_create_vcd_trace_file("pipe"); sc_trace(vcd, clk, "clk"); sc_trace(vcd, in1, "in1"); sc_trace(vcd, in2, "in2"); sc_trace(vcd, out2, "out2"); sc_trace(vcd, stall, "stall"); Stage0 S0("stage0"); S0.clk(clk); S0.out(in1); Stage1 S1("stage1"); S1.clk(clk); S1.in(in1); S1.stall(stall); S1.out(in2); Stage2 S2("stage2"); S2.clk(clk); S2.in(in2); S2.stall(stall); S2.out(out2); sc_start(0, SC_NS); //Initialize simulation for(int i = 0; i < 50; i++){ clk.write(1); sc_start( 0.5, SC_NS ); clk.write(0); sc_start( 0.5, SC_NS ); } return 0; } So I attached the waveform below. What I would want, is that from t=2ns, the in2 latch should essentially be stuck at 2. From my current implementation, the in2 latch stalls at 3 for a couple cycles, before continuing on. This matches my understanding, because the stage S1 will not see the updated stall signal from stage S2 until the next positive edge at t=4ns, at which point it would have written the value 3. Again, this is why I am unsure of what is the best way to implement a pipeline that supports stalling using SystemC.

I will include a code example when it is less late for me, but I guess my confusion with what you suggested is when the previous stage sees the ready signal value. Say we go on a slight modification of the pipe example, where there is a ready signal connected from each stage to the previous stage. Now, if some stage decides it should stall, and indicates so by writing an sc_signal that the ready signal to the not ready state, I though that the previous stage won't see that updated signal value till the next posedge event, when it really should be seeing it in the current posedge event.

I've been trying to find a good example of a simple pipeline that includes pipeline stalls. The reason I am looking for this is that every simple pipeline example I have found typically represents each stage as SC_METHOD sensitive to clk.pos(). That system works well when we have a free-flowing pipeline, but I am wondering how a pipeline with stalls is modeled. In that case, whether Stage 1 should output is dependent on whether Stage 2 finished whatever operation it was performing (for example: multi-cycle arithmetic operation causing a stall). The only idea I currently have on how to implement this is that instead of representing the stages as SC_METHODs that are sensitive to posedge, we have pipeline latches that are sensitive to posedge and take in signals of new_value and stall, while each pipeline stage is sensitive to the output of the previous pipeline latch. I haven't tried this out though, and I'm not sure if it is the right approach or if there is a better approach out there.