andrey at technepisteme.xyz
Fri Sep 10 22:24:59 BST 2021
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):
6?40 - Return a random vector consisting of 6, picking from 1 (default)
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
>> 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
>> 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).
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
> 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.
More information about the Libre-soc-dev