[Libre-soc-dev] synchronised incremental SV development planning

[Luke Kenneth Casson Leighton]

On Sat, Jan 23, 2021 at 1:41 PM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Fri, Jan 22, 2021, 06:45 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > jacob can i put you down for the c++ macros?
>
>
> sure, though we'd be limited to very poor register allocation, or to
> vectors with a max size of 64-bits for a vector limited to the first 32
> registers. Those limitations will only apply until gcc gains support for SV
> registers in assembly constraints.

incremental steps.

On Sat, Jan 23, 2021 at 1:41 PM Cesar Strauss <cestrauss at gmail.com> wrote:

> > the reason is that the testing system compares regfiles (and memory)
> > based on a single step of running a single instruction.  if ISACaller
> > does the *entire* loop but TestIssuer does only one, they are now
> > out-of-sync.
>
> Would it make sense to compare these only at the end of the vector
> instruction, when the loop has finished in both ISACaller and TestIssuer?

no because exceptions can occur on a per-instruction (per-element)
basis, and, also, the loop could "go wrong".

at the point at which we start doing SIMD back-ends where the loop
step quantity can be not-equal-to-one it gets much more involved and,
then, yes, it will be necessary to do some sort of "catch-up" which
will be a bundle-o-fun.  ask each system (TestIssue, ISACaller) *how
many* have you done.

my feeling there is that ISACaller and all other simulators should be
STRICTLY limted to ONLY doing one element at a time, otherwise it
quickly becomes hell to work out which system has done what.

performance optimisation of the simulators is an absolute rock-bottom
priority and should in absolutely no way interfere with clarity and
simplicity.

l.