From lkcl at lkcl.net  Sat Aug  1 14:55:27 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sat, 1 Aug 2020 14:55:27 +0100
Subject: [libre-riscv-dev] microwatt feature request: "switch off all
 optimisations" mode
In-Reply-To: <CAPweEDw+-AKRy9jB8Q6E-QiQ+OhM-BS4HizgAsh37buVd+Y0Gg@mail.gmail.com>
References: <CAPweEDw+-AKRy9jB8Q6E-QiQ+OhM-BS4HizgAsh37buVd+Y0Gg@mail.gmail.com>
Message-ID: <CAPweEDzFJH4MeTGHaHOj0++5ZbntYgWNMkMs8VDVFK1anA_2=w@mail.gmail.com>

On Friday, July 31, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

>
> what would you suggest here? how can we "single-step" microwatt?  clearly
> performance is not important: cycle-accurate comparisons is the goal.
>

i since realised that the DMI interface serves this purpose, and
investigated core_debug.vhdl

with a little bit (or a lot) of futzing about with a FSM i should be able
to run a single instruction then cycle through all of the GPRs, PC and MSR,
dumping them out.

by implementing the same interface in libresoc i can do a cycle by cycle
comparison and find the discrepancies.

it would be particularly useful to be able to get at the SPRs and the CR as
well, this way.

is there a standard for DMI address bus locations?

l



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

From lkcl at lkcl.net  Sat Aug  1 18:58:55 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sat, 1 Aug 2020 18:58:55 +0100
Subject: [libre-riscv-dev] daily kan-ban update 01aug2020
Message-ID: <CAPweEDxNBah24TSdRe20dhSsRbB5sO56FbjJ32FpV78HMJ3vUA@mail.gmail.com>

tasks:

*
https://bugs.libre-soc.org/showdependencytree.cgi?maxdepth=1&id=383&hide_resolved=1

yesterday:

* exploring litex libresoc simulation, found several bugs

today:

* looked at shiftrot formal proof
* continued litex simulation investigation

finding out what is going on in litex is hampered significantly by not
being able to do side-by-side comparisons.

therefore what i am going to do is add a dmi interface to libresoc and get
the litex sim to single-step then dump registers.  with a compatible dmi
interface the same sim code FSM will be useable on both types of core.

discrepancies should then be easy to spot by using diff on the two debug
logs.

at that point i will know which instruction is wrong, where right now it is
excruciating guesswork.

l.




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

From lkcl at lkcl.net  Sun Aug  2 16:36:05 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sun, 2 Aug 2020 16:36:05 +0100
Subject: [libre-riscv-dev] daily kan-ban update 02aug2020
Message-ID: <CAPweEDwgvVYfakyzQBpWTLkOLOoDb9zjf+EqT2nJLNGSsPjQGw@mail.gmail.com>

today:

* converting DMI debug interface to nmigen (done, not tested)

interestingly i had already added start/stop signals just not with an
interface on them.

next task will be to integrate with the test core (including reading
registers), and after that try enumerating and single-stepping.

l.



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

From lkcl at lkcl.net  Mon Aug  3 02:00:49 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Mon, 3 Aug 2020 02:00:49 +0100
Subject: [libre-riscv-dev] microwatt feature request: "switch off all
 optimisations" mode
In-Reply-To: <ecbdd6b08e1937fa1d6b953add782909e4db8015.camel@amazon.com>
References: <CAPweEDw+-AKRy9jB8Q6E-QiQ+OhM-BS4HizgAsh37buVd+Y0Gg@mail.gmail.com>
 <CAPweEDzFJH4MeTGHaHOj0++5ZbntYgWNMkMs8VDVFK1anA_2=w@mail.gmail.com>
 <ecbdd6b08e1937fa1d6b953add782909e4db8015.camel@amazon.com>
Message-ID: <CAPweEDxNzKwFdCG1PvbMDHqYa_LzpJyN0sQF8LNYDir=sUWcOw@mail.gmail.com>

On Monday, August 3, 2020, Herrenschmidt, Benjamin <benh at amazon.com> wrote:

>
> > is there a standard for DMI address bus locations?
>
> Not really... I just made it all up :-)


that's funny, i like it :)

can we collaborate on making some more up, for example adding CR, XER and
the remaining SPRs to the list of registers?

also bear in mind, FP regs may get added (to microwatt).  and that in
libresoc we intend to expand the scalar int and fp regs to 128 entries.

l.



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

From benh at kernel.crashing.org  Mon Aug  3 02:05:00 2020
From: benh at kernel.crashing.org (Benjamin Herrenschmidt)
Date: Mon, 03 Aug 2020 11:05:00 +1000
Subject: [libre-riscv-dev] [OpenPOWER-HDL-Cores] microwatt feature
 request: "switch off all optimisations" mode
In-Reply-To: <CAPweEDxNzKwFdCG1PvbMDHqYa_LzpJyN0sQF8LNYDir=sUWcOw@mail.gmail.com>
References: <CAPweEDw+-AKRy9jB8Q6E-QiQ+OhM-BS4HizgAsh37buVd+Y0Gg@mail.gmail.com>
 <CAPweEDzFJH4MeTGHaHOj0++5ZbntYgWNMkMs8VDVFK1anA_2=w@mail.gmail.com>
 <ecbdd6b08e1937fa1d6b953add782909e4db8015.camel@amazon.com>
 <CAPweEDxNzKwFdCG1PvbMDHqYa_LzpJyN0sQF8LNYDir=sUWcOw@mail.gmail.com>
Message-ID: <ef44d4fe97ab91f802f29e57212bdd3c0a7bdadf.camel@kernel.crashing.org>

On Mon, 2020-08-03 at 02:00 +0100, Luke Kenneth Casson Leighton wrote:
> 
> 
> On Monday, August 3, 2020, Herrenschmidt, Benjamin <benh at amazon.com>
> wrote:
> > > is there a standard for DMI address bus locations?
> > 
> > Not really... I just made it all up :-)
> 
> that's funny, i like it :)
> 
> can we collaborate on making some more up, for example adding CR, XER
> and the remaining SPRs to the list of registers?

Sure. Patches welcome ;-) Also check out Paul's WIP branches, he also
occasionally add stuff.

> also bear in mind, FP regs may get added (to microwatt).  and that in
> libresoc we intend to expand the scalar int and fp regs to 128
> entries.

Paul has some of that in his FPU work already.

Cheers,
Ben.




From lkcl at lkcl.net  Mon Aug  3 02:35:40 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Mon, 3 Aug 2020 02:35:40 +0100
Subject: [libre-riscv-dev] microwatt feature request: "switch off all
 optimisations" mode
In-Reply-To: <ef44d4fe97ab91f802f29e57212bdd3c0a7bdadf.camel@kernel.crashing.org>
References: <CAPweEDw+-AKRy9jB8Q6E-QiQ+OhM-BS4HizgAsh37buVd+Y0Gg@mail.gmail.com>
 <CAPweEDzFJH4MeTGHaHOj0++5ZbntYgWNMkMs8VDVFK1anA_2=w@mail.gmail.com>
 <ecbdd6b08e1937fa1d6b953add782909e4db8015.camel@amazon.com>
 <CAPweEDxNzKwFdCG1PvbMDHqYa_LzpJyN0sQF8LNYDir=sUWcOw@mail.gmail.com>
 <ef44d4fe97ab91f802f29e57212bdd3c0a7bdadf.camel@kernel.crashing.org>
Message-ID: <CAPweEDyEo9YjQBMLQDgdsn9gFbRi1OMuKMmjUida_vGsLD5sqg@mail.gmail.com>

On Monday, August 3, 2020, Benjamin Herrenschmidt <benh at kernel.crashing.org>
wrote:

> On Mon, 2020-08-03 at 02:00 +0100, Luke Kenneth Casson Leighton wrote:
> >
> >
> > On Monday, August 3, 2020, Herrenschmidt, Benjamin <benh at amazon.com>
> > wrote:
> > > > is there a standard for DMI address bus locations?
> > >
> > > Not really... I just made it all up :-)
> >
> > that's funny, i like it :)
> >
> > can we collaborate on making some more up, for example adding CR, XER
> > and the remaining SPRs to the list of registers?
>
> Sure. Patches welcome ;-)


ah i was thinking more along the lines of agreeing a spec that suits both
teams, even if the definitions are reserved for later implementation.

(btw we've an october tapeout deadline and i am not yet a vhdl developer).

by agreeing a set of registers, future teams with their own implementation
will want to save development effort and conform to the same spec.


Also check out Paul's WIP branches, he also
> occasionally add stuff.


willdo.



>
> > also bear in mind, FP regs may get added (to microwatt).  and that in
> > libresoc we intend to expand the scalar int and fp regs to 128
> > entries.
>
> Paul has some of that in his FPU work already.


ah excellent.




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

From lkcl at lkcl.net  Mon Aug  3 03:38:42 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Mon, 3 Aug 2020 03:38:42 +0100
Subject: [libre-riscv-dev] microwatt feature request: "switch off all
 optimisations" mode
In-Reply-To: <cf55d74b4cb63f11c5817fffbe178d9895fbdaea.camel@amazon.com>
References: <CAPweEDw+-AKRy9jB8Q6E-QiQ+OhM-BS4HizgAsh37buVd+Y0Gg@mail.gmail.com>
 <CAPweEDzFJH4MeTGHaHOj0++5ZbntYgWNMkMs8VDVFK1anA_2=w@mail.gmail.com>
 <ecbdd6b08e1937fa1d6b953add782909e4db8015.camel@amazon.com>
 <CAPweEDxNzKwFdCG1PvbMDHqYa_LzpJyN0sQF8LNYDir=sUWcOw@mail.gmail.com>
 <ef44d4fe97ab91f802f29e57212bdd3c0a7bdadf.camel@kernel.crashing.org>
 <CAPweEDyEo9YjQBMLQDgdsn9gFbRi1OMuKMmjUida_vGsLD5sqg@mail.gmail.com>
 <cf55d74b4cb63f11c5817fffbe178d9895fbdaea.camel@amazon.com>
Message-ID: <CAPweEDzc_+zFyPdBUDGmrX4EA+N=b6+uLardX8AEj-9gEZoWXQ@mail.gmail.com>

On Monday, August 3, 2020, Herrenschmidt, Benjamin <benh at amazon.com> wrote:

> On Mon, 2020-08-03 at 02:35 +0100, Luke Kenneth Casson Leighton wrote:
> >
> > ah i was thinking more along the lines of agreeing a spec that suits
> > both teams, even if the definitions are reserved for later
> > implementation.
>
> That's fine, the patch could be adding a debug-regs-spec.txt :-)


that works :)


>
> (Or we could use a .h as a spec, and use it in mw_debug)


understood.

l.



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

From lkcl at lkcl.net  Mon Aug  3 17:53:17 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Mon, 3 Aug 2020 17:53:17 +0100
Subject: [libre-riscv-dev] nmigen monday irc meeting 1 hr (1800 UTC)
Message-ID: <CAPweEDzMeSQEaA=jyaRFPAr2YJ-+tyfFTiF5Ka6Lw7R--izymw@mail.gmail.com>

1800 UTC, freenode, #nmigen.
l.



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

From lkcl at lkcl.net  Mon Aug  3 18:46:46 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Mon, 3 Aug 2020 18:46:46 +0100
Subject: [libre-riscv-dev] daily kan-ban update 03aug2020
Message-ID: <CAPweEDyzGpVwcHbmnpBLZOZ0=FY3SEA-sVMmmwJ1hhprAkoiig@mail.gmail.com>

tasks:

*
https://bugs.libre-soc.org/showdependencytree.cgi?id=383&maxdepth=1&hide_resolved=1

today:

* nmigen IRC meeting (in 15 mins)
* linked DMI interface to core and got reset, start and stop working.

i need to test single-step as well as add regfile reading and being able to
get MSR and the PC.

at that point i can modify the litex sim.py to put either core in
singlestep mode and dump out registers and the PC, sequentially.

l.



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

From libre-soc at platen-software.de  Mon Aug  3 19:23:22 2020
From: libre-soc at platen-software.de (Tobias Platen)
Date: Mon, 3 Aug 2020 20:23:22 +0200
Subject: [libre-riscv-dev] daily kan-ban update 03aug2020
In-Reply-To: <CAPweEDyzGpVwcHbmnpBLZOZ0=FY3SEA-sVMmmwJ1hhprAkoiig@mail.gmail.com>
References: <CAPweEDyzGpVwcHbmnpBLZOZ0=FY3SEA-sVMmmwJ1hhprAkoiig@mail.gmail.com>
Message-ID: <20200803202322.c197497870ee95cd2fa9676a@platen-software.de>

On Mon, 3 Aug 2020 18:46:46 +0100
Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:

today:
	testcase for data merger based on the diagrams (still incomplete)
	reading https://bugs.libre-soc.org/show_bug.cgi?id=393
	reading DualPortSplitter and LDSTSplitter code
	


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


From benh at amazon.com  Mon Aug  3 01:13:55 2020
From: benh at amazon.com (Herrenschmidt, Benjamin)
Date: Mon, 3 Aug 2020 00:13:55 +0000
Subject: [libre-riscv-dev] [OpenPOWER-HDL-Cores] microwatt feature
 request: "switch off all optimisations" mode
In-Reply-To: <CAPweEDzFJH4MeTGHaHOj0++5ZbntYgWNMkMs8VDVFK1anA_2=w@mail.gmail.com>
References: <CAPweEDw+-AKRy9jB8Q6E-QiQ+OhM-BS4HizgAsh37buVd+Y0Gg@mail.gmail.com>
 <CAPweEDzFJH4MeTGHaHOj0++5ZbntYgWNMkMs8VDVFK1anA_2=w@mail.gmail.com>
Message-ID: <ecbdd6b08e1937fa1d6b953add782909e4db8015.camel@amazon.com>

On Sat, 2020-08-01 at 14:55 +0100, Luke Kenneth Casson Leighton wrote:
> 
> 
> On Friday, July 31, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net
> > wrote:
> > what would you suggest here? how can we "single-step" microwatt? 
> > clearly performance is not important: cycle-accurate comparisons is
> > the goal.
> > 
> 
> i since realised that the DMI interface serves this purpose, and
> investigated core_debug.vhdl
>  
> with a little bit (or a lot) of futzing about with a FSM i should be
> able to run a single instruction then cycle through all of the GPRs,
> PC and MSR, dumping them out.
> 
> by implementing the same interface in libresoc i can do a cycle by
> cycle comparison and find the discrepancies.
> 
> it would be particularly useful to be able to get at the SPRs and the
> CR as well, this way.
> 
> is there a standard for DMI address bus locations?

Not really... I just made it all up :-)

Cheers,
Ben.

> l 
> 
> 
> 
> _______________________________________________
> OpenPOWER-HDL-Cores mailing list
> OpenPOWER-HDL-Cores at mailinglist.openpowerfoundation.org
> 
http://lists.mailinglist.openpowerfoundation.org/mailman/listinfo/openpower-hdl-cores

From benh at amazon.com  Mon Aug  3 02:39:20 2020
From: benh at amazon.com (Herrenschmidt, Benjamin)
Date: Mon, 3 Aug 2020 01:39:20 +0000
Subject: [libre-riscv-dev] [OpenPOWER-HDL-Cores] microwatt feature
 request: "switch off all optimisations" mode
In-Reply-To: <CAPweEDyEo9YjQBMLQDgdsn9gFbRi1OMuKMmjUida_vGsLD5sqg@mail.gmail.com>
References: <CAPweEDw+-AKRy9jB8Q6E-QiQ+OhM-BS4HizgAsh37buVd+Y0Gg@mail.gmail.com>
 <CAPweEDzFJH4MeTGHaHOj0++5ZbntYgWNMkMs8VDVFK1anA_2=w@mail.gmail.com>
 <ecbdd6b08e1937fa1d6b953add782909e4db8015.camel@amazon.com>
 <CAPweEDxNzKwFdCG1PvbMDHqYa_LzpJyN0sQF8LNYDir=sUWcOw@mail.gmail.com>
 <ef44d4fe97ab91f802f29e57212bdd3c0a7bdadf.camel@kernel.crashing.org>
 <CAPweEDyEo9YjQBMLQDgdsn9gFbRi1OMuKMmjUida_vGsLD5sqg@mail.gmail.com>
Message-ID: <cf55d74b4cb63f11c5817fffbe178d9895fbdaea.camel@amazon.com>

On Mon, 2020-08-03 at 02:35 +0100, Luke Kenneth Casson Leighton wrote:
> 
> ah i was thinking more along the lines of agreeing a spec that suits
> both teams, even if the definitions are reserved for later
> implementation.

That's fine, the patch could be adding a debug-regs-spec.txt :-)

(Or we could use a .h as a spec, and use it in mw_debug)

Cheers,
Ben.


From lkcl at lkcl.net  Tue Aug  4 13:45:13 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Tue, 4 Aug 2020 13:45:13 +0100
Subject: [libre-riscv-dev] daily kan-ban update 04aug2020
Message-ID: <CAPweEDwXLUq3=T6_=KhSNzcYqRerTAEGsmmC5MGhhuTpXhmQGA@mail.gmail.com>

tasks:

*
https://bugs.libre-soc.org/showdependencytree.cgi?id=383&maxdepth=1&hide_resolved=1

yesterday:

* add DMI interface

today:

* in litex sim add an FSM that interacts through the DMI, sets the core in
singlestep mode and gets the PC and other data

i will be able to dump the entire regfile this way and do a diff compare of
libresoc vs microwatt.

this will tell us exactly which instruction being executed is not doing the
correct thing.

l.



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

From lkcl at lkcl.net  Tue Aug  4 16:34:51 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Tue, 4 Aug 2020 16:34:51 +0100
Subject: [libre-riscv-dev] daily kan-ban update 04aug2020
In-Reply-To: <CAPweEDwXLUq3=T6_=KhSNzcYqRerTAEGsmmC5MGhhuTpXhmQGA@mail.gmail.com>
References: <CAPweEDwXLUq3=T6_=KhSNzcYqRerTAEGsmmC5MGhhuTpXhmQGA@mail.gmail.com>
Message-ID: <CAPweEDx-RfqBAz80j-39cRQGty-m8ooX_BSGU1PeHMFyt8GEiw@mail.gmail.com>

On Tue, Aug 4, 2020 at 1:45 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:

> i will be able to dump the entire regfile this way and do a diff compare of libresoc vs microwatt.
>
> this will tell us exactly which instruction being executed is not doing the correct thing.

ta-daaa, which is exactly what occurred.  the wishbone data-bus
request is not getting an "ACK" on a stw instruction, which means i
have a place to start investigating.

hurrah.

l.


From libre-soc at platen-software.de  Tue Aug  4 18:18:58 2020
From: libre-soc at platen-software.de (Tobias Platen)
Date: Tue, 4 Aug 2020 19:18:58 +0200
Subject: [libre-riscv-dev] daily kan-ban update 04aug2020
In-Reply-To: <CAPweEDwXLUq3=T6_=KhSNzcYqRerTAEGsmmC5MGhhuTpXhmQGA@mail.gmail.com>
References: <CAPweEDwXLUq3=T6_=KhSNzcYqRerTAEGsmmC5MGhhuTpXhmQGA@mail.gmail.com>
Message-ID: <20200804191858.1cee35c7f297e6a40eae5ce5@platen-software.de>

today:

unit test for DualPortSplitter


From lkcl at lkcl.net  Tue Aug  4 18:32:34 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Tue, 4 Aug 2020 18:32:34 +0100
Subject: [libre-riscv-dev] daily kan-ban update 04aug2020
In-Reply-To: <20200804191858.1cee35c7f297e6a40eae5ce5@platen-software.de>
References: <CAPweEDwXLUq3=T6_=KhSNzcYqRerTAEGsmmC5MGhhuTpXhmQGA@mail.gmail.com>
 <20200804191858.1cee35c7f297e6a40eae5ce5@platen-software.de>
Message-ID: <CAPweEDzDOo1bjQFZwLszgeRx5OEGFUXQAbO3PnZV2KAGaOgdUg@mail.gmail.com>

On Tue, Aug 4, 2020 at 6:19 PM Tobias Platen
<libre-soc at platen-software.de> wrote:
>
> today:
>
> unit test for DualPortSplitter

ok great.  btw you saw that i had to revert a commit that you made:
please do ensure that you commit code that is "working" or at least
doesn't cause other people to not be able to do "work".  i've had to
do this three times now.

as best i can tell when i wrote the unit test for LDSTSplitter, the
"logic" behind LDSTSplitter is correct, however the mask works on
*bits* not bytes (sigh).

also: the left port needs to be for when addr[4] == 0 and the right
port for when addr[4] == 1.  this is achieved with a crossbar on
*both* the LD *and* ST data.

l.


From libre-soc at platen-software.de  Wed Aug  5 17:40:58 2020
From: libre-soc at platen-software.de (Tobias Platen)
Date: Wed, 5 Aug 2020 18:40:58 +0200
Subject: [libre-riscv-dev] daily kan-ban update 04aug2020
In-Reply-To: <CAPweEDzDOo1bjQFZwLszgeRx5OEGFUXQAbO3PnZV2KAGaOgdUg@mail.gmail.com>
References: <CAPweEDwXLUq3=T6_=KhSNzcYqRerTAEGsmmC5MGhhuTpXhmQGA@mail.gmail.com>
 <20200804191858.1cee35c7f297e6a40eae5ce5@platen-software.de>
 <CAPweEDzDOo1bjQFZwLszgeRx5OEGFUXQAbO3PnZV2KAGaOgdUg@mail.gmail.com>
Message-ID: <20200805184058.c0b4c856e310d6f75f83d29c@platen-software.de>

On Tue, 4 Aug 2020 18:32:34 +0100
Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:

> On Tue, Aug 4, 2020 at 6:19 PM Tobias Platen
> <libre-soc at platen-software.de> wrote:
> >
> > today:
> >
> > unit test for DualPortSplitter
> 
> ok great.  btw you saw that i had to revert a commit that you made:
Yes, I saw 
> please do ensure that you commit code that is "working" or at least
> doesn't cause other people to not be able to do "work".  i've had to
> do this three times now.
> 
> as best i can tell when i wrote the unit test for LDSTSplitter, the
> "logic" behind LDSTSplitter is correct, however the mask works on
> *bits* not bytes (sigh).
> 
> also: the left port needs to be for when addr[4] == 0 and the right
> port for when addr[4] == 1.  this is achieved with a crossbar on
> *both* the LD *and* ST data.
> l.
> 
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev


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


From libre-soc at platen-software.de  Wed Aug  5 17:48:11 2020
From: libre-soc at platen-software.de (Tobias Platen)
Date: Wed, 5 Aug 2020 18:48:11 +0200
Subject: [libre-riscv-dev] daily kan-ban update 04aug2020
In-Reply-To: <20200805184058.c0b4c856e310d6f75f83d29c@platen-software.de>
References: <CAPweEDwXLUq3=T6_=KhSNzcYqRerTAEGsmmC5MGhhuTpXhmQGA@mail.gmail.com>
 <20200804191858.1cee35c7f297e6a40eae5ce5@platen-software.de>
 <CAPweEDzDOo1bjQFZwLszgeRx5OEGFUXQAbO3PnZV2KAGaOgdUg@mail.gmail.com>
 <20200805184058.c0b4c856e310d6f75f83d29c@platen-software.de>
Message-ID: <20200805184811.6e06ee8fa6b4a493dff57dd0@platen-software.de>

On Wed, 5 Aug 2020 18:40:58 +0200
Tobias Platen <libre-soc at platen-software.de> wrote:

> On Tue, 4 Aug 2020 18:32:34 +0100
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> 
> > On Tue, Aug 4, 2020 at 6:19 PM Tobias Platen
> > <libre-soc at platen-software.de> wrote:
> > >
> > > today:
> > >
> > > unit test for DualPortSplitter
> > 
> > ok great.  btw you saw that i had to revert a commit that you made:
> Yes, I saw 
> > please do ensure that you commit code that is "working" or at least
> > doesn't cause other people to not be able to do "work".  i've had to
> > do this three times now.
> > 
> > as best i can tell when i wrote the unit test for LDSTSplitter, the
> > "logic" behind LDSTSplitter is correct, however the mask works on
> > *bits* not bytes (sigh).
That might be the reason why I get an error when running the unit tests:
LenExpand 4 1 unsigned(16)
LenExpand 4 1 unsigned(16)
ldm 255 0b11010011
dlm 15 0b1100
dmask 0b11111111000000000000
dmask1 0b1111
dmask 0b1111000000000000
lds
send_ld
waiting
ld data1 0b11010011 0b11000000000000 12 0b1111000000000000
ld data2 16 0b0 0b1101
0b11 0b11010011
Traceback (most recent call last):
  File "addr_split.py", line 270, in <module>
    sim(dut)
  File "addr_split.py", line 261, in sim
    sim.run()
  File "/home/isengaara/Hacking/lSOC/TEST/nmigen/nmigen/sim/pysim.py", line 382, in run
    while self.advance():
  File "/home/isengaara/Hacking/lSOC/TEST/nmigen/nmigen/sim/pysim.py", line 371, in advance
    self._real_step()
  File "/home/isengaara/Hacking/lSOC/TEST/nmigen/nmigen/sim/pysim.py", line 347, in _real_step
    process.run()
  File "/home/isengaara/Hacking/lSOC/TEST/nmigen/nmigen/sim/_pycoro.py", line 120, in run
    self.coroutine.throw(exn)
  File "/home/isengaara/Hacking/lSOC/TEST/nmigen/nmigen/sim/_pycoro.py", line 61, in run
    command = self.coroutine.send(response)
  File "/home/isengaara/Hacking/lSOC/TEST/nmigen/nmigen/sim/pysim.py", line 265, in wrapper
    yield from process()
  File "addr_split.py", line 232, in send_ld
    assert ld_data_o == data
AssertionError
make: *** [Makefile:4: test_ldst_splitter] Fehler 1
I'll investigate that.
> > 
> > also: the left port needs to be for when addr[4] == 0 and the right
> > port for when addr[4] == 1.  this is achieved with a crossbar on
> > *both* the LD *and* ST data.
> > l.
> > 
> > _______________________________________________
> > libre-riscv-dev mailing list
> > libre-riscv-dev at 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 at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev


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


From lkcl at lkcl.net  Wed Aug  5 18:08:04 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 5 Aug 2020 18:08:04 +0100
Subject: [libre-riscv-dev] daily kan-ban update 04aug2020
In-Reply-To: <20200805184811.6e06ee8fa6b4a493dff57dd0@platen-software.de>
References: <CAPweEDwXLUq3=T6_=KhSNzcYqRerTAEGsmmC5MGhhuTpXhmQGA@mail.gmail.com>
 <20200804191858.1cee35c7f297e6a40eae5ce5@platen-software.de>
 <CAPweEDzDOo1bjQFZwLszgeRx5OEGFUXQAbO3PnZV2KAGaOgdUg@mail.gmail.com>
 <20200805184058.c0b4c856e310d6f75f83d29c@platen-software.de>
 <20200805184811.6e06ee8fa6b4a493dff57dd0@platen-software.de>
Message-ID: <CAPweEDw9ORH6iSTUqn05P=zWL4qjJbAH80mHFdykFkHHU-kBZA@mail.gmail.com>

On Wed, Aug 5, 2020 at 5:48 PM Tobias Platen
<libre-soc at platen-software.de> wrote:

> > > as best i can tell when i wrote the unit test for LDSTSplitter, the
> > > "logic" behind LDSTSplitter is correct, however the mask works on
> > > *bits* not bytes (sigh).
> That might be the reason why I get an error when running the unit tests:
> LenExpand 4 1 unsigned(16)
> LenExpand 4 1 unsigned(16)

yes.  i started adding an option of expanding to bytes rather than
bits, ran into difficulties and, given that the code is unused
anywhere at the moment, left it.

if you go back through the git logs you will find what i added at the time.

l.


From libre-soc at platen-software.de  Wed Aug  5 18:37:43 2020
From: libre-soc at platen-software.de (Tobias Platen)
Date: Wed, 5 Aug 2020 19:37:43 +0200
Subject: [libre-riscv-dev] daily kan-ban update 04aug2020
In-Reply-To: <CAPweEDw9ORH6iSTUqn05P=zWL4qjJbAH80mHFdykFkHHU-kBZA@mail.gmail.com>
References: <CAPweEDwXLUq3=T6_=KhSNzcYqRerTAEGsmmC5MGhhuTpXhmQGA@mail.gmail.com>
 <20200804191858.1cee35c7f297e6a40eae5ce5@platen-software.de>
 <CAPweEDzDOo1bjQFZwLszgeRx5OEGFUXQAbO3PnZV2KAGaOgdUg@mail.gmail.com>
 <20200805184058.c0b4c856e310d6f75f83d29c@platen-software.de>
 <20200805184811.6e06ee8fa6b4a493dff57dd0@platen-software.de>
 <CAPweEDw9ORH6iSTUqn05P=zWL4qjJbAH80mHFdykFkHHU-kBZA@mail.gmail.com>
Message-ID: <20200805193743.c1394fca391141c88693affd@platen-software.de>

On Wed, 5 Aug 2020 18:08:04 +0100
Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:

> > > > as best i can tell when i wrote the unit test for LDSTSplitter, the
> > > > "logic" behind LDSTSplitter is correct, however the mask works on
> > > > *bits* not bytes (sigh).
> > That might be the reason why I get an error when running the unit tests:
> > LenExpand 4 1 unsigned(16)
> > LenExpand 4 1 unsigned(16)

I found those two commits in the git history.

commit c4d90bf6e19f4a16adba68b8af9a7ae5005a7062
Author: Luke Kenneth Casson Leighton <lkcl at lkcl.net>
Date:   Tue Jun 9 18:33:22 2020 +0100

    allow LenExpand to output both byte- and bit- mask expansion

commit f700880e9add726c01ace79e2a36e48faa83946c
Author: Luke Kenneth Casson Leighton <lkcl at lkcl.net>
Date:   Tue Jun 9 14:01:06 2020 +0100

    expand LenExpand (haha) to cover bytes, with an argument "cover"
    all puns intentional


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


From lkcl at lkcl.net  Wed Aug  5 19:39:20 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 5 Aug 2020 19:39:20 +0100
Subject: [libre-riscv-dev] daily kan-ban update 04aug2020
In-Reply-To: <20200805193743.c1394fca391141c88693affd@platen-software.de>
References: <CAPweEDwXLUq3=T6_=KhSNzcYqRerTAEGsmmC5MGhhuTpXhmQGA@mail.gmail.com>
 <20200804191858.1cee35c7f297e6a40eae5ce5@platen-software.de>
 <CAPweEDzDOo1bjQFZwLszgeRx5OEGFUXQAbO3PnZV2KAGaOgdUg@mail.gmail.com>
 <20200805184058.c0b4c856e310d6f75f83d29c@platen-software.de>
 <20200805184811.6e06ee8fa6b4a493dff57dd0@platen-software.de>
 <CAPweEDw9ORH6iSTUqn05P=zWL4qjJbAH80mHFdykFkHHU-kBZA@mail.gmail.com>
 <20200805193743.c1394fca391141c88693affd@platen-software.de>
Message-ID: <CAPweEDx=hnH4uuq-Aujn4xtwV9DFa+QSf5NCBy1O1oMF-4NQ0A@mail.gmail.com>

On Wed, Aug 5, 2020 at 6:37 PM Tobias Platen
<libre-soc at platen-software.de> wrote:
>
> On Wed, 5 Aug 2020 18:08:04 +0100
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
>
> > > > > as best i can tell when i wrote the unit test for LDSTSplitter, the
> > > > > "logic" behind LDSTSplitter is correct, however the mask works on
> > > > > *bits* not bytes (sigh).
> > > That might be the reason why I get an error when running the unit tests:
> > > LenExpand 4 1 unsigned(16)
> > > LenExpand 4 1 unsigned(16)
>
> I found those two commits in the git history.

ok so the one you just changed, was this:

diff --git a/src/soc/scoreboard/addr_split.py b/src/soc/scoreboard/addr_split.py
index 0cd546ce..aa99f63c 100644
--- a/src/soc/scoreboard/addr_split.py
+++ b/src/soc/scoreboard/addr_split.py
@@ -100,7 +100,7 @@ class LDSTSplitter(Elaboratable):
         mzero = Const(0, mlen)
         m.submodules.ld1 = ld1 = LDLatch(self.dwidth, self.awidth-dlen, mlen)
         m.submodules.ld2 = ld2 = LDLatch(self.dwidth, self.awidth-dlen, mlen)
-        m.submodules.lenexp = lenexp = LenExpand(self.dlen, cover=8)
+        m.submodules.lenexp = lenexp = LenExpand(self.dlen)

and that got the unit test "working".... by *returning* LDSTSplitter
to do *bit* masking *not* byte masking.

this means that instead of having a 16 bit mask to cover 128 bits of
data,  a whopping *128* bit mask is needed and that's precisely what
we do not want.

l.


From libre-soc at platen-software.de  Wed Aug  5 19:55:06 2020
From: libre-soc at platen-software.de (Tobias Platen)
Date: Wed, 5 Aug 2020 20:55:06 +0200
Subject: [libre-riscv-dev] daily kan-ban update 04aug2020
In-Reply-To: <CAPweEDx=hnH4uuq-Aujn4xtwV9DFa+QSf5NCBy1O1oMF-4NQ0A@mail.gmail.com>
References: <CAPweEDwXLUq3=T6_=KhSNzcYqRerTAEGsmmC5MGhhuTpXhmQGA@mail.gmail.com>
 <20200804191858.1cee35c7f297e6a40eae5ce5@platen-software.de>
 <CAPweEDzDOo1bjQFZwLszgeRx5OEGFUXQAbO3PnZV2KAGaOgdUg@mail.gmail.com>
 <20200805184058.c0b4c856e310d6f75f83d29c@platen-software.de>
 <20200805184811.6e06ee8fa6b4a493dff57dd0@platen-software.de>
 <CAPweEDw9ORH6iSTUqn05P=zWL4qjJbAH80mHFdykFkHHU-kBZA@mail.gmail.com>
 <20200805193743.c1394fca391141c88693affd@platen-software.de>
 <CAPweEDx=hnH4uuq-Aujn4xtwV9DFa+QSf5NCBy1O1oMF-4NQ0A@mail.gmail.com>
Message-ID: <20200805205506.4836c315587bdc10c33064f2@platen-software.de>

On Wed, 5 Aug 2020 19:39:20 +0100
Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:

> this means that instead of having a 16 bit mask to cover 128 bits of
> data,  a whopping *128* bit mask is needed and that's precisely what
> we do not want.
I think now understand my mistake in thinking and how to solve the problem.

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


From lkcl at lkcl.net  Wed Aug  5 20:02:46 2020
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 5 Aug 2020 20:02:46 +0100
Subject: [libre-riscv-dev] daily kan-ban update 04aug2020
In-Reply-To: <20200805205506.4836c315587bdc10c33064f2@platen-software.de>
References: <CAPweEDwXLUq3=T6_=KhSNzcYqRerTAEGsmmC5MGhhuTpXhmQGA@mail.gmail.com>
 <20200804191858.1cee35c7f297e6a40eae5ce5@platen-software.de>
 <CAPweEDzDOo1bjQFZwLszgeRx5OEGFUXQAbO3PnZV2KAGaOgdUg@mail.gmail.com>
 <20200805184058.c0b4c856e310d6f75f83d29c@platen-software.de>
 <20200805184811.6e06ee8fa6b4a493dff57dd0@platen-software.de>
 <CAPweEDw9ORH6iSTUqn05P=zWL4qjJbAH80mHFdykFkHHU-kBZA@mail.gmail.com>
 <20200805193743.c1394fca391141c88693affd@platen-software.de>
 <CAPweEDx=hnH4uuq-Aujn4xtwV9DFa+QSf5NCBy1O1oMF-4NQ0A@mail.gmail.com>
 <20200805205506.4836c315587bdc10c33064f2@platen-software.de>
Message-ID: <CAPweEDynfs123E+vbuBpeMKRB3Q_Cgs-xFYFW8HuvK8PLTo60w@mail.gmail.com>

On Wed, Aug 5, 2020 at 7:55 PM Tobias Platen
<libre-soc at platen-software.de> wrote:
>
> On Wed, 5 Aug 2020 19:39:20 +0100
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
>
> > this means that instead of having a 16 bit mask to cover 128 bits of
> > data,  a whopping *128* bit mask is needed and that's precisely what
> > we do not want.
> I think now understand my mistake in thinking and how to solve the problem.

cool.

basically, the mask is wishbone "sel", set to a granularity of 8 bits
(one byte) per bit of "sel".

if you read the wishbone spec, concentrating on when "sel" is not just
a single bit, you'll see clearly what is needed.

we are propagating that byte-per-bit mask RIGHT THE WAY THROUGH THE
ENTIRE DESIGN.

it starts at LD/ST - right back when a byte, half-word, word or dword
LD/ST is requested - and goes - will go - through the ENTIRE design

through PortInterface.

through LDSTSplitter.

through DataMerger.

through the L1 cache which will need to respect byte-level masks

through the L2 cache which will need to respect byte-level masks.

through the wishbone buses which will need to respect byte-level masks

through to the DDR / SDR bus which will *ALSO* need to respect byte-level masks.

eeeeverything and i *mean* everyting.

SDR (DDR1, SDRAM) does in fact accept byte-level masks.

if at any time we encounter a memory system which does *NOT* respect
byte-level masks, then we have a problem and will have to rethink.

l.