kicad-developers team mailing list archive

["Timothy Hanson" <tim@...>]

Hi Jean-Pierre & Dick & everybody else,

I have completed my modifications to allow multiple instances of one
sheet in a schematic hierarchy.
In the implementation I store a hash which converts path to reference
number. Path is composed via the unique ID / timestamp represented as
8 hex chars -- e.g. here is the segment of a file for one capacitor:

$Comp
L R R?
U 1 1 478AD1B6
P 5650 3400
AR Path="/478AD1B6" Ref="R?"
AR Path="/478C2053/478AD1B6" Ref="R2"
AR Path="/478C2408/478AD1B6" Ref="R4"
F 0 "R2" H 5750 3450 60 0000 C C
F 1 "R" V 5650 3400 50 0000 C C
F 2 "SM0603" H 5650 3200 60 0000 C C
1 5650 3400
1 0 0 -1
$EndComp

where AR stands for Alternate Reference. There are three alternate
references, R? for when i first created the file, R2 for when the
component is a instantiated via sheet with a timestamp of 478C2053 and
R4 when instantiated via sheet 478C2408.
The text part of F 0 or m_Field[REFERENCE] is updated when a sheet is
loaded or selected in the hierarchy; it is necessary to keep that
around be the field specifies where the text is to be drawn. BOM and
netlisting, of course, works (though it took a bit of work to make it
so!)

DrawSheetStruct is the basis for the hierarchy, as opposed to
SCH_SCREEN -- see http://m8ta.com/images/537_2.png (I made this as I
was trying to figure out how to change eeschema, it's not the clearest
of diagrams). This required quite a few changes, including making
GetScreen() virtual. It has to be virtual because sometimes the
m_Parent pointer was a WinEDA_SchematicFrame and sometimes it was a
WinEDA_DrawFrame, and in WinEDA_SchematicFrame GetScreen() does *not*
return m_CurrentScreen -- it returns m_CurrentSheet->m_Screen. This
means that all the classes that inherit this method are also virtual
and have the same return type of BASE_SCREEN* -- I've changed this in
pcbnew as well.

Anyway, that's done, and though I have merged the changes, I've not
checked anything in. Still need to figure out how to arrange
interaction with PCBnew, which expects timestamps / unique identifiers
based upon 32-bit integers. As I explained in an earlier email,
forming a unique ID out of the path is easier to implement and
understand than a linked-list of associations. PCB new does not
expect netlist like this, though:

(
( /478FB04E SM0805 R5 R {Lib=R}
( 1 in_3 )
( 2 out_2 )
)
( /478FB047 SM0805 R6 R {Lib=R}
( 1 out_3 )
( 2 in_2 )
)
( /478C2408/478AD1B6 SM0603 R4 R {Lib=R}
( 1 out_2 )
( 2 GND )
)
( /478C2408/478AD1B2 SM0603 R3 R {Lib=R}
( 1 VCC )
( 2 out_2 )
)
...

It loads it fine, though.

There are two options here: add another unique ID to the hash so you
have something like (in the schematic file):
AR Path="/478C2053/478AD1B6" Ref="R2" PCBTimeStamp="45607AAF"

or extend PCBNEW to handle the full paths when cross-probing and
updating based on timestamp not ref (which I never have used... has
anybody?) I prefer the second of these two solutions, because the
first is 'uglier', is less elegant, causes more end-cases due to
redundant information, need to maintain two concurrent unique
identifier lists, cases where the user modifies the reference etc..

Another issue -- global labels seem to be used exclusively for
embedding a sheet in a hierarchy. It seems likely that people will
need both sheet-local labels (served by the wire labels) as well
sheet-independent labels that are truly 'global'. Does it make sense
to make glabel follow it's name (and be a global label), and make a
new button for adding sheet input-output ports?

Therefore, I'm asking you (all)'s advice on the two questions:
(1) which is best: store extra timestamps, modify PCBnew to use paths,
or don't bother & use references for updating pcbnew when the
schematic changes.
(2) do we need a new class for sheet i/o

I'm on the gEDA developer list, too, and they do not have this
feature; rather than updating the references based in instantiation,
they put the path in the netlist. We are, kinda, competing with
them.. two free software products still competing! -- this would put
us 'ahead' :) (In addition to all the work done on pcbnew.. and the
fact we use c++ not vanilla c)

thanks & sorry about the long email,
Tim

ps. Dick: I had some look at the visitor design pattern -- it looks
cool and i wanted to try to solve the GetScreen() issue without
resorting to a 'virtual BASE_SCREEN*' (as this requires typcasting to
any of the derived classes), but, I couldn't come up with any better
solutions. :(

On Jan 1, 2008 11:50 AM, jean-pierre charras
<jean-pierre.charras@...> wrote:
>
>
>
>
>
>
> Tim Hanson a écrit :
>
> >
> > yes, I've thought about this.
> >
> > -- The multiple units per device are not such an issue if, like me, you
> > group all the units in a given device onto one sheet. I think this is a
> > semi-reasonable assumption. It becomes too confusing if you do not do
> > this.
> > -- Concerning long references, it is not such an issue if you name your
> > sheets with really short names .. like "0" or so. Then reading a
> > component adds a maximum of one digit to the component reference. But,
> you
> > are right in that ultimately all this is compiled down to a board, which
> > is 'flat' in both a physical and hierarchal sense, and numbers are a
> > concise way of writing & storing unique identifiers :) Yet if you do use
> > 0402, SC-70, CSP etc there is no room for silkscreen anyway.
> >
> A problem when using the sheet number or the sheet name is these two
> items are subject to change:
> - the sheet number changes when adding a new sheet.
> - the sheet name changes when the user edit it...
>
> - Adding the sheet number or name to the reference is a good idea for
> simulation,
> but this usually creates a big problem for boards if the reference of
> already placed footprints changes.
>
> In fact we can reannotate a schematic without problem on a board, but
> only if we take care.
> All the items in kicad have a time stamp (m_TimeStamp member of the
> EDA_BaseStruct class) which is set when the component is put on a sheet.
> This time stamp is different for alls items, and does not change when
> editing (but it changes if we delete a component, and reload a new
> identical component )
> This feature allows to reannotate components in the schematic and send
> the changes to the board in a 3 steps manner:
> 1 - create a fresh netlist and read it by pcbnew (not really necessary,
> but ensures the time stamps are corresponding between the schemativ and
> the board)
> 2 - reannotate schematic and create the new netlist
> 3 - Reread the netlist by pcbnew, using the option "module selection" by
> time stamp. the new references will be updated, from the time stamp.
>
> So remember the time stamps must be handled like the references
>
>
> > That said, we could avoid all of these problems by extending the .SCH
> file
> > format to include the possibility of multiple references per device (or
> > unit). This was my original intention, but then somebody (Frank Bennett)
> > on the list suggested a hierarchal system of naming. Actually, it would
> > not be impossible to allow both naming schemes, selectable via a radio
> > button. You would have to modify the file format, though. I suggest
> > extending the
> > L R R35
> > line to something like
> > L R R35 R67 R99 R131
> > etc
> > I think this would not break old versions of eeschema.
> > The location and size of the text would still be stored in the
> > F 0 "R35" H 6650 1800 50 0000 C C
> > line, with the R35 exchanged with an entry in the reference list, indexed
> > by the # of the containing sheet.
> >
> As prevously seen, the time stamp and also must be handled in a similar
> manner...
>
> Obviously, the .SCH file format will be changed to support this new
> feature.
> Of course we can't expect old versions of eeschema read a new feature in
> .sch files.
> In fact, this is not a problem.
> I think the .SCH file format might not change when the projectno has
> not a complex hierarchy
> If the project has a complex hierarchy, new format will not be read by
> old eeschema version,
> but in fact, it is already the case! because annotations and time stamps
> are lost.
> Do not bother with old eeschema versions.
>
> So we can add new lines for each component in a complex hierarchy like
> (and somewhat more verbose than other lines):
> $Comp
> L GND #PWR01
> U 1 1 4718A579
> AltRef "sheet_id" Ref="Ref" Part=n TimeStamp=<TimeStamp value> // as
> many lines as sheet instances and therefore sheet_id
> P 8650 4550
> F 0 "#PWR01" H 8650 4550 30 0001 C C
> F 1 "GND" H 8650 4480 30 0001 C C
> 1 8650 4550
> 1 0 0 -1
> $EndComp
>
>
> > Right now, I've split up DrawSheetStruct and SCH_SCREEN so the former
> > contains a reference to the latter. Hence, you can have multiple
> > DrawSheetStructs referring to one SCH_SCREEN. SCH_SCREEN has the
> > EEDrawList of components. I think this is better than having a number of
> > duplicates in the hierarchy, as is done now, as this allows changes to
> one
> > schematic to immediately propagate to all other schematics, each which
> > ultimately is tied to the same file anyway.
> >
> > While I'm at it:
> > -- Would it be ok to split the header files up? Right now, if i make one
> > change to wxstruct.h, I have to recompile eeschema, which takes a while.
> >
> Ok.
>
> >
> > -- What about class names? There is:
> > --- SCH_SCREEN,
> > --- DrawSheetStruct,
> > --- EDA_DrawLineStruct,
> > --- WinEDA_ErcFrame, & others.
> > I get the Win{...} files, they are all derived from wxWidgets classes.
> > Would it be good to clean all this up?
> > -- The file names are confusing: there is:
> > --- annotate_dialog. cpp and dialog_find. cpp,
> >
> > --- component_class. cpp and class_screen. cpp and sheet.cpp.
> > Class member functions are often spread out among different files. It
> > does not bother me -- I have everything in KDevelop, and when i want to
> > change something i just grep all the files, but ... ?
> >
> > Anybody have opinions on these things?
> >
> Cleaning up files is a good thing.
> I suggest for file names:
> all dialog files start with "dialog_":
> dialog_xxxx.pjd (created from dialogblock)
> dialog_xxxx.cpp (when created from dialogblock, use dialog_blocks to
> rename files)
> dialog_xxxx.h (when created from dialogblock, use dialog_blocks to
> rename files)
>
> all files relatives to classes start with "class_" :
> class_xxx.cpp (and class_xxx.h)
>
>
>
> >
> > > Tim Hanson a écrit :
> > >> Hi,
> > >>
> > >> Yes, I'm willing to do this, and I've already got some start.
> > >> Originally
> > >> I had planned to give every component a different reference
> > depending on
> > >> the sheet instance it is in (orcad style, i guess), but a hierarchal
> > >> name
> > >> is much, much better (and requires no change to the file format), so
> > >> let's
> > >> do that? It will make the netlists longer, but it will also make them
> > >> more readable. Unless anyone has better ideas, I'll start tomorrow ...
> > >> cheers,
> > >> Tim
> > >>
> > >
> > > This does not work for components which have more than one part per
> > > package, like a 74HC00.
> > > In this case the component must have the same reference in all sheets
> > > (say U1), and this is only the selected part (U1A U1B or U1C...)
> > > and not the reference which changes from a sheet to an other sheet, and
> > > **not** the reference.
> > > Of course, the board knows only U1.
> > > In fact, handle the multiple parts per package components is the main
> > > difficulty.
> > > And most of cases we can't have long references in a board, because smd
> > > footprints are smaller and smaller,
> > > and only very short references (also true for values) can be drawn on
> > > the board.
> > > (And if a sheet includes an other sheet, references can become *very*
> > > large.)
> > >
> > > --
> > >
> > > Jean-Pierre CHARRAS
> > >
> >
>
> --
>
>
> Jean-Pierre CHARRAS
>
> Maître de conférences
> Directeur d'études 2ieme année.
> Génie Electrique et Informatique Industrielle 2
> Institut Universitaire de Technologie 1 de Grenoble
> BP 67, 38402 St Martin d'Heres Cedex
>
> Recherche :
> GIPSA-LIS - INPG
> 46, Avenue Félix Viallet
> 38031 Grenoble cedex
>
>