[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 #206 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jock Tanner from comment #205)
> (In reply to Luke Kenneth Casson Leighton from comment #204)
> > ermmm ermermerm i like the idea of keeping things in an external file
> > 
> > *thinks*... actually, CSV format would be better, because it's 3 lines of
> > code:
> > 
> >     import csv # standard python library
> >     with open(file_path, 'r') as csvfile:
> >         return list(csv.DictReader(csvfile))
> > 
> > remember, we need to minimise the dependencies (see HDL_workflow, and see
> > discussion we just had!)
> > 
> > in CSV format, it could be:
> > 
> > SIDE,pinname,offset,comment
> > NORTH,clk,,,
> > 
> > the defaults would be, if there is no offset, to make one.  the order of
> > the pins in the CSV file would define the order in which they appear on
> > that side.
> > 
> > i think that would work really well.  later we can consider actually
> > embedding
> > the CSV file contents *into* the docstring (or a function) of the actual
> > nmigen source code.
> 
> Looks like I implied too much.

(nono, we're discussing ideas, here.  it's just that unlike other projects
which can freely add arbitrary dependencies, we have to be careful and consider
how a particular task may be achieved.  the suggestion of doing something that
jinja would *be* suited to was great).

> First of all, I thought of keeping all the ioring logic intact as of a
> requirement, 

not a hard one.

> or at least as a generally good approach. 

yes.

> That's why I didn't
> consider adding, say, CSV support into 'coriolis2.ioring' or
> 'Configuration.loadConfiguration()'.

no that would be stepping on the toes of the coriolis2 project.

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

now, if ioring.py was capable of allowing us to specify that "signals a[0..15]
are to be on the LEFT part of the NORTH side", then yes i would say it was
perfect.

this is why i suggested being able to specify the precise location.


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

> Of course, I'm not yet proficient enough in the current workflow to see all
> the right implications. So I have to ask of you to specify my task.

ok, let's discuss this on another bugreport.

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