[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 #1 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
moving discussion from http://bugs.libre-riscv.org/show_bug.cgi?id=178#c208

(In reply to Jean-Paul.Chaput from comment #208)
> (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! ;-)

ah *ha*!

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

okaay.  so the positions are specified in coordinates along that edge. 
excellent.

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

the format of the ioring.py (which we didn't know about) covers it.

and, that leads me to investigate more thoroughly (grep -r "ioring.py"
src/coriolis-2.x) and i find this:

cumulus/src/plugins/chip/Configuration.py

ta-daaaa, ChipConf does pretty much (nearly) everything we need, jock.

which would leave just some "convenience" routines that help us to find
and construct the pad names, on which side.


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

yes this is why i suggested a pattern-match "helper" routine


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

i was tempted to suggest putting the *chip* information (which pads, which
side) into the structure-of-classes-which-happens-to-be-in-nmigen

why?  because the development is quite closely tied together

however a good case can be made for keeping the pads information completely
separate (in the soclayout repository)

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