[Libre-soc-dev] ASIC/FPGA discrepancies (was Re: daily kan-ban update 12aug2020)

[Luke Kenneth Casson Leighton]

On Wed, Aug 12, 2020 at 1:51 PM <whygee at f-cpu.org> wrote:
>
> Hi !
>
> Here I'm only providing a perspective, not a statement
> on the quality of your work (which I respect a lot)

appreciated. it is an iterative learning process.

> > very annoyingly, investigate replacing the unary int and fast regfiles
> > with
> > binary-addressed ones.  this may allow FPGA SRAMs to be used.
> >
> > i really do not like the idea of designing for FPGA targets when we are
> > doing an ASIC.
>
> This is more or less a repeat of what happened with F-CPU
> (yes, yet another parallel !) so it feels weird to me :-D

well, unless the ASIC tools also indicate the same issue i am highly
likely to ignore it.

> You have to remember that your architecture comes from a 60s era system,
> when people were allowed to think in 3D and make funky stuff like NOR
> latches.

well, the issue i think is more that it's an out-of-order design.  a
typical in-order design there is one pipeline, registers get read, go
into that one pipeline, and that's the end of the matter.

here we have *TEN* and that's just the beginning: there are, in the
large version for quad-core, going to be TWENTY FIVE.

for each of those ten pipelines, there are different regfiles.  ra,
rb, rc for INT, SHIFT, and ra, rb for Logical, MUL and Div.  there are
others, however for the INT regfile alone there are *SEVENTEEN*
destinations for INT regfile read to go to.

> You hit a fanout wall and I suppose there is a way to rethink this,
> I hope you'll find alternate methods, maybe like partitioning,
> duplication, I don't know, you're the one who knows best.

the plan is to have cyclic shift-registers between every regfile port
and every pipeline, instead (just not right now).

there exists within this an opportunity to delay the receipt of
operand data and at the same time keep the bus fan-out  / fan-in down,
or at least do it in stages.

an out-of-order design is *not* timing-dependent, it is
result-dependent.  we still have to keep an eye on things however it
is not a "massive showstopping problem".

l.