Synchronized register lab notebook

[paili0628]

When setting up test cases for the two-reader register, I realized that the current interface could be very hard for clients to use. To use it correctly users have to make sure that the read_en_* signal is immediately turned off once the corresponding read_done_* signal is high; however, there is essentially no way to do that since in the Verilog code we write for the primitive, read_done_* signal depends on read_en_* signal. Direct dependence on the read_done_* signal to turn off the read_en_* signal would in turn result in a combinational loop.

To make the interface easier to use, we could 1. internally make sure that each read_en_* signals can only consume 1 value; 2. give users a standardized, safe way of turning off the read_en_* signal once they have the value they want.

So here are a few design choices:

1. instead of making "out" high for one cycle, make it high until the next read_en is high. The drawback of this would be having stale values at out_* ports, which would not be a good choice if we wanted to implement barriers with this design

2. instead of directly outputting a register value, use a read_ready signal to limit the number of values one read_en_* signal can consume. This means that reading now takes 4 steps: 1) reader sends read_en_* signal; 2) register gets read_en_* signal and sends read_ready_* signal; 3) reader gets read_ready_* signal and sends read_* signal; 4) register sees that read_ready_* and read_* signal are both high, turns off read_ready_* immediately and sends out the value. Drawback: 1. this design is very complicated, which can potentially cause more bugs for a synchronization program. 2. Using this design, it would take 4 cycles to read, which leads to starvation especially on the side of producers(since it only takes one cycle to write).

3. make it so that we send out the value 1 cycle after read_done_* signal is high, so that users are able to turn off the read_en_* value immediately when the register sends out the value. In the documentation for this primitive, we could write down sample code like this:

   component main {
   cells {
   imm = std_sync_reg(32);
   r_read = std_reg(1);
   r_0 = std_reg(32);
   }
   wires {
   group read_imm {
   r_read = imm.read_done_0? 1'd1;
   imm.read_en_0 = !r_read.out? 1'd1;
   r_0.in = r_read?imm.out;
   r_0.write_en = r_read? 1'd1;
   read_imm[done] = r_0.done;
   }
   ...
   }
   control {
   ...
   }
   }

   Drawback: this design relies too much on the client

4. Based on 3, we can internalize the r_read signal in the sample code: create a read_ready signal that is high one cycle after read_done is high, which is the cycle that the value is sent out. This way, clients can use the read_ready signal as a guard to turn off the read_en_* signal in time.

Based on discussion with @rachitnigam and @sampsyo.

[rachitnigam]

@paili0628 for the current design, where the out and read_done signal arrive at the same, seems like the correct thing to do is to build an FSM inside the group to track when the read_en signal needs to be set to 0.

Would the following not work:

cells {
  once = std_reg(1);
  r = std_sync_reg(32);
  save = std_reg(32);
}
group do_read {
  // Latch read_done signal as soon as it arrives
  once.in = r.read_done_0;
  once.write_en = r.read_done_0;

  // Keep the signal high till once cycle after read_done
  r.read_en_0 = !once.out;

  // save the value when it arrives
  save.in = r.read_done ? r.out_0;
  save.write_en = r.out_0;
  do_read[done] = save.done
}

[paili0628]

Should it be
save.write_en = r.read_done
?

[paili0628]

Otherwise in a glance this should work. However, we'd still be taking advantage of the fact that once a value is consumed, it takes another cycle for the register to be full. i.e. read_en is still high probably when some other user is writing to the register. Again, this implementation does not cause a problem but can still be confusing.

[sampsyo]

This is a good example, @rachitnigam! It is a little bit of a "dance" required to read from the register, but it's not the worst thing in the world…

[sampsyo]

Thanks for the detailed writeup, @paili0628; this is quite helpful!

To clarify, I believe the "fantasy" way we would like to read from the register (with minimal fuss) would be something like this, right?

cells {
  r = std_sync_reg(32);
  save = std_reg(32);
}
group do_read {
  // ask to read the sync_reg
  r.read_en_0 = 1'd1;

  // save the value when it arrives
  save.in = r.read_done ? r.out_0;
  save.write_en = r.read_done;
  do_read[done] = save.done;
}

That is, it's sort of like an invoke. We can just set the read_en_0 port to a constant 1 because we're inside a group, and we can run the thing as long we want within the context of that group.

…but there's a danger with that constant assignment r.read_en_0 = 1'd1 that we'd try to read the register multiple times. In other words, the sync_reg's contract says that, as soon as a value is ready to be read, the client needs to stop asserting read_en_0 or we'll be "counting" this as the next attempted read.

That's why we originally needed to do r.read_en_0 = !r.read_done_0 ? 1'd1 instead, which led to the combinational cycle.

I think supporting the above code would amount to item 1 in the list. Is that right? Could this work if we made the convention that the value is not actually "consumed" until read_end_0 becomes 0, meaning that the sync_reg blocks writers until then?

[paili0628]

Interesting! I believe this is not a hard modification to make in terms of actual implementation. Although careful discussion is still needed about possible events that could occur once we do this. Would this be disabling parallel reads and writes?

[sampsyo]

That's a good point; it does seem to rule out parallel reads and writes. In a way, that seems justifiable… the register is not available for writing until the read "consumption" has finished. But it's certainly a cost!

[rachitnigam]

I wonder how of much of this becomes less of a problem if we start treating this as a FIFO with READERS + WRITERS number of cells. Maybe some of the annoying states where reads and writes may conflict go away? Additionally, I've talked to @paili0628 about:

1. using a simpler implementation for barriers in case we don't need the full complexity of the multi-reader, multi-writer stuff
2. Because we're generating code, being more okay with the complex interface