Mail Archives: geda-user/2015/06/29/15:45:09
On Jun 29, 2015, at 11:46 AM, Stefan Salewski <mail AT ssalewski DOT de> wrote:
> On Mon, 2015-06-29 at 10:54 -0600, John Doty wrote:
>> On Jun 29, 2015, at 9:44 AM, Stefan Salewski <mail AT ssalewski DOT de> wrote:
>>
>>> On Mon, 2015-06-29 at 10:47 -0400, Jason White
>>> (whitewaterssoftwareinfo AT gmail DOT com) wrote:
>>>> Stefan, I think the easiest solution to net grouping attributes such as
>>>> "Power", "Analog", or "Digital" is to allow for each net to be displayed
>>>> with a different color.
>>
>> The file format already supports line colors and styles. I have always
>> thought it would make more sense to represent nets and busses with
>> lines that have attached attributes than to have primitives for these.
>> What we have now is a factoring error. Not too serious, but a barrier
>> to the future.
>>
>
> gschem file format supports line colors and styles. But for nets only
> color index is available currently:
>
> N 53500 61600 53000 61600 4
>
> And my fear is that many colors and styles for nets are really confusing
> when displayed all the time. It may be OK when we generally use plain
> color/style for all nets, but when we query "show high current +5V nets"
> then these are shown in a special color and style. But I am not sure, we
> have to test that in real live, and that is some works…
The editor designer is not in a position to make these decisions for an unfamiliar flow.
>
>>>
>>> Yes, that is generally the first idea. Problem is, that we may not have
>>> enough different high contrast colors. We may have analog and digital
>>> ground, analog and digital power and ground, high speed signals,
>>> impedance controlled traces, short traces i.e. for bypass capacitors and
>>> much more. We discussed about all that about 4 years ago, when I started
>>> work on my Peted editor. I think one idea was to not add direct
>>> properties to nets, but net classes like "HighSpeed" which may be mapped
>>> to 50 Ohm with 2 inch maximum length.
>>
>> It would be another factoring error to build in too much meaning to
>> attributes at the schematic editor level. A lot depends on downstream
>> flow. Geda-gaf supports many downstream tools. Simulation needs
>> different network attributes than layout does. In geda-gaf, the
>> netlister carries the responsibility for assigning semantics to the
>> primitives. Making the editor aware of semantics detracts from its
>> flexibility.
>>
>
> That is generally true, you told us that some years ago, and it is a
> fine excuse to let gschem as it is. Unfortunately, some years ago
> sch2pcb was really stupid. It transfered footprints from schematics to
> PCB board, all stacked on top of each other, and gave us only net
> connect information. That is really a mess for larger boards. We loose
> too much information: Which bypass capacitor is for which OpAmp? Which
> trace is for high current. The layouter guy has to manually recover this
> information. One simple improvement is grouping elements -- for example
> all components close to an OpAmp on schematics should be placed as a
> group on PCB too. And there should be an option in PCB program to
> highlight all elements of this group, so that we can check if they are
> placed well.
This is more a PCB problem than a geda-gaf problem. It’s trivial to add an attribute like keep-near=U1 to a capacitor. That’s an advantage of a factored tool that’s agnostic about semantics. But since PCB doesn’t compose complex objects from simpler objects, there’s no way to express this in a netlist for PCB. The problem goes beyond graphics.
For one current project, I have an entire page devoted to FPGA bypass capacitors. It’s not as simple as “keep these near”, as there’s a hierarchy running from small ceramics to fat tantalums, with different metrics of nearness. The actual FPGA symbol is on a different page, but it’s only a box with busses, no pins. The pin connections are derived by parsing the .csv file from the Xilinx tools, joining that to relations that map pin names to nets, and then using pins2gsch to import the result into the design. I cannot imagine that a design focused on PCB, a very crude downstream tool, could handle this even as well as geda-gaf does currently.
The customer for this project has an in-house layout person who uses Osmond PCB, a contractor that uses Allegro, and another that uses PADS. I can generate all of these netlists from the schematics. Most of the hierarchical subcircuits also generate usable SPICE, without modification, via my spice-noqsi backend. The top level schematics do not yet have the necessary annotations for SPICE, but I’m working on it. Can any other tool match this? Can your vision match it?
It would be nice to be able to group objects in gschem without hierarchy, but it’s not terribly useful without a way to use that information downstream.
>
>
>
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -