X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Wed, 23 Dec 2015 00:18:09 GMT
From: falcon AT ivan DOT Harhan DOT ORG (Mychaela Falconia)
Message-Id: <1512230018.AA26106@ivan.Harhan.ORG>
To: gEDA User Mailing List <geda-user AT delorie DOT com>
Subject: Re: [geda-user] Verilog schematics (was Project leadership)
Reply-To: geda-user AT delorie DOT com

Peter Clifton (petercjclifton AT googlemail DOT com) wrote:

> Structural VHDL or its analogue equivalent would probably have given
> you a few more language intrinsic ways to abstract things a little
> more - at the expense of driving people mad with all the extra typing.

There is someone else who did a hack similar to mine, but based on
VHDL instead of Verilog - they called it PHDL for "PCB HDL".  You
should be able to find it easily with a web search.

As for me, I never learned VHDL - ran away scared every time I looked
into it.

> For me personally - I don't think it works as well for things like the
> analogue VCO. For that - I would prefer to see a gschem schematic, and
> a non-flattening net-list back-end which produces your verilog
> description as a secondary, generated output. (I'd understand that
> aspect of the circuit more readily then).

A valid point indeed.  Right now I essentially do a manual version of
what you just described: I wrote my Verilog code for those circuits
while looking at the original graphical schematics for the thing I'm
seeking to re-create. [1]

The VCXO circuit in question works by voodoo: I tried to understand
it, and failed.  Hence I am just mindlessly copying it from pre-existing
known-working designs w/o understanding.

[1] The "re-create" aspect is crucial here.  My typical projects are
not about creating anything truly new, but about re-creating things
that existed before, stuff which the mainstream society has relegated
to the realm of "obsolete", but which I personally find charming for
one reason or another.  And it's almost always re-creation with some
modifications (to suit my particular needs, or to adapt to changes in
the availability of parts or other issues), so I still need a new
netlist and a new PCB layout - it isn't as simple as just resending an
old set of gerbers to fab, even in those very exceptional cases when
such old gerbers are available.

> I'm presuming ueda has an element which can parse the verilog into a
> PCB netlist.

It is not one simple step though.  My tools implement the following
flow:

1. ueda-sverp parses the Verilog sources, elaborates the hierarchy and
   produces a flat netlist as its output.  The netlist emitted by
   ueda-sverp is in my own unet format; semantically it consists of a
   set of named wires (flat) and a set of COMPONENT objects with pins
   either connecting to these wires or explicitly unconnected.

2. unet-bind takes the unet netlist from step 1 as input and produces
   another unet netlist as its output.  The key transformation that
   happens in this step is the binding of the netlist to the MCL
   (Master Component List) - a feature retained from the previous
   incarnation of ueda.  The MCL is where all flat reference designators
   for the board are assigned, as well as other physical part attributes
   such as PCB footprints and Digi-Key part numbers.

3. Trivial utilities like unet2pcb and unet2pads convert ueda's internal
   netlist format (unet) to the netlist import formats of various PCB
   layout tools.

Naturally there is a Makefile in each board project with this flow, a
Makefile in which all of the above is codified. :-)

The Verilog source for the board fundamentally rests on a set of
"primitives" listed in a source file with that name.  Whenever a
Verilog module instantiates something, that something must be either
another Verilog module or a primitive, thus hierarchy expansion in the
ueda-sverp elaboration step produces a view of the board that is a
pile of these primitives interconnected with wires.  This pile of
interconnected primitives is what ueda-sverp emits in its unet output.

Ideally each primitive directly corresponds to a PCB package, with
Verilog ports of the primitive module being pin_1, pin_2 etc (or A1,
B2 etc for BGAs) - in this case the MCL binding step only needs to
assign flat reference designators to these instantiated primitives
corresponding to packages.  But a primitive can also be a subpackage,
with subpackages mapped to packages in the MCL binding step: this is
how I handle slots, i.e., situations in which two or more logically
and hierarchically separate circuit elements physically share one PCB
package.

M~