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

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 deci

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(Stag

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 imp