Netlist warning for multi-page EEschema symbol

[Frank Bennett]

Application: KiCad
Version: (2012-04-29 BZR 3537)-stable
Build: wxWidgets 2.9.3 (UTF-8,compiler with C++ ABI 1002,GCC 4.4.3,wx containers,compatible with 2.8)
Platform: Linux 2.6.32-40-generic i686, 32 bit, Little endian, wxGTK
Options: KICAD_GOST=OFF
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         USE_BOOST_POLYGON_LIBRARY
~
Modern SOCs have more functionality than can fit on a single sheet. An example of a multi-sheet symbol
can be found in kicad/import/edif2kicad/test/openrd.edf or via svn on edif2kicad.sourceforge.
$ cd edif2kicad; make
$ cd test ; ../e2sch openrd.edf
$ kicad
open openrd.pro, openrd.sch, make standard netlist, annotate, notice warning? (no netlist producded)
regarding 4x U1 refs. This is not an error since there are 4 parts of the 88F6281 on different sheets. The
netlist should show a single U1 with pin connections from the 4 different sheets. There would be any error
if the same pin of U1 is referenced mulitple times with different netnames attached.

[jean-pierre charras (jp-charras)]

Your schematic come from a converted schematic.
The converted schematic is broken.
It is broken at least for multipart per package components, and for power symbols.
For "U1", there are 4 different component is lib (88F6281_11A, B ,C ,D)
Each lib component has only one part.
Therefore they are 4 different components that should have 4 different references.

if 88F6281_11A, B ,C ,D are 4 parts inside the *same* component, the component in lib should:
- be called 88F6281_11 only
- have its number of parts set to 4
- include the 4 parts in the same description.

and the references should be U1A, U1B, U1C and U1D, corresponding to the package U1 on the board.

[Frank Bennett (bennett78-digis)]

On 05/12/2012 12:04 AM, jean-pierre charras wrote:
> Your schematic come from a converted schematic.
> The converted schematic is broken.
> It is broken at least for multipart per package components, and for power symbols.
> For "U1", there are 4 different component is lib (88F6281_11A, B ,C ,D)
> Each lib component has only one part.
> Therefore they are 4 different components that should have 4 different references.
>
> if 88F6281_11A, B ,C ,D are 4 parts inside the *same* component, the component in lib should:
> - be called 88F6281_11 only
> - have its number of parts set to 4
> - include the 4 parts in the same description.
Jean-Pierre:
   Thanks for looking at this. I have put all 4 parts into the same
component and bumped LibEntry->NumOfUnits++; but I'm confused as to
what separates the 4 parts. All 4 parts (actually 7) are now inside
one DRAW/ENDDRAW:
#
# 88F6281_11
#
DEF 88F6281_11 U 0 30 Y Y 7 0 N
F0 "U" 2370 160 60 H V
F1 "88F6281_11" 0 -1600 60 H V
DRAW
P 2 0 1 0 2750 -600 2700 -600
.....
X NF_IO2_/_SPI_CS#_/_MPP[0] C13_ -300 -100 300 R 49 49 1 1 U
ENDDRAW
ENDDEF
#
What separates each part?
My savlib.c is a copy of your:
int WriteOneLibEntry(FILE * ExportFile, LibraryEntryStruct * LibEntry)
of a few revisions ago...

-Frank
>
> and the references should be U1A, U1B, U1C and U1D, corresponding to the
> package U1 on the board.
>

--
Frank Bennett
owner, contractor
Mathegraphics, LLC. <http://mathegraphics.com/>
613 Bentley Pl
Fort Collins, Co 80526
970.402.9269

[jean-pierre charras (jp-charras)]

in pin description:
X NF_IO2_/_SPI_CS#_/_MPP[0] C13_ -300 -100 300 R 49 49 1 1 U
the first 1 is the part id: 1 for part A, 2 for part B ...
when set to 0, the pin is seen in all parts.
the second 1 is for converted shapes (De Morgan representation):
0 = the pin is seen in all shapes:
1 = the pin is seen in normal shape
2 = the pin is seen in converted shape
This is also true for graphic items.

Also note power symbols are also broken:
In Kicad, a power symbol is just a component (in fact, a pseudo component, because it does not appear in netlist).
Just it has a "power in" invisible pin.
This is this pin that connects a wire or an other pin to the power net.
- the name of the pin in the net name
- if the power symbol has a value, this is the same name as the pin name. The value is only for the reader.
- the flag "power" is set (to avoid any value change in schematic): option_flag = N (normal) or P (component type "power")
in DEF line:
 "DEF name reference unused text_offset draw_pinnumber draw_pinname unit_count units_locked option_flag"
- and its reference starts by # (like #PWR) : this is a flag that say: this is a pseudo component, do not list it in netlist or BOM

[Frank Bennett (bennett78-digis)]

kicad-contrib/import/edif2kicad/e2sch v0.99 recently commited.

now imports a couple multi-part symbols - 88F6281_11, BAT54 from edif file test/openrd.edf.
The 88F6281_11 works fine because the parts are sequential - A,B...G but the BAT54 is referenced
as a BAT54C and BAT54S which display ok. but EEschema annotation and the component editor complain
that BAT54 has more than 2 parts which is untrue This is an EEschma limitation more than a bug but
prohibits producing a netlist that I can evaluate the value of e2sch.

The logic for counting component parts could be improved for non-sequential parts.

[Frank Bennett (bennett78-digis)]

On 05/13/2012 07:57 AM, jean-pierre charras wrote:

Jean-Pierre:
   I'm getting back to improving edif2kicad and multi-part
symbols works great as long as each part is sequential
(A,B,C,etc) but not if the parts were specified in a random
order (C,N,J, etc)
> in pin description:
> X NF_IO2_/_SPI_CS#_/_MPP[0] C13_ -300 -100 300 R 49 49 1 1 U
> the first 1 is the part id: 1 for part A, 2 for part B ...
> when set to 0, the pin is seen in all parts.
Don't like this use, since different net names could
be attached to same pin on different symbol parts.
> the second 1 is for converted shapes (De Morgan representation):
> 0 = the pin is seen in all shapes:
> 1 = the pin is seen in normal shape
> 2 = the pin is seen in converted shape
> This is also true for graphic items.
>
> Also note power symbols are also broken:
> In Kicad, a power symbol is just a component (in fact, a pseudo component, because it does not appear in netlist).
> Just it has a "power in" invisible pin.
> This is this pin that connects a wire or an other pin to the power net.
> - the name of the pin in the net name
I wish it was the value, assumming only one pin per power symbol.
For the EDIF file test/openrd.edf the cells (library symbols) are defined
first i.e. VCC then this cellref is instanciated later on different pages

cell def in openrd.edf:
(cell(rename VCC "VCC") (cellType GENERIC)
    (view(rename &1 "1")
    (viewType GRAPHIC)
    (interface(property( rename EDIFHOTSPOT "EDIFhotspot")
      (string "(pt 100 -100)"))
      (property(rename ORCADVIEWTYPE "OrCADviewType")
       (string "GLOBAL_SYMBOL"))
      (property(rename NAME "Name")
       (string "VCC")))
     (contents(commentGraphics)
      (figure BODY(path(pointList(pt 100 -60)
       (pt 100 -100)))
       (circle(pt 70 -30)
        (pt 130 -30))))))
output in OPENRD.cache.lib:
#
# VCC
#
DEF VCC #PWR 0 30 Y Y 1 0 N
F0 "#PWR" 100 -100 60 H V
F1 "VCC" 0 0 60 H V
DRAW
C 100 -30 60 1 1 0
P 2 1 1 0 100 -100 100 -60
X VCC 99 100 -100 0 U 49 49 1 1 W
ENDDRAW
ENDDEF

cellref in openrd.edf:
  (portImplementation(name VCC5V(display POWER(justify UPPERLEFT)
     (origin(pt 12950 -1050))))
        (connectLocation(figure PORT(dot(pt 13050 -1250))))
        (instance(rename XGRINST48 "XGRINST48")
         (viewRef &1(cellRef VCC(libraryRef LCP__88F6281_32_SCH_32_LIB)))
         (transform(origin(pt 12950 -1150)))))

in PAGE04_58__32_SATA_44__32_USB_44__32_PCIE_44__32_I2S.sch:
Text Label 12460 2645 0 49 ~ 0
VCC5V
$Comp
L VCC #PWR482
U 1 1 00000000
P 12500 2700
F 0 "#PWR482" H 12500 2700 53 0000 L TNN
F 1 "VCC5V" H 12500 2700 53 0001 L TNN
   1 12500 2700
     1 0 0 -1
$EndComp

That is the value is easily changed in the $comp F1 instance rather
than creating a new symbol with pin named "VCC5V".
Thus multiple power and ground instances could be used sharing the same
symbol.
Currently a new symbol would need to be created for each power, ground
symbol.

If the value was used as the netname edif2kicad would work and probably
be backward compatible assuming no one has ever generated a multi-pin
power symbol!!

Frank Bennett <email address hidden>
> - if the power symbol has a value, this is the same name as...

[jean-pierre charras (jp-charras)]

1- "multi-part symbols works great as long as each part is sequential (A,B,C,etc) but not if the parts were specified in a random order (C,N,J, etc)"
 I am afraid I do not exactly understant your problem.
  Internally, parts are numbered 1, 2, 3... and if part 4 exists, obviously parts 1, 2 and 3 are expected to be existing.
 For references, Ux part 2 is displayed as UxB and in Kicad GOST version Ux-2
 What is the meaning of UxN ( Is Ux a component having 14 parts inside ?).
 If yes, UxC, UxN and UxJ are legal.
 if Ux has only 3 parts , only A, B, C are legal.

2 - "> when set to 0, the pin is seen in all parts.
Don't like this use, since different net names could
be attached to same pin on different symbol parts."

When a component is multipart, you can have this issue, regardless the internal representation of pins.
For instance, for a Op amp with 2 parts, :
if the power pins (V+ and V- for instance) exist on each part, you can connect each part to different powers.
if the power pins exist on only one part, you cannot connect power pins if you are using only one part in schematic (the one that do not have the power pins).

3 - Power symbols:
 "If the value was used as the netname edif2kicad would work and probably be backward compatible assuming no one has ever generated a multi-pin power symbol"
Using a value as netname is a possibility, but this is not what is used in Eeschema.
It should be done at the beginning of Kicad, not now:
This change has no great advantage (it is not bad, but not better than the current way Eeschema works)
It needs changes in code but also in documentations.
Is this work worth it to just help a translation tool ?
Currently you needs as many power symbols as you have different power nets.
Usually this means only few different symbols (GND, VCC, +12V ... perhaps 5 to 10 symbols)

[Frank Bennett (bennett78-digis)]

On 06/08/2012 12:50 AM, jean-pierre charras wrote:
> 1- "multi-part symbols works great as long as each part is sequential (A,B,C,etc) but not if the parts were specified in a random order (C,N,J, etc)"
> I am afraid I do not exactly understant your problem.
For the Orcad edif file: test/openrd.edf there are 2 parts defined for BAT34
"BAT54C" & "BAT54S" which get converted to parts 3, 19 for the BAT34
symbol.
These display just fine on the schematic but annotation/netlist report
an error
of more than 2 parts. I'm not sure how these parts were created in OrCad but
that is how they showup in the edif export. I think the logic for
eeschema should
be 19 parts with only 2 are defined and as long as the undefined parts
are not
referenced there should be no error generated and the netlist should be
generated.

Another headache: I put all symbol definitions in the *cache.lib but I see
when the schematic is opened the power.lib+path are added. The power.lib
parts
override the definitions in *cache.lib. I would recommend either if
cache exits
not adding the single library power.lib, path is ok or put the cache.lib
ahead of the
cache in the library search. The cache should be more valid that the
distributed
libs. For archiving I like to see the complete set of project files
local to one
directory and not rely on distributed libs that might change with kicad
update.
> Internally, parts are numbered 1, 2, 3... and if part 4 exists, obviously parts 1, 2 and 3 are expected to be existing.
> For references, Ux part 2 is displayed as UxB and in Kicad GOST version Ux-2
> What is the meaning of UxN ( Is Ux a component having 14 parts inside ?).
> If yes, UxC, UxN and UxJ are legal.
> if Ux has only 3 parts , only A, B, C are legal.
>
> 2 - "> when set to 0, the pin is seen in all parts.
> Don't like this use, since different net names could
> be attached to same pin on different symbol parts."
>
> When a component is multipart, you can have this issue, regardless the internal representation of pins.
> For instance, for a Op amp with 2 parts, :
> if the power pins (V+ and V- for instance) exist on each part, you can connect each part to different powers.
> if the power pins exist on only one part, you cannot connect power pins if you are using only one part in schematic (the one that do not have the power pins).
>
> 3 - Power symbols:
> "If the value was used as the netname edif2kicad would work and probably be backward compatible assuming no one has ever generated a multi-pin power symbol"
> Using a value as netname is a possibility, but this is not what is used in Eeschema.
> It should be done at the beginning of Kicad, not now:
> This change has no great advantage (it is not bad, but not better than the current way Eeschema works)
> It needs changes in code but also in documentations.
> Is this work worth it to just help a translation tool ?
Probably not, the user will have to manually generate symbols for each
power symbol with the new name and pin name...which is not much work.

> Currently you needs as many power symbols as you have different power nets.
> Usually this means only few different symbols (GND, VCC, +12V ... perhap...

[jean-pierre charras (jp-charras)]

Frank,
"BAT54C" and "BAT54S" are a value, not a reference.
They are two existing components.
Each has only one part per package (or 2, with one common pin)
Therefore considering BAT54S as the part 19 of component BAT54 is a bug, but not a KiCad bug.

Thanks for your work about Edif to KiCad converter.

[jean-pierre charras (jp-charras)]

I forgot:
Can you test Edif to Kicad under Windows.
It runs fine under Linux, but crashes under Windows.

Thanks.

[Frank Bennett (bennett78-digis)]

On 06/08/2012 12:37 PM, jean-pierre charras wrote:
> I forgot:
> Can you test Edif to Kicad under Windows.
> It runs fine under Linux, but crashes under Windows.
Fixed, checked in under bzr@lp and svn@SF.
> Thanks.

Frank Bennett
owner, contractor
Mathegraphics, LLC. <http://mathegraphics.com/>

[xzcvczx (xzcvczx)]

this looks to be resolved. Closing