[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 #208 from Jean-Paul.Chaput at lip6.fr ---
(In reply to Jean-Paul.Chaput from comment #207)
> Created attachment 35 [details]
> Coriolis2 ioring.py with explicit pad positioning

> > Second, I don't think that introducing an additional file with a special
> > format would do us any good. I suppose that 'coriolis2.ioring' is ok as it
> > is for passing pad configuration between stages. If I am just not aware of
> > the issues with it, please point me in a right direction.
> 
> the issue with ioring.py "as-is", is that the procedure for laying out the
> pads is entirely automatic, spaced-out evenly, because it's designed
> *exclusively* for doing Quad Flat Packages (QFPs).
> 
> what it can't do is something like this:
> 
> https://cdn.sparkfun.com/r/600-600/assets/7/a/6/9/c/51c0d009ce395feb33000000.
> jpg
> 
> that's an *uneven* distribution of the pads.

  Wrong! ;-) You can specify the exact position of each pad with the ioring.py
  file. I did put an example in attachement #35. It is not part of the toolkit
  as the related example is the adder with AMS 350nm (under NDA).

  I did not completely follow the thead about CSV file, but in my experience,
  I don't see the need of introducing a new file format (even if its simple
  CSV), directly write in Python instead.

> > What I did thought is necessary, is to eliminate the need for the user to
> > configure the pads at all, or at least to configure them separately from
> > top-level logic. I thought we can just set up formal rules (like putting
> > pins with names ending on '_i' to the left, '_o' − to the right), and
> > implement the reusable 'create_pads()' to inspect the list of pins according
> > to these rules and generate 'coriolis2.ioring'.
> 
> hmmm.... that may actually be useful in some cases.  i think... i think we
> need a class of some kind, with the ability to derive from it and create
> alternative layouts.

  In my experience again, there is too many different cases so that an
automated
  way works for for enough of them. And I'm very reluctant to put semantic in
  the pad names, it may clash with the HDL in too many ways.

   Lastly, if I'm not mistaken, you want to put information about the pads at
   nMigen level. I think it should be avoided. nMigen is for the design
   (behavioral or high leval description), and information pertaining to
   the layout should be kept at Coriolis level.

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