# Why reverse pipeline stages in cycle-level simulator?

In pipeline simulator exercise, it says that:

Traversing the stages in backwards order simplifies the instruction flow through the pipeline.

Also, in gpgpu-sim source code, the stages are reversed (line 2442):

void shader_core_ctx::cycle()
{
writeback();
execute();
issue();
decode();
fetch();
}


Why? What problem it solves? Can anyone elaborate a bit or give a pointer to books/papers on this particular "trick"?

Many thanks!

This solves the problem that, if you put them in "forward" order, an instruction can stream all the way from fetch to writeback in a single cycle of the emulator. An other solution is explicitly emulating the clocked logic between the stages as it would exist in hardware, but it takes more effort that way. Running the stages in reverse is a simple trick that also ensures that instructions properly "wait" at the boundaries between stages.

• Thx. Googling pipeline stage images, particularly here, I am a kind of understand (that each stage handles different instructions). This slide (page 61) also says that "backward pipeline traversal eliminates relaxation problems, e.g., provides correct inter-stage latch synchronization". But I don't understand what are relaxation problems, and what are other kinds of relaxation problems? May 9 '19 at 1:34

execute() will look something like:

void execute(){
switch(decode_execute_op){

Then read_operands() can simply write to the globals readop_operand1 and readop_operand2 to let execute() get access to the result.