[libre-riscv-dev] [Bug 336] ALU CompUnit needs to recognise that RA (src1) can be zero
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Mon Jun 15 00:21:04 BST 2020
https://bugs.libre-soc.org/show_bug.cgi?id=336
--- Comment #59 from Cesar Strauss <cestrauss at gmail.com> ---
Created attachment 64
--> https://bugs.libre-soc.org/attachment.cgi?id=64&action=edit
Suggested pipeline design for the ALU Comp Unit
(In reply to Luke Kenneth Casson Leighton from comment #58)
> (In reply to Cesar Strauss from comment #57)
> > I don't really recall being much afflicted by this sort of issue. But then,
> > I normally try to avoid using latches as much as possible, this may be the
> > reason.
>
> yyeah they're not a "normal" way to do FSMs. however with some aspects being
> combinatorial and some being sync, we can't use "standard" techniques.
Did you consider implementing the ALU CompUnit as a pipeline?
I have put some thought into it. See the attached diagram.
First, consider that rel / go protocol seems to be compatible with the valid /
ready protocol, by connecting n.ready_o->rd.rel_i and rd.go_o->n.valid_i.
Likewise on the dest port. A pass-thru stage helps, I think.
In the idle state, the switches will be set as shown, disconnecting the
pipeline from the input and output ports, connecting them instead to a full
sink and empty source respectively. So, there can be no activity on these
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 outputs n.valid_o only when
both p.valid_o are active. And then, it copies n.ready_i to both p.ready_i.
This combiner takes care to inform the ALU that all its operands input are
valid.
The ALU outputs directly to the dest port. holding the data itself, according
to the protocol, until the dest port can accept it.
Notice the little need for FSMs and latches in the design. The total complexity
is divided in manageable pieces, tucked inside the pipeline stages.
If all stages work in isolation, we can be confident that the design will work
when put together.
Does it make sense?
I think it is worth investing the time to implement this. If it turns up that
it works, we can be more confident on the design. Even apply the same principle
to LDSTCompUnit.
I can give it a try, in parallel with other tasks. It would be a nice way to
learn more about the pipeline API.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-riscv-dev
mailing list