[libre-riscv-dev] daily kan-ban update 13may2020

[libre-riscv-dev] daily kan-ban update 13may2020

[Luke Kenneth Casson Leighton]

yesterday i started on integrating the LDSTCompUnit into the
scoreboard and immediately ran into a brick wall in the form of the
address-request/release signalling.  when go_addr is raised (in
response to req_addr), the LDSTCompUnit is supposed to drop req_addr
one cycle later: instead it stays high.

i also investigated microwatt to find out what the heck is going on
with the register-order-swapping.  turns out that different classes of
operations (logical, rotate, arith) have different ordering.  why? who
knows.

today i will continue working through the address-negotiation in LDSTCompUnit.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] daily kan-ban update 13may2020

[Tobias Platen]

On Wed, 13 May 2020 11:28:25 +0100
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> yesterday i started on integrating the LDSTCompUnit into the
> scoreboard and immediately ran into a brick wall in the form of the
> address-request/release signalling.  when go_addr is raised (in
> response to req_addr), the LDSTCompUnit is supposed to drop req_addr
> one cycle later: instead it stays high.
> 
> i also investigated microwatt to find out what the heck is going on
> with the register-order-swapping.  turns out that different classes of
> operations (logical, rotate, arith) have different ordering.  why? who
> knows.
> 
> today i will continue working through the address-negotiation in LDSTCompUnit.
> 
> l.
> 
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

I've looked into the soc/src/soc/decoder/isa and src/soc/alu/ directories.
There is a TODO that references the PowerISA PDF, so I will first read the 
following sections, before writing anything.
        # 4.2.2 p124 FPSCR (definitely "separate" - not in SPR)
        #            note that mffs, mcrfs, mtfsf "manage" this FPSCR
        # 2.3.1 CR (and sub-fields CR0..CR6 - CR0 SO comes from XER.SO)
        #         note that mfocrf, mfcr, mtcr, mtocrf, mcrxrx "manage" CRs
        # 2.3.2 LR   (actually SPR #8)
        # 2.3.3 CTR  (actually SPR #9)
        # 2.3.4 TAR  (actually SPR #815)
        # 3.2.2 p45 XER  (actually SPR #0)
        # 3.2.3 p46 p232 VRSAVE (actually SPR #256)
I assume that that the version of the pdf referenced is still 3.0 one and not 3.1 recently released.
       
Tobias

-- 
Tobias Platen <libre-soc[at]platen-software[dot]de>

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] daily kan-ban update 13may2020

[Luke Kenneth Casson Leighton]

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

On Wed, May 13, 2020 at 2:56 PM Tobias Platen
<libre-soc@platen-software.de> wrote:
>
> On Wed, 13 May 2020 11:28:25 +0100
> Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>
> > yesterday i started on integrating the LDSTCompUnit into the
> > scoreboard and immediately ran into a brick wall in the form of the
> > address-request/release signalling.  when go_addr is raised (in
> > response to req_addr), the LDSTCompUnit is supposed to drop req_addr
> > one cycle later: instead it stays high.
> >
> > i also investigated microwatt to find out what the heck is going on
> > with the register-order-swapping.  turns out that different classes of
> > operations (logical, rotate, arith) have different ordering.  why? who
> > knows.
> >
> > today i will continue working through the address-negotiation in LDSTCompUnit.
> >
> > l.
> >
> > _______________________________________________
> > libre-riscv-dev mailing list
> > libre-riscv-dev@lists.libre-riscv.org
> > http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>
> I've looked into the soc/src/soc/decoder/isa and src/soc/alu/ directories.
> There is a TODO that references the PowerISA PDF, so I will first read the
> following sections, before writing anything.

a really useful self-contained sub-task would be to convert this to nmigen:
https://github.com/antonblanchard/microwatt/blob/master/countzero.vhdl

focussing on that would allow you to do something immediately that did
not require a lot of background reading or preparation, and yet is really
important and valuable, and can be done fast.

you can see what i did with rotator.py to get a feel for how that's done.
these are two really important gotchas to watch out for:

* signal(HI downto LO) must be converted to signal[LO:HI+1]  **NOTE
THE ADD ONE**
* A & B & C must be converted to Cat(C, B, A)

as this is only 140 lines of code, if you plan to - or imagine that -
the time taken
is greater than 60 to 90 minutes to complete a first cut (which should be
committed immediately), then something is wrong.  this is a half to one day
task, absolute max.

going on from there - beyond that half-day:

if you can also write a formal proof, these we can donate more, where for
the "main core" - just the countzero - we are running low from that budget.
formal proofs are basically "a bunch of asserts" exactly as you would have
in c++ code or any other language with "assert if this is true or not".

>         # 4.2.2 p124 FPSCR (definitely "separate" - not in SPR)
>         #            note that mffs, mcrfs, mtfsf "manage" this FPSCR
>         # 2.3.1 CR (and sub-fields CR0..CR6 - CR0 SO comes from XER.SO)
>         #         note that mfocrf, mfcr, mtcr, mtocrf, mcrxrx "manage" CRs
>         # 2.3.2 LR   (actually SPR #8)
>         # 2.3.3 CTR  (actually SPR #9)
>         # 2.3.4 TAR  (actually SPR #815)
>         # 3.2.2 p45 XER  (actually SPR #0)
>         # 3.2.3 p46 p232 VRSAVE (actually SPR #256)
> I assume that that the version of the pdf referenced is still 3.0 one and not 3.1 recently released.

correct.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] daily kan-ban update 13may2020

[Tobias Platen]

On Wed, 13 May 2020 15:33:53 +0100
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> a really useful self-contained sub-task would be to convert this to nmigen:
> https://github.com/antonblanchard/microwatt/blob/master/countzero.vhdl
I think I could do this in an hour or less.

-- 
Tobias Platen <libre-soc[at]platen-software[dot]de>

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] daily kan-ban update 13may2020

[Luke Kenneth Casson Leighton]

On Wed, May 13, 2020 at 3:43 PM Tobias Platen
<libre-soc@platen-software.de> wrote:
>
> On Wed, 13 May 2020 15:33:53 +0100
> Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>
> > a really useful self-contained sub-task would be to convert this to nmigen:
> > https://github.com/antonblanchard/microwatt/blob/master/countzero.vhdl
> I think I could do this in an hour or less.

ok great.  create a directory in soc.git, src/soc/countzero to work in.
don't commit the VHDL to the repo, reference it in a comment at the top
of countzero.py

also useful as a "very basic" simulation and confirmation of functionality
i'd recommend doing a unit test similar to countzero_tb.vhdl

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] daily kan-ban update 13may2020

[Cole Poirier]

Yesterday, after several rounds of failed testing of the coriolis2
chroot setup script, I conclueded that coriolis2 currently has a bug in
it that I should wait on JP for (thank for helping me come to this
conclusion luke). Today I will work on the non-chroot HDL_Workflow setup script.

Cole

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] daily kan-ban update 13may2020

[Luke Kenneth Casson Leighton]

tobias: encoder, in countzero.vhdl, is PriorityEncoder in nmigen.
however you have to invert the input bits for right-mode input[::-1]
or something like that.  there may be a function for it in nmigen

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev