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

[Steve Meier <smeier@xxxxxxxxxxxxxxxxxxx>]

I think the only area of question is... is there a need to translate
from spice to another language? The need for a spice output is so that
tools that use spice input exclusively can be supported and that users
who preffer to have a version of their work in a spice syntax can have
it. I see no need to deprive geda users of a spice output? If you don't
need it don't use it.

Steve Meier

al davis wrote:
> 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
>
>   



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