Mail Archives: geda-user/2016/08/03/15:46:59
--Apple-Mail=_A38E59BD-5977-4B64-BDEA-BA430FD280A8
Content-Type: multipart/alternative;
boundary="Apple-Mail=_8BD2F659-0B52-44A6-B537-12E91DE7A212"
--Apple-Mail=_8BD2F659-0B52-44A6-B537-12E91DE7A212
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Aug 3, 2016, at 12:19 PM, Ouabache Designworks (z3qmtr45 AT gmail DOT com) =
[via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>=20
>=20
> On Wed, Aug 3, 2016 at 8:05 AM, John Doty <jpd AT noqsi DOT com> wrote:
>=20
> On Aug 3, 2016, at 3:50 AM, Svenn Are Bjerkem =
(svenn DOT bjerkem AT googlemail DOT com) [via geda-user AT delorie DOT com] =
<geda-user AT delorie DOT com> wrote:
>=20
> > On 2 August 2016 at 23:02, John Doty <jpd AT noqsi DOT com> wrote:
> >> The way I do it is to have a project symbol directory. I copy the =
necessary
> >> symbols from libraries into there. It=92s safer to keep specialized =
symbols
> >> bundled with the project anyway. Libraries get revised.
> >
> > As an example, a "reuse" project. New design using two legacy =
modules
> > which are space-proven but have never been used in the same project
> > before. The modules are created by two separate designers, both who
> > are not you.
> >
> > mydesign/sym/lib_eth/decoder-1.sym
> > mydesign/sym/lib_uart/decoder-1.sym
> >
> > How to solve without renaming?
>=20
> Why not rename? If you constrain the solution unnecessarily, you just =
wind up with complexity.
>=20
> I do import subcircuits from previous projects occasionally, and I run =
into this, rarely. I don=92t see any reason that one couldn=92t write a =
utility to manage this, but it=92s not worth the effort to me. These =
rare cases are easily managed manually.
>=20
> In any case, this is most definitely not the responsibility of the =
schematic editor in a well-factored EDA toolkit.
>=20
>=20
>=20
> This is the difference between a small data environment like PCB entry =
and big data like a half billion gate asic. What you see as a
> rare event is now a frequent and almost expected occurrence.
Then make a specialized tool to do the design merge. gEDA is well-suited =
for this.
> Doing anything manually is a huge risk in any asic design. You =
automate everything or else you will be buried under a tsunami of code.
Anything? No inputs from the designer are allowed? But I agree that =
complex things should be automated.
>=20
> What happens if you bring in code that needs a fix that you simply =
change it yourself? Five years later a new team is formed to design the =
follow on product to your current design. They will start with your chip =
design and then add ,delete or modify code for the new product. They =
will download the latest versions of all your modules from their =
sources.
>=20
> Somebody on the new team will need to go in and exactly duplicate the =
work that you did on that module.
Why? If it=92s a custom version, e.g. a modified OpenIP subcircuit, I =
put it in *my* sources under a new name. Then nobody needs to go back =
and duplicate anything. The =93somebody=94 is often me: projects go into =
hibernation for years in my business.
If that=92s not the right thing, I could make a patch script (which =
might fail, of course).
> Did you leave enough
> documentation that they know what needs to be done? As your designs =
grow you have to formalize and document everything to a much greater =
extent than you do now.
That=92s why a toolkit (like gEDA) that is friendly to software-style =
configuration management and automated builds and testing is a good =
thing. In my big gEDA projects, a simple =93make=94 builds all of the =
data products. =93make check=94 does whatever checks I can automate. If =
either of these is broken on a clean clone of the source, the project is =
broken. A Makefile is better than some complicated manual procedure, no =
matter how well documented. For analog/mixed signal it=92s trickier: =
while I do checks, simulators are not perfectly predictable unless you =
like keeping obsolete binaries around to run on obsolete hardware.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_8BD2F659-0B52-44A6-B537-12E91DE7A212
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Aug 3, 2016, at 12:19 PM, Ouabache =
Designworks (<a href=3D"mailto:z3qmtr45 AT gmail DOT com">z3qmtr45 AT gmail DOT com</a>)=
[via <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] =
<<a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>>=
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Wed, Aug 3, 2016 at 8:05 AM, John Doty <span =
dir=3D"ltr"><<a href=3D"mailto:jpd AT noqsi DOT com" =
target=3D"_blank">jpd AT noqsi DOT com</a>></span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span class=3D""><br>
On Aug 3, 2016, at 3:50 AM, Svenn Are Bjerkem (<a =
href=3D"mailto:svenn DOT bjerkem AT googlemail DOT com">svenn DOT bjerkem AT googlemail DOT com<=
/a>) [via <a =
href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <<a =
href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>> =
wrote:<br>
<br>
> On 2 August 2016 at 23:02, John Doty <<a =
href=3D"mailto:jpd AT noqsi DOT com">jpd AT noqsi DOT com</a>> wrote:<br>
>> The way I do it is to have a project symbol directory. I copy =
the necessary<br>
>> symbols from libraries into there. It=92s safer to keep =
specialized symbols<br>
>> bundled with the project anyway. Libraries get revised.<br>
><br>
> As an example, a "reuse" project. New design using two legacy =
modules<br>
> which are space-proven but have never been used in the same =
project<br>
> before. The modules are created by two separate designers, both =
who<br>
> are not you.<br>
><br>
> mydesign/sym/lib_eth/decoder-1.sym<br>
> mydesign/sym/lib_uart/decoder-1.sym<br>
><br>
> How to solve without renaming?<br>
<br>
</span>Why not rename? If you constrain the solution unnecessarily, you =
just wind up with complexity.<br>
<br>
I do import subcircuits from previous projects occasionally, and I run =
into this, rarely. I don=92t see any reason that one couldn=92t write a =
utility to manage this, but it=92s not worth the effort to me. These =
rare cases are easily managed manually.<br>
<br>
In any case, this is most definitely not the responsibility of the =
schematic editor in a well-factored EDA toolkit.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
</font></span></blockquote></div><br><br></div><div =
class=3D"gmail_extra">This is the difference between a small data =
environment like PCB entry and big data like a half billion gate asic. =
What you see as a<br></div><div class=3D"gmail_extra">rare event is now =
a frequent and almost expected =
occurrence.</div></div></blockquote><div><br></div>Then make a =
specialized tool to do the design merge. gEDA is well-suited for =
this.</div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"></div></blockquote><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"> Doing anything manually is =
a huge risk in any asic design. You automate everything or else you will =
be buried under a tsunami of =
code.<br></div></div></blockquote><div><br></div>Anything? No inputs =
from the designer are allowed? But I agree that complex things should be =
automated.<br><div><br></div><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><br></div><div =
class=3D"gmail_extra">What happens if you bring in code that needs a fix =
that you simply change it yourself? Five years later a new team is =
formed to design the follow on product to your current design. They will =
start with your chip design and then add ,delete or modify code for the =
new product. They will download the latest versions of all your modules =
from their sources.</div></div></blockquote><blockquote type=3D"cite"><div=
dir=3D"ltr"><div class=3D"gmail_extra"><br></div><div =
class=3D"gmail_extra">Somebody on the new team will need to go in and =
exactly duplicate the work that you did on that =
module.</div></div></blockquote><div><br></div>Why? If it=92s a custom =
version, e.g. a modified OpenIP subcircuit, I put it in *my* sources =
under a new name. Then nobody needs to go back and duplicate anything. =
The =93somebody=94 is often me: projects go into hibernation for years =
in my business.</div><div><br></div><div>If that=92s not the right =
thing, I could make a patch script (which might fail, of =
course).</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"> Did you leave enough<br></div><div =
class=3D"gmail_extra">documentation that they know what needs to be =
done? As your designs grow you have to formalize and document everything =
to a much greater extent than you do =
now.<br></div></div></blockquote><div><br></div>That=92s why a toolkit =
(like gEDA) that is friendly to software-style configuration management =
and automated builds and testing is a good thing. In my big gEDA =
projects, a simple =93make=94 builds all of the data products. =93make =
check=94 does whatever checks I can automate. If either of these is =
broken on a clean clone of the source, the project is broken. A Makefile =
is better than some complicated manual procedure, no matter how well =
documented. For analog/mixed signal it=92s trickier: while I do checks, =
simulators are not perfectly predictable unless you like keeping =
obsolete binaries around to run on obsolete =
hardware.</div><div><br></div><div apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px;"><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">John =
Doty<span class=3D"Apple-converted-space"> =
<span class=3D"Apple-converted-space"> </span><span =
class=3D"Apple-converted-tab"> <span =
class=3D"Apple-converted-space"> </span></span></span>Noqsi =
Aerospace, Ltd.</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><a href=3D"http://www.noqsi.com/">http://www.noqsi.com/</a></p><p =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica"><a =
href=3D"mailto:jpd AT noqsi DOT com">jpd AT noqsi DOT com</a></font></p><br =
class=3D"Apple-interchange-newline"></span>
</div>
<br></body></html>=
--Apple-Mail=_8BD2F659-0B52-44A6-B537-12E91DE7A212--
--Apple-Mail=_A38E59BD-5977-4B64-BDEA-BA430FD280A8
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJXoknhAAoJEF1Aj/0UKykRAEwP/3Ls5jWg2dhm9l7YHVaJd6BO
jOr0phKO2UVH+vTBHj8wZpxZrdywB77ZpiENvhZoAq1U0g3CQHF04g6/RNjeDgOS
uIauY8D88BObp71R9AMnz0Ja11sWUpVrNhmLvVnEGU9I/iHhuJxXLwdMZKWVGijV
F0Ij4hHYmiTkiQ/yfIE+oBDLS+GkoyNjmIfeXv0qlot+Vc0M2mEtGQdpA02ZUN9G
8K9wXDCRkUUKlGiOy1R6taEnDcKGyv5cDcEpgGiUSoBy/rmZTa52XM908s3PP+mA
w7p3K8VOQ66bq3CjhiNtU0CeEmmh8n4cOD7dCqGUmVmazg4gPULkyteafUX+wbPL
CeWGZNoOniJnMFcUgbshn6OiGjKwmbHoXzzyTRq7aL8BeV8E/CKV5WZjG7ctga4C
VHmdXUVbsWz4TRcisUGt6UjdUtUzmz0JE5Tu0uwBES/8kyZqX/xcm9l+cuR0ssRg
TB/K0jXiZAZk4a+rl4IEHrG6Mkd9lKxN6DXLE6KM0D3z+taFPX8VM7W6QVwdyirz
rVR2yROCz80TXSaiX15HWLP3BRTkDlb86lfmE8F58pL5HtwXjYaRsKcCMfFDJPgl
nypGHwO7lkqCuiEX58myPmFXb/tO4O3GzRQ7VkQADGO4Q+y5vQOBdYYGWmPp9As/
U8VF8G5skLjc0A6LurWC
=BVWW
-----END PGP SIGNATURE-----
--Apple-Mail=_A38E59BD-5977-4B64-BDEA-BA430FD280A8--
- Raw text -