[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page
bugzilla-daemon at libre-riscv.org
bugzilla-daemon at libre-riscv.org
Thu Mar 12 11:48:26 GMT 2020
--- 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
not a hard one.
> or at least as a generally good approach.
> That's why I didn't
> consider adding, say, CSV support into 'coriolis2.ioring' or
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:
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
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
> 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.
More information about the libre-riscv-dev