[Libre-soc-bugs] [Bug 391] New: Investigate the use of the Pipeline API on the implementation of MultiCompUnit

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=391

            Bug ID: 391
           Summary: Investigate the use of the Pipeline API on the
                    implementation of MultiCompUnit
           Product: Libre-SOC's first SoC
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: DEFERRED
          Severity: enhancement
          Priority: ---
         Component: Source Code
          Assignee: cestrauss at gmail.com
          Reporter: cestrauss at gmail.com
                CC: libre-soc-bugs at lists.libre-soc.org
   NLnet milestone: ---

Created attachment 65
  --> https://bugs.libre-soc.org/attachment.cgi?id=65&action=edit
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.