[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: gEDA-dev: GAF wish list addition - complex boards having multiplelogic families
On Mon, 4 Sep 2006, Timmerman, Bert wrote:
> Hi Evan, DJ and all,
>
> Some questions come to mind if we start working with (heavy) symbols in
> this way:
>
> - Does gattrib handle pin attributes of symbols yet ?
No.
> If so, it would be relatively easy to alter (cut-'n'-paste) pin
> attributes on library symbols for maintenance/auditing outside gschem.
Yes, that's the vision (although I don't want to integrate gattrib
into gschem). Then the work-around you present below will
become practical.
First, however, we need to implement pin -- or pin attrib -- promotion
to schematic level. The current scheme is that the pin and pin
properties are stored in the .sym file. The .sym file is opened and
read by gnetlist when creating the netlist. Therefore, you can't
store any changes made to the pin attribs without changing the .sym
file, which is undesirable since the .sym files are used globally.
For your scheme to work, we need to be able to promote certain pins to
the schematic (.sch file), and have them overwrite the pins stored in
the .sym file. That is, it must work something like the way "refdes"
works. The "refdes" attrib lives in the .sym file, but gets
overwritten in the schematic, and the overwriting refdes is stored in
the .sch file. If we did the same thing with pin attributes, you
could overwrite the pin attribs present in the .sym file with those
specialized for your design, and then store the changes out in the
.sch file.
This change requires some architectural changes in libgeda. This may
be a good project for the upcoming code sprint. Thoughts?
Stuart
>
> And maybe in the foreseeable future:
>
> - Could gattrib be made to alter pin attributes of a symbol while inside
> gschem ?
>
> A possible workflow could become:
>
> 1. save current work of the schematic (a wise thing to do, before making
> drastic things happen ;-).
>
> 2. work on a symbol (pins) with gattrib (inside gschem in gattrib-mode
> ?).
>
> 3. save work (while in gattrib-mode).
>
> 4. revert the schematic.
>
> I think it's about time to get something like gattrib for pin attributes
> inside the gschem gui.
>
> Just select a single symbol and then hit a gattrib keystroke (or select
> from a pull down menu/or click a gattrib menu bar button).
>
> Just my EUR 0.01
>
> Kind regards,
>
> Bert Timmerman.
>
>
>
> -----Original Message-----
> From: geda-dev-bounces@moria.seul.org
> [mailto:geda-dev-bounces@moria.seul.org] On Behalf Of Evan Lavelle
> Sent: Monday, September 04, 2006 10:38 AM
> To: gEDA developer mailing list
> Subject: Re: gEDA-dev: GAF wish list addition - complex boards having
> multiple logic families
>
> DJ Delorie wrote:
>
>> I suppose we could tag pins with Voh, VihMin, VihMax, etc.
>
> That would be a *really* nice feature, and I think would be the only way
>
> to do this. I just had to manually review a (Protel) board with 4 supply
>
> voltages (CMOS FPGAs/ASICs and 74LVCH) and this would have caught maybe
> half a dozen show-stoppers.
>
> A DRC check for over-voltages would be a good start but, to be really
> useful, it would need to be more complex. Some thoughts:
>
> - you'd need to be able to calculate static currents in/out of input
> pins, including the case where the trace goes through a resistor (a
> current-limiting resistor, or a pull-up or pull-down). This is because
> some input structures will tolerate over-voltages if the current through
>
> the input protection diodes is limited (this is commonly done on
> mixed-voltage CMOS boards). So you'd need attributes for
> presence/absence of input protection diodes, and their current rating.
>
> - for some families, "over" voltage is relative to the real current
> supply voltage to the chip; for others, its an absolute voltage level
>
> - for older TTL families, you might also want to calculate static
> currents in/out of output pins, to make sure that you get a valid logic
> level. To do this, you'd also need an attribute like "this output can
> only sink 16mA", or whatever. This would let you do pullup and fanout
> checks as well as voltage level checks
>
> - you could also check for 'reverse' currents: eg. a 3.3V pull-up, to a
> 2.5V input, through a forward-biased protection diode, back to the 2.5V
> supply; you need to warn that the 2.5V supply might have a problem with
> this
>
> - you need to warn about 'under-driven' inputs. It's common, for
> example, to drive 3.3V inputs with 2.5V. This is technically Ok (in the
> families I know about) but you get less noise immunity, and the designer
>
> should be reminded about this
>
> - an obvious one - just checking that the supply voltage is in range;
> can be fiddly for all those low-voltage 7400 families, and when more
> complex chips have 3 or more supplies (core, I/Os, etc)
>
> Evan
>
>
> _______________________________________________
> geda-dev mailing list
> geda-dev@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
>
>
> _______________________________________________
> geda-dev mailing list
> geda-dev@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
>
_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev