Re: gEDA-user: Re: Minor details (was Re: Hm...not much improvement)

[John Griessen <john_g@xxxxxxxxxx>]

Patrick Doyle wrote:

>
> I'm looking forward to implementing a set of scripts again, this time
> for a CAD tool for which documentation is available on the file
> formats :-)
>
> So far, I have dealt with that by not using off page connectors :-)
>
========================
Hi Patrick,

I'm not getting much use from them either.

I just sent this to the -dev list:

I've done a little testing on a fairly recent checkout of geda using gnetlist
after putting some hierarchical schematics and symbols together with the 
attribute source=tmote-revb.sch attached the symbol of the same name, 
tmote-revb.sym placed in a higher schematic.

Asking for drc or PCB target, gnetlist suggests using a IO with refdes having 
the signal name to do a connection to the higher schematic.  That will put all 
wires and pins in a net list if the top schematic wire has an attribute attached 
netname=ADC7, for example.

It seems we're close to being able to add connectivity of unlabeled wires, but 
it's not there yet.

To make a system with signal connections we the usual suspects:  thru and SMT 
coax connectors, SMT and thru hole power connectors, SMT flat flex cable 
connectors.  Flex cables can be used repeatedly without huge prices, and they 
can easily have twenty wires each, so checking that the system is hooked 
together right from separately designed modules is something valuable in 
general, and I have it coming up soon.


Here's what I've observed about the state of gnetlist and what seem the next 
steps for hierarchy.  The below considers one net and the pins it touches
in my system of boards and cables:

If I make the symbol pin number be alphanumeric  J28-2  and don't use 
source=tmote-revb.sch

I run gnetlist to get:
unnamed_net2    J1-4 U1-J28-2

where U1 is the placed symbol with pins.  gnetlist creates a name by adding a 
dash then the pin number.  (Which I have extended with alphabet chars)

I attach source=tmote-revb.sch to the symbol in the top schematic,
then I run gnetlist to get:

U1/ADC7/DAC1/SVSin    U1/U0-6 U1/J28-2

and further down,

unnamed_net2    J1-4

the J1-4 connector pin is not associated with the ADC7/DAC1/SVSin net even 
though J28-2 and J1-4 are wired together on the top schematic.

I propose that IO connectors are good for flat connectioin of multipage 
schematics, but we should specify some association method for symbols and 
schematics of the same name so we can create a hierarchical netlist.

Even if it will bog down before we get to do programmable chips with 7000 modules...

It's valuable now for small systems of boards and cables to avoid the 
end-swapped connector mistake that could trash a layout and pcb fab cycle.

To make a hierarchic symbol, we could use an attribute attached to it and its 
pins, (with a little help from a gattrib modified to edit symbols with placed 
pins as well as schematics with placed parts).  It could be as simple as 
attaching source=tmote-revb.sch  and port=J28-2.   The same port attribute with 
a special value could be used in schematics to designate the hierachic IO's.

(I think adding IO connectors with required detailed editing with signal names 
on each is high effort/low value for this purpose -- best used as a multipage 
connector only,)

The to do list for that seems to be:

1. process schematics looking for attribute port=hier attached to symbols

2. For each symbol found with port=hier, create a connection to the hierarchic 
           symbol for this schematic by this recipe:
        create net name from connector refdes, (such as J28) plus a dash 
  plus connector pin number for each pin.  Look up the hierarchic 
symbol and match this name to one of its pins and add its refdes         in 
front, (such as U1/J28-2)

3. Merge any unnamed nets that contain J28-2 in the top schematic into the list 
for this one net. Does not depend on netname=ADC7/DAC1/SVSin, and continues even 
if there is a different netname on that level of hierarchy.

There we have it.  The useful for checking netlist with signal names listed even 
if they don't match -- which can be cause for action to correct or just OK as is...

John Griessen

PS    Let's talk about the merging of hierarchical signal names in a different 
thread, OK?






_______________________________________________
geda-dev mailing list
geda-dev@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user