[libre-riscv-dev] [Bug 208] implement CORDIC in a general way sufficient to do transcendentals

[bugzilla-daemon at libre-soc.org]

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

--- Comment #46 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Michael Nolan from comment #43)
> (In reply to Luke Kenneth Casson Leighton from comment #41)
> > 
> > yes.  an "Op".  this is what the "Op" field is for... see... ahh.. 1sec...
> > DivPipeCoreConfig and DivPipeCoreOperation (etc.)
> > 
> Ok 
> > 
> > it's actually really important to conform to this API because it's where
> > the "cancellation", identifier information etc. critically necessary for
> > the use of the pipeline in the scoreboard system is all placed.
> 
> Oh hold on, I thought that cancellation bit was for the pipeline to produce
> a result early. Since the cordic doesn't do that, I left it out. It sounds
> like I need to add that back in huh?

yyup :)

all operations need to be "cancellable" by way of a globally-broadcast
mask, equal in width to the number of Concurrent Computation Unit "front-ends".
see https://libre-soc.org/3d_gpu/architecture/6600scoreboard/

"Concurrent Computation Unit" diagram (which is from Mitch's Scoreboard
Mechanics, 2nd chapter).

so there will be... how many FP stages? 8? eek!  12! :) so we will need
*TWELVE* Function Unit front-ends, one to manage and track every single
result, and "re-match" that result *BACK* to the FU when it pops out.

now, we _could_ not have cancellation.  we could instead do this:

* let the result come out and when it arrives, throw it away.

  this means we have a Function Unit completely wasted, blocked and
  unusable for up to 12 cycles

* create a complex "ID" system (at least double the number of FU frontends)

  not a big fan of this method.  a counter wraps around, the ID associated
  with "new" requests, and is cleared to zero if the result is not to
  be put into the result FU buffer.


the simpler way is: have an unary "broadcast" mask that goes right the
way through the whole pipeline (one bit per "FU") and we just... simply...
pull that bit.

result dies.

FunctionUnit can rest.

job done.


so yes, you'll need to put that back in.  by conforming to the API,
you should *NOT* have to worry about whether the data is cancelled or
not, because the "MaskCancellable" Pipeline Mix-In class takes care
of that *automatically*.

but.

if FPPipeContext is *not used*... that is *not possible to do*.


> 
> > 
> > can you do that move?  the unit test as well.
> 
> Sorry, you mentioned nmutil and never said which place you thought it should
> go. nmutil or fpcommon?

oh sorry.  nmutil.

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