[libre-riscv-dev] [Bug 217] create a "ring" system which allows pad locations to be specified conveniently

[bugzilla-daemon@libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=217

--- Comment #9 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Jock Tanner from comment #7)

> I played with the example for several days, 

ok - don't leave it several days.  we don't have time for "i can't get it to
work therefore i'm going to keep quiet and spend time because i'm embarrassed
to admit i can't get it to work".

the *moment* you can't get something to work, please say so *immediately*, on
here.  this is *really* important.

> but I afraid I have no answers,
> but only more questions.

great.

> First of all, I'm not sure what the result of the 'doAlu16.py' script should
> be, and how running of the script relates to running 'make' with different
> targets. 

you need to run "make lvx" then "make view".  nothing else: absolutely nothing
else.

you *might* have to run "make clean" if something has not worked because
occasionally the intermediary files are modified such that on subsequent runs
they affect ongoing output.

> I thought I can find some documents on this, but I couldn't.

that's what the tutorial is for.

> I think the script is not working anyway. The most I can get out of it is
> 
> > [ERROR] NegociateWindow::createTrackSegment(): No track near axis of <id:7676 Horizontal b(15) METAL2 [320l 400l] [320l 400l] 2l rpD:0 ----UC---T-----ri-tt-> (after adjust).

ah.  that's a bug, that needs to be reported to jean-paul.

he will need the *EXACT* git version/revision of all repositories that you have
checked out (alliance, alliance-check-toolkit, coriolis2)

so, for example: i am using:

toolkit

commit abec1bea9643d69ac231791ad8a30c964a236794
Merge: b2380d6 a90033f
Author: Jean-Paul Chaput <Jean-Paul.Chaput@lip6.fr>
Date:   Wed Mar 4 01:40:39 2020 +0100

    Merge branch 'master' of gitlab.lip6.fr:vlsi-eda/alliance-check-toolkit


alliance

commit 93cd988d07037b71c3b8497c4c376b1d7d151f71
Author: Jean-Paul Chaput <Jean-Paul.Chaput@lip6.fr>
Date:   Wed Nov 13 17:47:22 2019 +0100

    Stable AP read/write generation.



coriolis-2

commit 59ee8358cac8254dcd999a945e07ef717573e32e
Author: Jean-Paul Chaput <Jean-Paul.Chaput@lip6.fr>
Date:   Wed Mar 4 00:50:18 2020 +0100

    First working recursive place & route (Libre-SOC ALU16 benchmark).



and i just "git pulled" soclayout (and pushed an add of a symlink to mksyms.sh)

aaaand.... it works perfectly.  "make lvx" followed by "make view" does what is
expected.

now let me do a git pull and rebuild on all three repos (one at a time, first).

.... arse.  alliance-check-toolkit critically relies on updates in coriolis2. 
arse.  ok have to do all three.

ok coriolis-2 is a big update it seems: alliance not so much.

ok that's built: i re-ran experiments7 (after running mksyms.sh and "make
clean" and, again, it worked perfectly.


> Is something wrong with my setup?

we don't know.  do "make clean", "make lvx" and (only if that works) "make
view".

coriolis2 is *supposed* to be absolutely replicable (deterministic) and so the
output is *not* supposed to "go wrong" on one system and "go right" on another.


> Oh, and it was only after I fixed an error with forgotten import:
> 
> (~/alliance-check-tookit/benchs/nmigen/ALU16/doAlu16.py:523)
> >     showPythonTrace( __file__, e, False )
> 
> but 'showPythonTrace()' is not defined.

generally this kind of approach - catching an exception then showing it - is
very bad practice.  it's better to let the exception happen, where it happens. 
the exit code *should* be non-zero on exception which is exactly what is wanted
anyway:

lkcl@fizzy:$ python -c "x = 5 / 0"; echo $?
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ZeroDivisionError: integer division or modulo by zero
1
lkcl@fizzy:$ python -c "x = 5 / 1"; echo $?
0

yyyep, non-zero exit code on exception.  therefore, doing "catch exception then
do sys.exit(code)" is completely unnecessary.


> I thought I could get something out of documentation, but it seems very
> scarce to me. I could not find an API reference manual (neither Python nor
> C++), but then I was starting to think it wouldn't help me either.

it's in HTML in the repository.  locate a docs dir.  however... yes, it doesn't
help exactly.

> It also makes me wonder why all the examples are totally devoid of
> meaningful comments or docstrings, as if they aren't meant for didactic
> purposes, but just for spinning off new devices. Like boilerplates. Except
> they are too big for boilerplates, and not exactly working.

time, basically.  jean-paul's a little overwhelmed with other tasks.


> I hope I was able to somehow address the issue of creating the layer Luke
> mentions:
> 
> https://git.libre-riscv.org/?p=soclayout.git;a=blob;f=experiments7/doAlu16.
> py;hb=HEAD#l25
> 
> But otherwise I am lost. And the overall quality of the Python code I'm
> dealing with in Coriolis makes me want to poke my eyes out. 

i know.  it absolutely seriously needs autopep8 run on it, big-time - the whole
lot.  (except autopep8 has gone downhill as its developer is failing to respond
to bugreports).

i haven't mentioned it yet, because autopep8, if run incorrectly, can do quite
a bit of readability damage (due to its developer not properly listening and
not fixing reported bugs that have been there for a minimum of eight years,
even when i reported a brain-dead trivial repro case)


> I'm terribly
> sorry if I offended someone, but at the same time I'm sure I'm not the only
> one saying this. I wonder why it is so bad and where to start improving it.

at the right time.

or if it's seriously intolerable, we do have a budget available for fixing
coriolis2 itself.  it needs coordinating with jean-paul and marie-minerve at
lip6.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev