X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-TCPREMOTEIP: 207.224.51.38
X-Authenticated-UID: jpd AT noqsi DOT com
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [geda-user] gEDA/gschem still alive?
From: John Doty <jpd AT noqsi DOT com>
In-Reply-To: <201507131725.t6DHPU2V010794@envy.delorie.com>
Date: Mon, 13 Jul 2015 19:44:43 -0600
Message-Id: <A6AC6CBE-7C31-48BE-AD0D-62C9B2422ECF@noqsi.com>
References: <CAM2RGhQfPO31-1Uyc3kC7w286r0VD7c41UZEZcyYquzknCxbsQ AT mail DOT gmail DOT com> <20150707060409 DOT GB14357 AT localhost DOT localdomain> <CAOP4iL2C_LU=RQy5FWYF-7RrHW6tqhqqyFJGjkwLQ2AD7FiYJA AT mail DOT gmail DOT com> <1436287952 DOT 678 DOT 26 DOT camel AT ssalewski DOT de> <559C0F7E DOT 7010009 AT neurotica DOT com> <1436295556 DOT 678 DOT 91 DOT camel AT ssalewski DOT de> <CAOuGh89C71vTW00QLQgVBAQy=m6Me8khjqep=eFH7KgKGqaSzw AT mail DOT gmail DOT com> <559C3778 DOT 4000105 AT neurotica DOT com> <20150708072021 DOT GB13243 AT visitor2 DOT iram DOT es> <C69A441D-23D3-43B3-8892-0AE219D3EC5B AT noqsi DOT com> <20150713082342 DOT GB26809 AT visitor2 DOT iram DOT es> <A6EB1F12-F56D-4AE4-9AC9-801BC51418A3 AT noqsi DOT com> <201507131725 DOT t6DHPU2V010794 AT envy DOT delorie DOT com>
To: geda-user AT delorie DOT com
X-Mailer: Apple Mail (2.1878.6)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id t6E1ioW1017036
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
Precedence: bulk


On Jul 13, 2015, at 11:25 AM, DJ Delorie <dj AT delorie DOT com> wrote:

> 
>> For things with a lot of pins, I usually just draw a box without
>> pins, run a bus to it, and make the pin connections from a table
>> with pins2gsch.awk.
> 
> When I have to debug a faulty pcb, stuff like this would be useless.

Not at all. At the top level of a complicated board you get an incomprehensible wad of lines if you try to diagram it. A table can be much more useful.

> A schematic should be more than just "capture the netlist" - it should
> help the viewer understand the design and operation of the device.

Absolutely. So, for the analog front end of a digital video system, I’ll draw draw active load, coupling, correlated double sampler, integrator, and antialias filter feeding the ADC. A diagram is essential here. But then, the output of the ADC dives though a 192 pin stacking connector to a 484 pin FPGA. With 16 such channels, I find it much easier to have a table that tells me that the bitstream for channel B-4 is on pin 156 than to try to trace a line through a mess of other lines on a diagram.

With the FPGA, the situation is more extreme. When debugging, I don’t care that the signal winds up on pin H-15. I can’t probe it there. There’s no graphics beyond there anyway: the design is VHDL. The pin assignments are defined by Vivado, and can shift between major revisions, so I take the .csv Vivado generates, join it to a mapping of pin names to net names (not 1-1), and feed the result to pins2gsch. This is much less prone to error than a manual drawing that wouldn’t be useful anyway.


> 
> But I agree that there's a tradeoff that's sometimes best solved with
> a table instead of a diagram.  I've suggested adding a "table" object
> to gschem, for things like power/gnd pins.
> 

But why complicate the tool, when the toolkit approach solves this without the complication?

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com