Mail Archives: geda-user/2015/07/13/21:45:05
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
- Raw text -