X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to;
	bh=e/ys7W+GqQZjwUY/oRw3ECSmPtaSLE+Cu/OCbjE1lSU=;
	b=sU7QN8BOlVGb4KG7HU2GYzzqGNFSXaTOV4EZfsndjgx+JYhJLH0aTteijWhoury3xX
	bv01O/2bmhx+Xsu9oDuEziLZWtbe8mp1A5V4irgfcLuKI3EzvfJPcQdf13EwDC2TLe/i
	Il8+0BXq4lGzeZ39g3nwqA2pHmV43lIfErvjCfeut+AZZQ78nZcG9wOa1x4ksqNuC0cm
	Hv+yK0/8QriVkoqvcHN4LDDo57wXxrghWvceQ5WgWikwEuHt9yFmehOAMJAfvj9WIuM9
	vAlgYWu+s3taXUFYUGVWRdJ+qL4LCRWDQCsEu8GsmlxQswDKVRupZ/ZpyuZyZqOMMZMJ
	NYrQ==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to;
	bh=e/ys7W+GqQZjwUY/oRw3ECSmPtaSLE+Cu/OCbjE1lSU=;
	b=XfR4OEbBQsGAgbwmMaTJe2mtQ99sjilt4oX9FYYCvBzq8GuBawr2E9cQnSbkly52aM
	rc/pjtvVsdCMH68h2MjtqW8RPVcs0IvV434NuIn/rh0DsD5VT9M/fr9d30X/RVSRvPk1
	0n9/cTno3M0tI9jhOkvR91WdVUr15VsWNcN2y8uKpT2vLFkh/IHDyLA2V/K0/AFV+k9v
	VfH0UrSUjCNCPX0zVrV/SjdcQ+sJaGZRxgWFQXaWJUpENsPkSCEfj8jQ31qFKHrsOdcw
	269bM7MTGYfMmx4/nOP0QXAr58+yGgUFaogqOe1txL8EBVDGhW9rEFeCIGKx1ghpHb1F
	r9HA==
X-Gm-Message-State:	ALyK8tJe8I47CewJCX1mrt6507hOo4yNwOX8bQMAwuvYvaSAJ+4Mc4wOHM3yJUNSWVq0KZwBdQqQzjzUdiCaHg==
MIME-Version:	1.0
X-Received:	by 10.36.22.130 with SMTP id a124mr4952825ita.58.1464539753091;
	Sun, 29 May 2016 09:35:53 -0700 (PDT)
In-Reply-To:	<CALT8Ef5EE=P=zo0ab8CC2_O=erj5ZXBQotXivCGy97kGq7JhUA@mail.gmail.com>
References:	<CALT8Ef7cjaCTZdU4QrR72ybb_pOrGb3nuXck5z0NkUvZoU0hfw AT mail DOT gmail DOT com>
	<20160528103918 DOT 82b3ae3b0e381a5e72b6b4cb AT gmail DOT com>
	<CAJXU7q-=Tq=aS=Qnzp8PZr2-t4i0mt7dUb5xrz6r-nLmLZhM2Q AT mail DOT gmail DOT com>
	<CALT8Ef5EE=P=zo0ab8CC2_O=erj5ZXBQotXivCGy97kGq7JhUA AT mail DOT gmail DOT com>
Date:	Sun, 29 May 2016 09:35:53 -0700
Message-ID:	<CAOP4iL2RDgB8qT8XzVi83ODS3n_At9K-A-J3GoW39Qpz__dtnQ@mail.gmail.com>
Subject:	Re: [geda-user] Hierarchial schematics, gnetlist, and attribs
From:	"Ouabache Designworks (z3qmtr45 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

--001a114453c2be1cc90533fdbbb0
Content-Type: text/plain; charset=UTF-8

On Sat, May 28, 2016 at 3:14 PM, Shashank Chintalagiri (
shashank DOT chintalagiri AT gmail DOT com) [via geda-user AT delorie DOT com] <
geda-user AT delorie DOT com> wrote:

> The bom backend also respects the contents of the attribs file - I've
> successfully been able to extract all manner of attributes using that
> method.
>
> When traversing the hierarchical schematic, though, there doesn't seem
> to be an obvious way to access the attributes of the 'parent'. I will
> try to use the hierarchical traversal disabled switch, though I would
> like to be able to do it on a per-run basis. i.e., I would first get
> bom.net with the bom backend, and then bom-top.net without
> hierarchical traversal to get a list of all the sources and associated
> refdes's of the symbols of subcircuits. Doing though by changing the
> gafrc file seems inappropriate.
>
> The ideal solution, though I'm not quite sure how to implement it,
> would be if when traversing hierarchical schematics, the 'child'
> packages inherit all the attributes of the 'parent' - so that any
> attributes of the parent which the child does not override, will
> trickle through down the hierarchy tree (however deep it may be) and
> remain accessible in the final, flattened BOM.
>

A child should never override anything passed down from it's parent.

Each child must define all of its attributes along with a default value.
The parent can then override any or all of the child's attributes as needed.
If it is not defined in the child then it is not used in the child.

This can get complicated, for example I have a VGA Interface module with
an attribute to configure as either 8 bit or 24 bit color. This attribute
is configured
in the top level and passed down into the interface module.

The setting of this attribute will affect to bus sizes on the RGB signals
so that the
intermediate levels will need to get the sizes from the lower level that
has
decoded them from the top level attribute.


The best solution is a new tool that will elaborate the top level design
into a
"uniquifed" new design that will give you your netlists.


John Eaton

--001a114453c2be1cc90533fdbbb0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, May 28, 2016 at 3:14 PM, Shashank Chintalagiri (<a href=3D"mail=
to:shashank DOT chintalagiri AT gmail DOT com">shashank DOT chintalagiri AT gmail DOT com</a>) [v=
ia <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank=
">geda-user AT delorie DOT com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">The bom backend also respects the contents of the attribs file - I&#39=
;ve<br>
successfully been able to extract all manner of attributes using that<br>
method.<br>
<br>
When traversing the hierarchical schematic, though, there doesn&#39;t seem<=
br>
to be an obvious way to access the attributes of the &#39;parent&#39;. I wi=
ll<br>
try to use the hierarchical traversal disabled switch, though I would<br>
like to be able to do it on a per-run basis. i.e., I would first get<br>
<a href=3D"http://bom.net" rel=3D"noreferrer" target=3D"_blank">bom.net</a>=
 with the bom backend, and then <a href=3D"http://bom-top.net" rel=3D"noref=
errer" target=3D"_blank">bom-top.net</a> without<br>
hierarchical traversal to get a list of all the sources and associated<br>
refdes&#39;s of the symbols of subcircuits. Doing though by changing the<br=
>
gafrc file seems inappropriate.<br>
<br>
The ideal solution, though I&#39;m not quite sure how to implement it,<br>
would be if when traversing hierarchical schematics, the &#39;child&#39;<br=
>
packages inherit all the attributes of the &#39;parent&#39; - so that any<b=
r>
attributes of the parent which the child does not override, will<br>
trickle through down the hierarchy tree (however deep it may be) and<br>
remain accessible in the final, flattened BOM.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"></font></span></blockquote><=
div><br></div><div>A child should never override anything passed down from =
it&#39;s parent. <br><br></div><div>Each child must define all of its attri=
butes along with a default value. <br></div><div>The parent can then overri=
de any or all of the child&#39;s attributes as needed.<br></div><div>If it =
is not defined in the child then it is not used in the child.<br></div><div=
><br></div><div>This can get complicated, for example I have a VGA Interfac=
e module with<br></div><div>an attribute to configure as either 8 bit or 24=
 bit color. This attribute is configured<br></div><div>in the top level and=
 passed down into the interface module.<br><br></div><div>The setting of th=
is attribute will affect to bus sizes on the RGB signals so that the<br></d=
iv><div>intermediate levels will need to get the sizes from the lower level=
 that has <br></div><div>decoded them from the top level attribute.<br><br>=
<br></div><div>The best solution is a new tool that will elaborate the top =
level design into a<br></div><div>&quot;uniquifed&quot; new design that wil=
l give you your netlists.<br><br><br></div><div>John Eaton<br><br></div><di=
v><br><br><br></div><div>=C2=A0<br></div></div></div></div>

--001a114453c2be1cc90533fdbbb0--

- Raw text -