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

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

[Luke Kenneth Casson Leighton]

yesterday i pitched in with some commentary and review on the ALU side
of the ALU that michael is doing.  we need to back-reverse-engineer
some implicit "well-known-in-the-industry" architectural design
decisions related to how ALUs are fed immediates and register data
(RA, RB, RC/RS), so as not to overwhelm the design with wires.  it's
looking like the "RB" port by general long-standing convention is also
the "immediate data" port.

also i did a small commentary on the Libre-SOC article being written
by MarketNext, sigh they are used to using google docs, so we go with
that before moving to the wiki.  i also heard from roberto
(powerpc-notebook) he has done an interview with charbax and wondered
if we would like an introduction
https://www.youtube.com/watch?v=7kM2zqTEHa8

today i am going to start tying in the new LDSTCompUnit (currently
going "busy" and staying there) and it will be the first time to try
two simultaneous LDs (or STs).  i also crystallised some of the
waffling i did yesterday on bug #305 (ALU) after analysing the forms
for fixedshift and fixedarith, realised it might be worth considering
to split out shift into its own ALU.

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

[Tobias Platen]

On Tue, 12 May 2020 11:45:22 +0100
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

Today I began reading the code that michael had written. 
Tomorrow I will also have a short look into the PowerISA 3.1 spec. 

> yesterday i pitched in with some commentary and review on the ALU side
> of the ALU that michael is doing.  we need to back-reverse-engineer
> some implicit "well-known-in-the-industry" architectural design
> decisions related to how ALUs are fed immediates and register data
> (RA, RB, RC/RS), so as not to overwhelm the design with wires.  it's
> looking like the "RB" port by general long-standing convention is also
> the "immediate data" port.
> 
> also i did a small commentary on the Libre-SOC article being written
> by MarketNext, sigh they are used to using google docs, so we go with
> that before moving to the wiki.  i also heard from roberto
> (powerpc-notebook) he has done an interview with charbax and wondered
> if we would like an introduction
> https://www.youtube.com/watch?v=7kM2zqTEHa8
> 
> today i am going to start tying in the new LDSTCompUnit (currently
> going "busy" and staying there) and it will be the first time to try
> two simultaneous LDs (or STs).  i also crystallised some of the
> waffling i did yesterday on bug #305 (ALU) after analysing the forms
> for fixedshift and fixedarith, realised it might be worth considering
> to split out shift into its own ALU.
> 
> l.
> 
> _______________________________________________
> 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 12may2020

[Michael Nolan]

Yesterday I modified the ALU tests to read the alu inputs as specified 
in the instruction instead of hardcoded register numbers. I refactored 
the test to greatly reduce the amount of time it takes to run (went from 
~1m to ~3s on my computer)

Today I'd like to split out the shift and rotate instructions into their 
own separate FU

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

[Yehowshua]

I’m currently attending Create-X startup school at Launch 2020 - for Systèmes Libres.

I also got hired by Georgia Tech to help re-write the computer architecture class. The reason I mention this is that classes like these are very formative for students - and perhaps one of these students might contribute to Libre-SOC in the future.

With that in mind, I tried to incorporate concepts such as git, using nMigen, Cocotb, etc…

https://comparch-resources.ece.gatech.edu <https://comparch-resources.ece.gatech.edu/>

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

[Luke Kenneth Casson Leighton]

On Tue, May 12, 2020 at 3:29 PM Michael Nolan <mtnolan2640@gmail.com> wrote:
>
> Yesterday I modified the ALU tests to read the alu inputs as specified
> in the instruction instead of hardcoded register numbers.

great.  i think we also worked out, it's kinda been a long-standing
convention that, instead of adding yet another 64 bit data path to
feed the ALU, the RB wires are used to feed in the immediate.

otherwise you have 64 wires for RA, 64 wires for RB, 64 wires for
RC/RS, and *another* 64 wires for an immediate.

so this is why i think you see the 6600, and RISC-V, and Power, and
many others, all never doing a 2nd reg (RB) *and* an immediate.
there's a *third* register - RC - in the case of POWER, because unlike
RISC-V which seems to be based around 2-64-bit-inputs (except FMAC),
and 1-64-bit-output, POWER seems to be based around a much more
complex 3-64-bit-datapaths-in and up to *two* 64-bit-datapaths-out....
*plus* Condition Registers in and out.

> I refactored
> the test to greatly reduce the amount of time it takes to run (went from
> ~1m to ~3s on my computer)
>
> Today I'd like to split out the shift and rotate instructions into their
> own separate FU

i think that will help make things clearer, and the actual ALU code in
each module a lot shorter.

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

[Luke Kenneth Casson Leighton]

On Tue, May 12, 2020 at 3:43 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> I’m currently attending Create-X startup school at Launch 2020 - for Systèmes Libres.
>
> I also got hired by Georgia Tech to help re-write the computer architecture class.
> The reason I mention this is that classes like these are very formative for students -
> and perhaps one of these students might contribute to Libre-SOC in the future.

that's a really good idea.

> With that in mind, I tried to incorporate concepts such as git, using nMigen, Cocotb, etc…

honestly, if they're learning verilog and VHDL as the primary HDL,
it's like teaching 1980s programming.  i mean, it's _good_ that they
learn those - but move very very swiftly on.

something that might be really good to include as a teaching aid is
that online javascript logic simulation thing.  just to get them the
absolute basics of logic gates.

even something as basic as "design a 4-bit adder at the gate level....
now redo it in VHDL, and now redo it in nmigen" would be a really
instructive and eye-opening exercise - particularly if first specified
as "for a first version you're allowed in VHDL and nmigen to do it
using the "add" operator, but the second version you are not: it must
be done with half and full adders, as modules".

that would hammer home to them the significance of even using
something as quotes basic quotes as the "add" operator in nmigen and
VHDL.

the next level up from that would be to say, "ok now do a 128-bit
adder", and they will struggle to create efficient-looking code in
VHDL, because they will end up cut/pasting 128 full-adders into the
file.  the point of *that* exercise being to point out to them that
VHDL (and verilog) are *not* adequate modern languages (they never
were), and that nmigen you can use a *python for-loop* to create - and
link up - the 128 full-adders.

end-result: about 50 lines of python code instead of 300+ lines of
heavily-duplicated VHDL.

l.

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

[libre-riscv-dev] teaching the benefits of using nmigen over VHDL/Verilog

[Jacob Lifshay]

On Tue, May 12, 2020, 08:04 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> the next level up from that would be to say, "ok now do a 128-bit
> adder", and they will struggle to create efficient-looking code in
> VHDL, because they will end up cut/pasting 128 full-adders into the
> file.  the point of *that* exercise being to point out to them that
> VHDL (and verilog) are *not* adequate modern languages (they never
> were), and that nmigen you can use a *python for-loop* to create - and
> link up - the 128 full-adders.
>

That may not be an adequate demonstration, since a 128-bit ripple adder can
be implemented in a few lines using the following pseudo-Verilog:

module full_adder(a, b, c_in, c_out, o);
    wire [127:0] a, b, c_in, c_out, o;
    assign o = a ^ b ^ c_in;
    assign c_out = (a & b) | (a & c_in) | (b & c_in);
endmodule

module adder(a, b, c_in, c_out, o);
    wire [127:0] a, b, o, c;
    wire c_in, c_out;
    full_adder fa(
        .a: a,
        .b: b,
        .o: o,
        .c_in: {c[126:0], c_in},
        .c_out: c,
    );
    assign c_out = c[127];
endmodule

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] teaching the benefits of using nmigen over VHDL/Verilog

[Luke Kenneth Casson Leighton]

On Wednesday, May 13, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:

> On Tue, May 12, 2020, 08:04 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
> wrote:
>
> > the next level up from that would be to say, "ok now do a 128-bit
> > adder", and they will struggle to create efficient-looking code in
> > VHDL, because they will end up cut/pasting 128 full-adders into the
> > file.  the point of *that* exercise being to point out to them that
> > VHDL (and verilog) are *not* adequate modern languages (they never
> > were), and that nmigen you can use a *python for-loop* to create - and
> > link up - the 128 full-adders.
> >
>
> That may not be an adequate demonstration, since a 128-bit ripple adder can
> be implemented in a few lines using the following pseudo-Verilog:
>
> module full_adder(a, b, c_in, c_out, o);
>     wire [127:0] a, b, c_in, c_out, o;
>     assign o = a ^ b ^ c_in;
>     assign c_out = (a & b) | (a & c_in) | (b & c_in);
> endmodule


that's the simple version (and a cool one), i was thinking in terms of a
suite of single-bit full adders that then need to be manually linked up.

in verilog or vhdl this is a total pain.

in nmigen it is just a for loop with setattr(m.submodules, "fulladd%d" % i,
fainstance)

the very simplicity of doing a full adder is why it would work as a rapid
demonstration of using python for HDL.

if the exercise were more complex the design of the submodule would
distract from the point.

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] teaching the benefits of using nmigen over VHDL/Verilog

[Michael Nolan]

On 5/13/20 2:18 PM, Luke Kenneth Casson Leighton wrote:
> that's the simple version (and a cool one), i was thinking in terms of a
> suite of single-bit full adders that then need to be manually linked up.
>
> in verilog or vhdl this is a total pain.
>
I agree it's easier to do in nmigen, but both verilog and vhdl support 
generate statements for doing just that.

module wide_adder(o, a, b);
    input [8:0] a;
    input [8:0] b;
    output [8:0] o;

    genvar     i;

    wire [9:0]     carries;
    assign carries[0] = 0;

    generate
       for(i=0; i<9; i=i+1) begin
      adder u0 (.o(o[i]), .carry_out(carries[i+1]),
            .a(a[i]), .b(b[i]),
            .carry_in(carries[i]));
       end
    endgenerate
endmodule

--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] teaching the benefits of using nmigen over VHDL/Verilog

[Jacob Lifshay]

On Wed, May 13, 2020, 11:52 Michael Nolan <mtnolan2640@gmail.com> wrote:

> On 5/13/20 2:18 PM, Luke Kenneth Casson Leighton wrote:
> > that's the simple version (and a cool one), i was thinking in terms of a
> > suite of single-bit full adders that then need to be manually linked up.
> >
> > in verilog or vhdl this is a total pain.
> >
> I agree it's easier to do in nmigen, but both verilog and vhdl support
> generate statements for doing just that.
>

Maybe a better (though maybe not realistic) example is trying to xor all
input bits where the bits' indexes are prime numbers, that would be
relatively easy in nmigen but quite hard in VHDL or Verilog.

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] teaching the benefits of using nmigen over VHDL/Verilog

[Luke Kenneth Casson Leighton]

On Wednesday, May 13, 2020, Michael Nolan <mtnolan2640@gmail.com> wrote:

> On 5/13/20 2:18 PM, Luke Kenneth Casson Leighton wrote:
>
>> that's the simple version (and a cool one), i was thinking in terms of a
>> suite of single-bit full adders that then need to be manually linked up.
>>
>> in verilog or vhdl this is a total pain.
>>
>> I agree it's easier to do in nmigen, but both verilog and vhdl support
> generate statements for doing just that.


oh! nice! i kinda learned them both by osmosis :)

so it would be a side by side comparison of how to do submodules.

i wonder where it gets really difficult (primes is a nice example, jacob).

i know.  something where you pass in different Record layouts in nmigen.
VHDL you would have to do macro substitution of the record type, and only
mentor graphics sv supports records as arguments to modules.

then the next horrible thing to do would be a multiple inheritance python
module, or, like in the FP code surrounding ctx and pspec, use dynamic
classes that override __new__.

first time i did something like that and actually had to ask on
stackoverflow :)

even just passing in the class (ctx kls) would cause a seasoned verilog HDL
engineer to blow a fuse :)

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