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
	:content-type;
	bh=+QkKqZa6ThV+nIe6DK+pFObFmj4BuXSbsa6psJGyGMA=;
	b=iasboiSBWVznLtN7fcnOYkPKl5AzTYUH0D0xVlN1QdnMk6Q7bcVNlS9wKyOpCabWtc
	k8jP5JmCwrjoQqqnCzwcKdOl+AiB9hCzQaNckT8RbmsgS8tEj8ft/rt3p5bLeKVcTN8q
	wdnD9tg6wklRmBe77ZgS5KOX/EVJrHBCy/E21YUnw25bvielGYy5K5TbUaW/sQlq7sRU
	TXtjTbMeu/jtlRpmmPSqlvMNEj5ChT3nm6WwLvf9iXbG4yz7gFYTLcTQNuf+eAqK34za
	GHFpIxvmEwSocCzzFaxSUsy8Vzy+3tg7DJWLzQhfKPW4RBJgvgF2zcpz+S4gKNA4Q6BU
	5icA==
MIME-Version:	1.0
X-Received:	by 10.107.19.161 with SMTP id 33mr57037322iot.62.1441810439246;
	Wed, 09 Sep 2015 07:53:59 -0700 (PDT)
In-Reply-To:	<201509090058.t890wwDB014552@envy.delorie.com>
References:	<alpine DOT DEB DOT 2 DOT 11 DOT 1509031356150 DOT 13201 AT nimbus>
	<msi77b$6rr$1 AT ger DOT gmane DOT org>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1509082036590 DOT 3066 AT lichen>
	<201509082040 DOT t88KerD6005455 AT envy DOT delorie DOT com>
	<55EF7C26 DOT 8080108 AT ecosensory DOT com>
	<201509090058 DOT t890wwDB014552 AT envy DOT delorie DOT com>
Date:	Wed, 9 Sep 2015 07:53:59 -0700
Message-ID:	<CAOP4iL1yGEhSO1GkF4XmMo7sEtN3z3ZTtBfcA=NaLNkmzq9wgw@mail.gmail.com>
Subject:	Re: [geda-user] New experimental netlist features
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

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

On Tue, Sep 8, 2015 at 5:58 PM, DJ Delorie <dj AT delorie DOT com> wrote:

>
> > If a buss is labelled
>
> buss (n) a kiss, or (v) to kiss.  I don't label mine ;-)
>
> > [0..3] and is in contact with a buss having label x[0..31] all the
> > info is there to figure out that the [0..3] buss is called x[0..3]
>
> It's the "and is in contact with" that's the problem.  In gnetlist,
> all net segments that are connected are considered as one net.  A
> collection of connected bus segments would be one bus.  Naming
> different segments of that bus differently causes ambiguity.
>
> The problem is as pictured here:
>
>   http://www.delorie.com/pcb/bus-pins.html
>
> If a bus has multiple signals in it, and you give different ends (or
> branches) of the bus different netnames, you've created a conflict
> that the netlister has to magically resolve.
>
> The way bus segments work *now*, the bus segment itself is the magic
> that keeps the nets connected to the bus rippers from being
> "connected" and thus they're allowed to have different names.
>



I for one usually think of a bus as several different signals that are
always used together such as a microprocessor
bus with have address, data and control signals.

I would use vector for what you are calling a bus if it is only one signal
name and a width.


The problem with PCB netlists is that digital design always uses a subset
of verilog known as "synthesisable verilog" for
all design work. Only the testbench can use the entire language.

PCB design is actually a superset of verilog. You can run a piece of metal
between any two nodes and have a valid circuit
that will be a real mess for the netlister to understand. I can have a 34
pin flat cable connector with 17 signals on the odd
pins and ground on all the evens. Feed that to verilog and it will puke. A
component can have multiple pins with the same
name and those pins are all shorted together. Solder it to a board and you
change the netlist.

A verilog netlister has to do more than simply converting syntax. Sometimes
it has to resolve aliases and put in transmission
gates.


I am also not thrilled with the current bus rippers. The two component
rippers only have one hot spot so the connection is made by name
only, it works even if its not on the correct bus. The third option of
using a net as a bus ripper does have two hot spots and works
correctly. Adding a second hot spot to the rippers should fix that.



John Eaton

--001a113f39f0109aa7051f51a73c
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 Tue, Sep 8, 2015 at 5:58 PM, DJ Delorie <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:dj AT delorie DOT com" target=3D"_blank">dj AT delorie DOT com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
&gt; If a buss is labelled<br>
<br>
</span>buss (n) a kiss, or (v) to kiss.=C2=A0 I don&#39;t label mine ;-)<br=
>
<span class=3D""><br>
&gt; [0..3] and is in contact with a buss having label x[0..31] all the<br>
&gt; info is there to figure out that the [0..3] buss is called x[0..3]<br>
<br>
</span>It&#39;s the &quot;and is in contact with&quot; that&#39;s the probl=
em.=C2=A0 In gnetlist,<br>
all net segments that are connected are considered as one net.=C2=A0 A<br>
collection of connected bus segments would be one bus.=C2=A0 Naming<br>
different segments of that bus differently causes ambiguity.<br>
<br>
The problem is as pictured here:<br>
<br>
=C2=A0 <a href=3D"http://www.delorie.com/pcb/bus-pins.html" rel=3D"noreferr=
er" target=3D"_blank">http://www.delorie.com/pcb/bus-pins.html</a><br>
<br>
If a bus has multiple signals in it, and you give different ends (or<br>
branches) of the bus different netnames, you&#39;ve created a conflict<br>
that the netlister has to magically resolve.<br>
<br>
The way bus segments work *now*, the bus segment itself is the magic<br>
that keeps the nets connected to the bus rippers from being<br>
&quot;connected&quot; and thus they&#39;re allowed to have different names.=
<br></blockquote><div><br><br><br></div><div>I for one usually think of a b=
us as several different signals that are always used together such as a mic=
roprocessor<br></div><div>bus with have address, data and control signals.<=
br><br></div><div>I would use vector for what you are calling a bus if it i=
s only one signal name and a width.<br><br><br></div><div>The problem with =
PCB netlists is that digital design always uses a subset of verilog known a=
s &quot;synthesisable verilog&quot; for<br></div><div>all design work. Only=
 the testbench can use the entire language. <br><br></div><div>PCB design i=
s actually a superset of verilog. You can run a piece of metal between any =
two nodes and have a valid circuit <br></div><div>that will be a real mess =
for the netlister to understand. I can have a 34 pin flat cable connector w=
ith 17 signals on the odd <br></div><div>pins and ground on all the evens. =
Feed that to verilog and it will puke. A component can have multiple pins w=
ith the same<br></div><div>name and those pins are all shorted together. So=
lder it to a board and you change the netlist.<br><br></div><div>A verilog =
netlister has to do more than simply converting syntax. Sometimes it has to=
 resolve aliases and put in transmission<br></div><div>gates.<br><br><br></=
div><div>I am also not thrilled with the current bus rippers. The two compo=
nent rippers only have one hot spot so the connection is made by name <br><=
/div><div>only, it works even if its not on the correct bus. The third opti=
on of using a net as a bus ripper does have two hot spots and works<br></di=
v><div>correctly. Adding a second hot spot to the rippers should fix that.<=
br><br></div><div><br><br>John Eaton<br><br></div><div><br><br></div><div><=
br><br></div><div><br><br><br>=C2=A0<br></div></div><br></div></div>

--001a113f39f0109aa7051f51a73c--

- Raw text -