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 > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > > _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
