On Thu, 15 Mar 2007, Steve Meier wrote:
To recap,
XML usage is a dead subject as far as the geda project is concearned.
For the following reasons
1) xml tends to be bloated file size wise.
2) incorporating xml into geda would distract developers.
Well, there are a couple of other reasons too. I put the whole thing
on the gEDA FAQ under:
http://geda.seul.org/wiki/geda:usage#can_we_change_geda_to_use_an_xml_file_format
But don't dispair! I think there are other ways to address your points...
Do they work. Sure for flat designs. But, not for complex hierarchical
designs.
Actually, the gEDA file format is similar to -- but not the same as --
the ViewDraw file format. And ViewDraw *does* support hierarchy &
working bus rippers. Therefore, at least IMO, the point is not to
implement an XML format, but rather to define a hierarchical format
for gschem which is a superset of our current format. The idea is to
enable hierarchy, but not break existing designs. Doing it this way
enables us to leverage our existing code and project base.
My reality is that I forked from geda back in 2003. I made a hap hazzard
attempt to merge my code with the 2005 geda version. Then I decided that
libgeda data structures as is just don't support complex designs. This
is not saying thet they are trash they have a lot of important concepts
with in them. But as they stand they are not adequate.
That's fine. The discussion about hierarchy should focus on the
following points:
* What kind of data structures are desirable? How would they look?
Right now, the main data structure for a schematic is a linear linked
list of graphical objects (for each schematic page). Some list items
point to others (i.e. to support component attributes). How would that
change to support hierarchy?
* ONce a datastructure is decided upon, then what does the file
format look like? Note that our current file format maps fairly
closely onto the internal data structures. Preserving this close
mapping is a desirable goal. Therefore, the data structures defining
hierarchy should more-or-less dictate what the file format should look
like.
* How should gschem behave once hierarchy is architected in? Right
now you attach a source= attribute to a symbol. Then you do
"schematic down" on that symbol to dive into the sub-schematic. Is
that OK? Or what's a better scheme?
And how to handle re-use blocks? That is, if I have a sub-schematic
which I instantiate four times, how should it be refdesed in the
netlist? If I dive into one of the four instantiations and edit it,
is it OK that the other three instantiations are also updated.
A list of use-cases would be helpful here.
* Similarly, how should gnetlist behave? A use-case list would be
useful.
* Finally, how should PCB behave with a hierarchical schematic?
If geda is to be relevent in the future it needs to address:
1) hierarchical data and file structures (xml or other)
2) an integrated hierarchical netlister
Can do per above comments.
3) use of a better supported scripting language
This is a long discussion. If we want to really dive into this, we
should start another thread. And put another pot of coffee on.....
4) a method of dynamically partioning devices into meaningfull symbols
?
5) a method of communicating between the schematic design and the layout
program on issues of slot swapping, i/o pin swapping, differential i/o
pin swapping, bank swapping
Agreed. This may be already in progress.....
6) strong drc
Sure, but where? DRC is usually a layout issue. We have a schematic
DRC checker which -- IMO -- causes us more grief than it should since
newbies blindly use it and then complain to geda-user when it reports
trivial errors. IMO, DRC is a PCB layout issue. Maybe we should
rename our schematic DRC program "schematic-checker" or something,
since design-rules are generally a manufacturability check.
If we want to discuss this one further, please start a new thread.....
7) quality libraries of symbols, land patterns and simulation models
I see a business model......
8) a clear deffinition of what is GPL and what is available for
commercial use. I have even dumped the busripper.sym because I don't
know if it would contaminate my commercial projects
This is an interesting point. We usually make the analogy to
OpenOffice Writer, which is GPL'ed software with fonts. What licence
covers the fonts? I belive somethign open-source, right? In any
event, if you write a doc using Writer, it doesn't automatically
become open-source.
GEDA should be the same. The software is open-source, as are the
symbols & footprints. However, designs created usign gEDA can be
closed-source and proprietary.
The action item here is to create a web page clearly spelling these
things out.
ps geda is now available through sourceforge and 7 developers are
registered. I have in the past for other projects made donations to
support development. It looks like of the seven developers only one is
interested in such donations.
This has been discussed. Ales is the head of the project, so he
handles the money. We have discussed opening a separate bank acct for
the donations. We have plan to use the $$$$ for things
like paying for hosting & advertising.
Just MHO,
Stuart
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
