X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Tue, 17 Feb 2015 02:42:15 GMT
From: falcon AT ivan DOT Harhan DOT ORG (Spacefalcon the Outlaw)
Message-Id: <1502170242.AA18887@ivan.Harhan.ORG>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] Star connection points in PCB?
Reply-To: geda-user AT delorie DOT com

Peter Stuge <peter AT stuge DOT se> wrote:

> Your choices are pretty much to either use one net or to propose a patch.

Well, there is also a 3rd choice of having separate nets and starpoints
in the structural Verilog source for the board (which I use instead of
graphical schematics; see below), but as an interim measure until PCB
gains the proper support, have the nets merged into one in the tool
that converts the generated netlist into PCB's import format - but I
might indeed try to make a PCB patch that does what I seek.

The main reasons I posted my inquiry here are:

1. I wanted to see if anyone else ran into a similar problem and
   already developed some hacky patch for it - I know that plenty of
   people use their own private forks of PCB with non-mainlinable
   patches, and there has even been a recent mention of one by another
   list member.

2. I wanted to make people aware that the oft-seen "solution" of
   putting physical jumpers, resistors or inductors on the board
   instead of layout starpoints can have its own serious problems,
   Openmoko's infamous bug #1024 being a glaring example.

Now as far as actually implementing starpoint support in PCB, I'm
thinking of the following approach: find the code that checks for
shorts, and work the hack in there: teach the code that for certain
pairs of nets declared in some way, having exactly *one* short is
fine, but having two or more shorts is bad - and having no short at
all is bad too for those special nets.  But I might be totally off-
base here, not having looked at the code at all yet.  Anyone familiar
with PCB's handling of shorts who is reading this - is my idea on the
right track or totally off-base?

OK, I mentioned above that I use structural Verilog as my board design
entry language instead of graphical schematics.  Some folks will
undoubtedly be curious, so let me explain myself.  I made the decision
to forego graphical schematics because of the unique way my brain is
wired.  I was born with a brain that works especially well for anything
that can be expressed in lines of ASCII text, but is extremely poor at
graphical or visual tasks.  In other words, I have an 80 column mind.

I've only designed one board with graphical schematics as the design
entry language - my CSU/DSU for SDSL, historically named OSDCU.  The
board has been built and works great: the bits of this post are passing
through it on their way from my personal mail server to the list.  But
I found that when drawing schematics, I have to do double the work:
not only the inherently necessary part of entering the design data of
what components are present and how they are interconnected, but also
an artistic job on the side: deciding how the symbols should be drawn,
how they should be laid out on the page, where to make the splits
between pages etc.

Right now with my current project I simply don't have the extra life-
force energy to do all that extra artistic work, so I decided to just
skip the graphical schematics altogether.  Hand-coding a final-form
netlist of the kind one would import into PCB wasn't exactly appealing
to me either - for the same reasons I normally prefer to write C code
than enter machine instructions in hex.  Back when I did my OSDCU
board I converted the schematics from gschem into my own ad hoc uschem
format, and the latter expresses the graphical and interconnect aspects
in a mostly orthogonal manner.  Thus a uschem schematic "sheet" can be
either graphical or non-graphical.

But when I tried using my own uschem "language" in the non-graphical
mode as the design entry method for board source code, I empirically
found it to be poorly suited for the task.  The problem is that it's
too low-level, too much like writing a final-form netlist by hand.

And then I found what currently appears to be a perfect solution for
my specific needs: structural Verilog.  An example can speak better
than a thousand words, so here is the source in my CVS repo:

$ cvs -d :pserver:anoncvs AT ifctfvax DOT Harhan DOT ORG:/fs1/IFCTF-cvs co ueda fcm01

Of the two modules named in the cvs checkout command, ueda is my
toolchain and fcm01 is the board project I'm working on.  The two are
currently coevolving, just like my earlier incarnation of ueda/uschem
and the OSDCU board did.  The source code for the board is written in
structural Verilog, making extensive use of hierarchy to break what
would otherwise be one giant incomprehensible netlist into something
that's humanly readable and editable (at least by a human with a brain
wired like mine), and this Verilog source is processed by a tool I
wrote called ueda-sverp - it stands for "structural Verilog processor".
Ueda-sverp groks the structural Verilog sources (I wrote the parser
from scratch for the absolutely minimal subset of Verilog I need) and
elaborates the hierarchy into a flat netlist, which is the output of
the tool.

Next steps to be developed: bind this sverp-generated netlist to the
MCL (Master Component List, a human-written ASCII file in which all
BOM data are entered, a concept/feature I'm retaining mostly unchanged
from my earlier incarnation of ueda/uschem) and produce netlist output
in the right format for import into PCB.

Hasta la Victoria, Siempre,
SF