[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Defining parts with REALLY complicated pin labels

Stuart Brorson wrote:

My question:  Why should this functionality be embedded into gschem?
What's wrong with a separate GUI-based utility which accomplishes the
same effect?  Does integration into gschem solve a problem
which can't be solved using an independent utility?


Perhaps it should be a separate tool - I wouldn't rule it out.

I was just thinking about the workflow issues - ideally, if I am editing a schematic and need to reconfigure the part, I want to click on the part and change it. Now, if that action launches a separate program that doesn't really matter to me - indeed, from an implementation standpoint it probably would be better if a separate program were launched.

Thinking about it, what I would see happening would be there would be an attribute added to the part definition in the basic symbol library that would define a "configuration" script/program/whatever file. I'd think such data would probably be best stored as an XML file that defined the configurable pins, the available options for each pin, and the configuration data (register data) for each pin (with possibly some scripting embedded to handle any weird conditions). In addition, each instance of a configurable part on a schematic would have one or more attributes that defined what the configuration output file(s) were within the project hierarchy (e.g. ${PROJ}/software/cpld1/config.h). Then the configuration tool would read that XML file and provide the user interface for the setup.

Probably the "part" would actually be embedded into the schematic rather than referenced - adding the part would instantiate the part within the schematic.

I'm coming at this from the standpoint of an embedded software/hardware designer of 18 years - I have seen too many mis-matches between the data the hardware types are working with and the data the software types are working with. Ideally, I want the whole stinkin' project under version control, and set up so that when the hardware types make a change, that can drive a recompile on the software side, and ideally so that when the software types make a change that back-annotates the schematic.

Like I said earlier - when I dream, I dream big - adding features like that would REALLY make the gEDA suite stand out when compared with the likes of Mentor Graphics.