[Libre-soc-isa] [Bug 560] big-endian little-endian SV regfile layout idea

[bugzilla-daemon at libre-soc.org]

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

--- Comment #77 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #75)
> I thought I'd already shown that I understand how ld and ldbrx work. 

i am barely keeping up and i did make it clear to keep the discussion to scalar
only.  i saw something in amongst vectors and consequently did not spend time
reading it because until OpenPOWER v3.0B scalar is understood there is
literally no point.

> What
> else remains so we can finish this exchange and get to my suggestion, that
> is not related with this?

i forgot to ask: can you read VHDL? or is the explanation of why XNOR is used
sufficient?

the purpose of asking you the questions that i did, limited to v3.0B scalar
only, were designed to help you understand the relationship, in the HDL source,
between

* Memory
* Number (hexadecimal)
* regfile
* ALU

the answers in each of the cases were - are - LE. it was a trick question


* ld     LE: ordering of the MEANING in regfile LE
* ldbrx  LE: ordering of the MEANING in regfile LE
* ld     BE: ordering of the MEANING in regfile LE
* ldbrx  BE: ordering of the MEANING in regfile LE

> > a dynamic LE-BE regfile
> 
> My suggestion of iteration order in sub-register vector elements is
> unrelated to this.

the time for suggestions is, unfortunately, over.  we were supposed to have had
implemented SV in RISC-V about one year ago.  the RVF ******d that for us.

when you joined we were already behind by at least 12 months, not having had
the time to even do the conversion of SV Prefix to OpenPOWER.

the only reason that the discussion of development of svp64 is taking place is
because we're forced to, and forced to under some serious timecrunch.

the actual design of SV (the concept) was 18+ months ago, at which time
suggestions would have been extremely welcome, and there woukd have been plenty
of time to discuss and evaluate them.

now? right now? i'm really sorry to have to say this, but no.



> Should I file a separate bug for it so that you'll read it?

the best thing is to make sure that it is written, if not fully detailed at
least some notes.

the reason is that whilst we move to implementation, it may turn out that we
made an error or there was something we overlooked.

having a clear record of ideas gives us a reminder that we can go "ah! we
discussed this before.  the solution was X".

rather than, "arse, we're screwed, we have to stop for 2 months and discuss
redesigns"

so yes, please document it, i will look at it but unless it is in line with the
decisions already made it will go into the "to look at again if we encounter a
problem" pile.

this is how it has to be given the massive schedule delay and timecrunch we are
under.

we are now moving from "spec wording review" mode into "draft spec freeze" mode
so that we can get to "implement" mode within the next few days.

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