[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[Jean-Paul Chaput]

On Sun, 2020-02-16 at 11:20 +0000, bugzilla-daemon at libre-riscv.org wrote:
> http://bugs.libre-riscv.org/show_bug.cgi?id=178
> 
> --- Comment #23 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
> 
> 
> On Sunday, February 16, 2020, Jean-Paul Chaput <Jean-Paul.Chaput at lip6.fr>
> wrote:
> 
> > yep done, added already, and replied.
> 
>   Caramba ! Encore raté !
>      -- Tintin, L'Oreille Cassée.
> 
> :)
> 
> 
>   My apologies here, the LIP6 spam filter is still tagging some,
>   but not all, of your messages as spam,
> 
> it is utterly bizarre.  are you allowed to ask admins for whitelisting?

  I can, I'm one of them... But not the one in charge of the mail.
  That one has just gone into vacation until the end of the month.
  I will ask him when he returns.
    Your mail is tagged as spam by spamassasin because of:

      URIBL_DBL_SPAM     Contains a spam URL listed in the Spamhaus DBL

    If it is of any help...

> > > The Makefile system was the quickest way to stitch together the
> > > design flow. In the long run, what I would try is to wrap each
> > > external (non-Coriolis2 tool) in a Python wrapper, so making a
> > > design will be one big Python script.
> > 
> > 
> > ok interesting. ( i quite like Makefiles, because of their ability to
> > handle file dependencies)
> 
>   I was having the feeling that the whole Makefile system was reaching
>   an "obfuscation limit" and would deter people using it.
> 
> things like \$$macroname, these are where i personally would draw a line.
> 
> having python tools that are called *by* Makefiles because make works out that
> to generate file X.ext from X.ext2, doing that job in python, is a nuisance.

  There is a tradeoff here. If your tools are separated and communicate
  through files, Makefile is the best tool.
    In the other hand, the paradigm of Coriolis is to integrate the
  tools so that they communicate efficiently through a common C++
  data structure, becoming a kind of a big binary blob. This is
  the acknowledged trend among this kind of tools.
    Anyway, I try to make Coriolis "agnostic" on the way it is used,
  that is not try to enforce any specific way to use it.


> when it goes recursive, it gets even more hairy in python (bear in mind we need
> to do a hierarchical layout, not a "full automated and pray" one)
> 
> so for example, we need to generate the netlist not from a hardcoded list that
> goes into the top level Makefile, we need a *program* that generates that
> information, based on what comes out of the *nmigen* conversion to ilang.

  Sound like a more like a Python program to me than a Makefile.
  But it's the troll part of me which is speaking. Use what you
  see fit.

>   The idea of Python wrapper is to be able to manage some kind of
>   "meta-information" across the whole design flow. And, hopefully,
>   reduce the obfuscation of the Makefile by using object oriented
>   structuration.
>     And lastly (but very long term) to seamlessly switch from a
>   wrapped old tool to a shiny new one directly implemented in
>   Coriolis...
> 
> :)
> 
-- 

      .-.     J e a n - P a u l   C h a p u t  /  Administrateur Systeme
      /v\     Jean-Paul.Chaput at lip6.fr
    /(___)\   work: (33) 01.44.27.53.99              
     ^^ ^^    cell:      06.66.25.35.55   home: 09.65.29.83.38

    U P M C   Universite Pierre & Marie Curie
    L I P 6   Laboratoire d'Informatique de Paris VI
    S o C     System On Chip