Mail Archives: geda-user/2016/01/16/15:00:51
> 1. For netlists flattened by gnetlist, we have a configurable syntax
> for net renaming before the Scheme stuff gets the data. The bus
> syntax here will have some difficulty with that.
Because of my choice of syntax, or because of some design limitation
in that part of the code? I'm not tied to the syntax, I know verilog
has a specific one it needs to use, that I don't mind adopting, but I
figured it would be neccessary for the backend at some point to pick
"something" via a callback to choose/enable such expansion.
> 2. For genuinely hierarchical netlists, there's probably not a
> single one-size-fits-all plug in solution. Not today.
Sigh.
> 3. For pinseq-centered netlisting (SPICE), it needs to expand
> pinseqs, too.
My example expands two attributes; expanding three shouldn't be a
problem.
> Another issue is that "-" seems a little strange as a range
> token. ":" would match Verilog and some programming languages for
> more user familiarity.
I picked dash because common English uses it as a shortcut for "to",
like "Copyright 1990-1995" or "meeting from 1-3pm". It made sense in
a list context.
Perl, C, and C++ use ".." (or "...") for ranges. It varies.
Plus, consider that a layout "bus" connects to a list of usually
non-sequential pin numbers. From the pinnumber point of view, "A:B"
syntax is less common than the "A,B,C" syntax.
OTOH the two syntaxes are orthogonal; one module could expand both -
so you could say A[1:4] connects to pins "4-6,8".
And I can see some folks getting confused about whether the :N means
"to this number" or "for this many numbers". I.e. is A[4:2] A4,A3,A2
or A4,A5 ? Unless you already know Verilog, it might be a stumbling
point, esp if you've seen ":16" elsewhere to mean "a 16-bit bus".
But in any case I'm not particularly tied to the syntax.
> I suggest using Dirac-style angle brackets to designate a bus
> definition, so a typical example might be "<nBL,A[8:2]>". While I
> think a sufficiently aware gnetlist plugin could navigate this
> without the extra tokens, we've historically exploited the
> transparency of our formats to process schematics with other tools
> as well. The extra tokens will help.
I don't see how the extra syntax helps anything, as it would just add
a "strip angle brackets around string" step. Busses would always only
have <> around the whole string.
I.e. what's the difference in usability between these:
<nBL,A[8:2]>
nBL,A[8:2]
I see no problem with just stripping out angle brackets, if that's
what you mean.
- Raw text -