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

Luke Kenneth Casson Leighton lkcl at lkcl.net
Sat Jun 1 01:55:15 BST 2019


On Saturday, June 1, 2019, Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Sat, Jun 1, 2019 at 12:33 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> >  > VL is a CSR that completely changes the instruction behaviour at the
> issue
> > > phase.
> > >
> > > As in, it actually causes MORE instructions to be issued in a hardware
> > > for-loop.
> > >
> > > So, setting it causes some intricate critical dependencies that will
> have
> > > to be thought through really carefully.
> > >
> > Just do the same thing you'd do for mispredicted branches, cancel all
> > instructions issued after, then issue the correct instructions.
>
>  if there was a decision-point (branching-point) that i believe would
> be the correct strategy.



Also, I think... if the instructions have been issued they should have the
correct VL to do so (or have a means to get the correct VL)

And if they need cancelling it would mean that an instruction did NOT have
the correct VL, which I feel is an implementation path that should not be
explored.

The rules are, in scoreboards, that instructions should not even begin
unless they have the information they need to complete, ST being a minor
variant on that, because there are 2 "stop" points, one on getting the regs
to calc the addr and another on the actual store.

And the other rule is that of shadowing, which is that if an instruction
might need to cancel ITSELF (exception, predication, wrong branch path) it
holds the schroedinger high until it knows what to do: cancel or allow.

VL seems to me to fall into rule 1 not rule 2.

L.



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


More information about the libre-riscv-dev mailing list