Re: gEDA-user: uEDA .. was .. Re: Heavy Symbols and such

[al davis <ad151@xxxxxxxxxxxxxxxx>]

On Thursday 06 December 2007, Steve Meier wrote:
> Perhaps what Al is
> suggesting is that vhdl has all the elements needed for
> constructing an internal data structure?

Not really ... The idea is a common interchange format.  Even if 
the data is different, the syntax can be the same.

Steve also said this in private mail (I hope you don't mind my 
repeating it in public):
> I actually think that one of the rather remarkable things
> about geda is the use of a macro language to generate the
> output.
 .... repeated because I agree with it, strongly.

On Thursday 06 December 2007, John Doty wrote:
>  I have no strong preference as  
> long as the result retains gEDA's flexibility.
... also repeated because I agree with it, strongly.

Those last two points are so strong that if the format fails to 
meet either, it must be rejected.

ok ... let's look at the requirements

First, the data.

All of the tools dealing with structure need files consisting of 
the following:

-- The ability to encapsulate into some kind of modules.

Each module contains a list of objects .. "instances".

Each "instance" statement contains 4 parts:

1. The type.
2. The name or label.
3. A list of connections.
4. A list of parameters or attributes.

If you disagree at this point, address it now.

If you can accept that, let's look at some formats.

The obvious one is the Spice format.

R1 1 3 10k
Q2 2 4 5 2n2222
X1 3 5 block

Let's do something a little harder ..
parameterized values, fancy sources, arguments to subcircuit 
calls ...

R1 1 3 bob
Q2 2 3 5 6 lateral area=2
X1 2 4 block d=4 e=6
V1 1 0 pulse (.001 23 44.55 6 0)
X2 a b c d e f g h i j

What is the letter for an op-amp?
What is the letter for an SCR?
What is the letter for a trace on a PC board?
What is the letter for a Via?
Do you remember the order of those arguments on the V1 line? 
-- I don't .
On the X2 line, can you figure out which arguments are nodes, 
which is the name of the subcircuit being called, which are 
parameters?
 -- remember, the ()[]= are all just whitespace!
It seems that every type has different syntax.
Type is encoded in the letter.
It was a good format in 1975.  We have outgrown it.
----- fails both the macro language and flexibility criteria.


The logical outgrowth of this is the Spectre format.
R1 (1 3) resistor r=bob
Q1 (2 3 5 6) lateral area=2
X1 (2 4) block d=4 e=6
V1 (1 0) vsource type=pulse width=1u rise=.1u delay=1u
X2 (a b c) d (e=f g=h i=j)

---- much better.
Still, the parentheses are optional.  You need to scan forward 
to the first "=" to figure out what is where.
It is nice from a human viewpoint, but as is fails the macro 
language test.  It is easy to fix, but they didn't.
Every type has the same syntax, regardless of what it is.

If the parentheses were required it would be an excellent 
format.

One big problem .....
The spec is proprietary.  It belongs to Cadence.

We should support standards, not proprietary formats, except as 
import and export.


How about VHDL ...
r1: entity resistor port map (p => 1, n => 3) generic map
    (resistance => bob);
Q2: entity lateral port map (c => 2, b => 3, e => 5, sub => 6)
    generic map (area => 2);

---- it's regular.  Could be adequate, but lots of extra stuff.
Every type has the same syntax, regardless of what it is.

The full spec (which mostly covers stuff not relevant here) is 
published and available for a price.  The price pays for the 
document itself, no restrictions on implementation.

It is certainly flexible enough.  Does it pass the macro 
language requirement?



Verilog....
resistor #(.r(bob)) r1 (1,3);
lateral #(.area(2)) Q2 (2, 3, 5, 6);
block #(.d(4), .e(6)) b1 (.hot(2), .cold(4));

--- it's not as pretty as the Spectre format, but it is easy to 
parse.

The first argument is always the type.
The parameters, which are optional, are marked with #, and 
enclosed in parentheses.
The label is next,
The ports are enclosed in parentheses.

Either list (ports or parameters) can be listed with the values 
in order, or by name in any order.  By name they always have 
the form .name(value) .. 

So, it meets the needs of retaining the flexibility, and being 
parsable with a macro language.  A statement can be generated 
with one line of code in most programming languages.

Every type has the same syntax, regardless of what it is.

The offical spec can be downloaded at no charge.  Mostly it 
covers behavioral modeling, which is beyond the scope of what 
we need here.


These formats were all designed by people who know Spice and 
needed something more flexible, and more parsable.



You could also make an XML based format to do this.  Note that I 
didn't say "use XML as the format".  Just saying XML doesn't 
say enough.  More info is needed.  It can be done, but there is 
no precedent for it.  There is a library for it, but do we want 
another dependency?  Can you easily parse it with a macro 
language?



Now, to generalize to things other than simulation netlists..

To represent a layout, "types" might say whether it is a via, 
trace, fill block, footprint by name.  The attributes are 
length, width, forms, scaling.  The connections are physical 
locations.  This is the same info that is in a PCB file now.  
(or any layout program)

To represent a schematic, "types" might say whether it is a 
line, dot, or a symbol by name.  The attributes are the 
attributes you specify now, and also perhaps color.  The 
connections are physical locations.  This is the same info that 
is in a gschem file now.  (or any schematic program)

You could extend this to just about anything that can be 
described as such a list of objects.


My proposal is (and has been) to pick one, and make the 
translators go through it as an intermediate format.  Ideally, 
tools could use it directly, but that is not necessary.

There is no standard for languages used by schematic and layout, 
so no basis there for choice.

The high end EDA tools are using something called "open access" 
as a generalized communication format.  There is a library 
available for reading and writing it.  It has several problems.  
The first is that it fails the macro language requirement.  The 
second is that the licensing on the library is not appropriate, 
and it is too complicated to consider rewriting.

The Spice, Spectre, VHDL, and Verilog languages are used by 
simulation and synthesis tools, extensively.  Other than Spice, 
it is easy to translate one to another.

Using a simulation language makes it easy to simulate directly 
from a schematic or layout, with no simulator extensions 
needed, other than to define what the types mean in that scope.

In research settings, I have seen all of these used to represent 
things more general than circuits.

For other uses, just use a different definition of what the 
types mean.

For simulation a PCB trace is a transmission line.
For layout a PCB trace is a box with dimensions.
That part is supplied externally.
The part in the data file can be the same.



So, .. the idea is: pick a syntax.  It must be sufficiently 
flexible and parsable with a macro language.
Then map it.

You could invent a new syntax, but there is no precedent for its 
use in this area, so you are on your own.  Pick one that people 
are already using, we get support from people who are using it, 
including some EDA researchers who would love to be able to use 
gEDA.....  (and have actually asked me about a way to do this, 
that isn't "open access" which isn't really open).








_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user