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

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

[Luke Kenneth Casson Leighton]

little late.  yesterday and this morning

* helped Michael go over the Condition Register pipeline reorg.  the CR
regfile is to be split into 8 4bit registers rather than one massive 32 bit
one
* sorted new CR register allocation scheme for when we put a CompUnit in
front of it
* described to Cesar the design mod requirements to ALUCompUnit needed: to
add selection of RA being a zero immediate and to bypass RD.REQ[0] when
that happens.
* added a zero_a flag to Decode2ExecuteType to support that
* reorganised the soc.fu code a little after separating out the op subsets
CompBrOpSubset etc
* cookie cut shiftreg and logical to soc.fu.mul and soc.fu.div
respectively, and placed some stub code for replacing with ieee754fpu
pipeline stages, for Jacob
* helped Jean-Paul in understanding the FU-FU Dependency Matrix so he can
do a layout experiment in coriolis2
* attended both OpenPOWER weekly coffee calls which were nice to do,
especially learning about microwatt first boot and also what Cesar does.
both very cool.

y'know... i have to say, i am not often aware at the time because i take
breaks and binge watch series episodes (Stargate SG1 at present, but only
because i ran out of American Ninja Warrior episodes), but each day when
actually written out does seem to be one hell of a lot.  this probably
because i don't do anything else, the entire day.

anyway.

todo:

* draw out a new ALUCompUnit diagram for documentation purposes
* keep an eye out for Cole.  i couldn't work it out, either.  might need
your help, Michael.
* keep thinking through the multi comp unit data structures.
* answer issues as they come up

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

[Michael Nolan]

Yesterday I worked on porting the CR function unit to the new CR 
interface (taking in several 4 bit CR fields instead of the full register).

Today I reworked the formal proof for the CR FU by adding a translation 
layer so I could use most of the existing proof on the new interface. I 
also ported the branch FU to use the new CR interface. This afternoon I 
will probably work on writing a proof for the branch unit, and work some 
on the bperm module with Cole.

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

[Luke Kenneth Casson Leighton]

On Fri, May 22, 2020 at 4:20 PM Michael Nolan <mtnolan2640@gmail.com> wrote:

> Today I reworked the formal proof for the CR FU by adding a translation
> layer so I could use most of the existing proof on the new interface.

retrospectively this may have been the best way to do it, due to the
awkwardness of indexing dynamic bit-masked groups.

> I also ported the branch FU to use the new CR interface.

confirmed the unit tests run.

> This afternoon I
> will probably work on writing a proof for the branch unit, and work some
> on the bperm module with Cole.

excellent.

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

[Cole Poirier]

On May 22 2020, at 8:02 am, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> * attended both OpenPOWER weekly coffee calls which were nice to do,
> especially learning about microwatt first boot and also what Cesar does.
> both very cool.

Would you mind giving a one line description here of what Cesar does?
I'd be interested to know as well.

> y'know... i have to say, i am not often aware at the time because i take
> breaks and binge watch series episodes (Stargate SG1 at present, but only
> because i ran out of American Ninja Warrior episodes), but each day when
> actually written out does seem to be one hell of a lot.  this probably
> because i don't do anything else, the entire day.

From an outsiders perspective, Luke, it appears as if you never sleep!! :)

> * keep an eye out for Cole.  i couldn't work it out, either.  might need
> your help, Michael.

Appreciated, very much appreciated. I spent all of yesterday failing to
get bpermd to work correctly, upon reflection today, since I'm pretty
sure I've tried all possible reverse indexing (e.g. 63-i, 7-i)
permutations, I suspect that I may be missing a line? Or something else
that I causing my module to behave close-ish(very ish) to correctly,
since it produces bit patterns that are usually off-by-one but in
but the bit that is off tends to move around the 'result area' that is
the least significant byte of output ra.

> work some on the bperm module with Cole.
> --Michael

I appreciate it Michael, in the mean time, I will work on the corilis2
chroot script, I believe it is almost complete, just have to setup a
user-USERNAME.mk file that sets up the include paths for alliance correctly.

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

[Tobias Platen]

First I fixed a ModuleNotFoundError, afterwards I ran score6600_multi.py test case, where I tried to find out whats going wrong.
That took the whole day, and I still did not find the error.

Tobias

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

[Luke Kenneth Casson Leighton]

On Fri, May 22, 2020 at 8:19 PM Tobias Platen
<libre-soc@platen-software.de> wrote:
>
> First I fixed a ModuleNotFoundError, afterwards I ran score6600_multi.py test case, where I tried to find out whats going wrong.
> That took the whole day, and I still did not find the error.

score6600_multi.py is not broken: the testing is

reg 0 expected 0 received 0 OK
reg 1 expected 1 received 1 OK
reg 2 expected 2 received 2 OK
reg 3 expected 3 received 3 OK
reg 4 expected 4 received 4 OK
reg 5 expected 5 received 5 OK
reg 6 expected 6 received 12 !ok   <- correct result
reg 7 expected 7 received 7 OK

the regfile / memory simulator in score6600_multi.py has not been
replaced with the one that michael wrote, hence why i have not updated
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 22may2020

[Jacob Lifshay]

working on mul and div units today, may not get much done due to less time
to work.

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

[Luke Kenneth Casson Leighton]

On Fri, May 22, 2020 at 9:00 PM Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> working on mul and div units today,

superb.

> may not get much done due to less time
> to work.

ok.

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

[Luke Kenneth Casson Leighton]

the thought occurs to me jacob, if you can get the two pipelines
established (3rd add, carry in on the add side) michael and i can likely
link it together at the POWER9 side

On Friday, May 22, 2020, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> On Fri, May 22, 2020 at 9:00 PM Jacob Lifshay <programmerjake@gmail.com>
> wrote:
> >
> > working on mul and div units today,
>
> superb.
>
> > may not get much done due to less time
> > to work.
>
> ok.
>


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

[Cesar Strauss]

Hi Cole and all,

On 05/22/2020 16:10, Cole Poirier wrote:
> Would you mind giving a one line description here of what Cesar does?
> I'd be interested to know as well.

I work in a research institute, on data acquisition and control of
scientific instruments for astronomy.

Let me expand a bit on that.

Some of the projects I'm involved, past and present:

1) Microwave receivers for a 14 m radio telescope.
2) Control of a 26-element radio interferometer array
3) Image acquisition for an infrared camera
4) Data acquisition for a X-ray detector in a stratospheric balloon.
5) Miniaturized version of the above, to fly on a nano-satellite (2U
cubesat)
6) Spherical-mass gravitational wave detector

Some phenomena that the scientists observe with the above:

1) Molecular clouds and star formation
2) Variability in the active nuclei of galaxies (quasars)
3) Accretion disks around black holes
4) Gamma ray burst
5) Solar flares and coronal mass ejections
6) Space weather

Some technologies I use:

1) Data acquisition and remote control of voltmeters and spectrum
analyzers via RS-232, GPIB, Ethernet and USB
2) Multi-channel analog data acquisition boards
3) Microcontrollers like 8051, PIC, ARM Cortex, Arduinos
4) FPGA for glue logic, data acquisition and signal processing
5) Single-board computer
6) Cryogenics for low noise temperature radio frequency receivers

Software tools:

1) GCC, C/C++ compiler for the PC and some microcontrollers
2) SDCC, C compiler for smaller microcontrollers
3) Icarus Verilog for FPGA simulation
4) gEDA/gaf, Pcb and Gerbv for PCB design
5) Python, for quick prototyping, data processing, plotting.
6) R, Octave, for data processing

My motivation to participate in Libre-SOC:

A libre, supported, fully documented SoC, free of proprietary drivers,
firmware and bootloaders, that I can trust to use in my workstation,
server and as building blocks of scientific instruments.

Regards,

Cesar

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

[Luke Kenneth Casson Leighton]

On Saturday, May 23, 2020, Cesar Strauss <cestrauss@gmail.com> wrote:

>
> My motivation to participate in Libre-SOC:
>
> A libre, supported, fully documented SoC, free of proprietary drivers,
> firmware and bootloaders, that I can trust to use in my workstation,
> server and as building blocks of scientific instruments.


very cool.

and even in FPGA, one that had good number crunching capability might be
useful, i assume.

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

[Cesar Strauss]

On 05/22/2020 23:41, Luke Kenneth Casson Leighton wrote:
> On Saturday, May 23, 2020, Cesar Strauss <cestrauss@gmail.com> wrote:
> 
>>
>> My motivation to participate in Libre-SOC:
>>
>> A libre, supported, fully documented SoC, free of proprietary drivers,
>> firmware and bootloaders, that I can trust to use in my workstation,
>> server and as building blocks of scientific instruments.
> 
> 
> very cool.
> 
> and even in FPGA, one that had good number crunching capability might be
> useful, i assume.
> 

If you mean a libre FPGA, I am all for it.

A libre, supported, fully documented FPGA, with open architecture and
bitstream format.

If some people (hint!) were to start a libre-FPGA project, it would be
absolutely wonderful.

Independent of having a number crunching capability or not.

For synthesis, placing and routing, we do have libre tools. But, to
actually program the Configurable Logic Blocks (CLB), the routing switch
matrices, etc., inside the FPGA, we are forced to either use the
proprietary tools, or use libre tools based on a reverse engineered
bitstream format. It's a complete lock-in.

The community did produce a completely libre flow, from HDL to
bitstream, for Lattice chips. But the bitstream format is still
proprietary, and had to be reverse engineered. It is not assured that we
always will be able to do so, as new families are introduced. It is a
waste of effort, and features will be lacking.

I think there are experimental FPGAs developed in academia, but not
reaching commercial availability.

Cheers,

Cesar

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

[Luke Kenneth Casson Leighton]

On Sat, May 23, 2020 at 11:24 AM Cesar Strauss <cestrauss@gmail.com> wrote:
>
> On 05/22/2020 23:41, Luke Kenneth Casson Leighton wrote:
> > and even in FPGA, one that had good number crunching capability might be
> > useful, i assume.
> >
>
> If you mean a libre FPGA, I am all for it.

:)

> I think there are experimental FPGAs developed in academia, but not
> reaching commercial availability.

yes we found one a few months ago, written in chisel (!) and
considered putting it into silicon.  however it is a big project in
its own right, you'd have to go through the full business case
justification and properly commit 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

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

[Cesar Strauss]

Em 22/05/2020 23:41, Luke Kenneth Casson Leighton escreveu:
> On Saturday, May 23, 2020, Cesar Strauss <cestrauss@gmail.com> wrote:
> 
>>
>> My motivation to participate in Libre-SOC:
>>
>> A libre, supported, fully documented SoC, free of proprietary drivers,
>> firmware and bootloaders, that I can trust to use in my workstation,
>> server and as building blocks of scientific instruments.
> 
> 
> very cool.
> 
> and even in FPGA, one that had good number crunching capability might be
> useful, i assume.
> 

If you mean, programming an FPGA board with a libre-SOC core, it would
have to be seriously optimized for size, not speed. These big FPGAs
boards are very expensive, compared to an equivalent Single Board Computer.

There is no way a relatively simple DSP algorithm, implemented on the
raw resources of an FPGA, could be beaten by a CPU/GPU core executing
this same algorithm, in the same FPGA.

Yes, people put CPU cores in FPGAs, but mainly to interface to the
outside world, providing a convenient interface to the FPGA. The main
data processing is still done in the free resources which remains after
placing the CPU core.

Of course, I could use parts of libre-SOC, like the floating points
pipelines. But, fixed-point algorithms are more common than
floating-point in FPGA applications.

Regards,

Cesar

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

[Luke Kenneth Casson Leighton]

On Saturday, May 23, 2020, Cesar Strauss <cestrauss@gmail.com> wrote:

>
> Of course, I could use parts of libre-SOC, like the floating points
> pipelines. But, fixed-point algorithms are more common than
> floating-point in FPGA applications.


one of the big advantages of an OoO design is the opportunity for parallel
processing interwoven cleanly behind a sequential "API" (the instruction
set).

so let us suppose that you needed for example a significant number of fixed
point correlators, done in a specialist hardware-optimised mathematical way
that is massively inconvenient even for a DSP or a standard CPU.

however a full FPGA implementation is also inconvenient because the level
of parallelism required, when interacting closely with a sequential
program, makes the FPGA correlator a huge pain to program.

what you need would therefore be a CPU with sequential behaviour that could
just call a sequential instruction in a loop, to activate the special
custom correlator, but because that CPU is an out of order parallel
processor multiple such custom instructions (custom correlators) get issued
in parallel and the dependencies automatically resolved for you.

here you would get the best of both worlds.

another thought, for when we have time: if you can clearly express the
primitives needed, it would be a fascinating use-case evaluation to see
whether the ASIC would be any good, for the kind of DSP work that you do,
and if not, what operations would actually be needed.

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

[Cole Poirier]

> On May 22, 2020, at 6:56 PM, Cesar Strauss <cestrauss@gmail.com> wrote:
> 
> Hi Cole and all,
> 
>> On 05/22/2020 16:10, Cole Poirier wrote:
>> Would you mind giving a one line description here of what Cesar does?
>> I'd be interested to know as well.
> 
> I work in a research institute, on data acquisition and control of
> scientific instruments for astronomy.
> 
> Let me expand a bit on that.
> 
> Some of the projects I'm involved, past and present:
> 
> 1) Microwave receivers for a 14 m radio telescope.
> 2) Control of a 26-element radio interferometer array
> 3) Image acquisition for an infrared camera
> 4) Data acquisition for a X-ray detector in a stratospheric balloon.
> 5) Miniaturized version of the above, to fly on a nano-satellite (2U
> cubesat)
> 6) Spherical-mass gravitational wave detector
> 
> Some phenomena that the scientists observe with the above:
> 
> 1) Molecular clouds and star formation
> 2) Variability in the active nuclei of galaxies (quasars)
> 3) Accretion disks around black holes
> 4) Gamma ray burst
> 5) Solar flares and coronal mass ejections
> 6) Space weather
> 
> Some technologies I use:
> 
> 1) Data acquisition and remote control of voltmeters and spectrum
> analyzers via RS-232, GPIB, Ethernet and USB
> 2) Multi-channel analog data acquisition boards
> 3) Microcontrollers like 8051, PIC, ARM Cortex, Arduinos
> 4) FPGA for glue logic, data acquisition and signal processing
> 5) Single-board computer
> 6) Cryogenics for low noise temperature radio frequency receivers
> 
> Software tools:
> 
> 1) GCC, C/C++ compiler for the PC and some microcontrollers
> 2) SDCC, C compiler for smaller microcontrollers
> 3) Icarus Verilog for FPGA simulation
> 4) gEDA/gaf, Pcb and Gerbv for PCB design
> 5) Python, for quick prototyping, data processing, plotting.
> 6) R, Octave, for data processing
> 
> My motivation to participate in Libre-SOC:
> 
> A libre, supported, fully documented SoC, free of proprietary drivers,
> firmware and bootloaders, that I can trust to use in my workstation,
> server and as building blocks of scientific instruments.
> 
> Regards,
> 
> Cesar

That’s some wildly cool stuff Cesar! Thanks for sharing, I’m excited we’ve got you as a new member!
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev