How ever.... if you are interested in hierarchical buses and netlists and want to be able to generate them into your favorite syntax then please poke away at wahat I am working on tell me what you need and where my output in your format of choice can be improved.
Steve Meier Steve Meier wrote: > 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 > > _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
