[Libre-soc-dev] Introduction

[Andrey Miroshnikov]

On 10/09/2021 19:52, lkcl wrote:
> the BBC Atom had something insanrly obscure, and i remember in.... 1979 a neighbour having a Superbrain with something called APL.
> 
Quite the wacky language, APL! Just looked at the wikipedia page for it, 
here's an example for picking 6 random numbers (say for a lottery):
x[⍋x←6?40]

6?40 - Return a random vector consisting of 6, picking from 1 (default) 
to 40.
x← - Assign vector to variable x.
⍋x - Sort vector x in ascending order and return indeces corresponding 
to sorted order.
x[⍋x] - Display the sorted values to standard output (default APL 
behaviour is to display)

It looks a lot more pure-maths oriented, even use a default base e 
(natural logarithm) when you don't specify the base for the exponent 
operator (for example *3 means e^3).

> and as the basis for VHDL, apparently
Yes, I think I remember hearing that about VHDL, had the origins in USA 
DoD too.

>> Ah, do you mean formal verification?
> 
> oh, nice, because we have quite a lot of EUR availabke if you want to go that route.
>Sounds amazing! I'd like to learn more about formal verification, so is 
a great incentive.

>> I haven't studied the OpenPower spec yet (should I give the 3.0b or
>> 3.0c
>> a read?)
> 
> muhahaha only if you want to go blind. it's 1350 pages.
Fair enough ;)
But I wanted to download it more for reference, and the openpower 
website shows two downloads: v3.0b (2017) and v3.0c (2020).
https://openpower.foundation/specifications/powerisa30/

Given Libre-SOCs switch to OpenPower in 2020, I'm guessing v3.0c is the 
more appropriate. Is that the case?

> the saner route is "learn by doing", go over Dmitry's excellent "firststeps" tutorial (on the wiki)True, I'll focus on making sense of the code, and will give Dmitry's 
tutorial a look.

> cool.  basically look at teststate.py in soc, which kyle recently created, the static (expected) results should fit with that in some dummy way, so that (see test_core.py) when handed to check_regs it goes, "pffh i can check against that"
Ok, I'll focus on this and on Dmitry's tutorial.

>> lack of -j$(nproc) flag in the "make" statements, so the compilation
>> only used one thread (unless the system "make" config has a default I
>> guess).
> 
> i prefer to make the decision explicitly as to whether to overheat my laptop.  if there's a way to make that flexible feel free
Sure, how about a message saying:
"Would you like to use more than one thread to speed up compilation with 
make? Y/N/[number of threads]:"

And the user can specify:
Y - use $(nproc) threads
N - use single thread
Number - use user-specified number of threads (2, 3, 20 etc.)



Also noticed the "symbiflow-install" script in dev-env-setup is not 
really a script, just some notes. Is anyone planning to work on it?
During the time I'll allocate to the shell scripts, I could look at 
turning it into a script if no one's doing it.


Andrey