On Dec 10, 2007, at 7:18 AM, Peter Clifton wrote:
>
> On Sat, 2007-12-08 at 17:41 +0900, John Doty wrote:
>
>> Automatically copy any symbol referenced to there. *That's* where you
>> "embed" symbols (not in some random schematic file, where they do not
>> belong). Give any symbol found there sil
On Sat, 2007-12-08 at 17:41 +0900, John Doty wrote:
> Automatically copy any symbol referenced to there. *That's* where you
> "embed" symbols (not in some random schematic file, where they do not
> belong). Give any symbol found there silent, unconditional priority
> over library symbols, s
DJ Delorie wrote:
>> I'm not advocating making a relational database part of the required
>> geda tool set
>
> No reason it couldn't be, either. We can hide all that in gattrib and
> the netlisters.
>
> No reason not to support multiple BOM files in gattrib either; just
> like we support multipl
On Dec 8, 2007, at 10:13 AM, Peter Clifton wrote:
>
> On Sat, 2007-12-08 at 08:52 +0900, John Doty wrote:
>> ...
>> Right now, the mechanics of browsing the libraries for a graphic,
>> copying that to your project library, rescanning symbols to make it
>> visible (arrrggh!), and then finally pick
On Dec 8, 2007, at 4:25 PM, Peter TB Brett wrote:
> On Friday 07 December 2007 23:52:05 John Doty wrote:
>
>> Right now, we, by default, reference light symbols in a common
>> library, and then attach attributes to them. That's wrong, too: if
>> I'm going to use a bunch of, say, OP220's in a desi
On Friday 07 December 2007 23:52:05 John Doty wrote:
> Right now, we, by default, reference light symbols in a common
> library, and then attach attributes to them. That's wrong, too: if
> I'm going to use a bunch of, say, OP220's in a design, I want all of
> them to have the same package and temp
think of tables of tables,
i have a resistor table that has all of my companies resistors, hell
even the reel number for the pick and place machine i am using, and
my schematic page is linked to a table it reads that table and sees
that you have resistor known as abc123 it points to the resist
DJ Delorie wrote:
>> I'm not advocating making a relational database part of the required
>> geda tool set
>
> No reason it couldn't be, either. We can hide all that in gattrib and
> the netlisters.
I should mention one little gotcha... hierarchy always throws in a few
kinks, since a database
> I'm not advocating making a relational database part of the required
> geda tool set
No reason it couldn't be, either. We can hide all that in gattrib and
the netlisters.
No reason not to support multiple BOM files in gattrib either; just
like we support multiple SCH files already.
On Fri, Dec 07, 2007 at 06:24:00PM -0800, Dave N6NZ wrote:
>
> In the geda world, I think this makes just as much sense. The above 5
> column table would work perfectly fine in mySQL or pick your favorite
> database.
I don't want to get bogged down in the whole argument, but I will point
out t
This problem was solved in the last millennium, and the tools have been
written. It's called a relational database.
You can't do a CPU design project involving hundreds of engineers with a
schematic system that doesn't scale. In the last century I worked on
several CPU's where the schematics,
On Sat, 2007-12-08 at 08:52 +0900, John Doty wrote:
> Right now, we, by default, reference light symbols in a common
> library, and then attach attributes to them. That's wrong, too: if
> I'm going to use a bunch of, say, OP220's in a design, I want all of
> them to have the same package and
Hey, a thought...
What if gattrib could accept a *.bom on the command line in addition
to the *.sch ? We'd have to color code the cells to say which
attributes go to the schematics and which to the bom, and figure out
the logistics, but it might fit what we're trying to accomplish.
___
On Dec 7, 2007, at 4:08 PM, Steve Meier wrote:
> John Doty wrote:
>> The interesting idea so far in this discussion has been to let the
>> BOM be source rather than product.
>>
>>
> Dang, That was the idea I intentionally left out of my last diatribe.
> And you cut right to it. I agree, that the
Steve Meier wrote:
> John Doty wrote:
>> The interesting idea so far in this discussion has been to let the
>> BOM be source rather than product.
>>
>>
> Dang, That was the idea I intentionally left out of my last diatribe.
> And you cut right to it. I agree, that the world being bom specific
al davis wrote:
> On Thursday 06 December 2007, Steve Meier wrote:
>
> 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.
>
John Doty wrote:
>
>
>> I have an internal language and read my lips "I ain't going to change
>> its basic structure other then to extend it".
>>
>
> What do you mean by internal language? We have two: sch/sym as data,
> scheme as program. And maybe we want more:
>
> 1. A database for hea
John Doty wrote:
> The interesting idea so far in this discussion has been to let the
> BOM be source rather than product.
>
>
Dang, That was the idea I intentionally left out of my last diatribe.
And you cut right to it. I agree, that the world being bom specific as
opposed to schematic speci
On Dec 7, 2007, at 2:10 PM, Steve Meier wrote:
> Al, John,
>
> Stop worrying about anyone trying to use spice as an internal
> language.
> To quote the SNL version of George Bush "It's not going to happen".
Of course it's not going to happen. It's the chaos it could cause by
trying to happen
John Doty wrote:
> On Dec 7, 2007, at 3:45 AM, Dan McMahill wrote:
>
>> John Doty wrote:
>>> On Dec 6, 2007, at 2:46 PM, Steve Meier wrote:
>>>
As long as its semantics is well enough deffined that I can write a
macro to read and write its file formats then why not?
>>> It might be nice,
John.
As a ground rule I think you should let Al speak for himself. Thus you
are free to claim discomfort when others put their interpretations of
your ideas as quotes from you.
If you want you can say "I think Al wants "the structural subset" of
verilog to be the data base." Showing you are
Al, John,
Stop worrying about anyone trying to use spice as an internal language.
To quote the SNL version of George Bush "It's not going to happen".
Likewise, stop worrying about vhdl or verilog being the internal
language. "It's not going to happen".
I have an internal language and read my lip
On Dec 7, 2007, at 12:53 PM, Steve Meier wrote:
> I think the only area of question is... is there a need to translate
> from spice to another language?
Think of SPICE as object code. It's useful as an import format for
modules somebody else has "compiled" and you don't intend to change.
It'
For answers #1, #2 and #3 That the point of having a scripting backend?
I also refuse to become fluent in klingon but I am not opposed to having
other who are interested work on traslators. Same goes for xml or any
other language. The test of the quality of the universiality of the
libgeda or "non-
On Dec 7, 2007, at 12:40 PM, Steve Meier wrote:
>
> I am particularily interested in being able to output netlists for
> simulation wich support hierarchical references.
Right now, the big problem is that gnetlist will insist on expanding
all references via source= itself, so you wind up with
On Thursday 06 December 2007, 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
On Thursday 06 December 2007, Peter Clifton wrote:
> XML can be an expressive "format" if you use it right (define
> a good DTD to use for your application), so I'm not saying
> VHDL / Verilog are the only solutions.
An XML based format could have an "advantage" (in quotes because
whether it is a
On Thursday 06 December 2007, Peter Clifton wrote:
> Al previously explained how this could also be used to model
> PCB tracks, where the simple model could be that they are
> wires (or short circuits), and with more complex models being
> substituted based on their physical geometry if desired.
>
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
John Doty wrote:
> On Dec 6, 2007, at 11:43 PM, Steve Meier wrote:
>
>
>> John,
>>
>> Well veralog or vhdl as an internal data structure format? Maybe but I
>> am not going to worry about it or attempt it.
>>
>
> But that is what Al is proposing.
>
>
I don't think so. At least he isn't a
On Thu, 2007-12-06 at 20:11 -0500, al davis wrote:
> 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 l
>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
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 als
On Fri, 2007-12-07 at 08:35 +0900, John Doty wrote:
> The issue at hand is how the databases that drive this should work.
> Various people have various visions. I have no strong preference as
> long as the result retains gEDA's flexibility. But I don't know how
> to evaluate Al's suggestion
On Dec 7, 2007, at 3:45 AM, Dan McMahill wrote:
> John Doty wrote:
>> On Dec 6, 2007, at 2:46 PM, Steve Meier wrote:
>>
>>> As long as its semantics is well enough deffined that I can write a
>>> macro to read and write its file formats then why not?
>>
>> It might be nice, but who knows what it
On Dec 6, 2007, at 11:43 PM, Steve Meier wrote:
> John,
>
> Well veralog or vhdl as an internal data structure format? Maybe but I
> am not going to worry about it or attempt it.
But that is what Al is proposing.
> But I am curios enough
> that I might look at icarus' data structures. Perhaps w
John Doty wrote:
> On Dec 6, 2007, at 2:46 PM, Steve Meier wrote:
>
>> As long as its semantics is well enough deffined that I can write a
>> macro to read and write its file formats then why not?
>
> It might be nice, but who knows what it is, and how to reasonably map
> it onto our problem? A
John,
Well veralog or vhdl as an internal data structure format? Maybe but I
am not going to worry about it or attempt it. But I am curios enough
that I might look at icarus' data structures. Perhaps what Al is
suggesting is that vhdl has all the elements needed for constructing an
internal data s
On Dec 6, 2007, at 3:13 PM, Steve Meier wrote:
> John,
>
> The beauty of geda and its scheme capabilities is that any file format
> that is reasonably well deffined can be supported.
Indeed. Give me a well defined format with a clear use, I might even
help.
>
> Instead of railing at at Al sta
On Dec 6, 2007, at 3:38 PM, al davis wrote:
> On Thursday 06 December 2007, John Doty wrote:
>> It might be nice, but who knows what it is, and how to
>> reasonably map it onto our problem? Al's always selling
>> Verilog. But I went and bought the book he recommended on
>> Verilog-AMS, and it w
On Thursday 06 December 2007, John Doty wrote:
> It might be nice, but who knows what it is, and how to
> reasonably map it onto our problem? Al's always selling
> Verilog. But I went and bought the book he recommended on
> Verilog-AMS, and it was mostly more sales pitch.
>
> I AM REALLY TIRED OF
John,
The beauty of geda and its scheme capabilities is that any file format
that is reasonably well deffined can be supported.
Instead of railing at at Al start helping to nail doen the deffinitions
on the formats your prefer.
As I have said my short term goals are to provide output support for
On Dec 6, 2007, at 2:46 PM, Steve Meier wrote:
> As long as its semantics is well enough deffined that I can write a
> macro to read and write its file formats then why not?
It might be nice, but who knows what it is, and how to reasonably map
it onto our problem? Al's always selling Verilog.
As long as its semantics is well enough deffined that I can write a
macro to read and write its file formats then why not?
al davis wrote:
> On Wednesday 05 December 2007, Michael Sokolov wrote:
>
>> al davis <[EMAIL PROTECTED]> wrote:
>>
>>> Why invent a new language? Either Verilog-AMS
On Wednesday 05 December 2007, Michael Sokolov wrote:
> al davis <[EMAIL PROTECTED]> wrote:
> > Why invent a new language? Either Verilog-AMS or VHDL-AMS,
> > the = structural subset, has everything you need.
>
> I needed something I could implement by myself without any
> help from the outside wo
al davis <[EMAIL PROTECTED]> wrote:
> Why invent a new language? Either Verilog-AMS or VHDL-AMS, the =
> structural subset, has everything you need.
I needed something I could implement by myself without any help from the
outside world and without any dependencies. It also needs to run under
UN
On Wednesday 05 December 2007, Michael Sokolov wrote:
> Yes, you've hit the nail right on the head! That's exactly
> how I do it in uEDA, gEDA's evil twin.
>
> In uEDA the master source code for a board is an ASCII text
> file named MCL, which stands for Master Component List. It
> is not a gener
48 matches
Mail list logo
