Mail Archives: geda-user/2023/05/06/13:56:23
This is a multi-part message in MIME format.
--------------PGwmuT06vvk6vzLhHjCh05BP
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hello Roland,
Op 06-05-2023 om 13:46 schreef Roland Lutz:
> Hi Richard,
>
> On Fri, 5 May 2023, Richard Rasker (rasker AT linetec DOT nl) [via
> geda-user AT delorie DOT com] wrote:
>> Maybe a bit of an awkward observation, but it appears that more
>> recent incarnations of gschem and pcb […] enforce stricter rules that
>> break older designs in several different ways.
>
> gnetlist used to have undefined behavior in a lot of situations
> resulting in subtle bugs in the design. For example, a large SMD
> board at my university would be missing one in row of identical
> transistors; this had to be discovered and patched in by hand. In
> order to prevent this kind of error, I decided to have gnetlist fail
> rather than "just output something" if it encountered a situation that
> was likely to result in a problem.
>
>> I used to have the net:pin definition "net=[name]:1" (not visible),
>> together with "netname=[name]" (visible) -- but for some reason, it
>> is no longer allowed to have both a net and a netname attribute defined.
>
> This is prone to errors: someone may change the netname= attribute but
> not realize that there is a net= attribute to be changed as well,
> resulting in one net being displayed and another net being connected.Â
> Therefore, recent versions of gnetlist honor the netname= attribute
> directly but require the redundant net= attribute and the pinumber=
> attribute on the pin to be removed.
>
> So, the "canonical" fix would be to use a new-style power symbol (or
> just create a copy of the old one minus the two attributes) and remove
> the net= attribute.
How is such a new-style power symbol defined?
>> Virtually every older project that I created now throws numerous
>> errors when I try to open and/or modify it, causing a lot of extra work.
>
> I'm sorry about that! I added these checks to avoid more costly
> errors later, but I guess I made them a bit too strict...
It's not a big deal when the cause of the problem(s) is clear -- but
messages like "could not find refdes on component and could not find
net= attribute on pin" are annoying, because at first I had no idea
where to look. It took me an hour before I remembered about those
input/output symbols.
I understand that in cases like this, there is no refdes to point to,
but it would be helpful already if the error message included the name
of the symbol(s) causing the problem (input-1.sym and output-1.sym).
Best regards,
Richard Rasker
Linetec
--
Linetec Translation and Technology Services
Akkerstafhof 15
7544SP Enschede
The Netherlands
+31-53-4350834
http://www.linetec.nl/
e-mail: rasker AT linetec DOT nl
--------------PGwmuT06vvk6vzLhHjCh05BP
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello Roland,<br>
</p>
<div class="moz-cite-prefix">Op 06-05-2023 om 13:46 schreef Roland
Lutz:<br>
</div>
<blockquote type="cite"
cite="mid:9b1da9df-b3f3-4fe6-7cc2-1bbdc2bfb281 AT grinsen-ohne-katze DOT de">Hi
Richard,
<br>
<br>
On Fri, 5 May 2023, Richard Rasker (<a class="moz-txt-link-abbreviated" href="mailto:rasker AT linetec DOT nl">rasker AT linetec DOT nl</a>) [via
<a class="moz-txt-link-abbreviated" href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] wrote:
<br>
<blockquote type="cite">Maybe a bit of an awkward observation, but
it appears that more recent incarnations of gschem and pcb […]
enforce stricter rules that break older designs in several
different ways.
<br>
</blockquote>
<br>
gnetlist used to have undefined behavior in a lot of situations
resulting in subtle bugs in the design. For example, a large SMD
board at my university would be missing one in row of identical
transistors; this had to be discovered and patched in by hand. In
order to prevent this kind of error, I decided to have gnetlist
fail rather than "just output something" if it encountered a
situation that was likely to result in a problem.<br>
<br>
<blockquote type="cite">I used to have the net:pin definition
"net=[name]:1" (not visible), together with "netname=[name]"
(visible) -- but for some reason, it is no longer allowed to
have both a net and a netname attribute defined.
<br>
</blockquote>
<br>
This is prone to errors: someone may change the netname= attribute
but not realize that there is a net= attribute to be changed as
well, resulting in one net being displayed and another net being
connected. Therefore, recent versions of gnetlist honor the
netname= attribute directly but require the redundant net=
attribute and the pinumber= attribute on the pin to be removed.
<br>
<br>
So, the "canonical" fix would be to use a new-style power symbol
(or just create a copy of the old one minus the two attributes)
and remove the net= attribute.<br>
</blockquote>
<p>How is such a new-style power symbol defined?<br>
</p>
<blockquote type="cite"
cite="mid:9b1da9df-b3f3-4fe6-7cc2-1bbdc2bfb281 AT grinsen-ohne-katze DOT de">
<blockquote type="cite">Virtually every older project that I
created now throws numerous errors when I try to open and/or
modify it, causing a lot of extra work.
<br>
</blockquote>
<br>
I'm sorry about that! I added these checks to avoid more costly
errors later, but I guess I made them a bit too strict...
<br>
</blockquote>
<p>It's not a big deal when the cause of the problem(s) is clear --
but messages like "<span style="font-family:monospace">could not
find refdes on component and could not find net= attribute on
pin</span>" are annoying, because at first I had no idea where
to look. It took me an hour before I remembered about those
input/output symbols.</p>
<p>I understand that in cases like this, there is no refdes to point
to, but it would be helpful already if the error message included
the name of the symbol(s) causing the problem (input-1.sym and
output-1.sym).</p>
<br>
<div class="moz-signature"
signature-switch-id="00c1a468-7bb7-4a48-b887-259be8969731">Best
regards,<br>
<br>
Richard Rasker<br>
<br>
Linetec<br>
-- <br>
Linetec Translation and Technology Services<br>
Akkerstafhof 15<br>
7544SP Enschede<br>
The Netherlands<br>
<br>
+31-53-4350834<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.linetec.nl/">http://www.linetec.nl/</a><br>
e-mail: <a class="moz-txt-link-abbreviated" href="mailto:rasker AT linetec DOT nl">rasker AT linetec DOT nl</a></div>
</body>
</html>
--------------PGwmuT06vvk6vzLhHjCh05BP--
- Raw text -