[libre-riscv-dev] KCP53000B micro-architecture thoughts

[Luke Kenneth Casson Leighton]

On Monday, June 3, 2019, Samuel Falvo II <sam.falvo at gmail.com> wrote:

> On Sun, Jun 2, 2019 at 12:27 PM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
> > It sounds like you are merging (moving) the functionality that should be
> in
> > the CU into the FU, which should be fine as long as it really is the
> same.
>
> I find the division of labor between the CU and FU to be challenging
> to keep straight.


Me too, it was weeks of arseing about changing things to sync and comb and
back again. Strategically however CU is the key to synchronisation (aka
phase 2 below).


>
> It's entirely possible that I'm getting it quite
> wrong; after I'm done with my first cut design, I'll need to re-read
> the Mitch Alsup chapters.


I went with it, trusting in the design, because it allowed me to ask
questions.

Modifying a *working* design is a hell of a lot easier than getting a
nonworking design running.


>   As it currently stands, I can see myself
> implementing four tiers of logic:
>
> 1) The raw data processing logic.
> 2) The state machine that actually drives the processing logic (if
> required).


2 is much more than that, it is the *two way* synchronisation point between
1 and 3. It is the time-synced *gateway*.


> 3) The FU logic and/or sub-state machines that is local/unique to the
> CU (if required).
> 4) The FU state machine that interacts with the scoreboard's
> FU-generic interface.
>
> It seems like Mitch considers layers 1+2 to be a CU,


>
Perhaps. I consider them separate, such that multiple CUs can front to the
same (pipelined, multiplex capable) ALU.


 and 3+4 to be the
> FU.  However, right now, I'm considering layer 1 to be the CU, 2+3 to
> be the FU, and 4 to be the instruction dispatcher.
>
> No matter how this comes out, it'll be neat to compare notes
> afterwards.  If it lets me fit a complete RV64I out-of-order processor
> into less than 5500 logic cells on an iCE40HX8K, I'll consider my
> first attempt at this a resounding success.  ;-)


:)


>
> > Yes, please, do, if the CU is not a 6600 style CU, as it already caused
> > confusion.
>
> Will make the adjustments.  Thanks for the feedback!
>
> --
> Samuel A. Falvo II
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68