Created attachment 65 [details] Suggested pipeline design for MultiCompUnit MultiCompUnit is sequential by contract, and allowing multiple operations in flight is a violation of that protocol. However, it can still benefit from the use of the Pipeline API, for implementing sequential operation (eliminating all complex FSMs), and at the same time enforcing the ready/valid and rel/go protocols for free. It started when I suspected that the rel/go protocol of the src and dest ports are likely compatible with the valid/ready protocol of the ALU. It was then that I conceived of the src and dest ports being joined to the ALU using the pipeline API. See the attached diagram. In the idle state, the switches will be set as shown, disconnecting the pipeline from the input and output ports. At issue time, you transition the dest switch from straight to crossed. Also, in each parallel arm, choose either one of the src or imm switches to cross. The barrier / combiner joins the input data and takes care to inform the ALU that all its operands input are valid. The ALU outputs directly to the dest port. The only thing, is making sure that only one operation is in flight in the pipeline at a any time. A simple FSM would take care of that, I think. Given the time invested into MultiCompUnits, and the timescales, we really should prioritise, and come back to this idea later.
super idea, love it. anything that helps make the CompUnits clear. can you put the link to the comment# from where it was initially discussed, and add to "See also" above? (found it)