[libre-riscv-dev] daily kan-ban update 09jun2020

[libre-riscv-dev] daily kan-ban update 09jun2020

[Alain D D Williams]

Sigh ... trying to get bzkanban working ......

I implemented the latest bugzilla - this works nicely (bugzilla that is, not bzkanban)

If you want to play with it you need to put this into your /etc/hosts

46.235.227.77   bugs-5.0.6.libre-soc.org

I can make that the current bugzilla if it does not break anything.


So: I then got bugzilla (5.0.6) working under another Debian 10 machine under
nginx with postgresql - that works.

Blood on my keyboard when I tried to get bzkanban working.

Run up Apache and, after a couple of sillies, it works - bugzilla and bzkanban I mean.

Flip back & forth between the two - never under works nginx, always under
apache. I'm stopping - there is an Einstein quote popping up in my head.


So: if you want bzkanban - I can install apache & replace nginx. I'm *****ed
if I can see another way.

Is there a good reason for needing nginx ?

I'm off to bed.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

_______________________________________________
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 09jun2020

[Luke Kenneth Casson Leighton]

On Tue, Jun 9, 2020 at 10:49 PM Alain D D Williams <addw@phcomp.co.uk> wrote:
>
> Sigh ... trying to get bzkanban working ......
>
> I implemented the latest bugzilla - this works nicely (bugzilla that is, not bzkanban)
>
> If you want to play with it you need to put this into your /etc/hosts
>
> 46.235.227.77   bugs-5.0.6.libre-soc.org

nicely done, alain.  actually we can probably put that into the dns.

>
> I can make that the current bugzilla if it does not break anything.
>
>
> So: I then got bugzilla (5.0.6) working under another Debian 10 machine under
> nginx with postgresql - that works.
>
> Blood on my keyboard when I tried to get bzkanban working.
>
> Run up Apache and, after a couple of sillies, it works - bugzilla and bzkanban I mean.

hurrah!

> Flip back & forth between the two - never under works nginx, always under
> apache. I'm stopping - there is an Einstein quote popping up in my head.

:)

>
> So: if you want bzkanban - I can install apache & replace nginx. I'm *****ed
> if I can see another way.
>
> Is there a good reason for needing nginx ?

mmm... i switched all my web services (including for clients) over to
it after learning of its lower workload and greater security by
design.

if it's getting in the way, although it makes me slightly nervous we
can flip over to it.

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] daily kan-ban update 09jun2020

[Luke Kenneth Casson Leighton]

yesterday:

* reviewed slide deck
* did some minor "no-brain" code-morphs
* a bit on TRAP including adding a privilege testing function

today:

* a bit more on OP_TRAP
* augmented LenExpand to be byte-capable (for shift/mask in LD/ST)

rest of today:

* looking to do proper byte shift/mask in L0CacheBuffer.

---
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 09jun2020

[Tobias Platen]

yesterday:

not much, reading some of the code only

today:

ld/st splitter and port interface
 

_______________________________________________
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 09jun2020

[Luke Kenneth Casson Leighton]

On Tue, Jun 9, 2020 at 2:23 PM Tobias Platen
<libre-soc@platen-software.de> wrote:
>
> yesterday:
>
> not much, reading some of the code only
>
> today:
>
> ld/st splitter and port interface

we're going to need this, it's coming up on the critical path, because
it's the way that mis-alignment will be taken care of.

i've just added that extra argument to LenSplitter which allows it to
create a *byte* mask, where LDSTSplitter rather hilariously deals only
with bits.

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 09jun2020

[Jacob Lifshay]

yesterday:
not much

today:
working on mul and div units -- they will most likely increase the core's
gate count by a large amount, particularly the div pipeline, since it's
designed for high performance, not as much for low area.

Also, I saw the new *inter-core* speculative execution vulnerability in
Intel processors, the previous ones were mostly intra-core.

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 09jun2020

[Luke Kenneth Casson Leighton]

On Tue, Jun 9, 2020 at 6:21 PM Jacob Lifshay <programmerjake@gmail.com> wrote:

> yesterday:
> not much

:) rest is good

> today:
> working on mul and div units -- they will most likely increase the core's
> gate count by a large amount, particularly the div pipeline, since it's
> designed for high performance, not as much for low area.

hm hm well as long as it is below 45k LUTs we should be good.  last
resort there is always the microwatt div algorithm, which i noticed in
its FSM has the option to skip large batches of zeros (8 at a time).
personally i hope it fits, hmm it should be easy to check, with
synth_ecp5
this is for test_div_pipe_core_bit_width_8_fract_width_4_radix_2.il

=== top ===

   Number of cells:               3411
     CCU2C                         461
     L6MUX21                       116
     LUT4                         1777
     PFUMX                         539
     TRELLIS_FF                    518

that's a very small one, though, isn't it?  bit-width of 8?

> Also, I saw the new *inter-core* speculative execution vulnerability in
> Intel processors, the previous ones were mostly intra-core.

oh no!  i don't know whether to laugh, start to feel sorry for them,
or look it up and make sure we don't make the same mistake.  probably
all of those :)

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 09jun2020

[Cole Poirier]

On Jun 9 2020, at 6:11 am, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> yesterday:
> 
> * reviewed slide deck

Thank you Luke, your help so far has already made the slide deck much
better. Looking forward to your comments as you have time to read. Not
as much of a rush now since the pitch has been moved to next wednesday :)

Yesterday: spent entire day writing slide deck

> * a bit on TRAP including adding a privilege testing function
> today:
> 
> * a bit more on OP_TRAP

Today:

I'm excited to start writing unit tests for the TRAP pipeline today, and
to use the learning methodology you laid out on bug 325 for me that
involves looking at gtkwave timing diagrams.



_______________________________________________
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 09jun2020

[Luke Kenneth Casson Leighton]

On Tue, Jun 9, 2020 at 8:35 PM Cole Poirier <colepoirier@gmail.com> wrote:

> Today:
>
> I'm excited to start writing unit tests for the TRAP pipeline today, and
> to use the learning methodology you laid out on bug 325 for me that
> involves looking at gtkwave timing diagrams.

with michael having added the qemu-execution thing, you should now
first be able to add a "twi" (or tdi) instruction unit test to that,
first.

this will allow you to check that the *simulator* is correct.

then after you know that the *simulator* is correct, the same unit
test can be used in test_pipe_caller.py, and in that way you will then
be able to test that the *hardware* is 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 09jun2020

[Cole Poirier]

On Jun 9 2020, at 1:15 pm, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> with michael having added the qemu-execution thing, you should now
> first be able to add a "twi" (or tdi) instruction unit test to that,
> first.

This is filling in the pseudo-code for the soc/decoder/isa/caller.py?

> this will allow you to check that the *simulator* is correct.

How do I use qemu to verify that the simulator is correct? Sorry I've
looked on the bug report and the wiki? Is there a wiki page with the
procedure? If not, what's the procedure I should follow?
 
> then after you know that the *simulator* is correct, the same unit
> test can be used in test_pipe_caller.py, and in that way you will then
> be able to test that the *hardware* is correct.

Sounds like a plan.

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 09jun2020

[Luke Kenneth Casson Leighton]

On Tue, Jun 9, 2020 at 10:01 PM Cole Poirier <colepoirier@gmail.com> wrote:
>
> On Jun 9 2020, at 1:15 pm, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>
> > with michael having added the qemu-execution thing, you should now
> > first be able to add a "twi" (or tdi) instruction unit test to that,
> > first.
>
> This is filling in the pseudo-code for the soc/decoder/isa/caller.py?

yeees... however the first thing to do is write the unit test.  then
you have a means by which the code in caller.py py will be... called.
without writing the unit test, you have no way to call that code,
therefore how can you know if what you write is correct?

> > this will allow you to check that the *simulator* is correct.
>
> How do I use qemu to verify that the simulator is correct?

well, first we recall that it was michael who added the code, under
the recent bugreport from monday.  so we do this:

$ git log > /tmp/f

then, we open up that file, and grep "Michael".   that shows this line:
commit 613b15043fc7302c8ad4495b6bff65063eb1c0e3
Author: Michael Nolan <mtnolan2640@gmail.com>
Date:   Mon Jun 8 13:36:57 2020 -0400

    Restore test_sim.py, begin modifying it for testing against qemu

that looks about right, doesn't it?  (i don't know the answer, either,
however i am simply following a deductive reasoning trail, from
evidence left by michael).

so let's do a git diff

$ git diff 613b15 3a0b0f

and that shows (just as the comment says) a file called test_sim.py.
from the top of the diff it shows that that test_sim.py file is in
soc/simulator/test_sim.py

so now we know where that file is.

> Sorry I've
> looked on the bug report and the wiki? Is there a wiki page with the
> procedure? If not, what's the procedure I should follow?

you need to think through a process of deducing this information for yourself.

looking at that file, it's a unit test, isn't it?  and it has the
exact same "run_tst_program" pattern that's in the test_pipe_caller.py
programs, doesn't it?

therefore, logically, if we put instructions in a unit test listing,
we expect them to be run, yes?

and if you look at test_sim.py's "run_tst_program()" function, we can
see that it has two aspects: the first being that the simulator's
"run_tst" function is called, and the second that the qemu
run_program() function is called.

each of those will modify their respective register files, and
qemu_register_compare walks through them and compares them, doesn't
it?

this really isn't hard to deduce!

therefore to test twi, we add a new unit test to that file, and run
it.  now, it *may* fail (because it's a trap, and we don't actually
know how qemu will react to that).  we'll cross that bridge when we
come to it, ok?  we expect at least the PC to be changed to 0x700, so
will have to work out how to get the PC out of qemu.


in essence, here, there is a series - a chain - of logical deductive
reasoning that allows us, from a few well-known sources that we have
access to, to find the information that was sought.

being able to do this, regardless of the size of the codebase and
regardless of whether quotes documentation quotes exists, is an
absolutely essential and critically important skill.

it is however important that you appreciate and have confidence that
you *can* in fact deploy such techniques (or others like it) in order
to find what you seek.

when this particular technique has failed me (due to the codebase size
being over a quarter of a million lines) i have been known to print it
out entirely on double-sided double-column pages (where an 80 char
limit has been absolutely essential in meeting that), and literally
going through absolutely every single page in the course of a day,
speed-reading flicking one by one, to get a "subconscious" handle on
the codebase that then allows me to go "i've seen that before" and
stand a chance of being able to find it relatively quickly.

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 09jun2020

[Luke Kenneth Casson Leighton]

euurrgh took a while

powerpc64-linux-gnu-gdb -interpreter=mi
~-data-list-register-names
^done,register-names=["r0","r1","r2","r3","r4","r5","r6","r7","r8","r9","r10","r11","r12","r13","r14","r15","r16","r17","r18","r19","r20","r21","r22","r23","r24","r25","r26","r27","r28","r29","r30","r31","f0","f1","f2","f3","f4","f5","f6","f7","f8","f9","f10","f11","f12","f13","f14","f15","f16","f17","f18","f19","f20","f21","f22","f23","f24","f25","f26","f27","f28","f29","f30","f31","pc","msr","cnd","lr","cnt","xer","fpscr","mq"

ah HA!  one of those is the condition register!

_______________________________________________
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 09jun2020

[Cole Poirier]

On Jun 9 2020, at 2:48 pm, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> On Tue, Jun 9, 2020 at 10:01 PM Cole Poirier <colepoirier@gmail.com> wrote:
>> 
>> On Jun 9 2020, at 1:15 pm, Luke Kenneth Casson Leighton
>> <lkcl@lkcl.net> wrote:
>> 
>> > with michael having added the qemu-execution thing, you should now
>> > first be able to add a "twi" (or tdi) instruction unit test to that,
>> > first.
>> 
>> This is filling in the pseudo-code for the soc/decoder/isa/caller.py?
> 
> yeees... however the first thing to do is write the unit test.  then
> you have a means by which the code in caller.py py will be... called.
> without writing the unit test, you have no way to call that code,
> therefore how can you know if what you write is correct?
> 
>> > this will allow you to check that the *simulator* is correct.
>> 
>> How do I use qemu to verify that the simulator is correct?
> 
> well, first we recall that it was michael who added the code, under
> the recent bugreport from monday.  so we do this:
> 
> $ git log > /tmp/f
> 
> then, we open up that file, and grep "Michael".   that shows this line:
> commit 613b15043fc7302c8ad4495b6bff65063eb1c0e3
> Author: Michael Nolan <mtnolan2640@gmail.com>
> Date:   Mon Jun 8 13:36:57 2020 -0400
> 
>    Restore test_sim.py, begin modifying it for testing against qemu
> 
> that looks about right, doesn't it?  (i don't know the answer, either,
> however i am simply following a deductive reasoning trail, from
> evidence left by michael).
> 
> so let's do a git diff
> 
> $ git diff 613b15 3a0b0f
> 
> and that shows (just as the comment says) a file called test_sim.py.
> from the top of the diff it shows that that test_sim.py file is in
> soc/simulator/test_sim.py
> 
> so now we know where that file is.
> 
>> Sorry I've
>> looked on the bug report and the wiki? Is there a wiki page with the
>> procedure? If not, what's the procedure I should follow?
> 
> you need to think through a process of deducing this information for yourself.
> 
> looking at that file, it's a unit test, isn't it?  and it has the
> exact same "run_tst_program" pattern that's in the test_pipe_caller.py
> programs, doesn't it?
> 
> therefore, logically, if we put instructions in a unit test listing,
> we expect them to be run, yes?
> 
> and if you look at test_sim.py's "run_tst_program()" function, we can
> see that it has two aspects: the first being that the simulator's
> "run_tst" function is called, and the second that the qemu
> run_program() function is called.
> 
> each of those will modify their respective register files, and
> qemu_register_compare walks through them and compares them, doesn't
> it?
> 
> this really isn't hard to deduce!
> 
> therefore to test twi, we add a new unit test to that file, and run
> it.  now, it *may* fail (because it's a trap, and we don't actually
> know how qemu will react to that).  we'll cross that bridge when we
> come to it, ok?  we expect at least the PC to be changed to 0x700, so
> will have to work out how to get the PC out of qemu.
> 
> 
> in essence, here, there is a series - a chain - of logical deductive
> reasoning that allows us, from a few well-known sources that we have
> access to, to find the information that was sought.
> 
> being able to do this, regardless of the size of the codebase and
> regardless of whether quotes documentation quotes exists, is an
> absolutely essential and critically important skill.
> 
> it is however important that you appreciate and have confidence that
> you *can* in fact deploy such techniques (or others like it) in order
> to find what you seek.
> 
> when this particular technique has failed me (due to the codebase size
> being over a quarter of a million lines) i have been known to print it
> out entirely on double-sided double-column pages (where an 80 char
> limit has been absolutely essential in meeting that), and literally
> going through absolutely every single page in the course of a day,
> speed-reading flicking one by one, to get a "subconscious" handle on
> the codebase that then allows me to go "i've seen that before" and
> stand a chance of being able to find it relatively quickly.
> 
> l.

Thank you, I appreciate the walkthrough and the story about going the
old fashioned paper way. I thought that I had to do something in qemu
itself, which would have been outside the bounds of this deductive
reasoning process, as I have a tendency to get lost in forums and
documentation when dealing with complex, always buggy to some extent,
software like qemu. So I wanted to see if we had prior art pertaining to
qemu simulation. I think I should have taken the deductive reasoning
about the codebase approch for my other questions. I'm fighting my "aaah
I don't understand," and with your reminder and guide here will be able
to do so better next time.

> powerpc64-linux-gnu-gdb -interpreter=mi
> ~-data-list-register-names
> ^done,register-names=
>["r0","r1","r2","r3","r4","r5","r6","r7","r8","r9","r10","r11","r12","r13","r14","r15","r16","r17","r18","r19","r20","r21","r22","r23","r24","r25","r26","r27","r28","r29","r30","r31","f0","f1","f2","f3","f4","f5","f6","f7","f8","f9","f10","f11","f12","f13","f14","f15","f16","f17","f18","f19","f20","f21","f22","f23","f24","f25","f26","f27","f28","f29","f30","f31","pc","msr","cnd","lr","cnt","xer","fpscr","mq"

> ah HA!  one of those is the condition register!

Very cool and helpful. I think I over-stressed my self while working on
the presentation yesterday, which has caused me to inadvertantly 'take'
today off. Will be back and well rested to take on these challenges of
deductive reasoning, especially in using gtkwave to understand the ALU
signaling, tomorrow :)

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 09jun2020

[Luke Kenneth Casson Leighton]

> On Jun 9 2020, at 2:48 pm, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> Thank you, I appreciate the walkthrough and the story about going the
> old fashioned paper way. I thought that I had to do something in qemu
> itself, which would have been outside the bounds of this deductive
> reasoning process, as I have a tendency to get lost in forums and
> documentation when dealing with complex, always buggy to some extent,
> software like qemu.

hence the discussion in the bugreport (which you raised a couple days
ago?) about running actually against a POWER9 native.  skipping qemu
and running the programs directly, calling gdb on them.  exactly how
we'll do that, i have no idea yet, because it may require a huge
runtime, or possibly even virtualisation (to be able to run bare-metal
binaries directly).  have to see.

> So I wanted to see if we had prior art pertaining to
> qemu simulation. I think I should have taken the deductive reasoning
> about the codebase approch for my other questions.

it took me several years to work it out.

> I'm fighting my "aaah
> I don't understand," and with your reminder and guide here will be able
> to do so better next time.
>
> > powerpc64-linux-gnu-gdb -interpreter=mi
> > ~-data-list-register-names
> > ^done,register-names=
> >["r0","r1","r2","r3","r4","r5","r6","r7","r8","r9","r10","r11","r12","r13","r14","r15","r16","r17","r18","r19","r20","r21","r22","r23","r24","r25","r26","r27","r28","r29","r30","r31","f0","f1","f2","f3","f4","f5","f6","f7","f8","f9","f10","f11","f12","f13","f14","f15","f16","f17","f18","f19","f20","f21","f22","f23","f24","f25","f26","f27","f28","f29","f30","f31","pc","msr","cnd","lr","cnt","xer","fpscr","mq"
>
> > ah HA!  one of those is the condition register!
>
> Very cool and helpful.

i added them to test_sim.py - it causes test_sim.py unit tests to fail
(not your problem) because qemu defaults CR to 0x20000002 at start-up.
we can "fix" that by initialising the simulator CR to the same value.


> I think I over-stressed my self while working on
> the presentation yesterday, which has caused me to inadvertantly 'take'
> today off.

been there... :)

_______________________________________________
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 09jun2020

[Michael Nolan]

On 6/9/20 5:48 PM, Luke Kenneth Casson Leighton wrote:
>
> therefore to test twi, we add a new unit test to that file, and run
> it.  now, it *may* fail (because it's a trap, and we don't actually
> know how qemu will react to that).  we'll cross that bridge when we
> come to it, ok?  we expect at least the PC to be changed to 0x700, so
> will have to work out how to get the PC out of qemu.

While I don't remember exactly how I did it, I think I placed a 
breakpoint on the instruction after the end of the program and had qemu 
continue until it hit the breakpoint. Since trapping will never trigger 
that breakpoint I don't know what will happen. I suspect it will require 
a more creative solution though.

--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 09jun2020

[Cole Poirier]

On Jun 10 2020, at 11:53 am, Michael Nolan <mtnolan2640@gmail.com> wrote:
> While I don't remember exactly how I did it, I think I placed a 
> breakpoint on the instruction after the end of the program and had
> qemu 
> continue until it hit the breakpoint. Since trapping will never
> trigger 
> that breakpoint I don't know what will happen. I suspect it will
> require 
> a more creative solution though.

Thanks for the insight Michael!!

Cole

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