← Back to team overview

kicad-developers team mailing list archive

Re: Netlist generation for pins with no-connects

 

Hi André,

I understand what you mean, that's a very reasonable use case.  It is a
known issue that the design rules framework is not flexible enough for all
use cases, it is already on the roadmap to overhaul that system and make it
more flexible.

-Jon

On Fri, Jun 8, 2018 at 1:02 AM, André S. <list.dev.kicad@xxxxxxxxxxxx>
wrote:

> Hi Jon,
>
> just for clarification:
> I can attach a NC to a signal thats connected to only one component pin in
> eeschema. ERC then recognizes that the signal is terminated and does not
> throw an error. I can also give that net a label that is then exported to
> the netlist (with a leading "/", maybe to signal it's a single pad net?).
>
>
> What I did not check until today (with 4.0.7):
> I can put that net into a net group. When reading the netlist into Pcbnew
> I have to check "keep single pad nets". Then the design rule is observed
> during routing. Very fine!
>
> Why would I do something like this?
> Lets say I have a transformer in my design that has two mains windings
> with a common middle pin. That pin is not used in my design but still
> carries mains voltage. I would give that pin a net with a name and then in
> pcbnew in the design rules I can put that net (easily, due to its name) in
> a net group with a high distance from other nets.
>
> On a sidenote:
>
> I work for a company where we do this all the time (in Zuken) to be able
> to handle (very) complex designs where high voltages and low voltage
> control circuits are on the same board.
>
> Checking this today in Pcbnew also showed me, that net groups can only
> have one distance. I wonder if no one until now had the requirement where
> nets in different voltage domains need to be kept away from another but can
> have a close distance within the net group. Can Pcbnew/Kicad do this? Or is
> this too exotic of an requirement? I know that this can get _very_ complex
> when you have up to over 100 net groups due to isolation requirements…
>
> Regards,
>   André
>
> Zitat von Jon Evans <jon@xxxxxxxxxxxxx>:
>
>
> For your PS, do you mean NCs attached to the end of wires rather than the
>> end of pins?  I don't think that's how it's designed to work today (NC
>> symbols are only for pins)  We could add that though.
>>
>> On Tue, Jun 5, 2018 at 12:50 PM, André S. <list.dev.kicad@xxxxxxxxxxxx>
>> wrote:
>>
>> One reason one wants (labeled) NC nets can be isolation of nets via net
>>> classes to ensure proper distances between not connected pins and other
>>> signals.
>>>
>>> Regards,
>>> André
>>>
>>> PS: This reminds me that eeschema correctly recognizes NC symbols as
>>> termination for nets (via ERC) but still shows a “not terminated" marking
>>> on that NC terminated net ending. Is there a bug filed for this
>>> somewhere?
>>>
>>>
>>>
>>> On June 5, 2018 2:38:24 AM UTC, Jon Evans <jon@xxxxxxxxxxxxx> wrote:
>>>
>>>>
>>>> Hi all,
>>>>
>>>> In the current netlisting algorithm, pins with no-connects sometimes
>>>> appear in the netlist, with auto-generated names like Net-(U1-Pad1).
>>>>
>>>> This seems to not always happen, but I haven't investigated why yet,
>>>> since I'm approaching netlisting from a different direction with my new
>>>> connectivity algorithm.  In my algorithm, a pin with a no-connect
>>>> attached
>>>> will never generate an entry in the netlist.
>>>>
>>>> Is there some reason we should be including these pins on the netlist?
>>>> It seems like if they are marked as no-connects and don't actually
>>>> connect
>>>> to anything, we shouldn't be forwarding them to the layout.
>>>>
>>>> -Jon
>>>>
>>>>
>>>
>
>
>

References