[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: uEDA .. was .. Re: Heavy Symbols and such
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
>> 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
>
>
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user