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

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

[Luke Kenneth Casson Leighton]

i will continue working on the multi-go/req new version of LDSTCompUnit.
got 30% through it yesterday.

talked with marketnext. marketnext have done a fantastic video for us, for
their hackathon. they set a deadline of mar 15th for applicants.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
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 06may2020

[Tobias Platen]

On Wed, 6 May 2020 10:37:50 +0100
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

I will be working on the simulator until Friday, integer ops that change the condition register.
The update_cr0 method in the InternalOpSimulator is partially implemented, currently one bit is not set yet.

Tobias


> i will continue working on the multi-go/req new version of LDSTCompUnit.
> got 30% through it yesterday.
> 
> talked with marketnext. marketnext have done a fantastic video for us, for
> their hackathon. they set a deadline of mar 15th for applicants.
> 
> l.
> 
> 
> 
> -- 
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev


-- 
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 06may2020

[Luke Kenneth Casson Leighton]

On Wed, May 6, 2020 at 2:31 PM Tobias Platen
<libre-soc@platen-software.de> wrote:

> On Wed, 6 May 2020 10:37:50 +0100
> Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>
> I will be working on the simulator until Friday, integer ops that change the condition register.

oh good.  we need that.

> The update_cr0 method in the InternalOpSimulator is partially implemented, currently one bit is not set yet.

ok, good to know - not a problem.  remember that if you're the only
person using some code (because it's entirely new), you can't do any
"harm" to the rest of the codebase, so commit regularly, do *not* wait
"a few days until it's totally finished".

then people who need to coordinate around what you're doing can do so,
because they see the regular commits in certain files.

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 06may2020

[Yehowshua]

Still doing the legal work..

Made an attempt to explain how PowerOP combined with Enum works…

https://libre-soc.org/Documentation/SOC/index/ <https://libre-soc.org/Documentation/SOC/index/>

Yehowshua
_______________________________________________
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 06may2020

[Luke Kenneth Casson Leighton]

On Wed, May 6, 2020 at 3:00 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> Still doing the legal work..

great.

> Made an attempt to explain how PowerOP combined with Enum works…
>
> https://libre-soc.org/Documentation/SOC/index/ <https://libre-soc.org/Documentation/SOC/index/>

PowerOp....
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/power_decoder.py;h=6094da1b4c84cbe1e1342cda62733bd3e1db6774;hb=HEAD#l106

ah that one mirrors what's in the CSV files, basically (where in
microwatt it was all hard-coded into the VHDL files).

it's directly equivalent to decode_rom_t type in microwatt:
https://github.com/antonblanchard/microwatt/blob/master/decode1.vhdl#L33

which you can then see in decode_types:
https://github.com/antonblanchard/microwatt/blob/master/decode_types.vhdl#L50

note that PowerOp is an *internal* type.  you would never actually use
or interface directily with PowerOp.  the "end-user" would use
PowerDecode2.
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/power_decoder2.py;h=4a3785efaba9c03d76a0159f19e4cab0219d0b7d;hb=HEAD#l329

as that contains *all* decoded fields (merged globally into the one
data structure regardless of whether they are needed), this is quite
annoying, so there are two *SUBSET* classes that "pinch" only the
fields that are needed (and there will be more of those).

ComputationUnit's Decode subset, ComALUOpSubset:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/alu_hier.py;h=0021c0793c6cf874060148ff83c0cee6720b6f8d;hb=HEAD#l23

and the LDSTCompUnit's Decode subset, CompLDSTOpSubset:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/compldst_multi.py;h=d1be1355ecce4f8e1b503c0b950a46ad306ae1f4;hb=HEAD#l66

note how CompLDSTOpSubset, CompALUOpSubset and Decode2Execute1Type all
derive from nmigen Record.  this provides "fields" (which comes from
the layout) which in turn allows us to walk through the Record and
grab only the subset of fields that we actually want to copy.

the "normal" Record.eq would unfortunately treat the *BITS* of each
derived Record as "a fixed sequential linear block of bits to copy"
(treating the two exactly like memcpy).

can i leave it with you to update the source code docstrings with
notes from the above?  if not, let me know and i'll do it.

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 06may2020

[Michael Nolan]

Working on branches in the power_pseudo simulator. I now have branch and 
link working, move to spr, and branch to lr and ctr working. I did run 
into an issue here though, in that the generated python is slightly 
broken in a way I'm not entirely sure I can fix inside the code 
generator. I added a way to automatically patch the generated python 
files to work around this.

The issue is in the following line:

         ctr_ok = BO[2] | (CTR[M:64] != 0) ^ BO[3]

It xors the result of comparing CTR to 0 (which is a bool) with BO[3] 
(Which is a selectableInt)
I'm not sure how to fix this aside from having the code generator 
surround every comparison expression with SelectableInt(x, bits=1)

--Michael

_______________________________________________
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 06may2020

[Luke Kenneth Casson Leighton]

On Wed, May 6, 2020 at 5:23 PM Michael Nolan <mtnolan2640@gmail.com> wrote:

> I'm not sure how to fix this aside from having the code generator
> surround every comparison expression with SelectableInt(x, bits=1)

it'll look awful however that's a perfectly reasonable solution - go
for it.  i'm amazed the auto-generated output is as readable as it is.

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 06may2020

[Luke Kenneth Casson Leighton]

btw at some point, michael, we need to stop using the "standard"
python operators and use explicit functions.

oh.  this is another way to fix it.  add functions eq, gt, ge to
globals, and get the codegenerato to do this instead:

  BO[2] | (eq(CTR[M:64],0)) ^ BO[3]

then, eq() can return a SelectableInt(x, bits=1) without having that
duplicated everywhere.

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 06may2020

[Jacob Lifshay]

Still figuring out load/store code...


found an interesting article in this week's This Week in Rust about forking
a process onto a remote computer:
https://thume.ca/2020/04/18/telefork-forking-a-process-onto-a-different-computer/

Jacob
_______________________________________________
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 06may2020

[Luke Kenneth Casson Leighton]

On Thu, May 7, 2020 at 6:53 AM Jacob Lifshay <programmerjake@gmail.com>
wrote:

> Still figuring out load/store code...
>

remember you don't have to do that "alone".  ask questions, even if it's
"what does this class do".  also that if one approach does not work (it's
been around 4 weeks now) perhaps a different approach?


>
> found an interesting article in this week's This Week in Rust about forking
> a process onto a remote computer:
>
> https://thume.ca/2020/04/18/telefork-forking-a-process-onto-a-different-computer/


ah bless 'im.  he's re-inventing DCE/RPC which solved this 25+ years ago
:)  i am constantly amazed by how completely unaware of fundamental
technology that already exists.

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