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

[bugzilla-daemon at libre-riscv.org]

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

--- Comment #66 from Jean-Paul.Chaput at lip6.fr ---

> > I'm on the same line of though here. Reproductibility through full
> > automation is a key point in this line of work. My brain was a
> > little slow to kick off, but I finally reminded myself that, based on
> > our experience at building ASICs here, it is fundamental that
> > we choose *one* target platform, specify the *exact* versions
> > (git hashes) of each tools to build the design.
> 
> eurk.  yeah.

  I know it looks a bit like dictatorship. And the end goal is to run
  on any sufficiently new system. But this way should allow us to build
  and debug more quickly by suppressing any "external" cause of
  problems outside the tool we are using and the design itself.
    People can then port from that master reference to others
  system.
    The proposed method is to focus on one system to completely build
  the design quickly, and only then, expand to other systems.

> > It can be a chrooted
> > environment, a docker container, a full VM image or whatever so
> > all people works exactly the same. We may provide the image and the
> > fully automated procedure to rebuild it from scratch.
> 
> hmmm... ok.
>  
> > Considering a chrooted Debian 9, we should use the *same* user inside
> > it. 
> 
> that makes sense.  not keen on it, as it becomes inconvenient to
> schroot into.  mind you if that's done with a script (outside) it's
> ok.
> 
> > Ideally the same name/UID, but keeping a common UID across various
> > systems may be difficult, so at least the same name. 
> 
> that's a good idea.
> 
> > And publish the
> > whole constructed chrooted filesystem (bit tarball).
> 
> bleuch.

  When we did ASICs, we did take a whole snapshot of all the tools
  along with design to be sure we can rebuild it later. Almost
  mothballed the computer also...

> > Running nMigen outside the chroot is a quick hack, but the kind that
> > must be avoided. I've absolutely nothing against hack, as long as
> > they can be automated.
> 
> i've installed nmigen inside.  it was a bit of a nuisance but doable.
> 
> debian 9 honestly is too old (no python 3.6), and stretch-backports
> doesn't included it (the normal and stable way you'd include later
> software)

So why not use Debian 10 ?

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