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

[bugzilla-daemon at libre-riscv.org]

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

--- Comment #8 from Jean-Paul.Chaput at lip6.fr ---
(In reply to Jock Tanner from comment #7)
> (In reply to Luke Kenneth Casson Leighton from comment #6)
> > ok, jock, i thought about it: i have a specific task for you :)
> > 
> > * take benchs/nmigen/ALU16 and create (cut/paste) experiments7
> >   in soclayout
> > * in doAlu16.py, in each of add(), sub() and alu16(), *replace*
> >   the hand-coded addition of Pins (Pin.create) with explicit
> >   use of ChipConf from cumulus/src/plugins/chip/Configuration.py
> > 
> > the only thing to watch out for is that BLOCKAGE2 through BLOCKAGE5
> > are added in add() and sub().  it *may* be necessary to create a
> > separate function for that, we just have to see.
> > 
> > if necessary, for now, take a copy of Configuration.py and add it
> > to experiments7 in the soclayout repo, so that you can edit it.
> > or, better (preferred), subclass it.
> > 
> > just get stuck in, and see how that goes?
> 
> Luke and everybody,
> 
> I played with the example for several days, but I afraid I have no answers,
> but only more questions.
> 
> 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. I thought I can find some documents on this, but I couldn't.

  The end result of this script is a "layout", that is literally the
  drawing you will send to the factory (foundry) to be fabricated. It is stored
  in the various ".ap" files (symbolic layout). They must be coherent with the
  associated ".vst" (nelist) files.


> 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).
> 
> Is something wrong with my setup?

  Obviously. Because it works on my end. I will redo the whole install
  process under Debian 10 in the next few days to see if I can reproduce
  your problem.


> 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.

  That is right, I will correct it.


> 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.

  You can find the documentation here: http://coriolis.lip6.fr/
  The C++ API is exported almost exactly "as is" in Python.
  There is also the documentation of alliance-check-toolkit.


> 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.

  Both true and false. alliance-check-toolkit, as it's name hints was started
  as a kind of regression test and tookit for people already acquainted with
  the ASIC design flow. In that sense it is not pedagogical.
    In the other hand, for people familiar with it, the target names are
  almost self explanatory.


> 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'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.

  Coriolis has always been tricky to install from sources (but try to build
  the whole Gnome3 stack instead of using packaged versions to make a fair
  comparison). As I happen to manage Cadence/Mentor/Synopsys in my lab,
  I assure you, that they are not simpler, by a long shot (with a license
  fee around 100K$ a year, for commercial purpose).
    That context being setup, I know myself to have a tendency to make things
  too complicated, but it is difficult to improve without feedback.
    I'm always eager to improve the quality of my software and coding style,
  but ranting about "this is badly written" do not help. I flatter myself
  to have the "scientific spirit", so if you pinpoint me badly written code
  and *why* it is so (with reference), I will improve it in my futur code
  and progressively rewrite the old one.

-- 
You are receiving this mail because:
You are on the CC list for the bug.