[Libre-soc-bugs] [Bug 336] ALU CompUnit needs to recognise that RA (src1) can be zero

[bugzilla-daemon at libre-soc.org]

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

--- Comment #62 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cesar Strauss from comment #61)
> (In reply to Luke Kenneth Casson Leighton from comment #60)
> > (In reply to Cesar Strauss from comment #59)
> > > Did you consider implementing the ALU CompUnit as a pipeline?
> > 
> > you mean, MultiCompUnit itself?  if so: this would violate the
> > mission-critical
> > protocol, the purpose for which MultiCompUnit exists.
> 
> I understand that MultiCompUnit is sequential by contract, and that allowing
> multiple operations in flight is a violation of that protocol.
> 
> That was not my idea when I conceived using the pipeline API in the design
> of MultiCompUnit.

ah?

> The idea was to use the pipeline API to enforce sequential operation
> (eliminating all complex FSMs), and at the same time enforcing the
> ready/valid and rel/go protocols for free.

ahh okaaay now i get it.  sorry: comparison-and-difference was what it
took for me to understand.

> Is started when I suspected that the rel/go protocol of the src and dest
> ports maybe were compatible with the valid/ready protocol of the ALU.

yes this is extremely likely.

> I was then that I conceived of the src and dest ports being joined to the
> ALU using the pipeline API.
> 
> 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.
> 
> But then, I would be crippling the power of the pipeline concept, which does
> seems like a waste.

not quite.  it's that "tracking" which is paramount, everything else is
secondary.

> Oh well, at least I conceived an example of a parallel, dynamically
> reconfigurable pipeline, with new elements like cross-switches and
> barriers/combinators, that are maybe useful in other contexts.

:)

what you've come up with is basically a pipeline-compatible "information
collector and distributor", where:

* certain information has to come in from multiple different sources
* processing has to take place which cannot begin until all incoming
  information is received
* processed information has to be distributed out to multiple destinations

this may indeed prove extremely useful, although under some very special
circumstances.

given that the ready/valid protocol is basically Wishbone compatible
it *might* turn out to be the case that it's useful for special Bus
Transactions.

now that i think about it - it was over a year ago - i did sort-of begin
something like this (at least on the receiving side), it was a multi-bit
ready/valid with a funnel.

i didn't exactly abandon it... it just turned out to be complex.

i really like it... however given the time invested into MultiCompUnits,
and the timescales, we really should prioritise, and come back to this
idea later.

can you raise a bugreport with a summary and a link to the attachment?

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