<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Dear All,</p>
<p>I am mindful of a number of things as I reply with the following
- firstly I'm very much the new kid on the block here and secondly
that Wally's analysis is well thought through even if I perhaps
disagree with aspects of it :) <br>
</p>
<p>So I write the following seeking to be respectful of the voices
that have gone before in this discussion and who know the
intricacies of the engineering required moreso than I. Where I am
more confident I possess relevant domain knowledge though is in
the open hardware space and trends we're seeing there.<br>
</p>
<p>I may have erred somewhat in the way I framed my original reply
to this thread, namely that the point is more about file formats,
interoperability and longevity of access to work products than the
tools per se. These all of course go very much hand in hand, but
it's really that longevity piece that I think is important to us
moreso than the tools - but they are inexorably coupled.<br>
</p>
<p>Conducted well, the Ground Station project will likely outlive
any commercial tools we use. It is our choice as to whether it
outlives the file formats chosen. That is to say we'll be
building and launching iterations of todays work when many of the
existing proprietary tools are fading, or have faded from view.
Ensuring we can use accumulated design work products over a couple
of decades becomes important.<br>
</p>
<p>We've already seen basic multilayer designs using at least DDR3
and similarly specified SERDES done using open tools such as KiCAD
- one recent example is <a moz-do-not-send="true"
href="https://github.com/gregdavill/OrangeCrab">OrangeCrab</a>
This board is of course simpler than what we will need for the
project, but I believe illustrates the feasibility of the
endeavour.</p>
<p>In a (recent) previous life I worked with an organisation doing
open source high performance computing hardware - their next
generation designs will be multilayer (10 I think) and support
PCIeGen4, DDR4 and likely OpenCAPI with a server class CPU. This
will be done in its entirety with open tools - KiCAD among them.</p>
<p>We have already seen a strong trend of the PCB fab houses
embracing these open tools, it's not unreasonable to think this
trend will continue to increasingly sophisticated board materials,
layer options etc.</p>
<p>I don't think we'll see proprietary tools like Allegro, Altium,
OrCad disappear overnight, but as open offerings become
increasingly capable their days surely become more difficult.
Couple this with a new generation of EE who cut their teeth on
open tools expecting to use them in industry and we may well find
established engineers favouring an opportunity to learn how to use
this open source KiCAD thing they've heard so much about :)</p>
<p>I am slightly more confident what we will see, and soon, is a
disappearance of proprietary tools for FPGA and ASIC layout. We've
seen a rapid catchup of open tools in this space in just 12 months
- you can now, for example, synthesize and simulate or program
relatively complex <a moz-do-not-send="true"
href="https://github.com/antonblanchard/microwatt">OpenPOWER</a>
and <a moz-do-not-send="true"
href="https://github.com/enjoy-digital/litex">RISC-V</a>
cores/SoCs using only these tools.</p>
<p>Vendors like Xilinx are I gather already contemplating a shift to
make their tools open and/or get behind open tools as a way to
support the open ecosystem and, ultimately, reduce their costs.
This, at least in part, because the open tools actually end up
being nicer to use and quicker to get bugs fixed :) I'd give the
proprietary tools here less than a decade, likely much less.</p>
<p>We're seeing increasingly complex full system synthesis/emulation
too - for example <a moz-do-not-send="true"
href="https://renode.io/">Renode</a>.<br>
</p>
<p>Within this calendar year we'll see the first production of
microprocessors and other ICs <a moz-do-not-send="true"
href="https://www.theregister.com/2020/07/03/open_chip_hardware/">using
entirely open source tooling</a>. It's 130nm so not bleeding
edge but enough for plenty of things, and an interesting starting
point. That smaller geometries follow is all but inevitable.<br>
</p>
<p>I submit that if open tooling can allow the production of
complete from scratch chip designs, anything further up the
hardware design stack - a schematic, a PCB or a finished system is
only a matter of time.</p>
<p>Thank you for reading :)</p>
<p>vy 73<br>
Hugh<br>
VK3YYZ/AD5RV<br>
</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 28/7/20 10:50 am, Wally Ritchie via
Ground-Station wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+Vp+8Sf1nULooy8k19UtAWGX03-MtktX3UHMiSwmMw0M_toNQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">1. Few if any tools are perfect, certainly not any
PCB design tools, or as John Ackermann eloquently put it - all
of them suck to varying degrees. All depends on whether your
outlook is half-empty or half-full, what you are trying to
accomplish, and what value you place on different things -
especially, time and money.
<div><br>
</div>
<div>2. Generally, we are not in the business or non-business of
producing tools - except maybe those that are so specialized
to our tasks that they make sense, either because of the
nature of the task or the learning curves associated with the
alternative. So we might write some ad-hoc open-source
verification tools in python instead of an expensive simulink
framework - then again the latter may make more sense - it all
depends on what we are trying to do and the skill sets
available to the project. </div>
<div><br>
</div>
<div>3. We are embarking on a level of Engineering development
on a scale not undertaken before in the Amateur community, at
least with regards to the technologies we are working with -
$2000 FPA chips, $800 radio chips, 12 layer boards, SERDES
lanes operating at 12GHz, multi-kilobuck dev boards. These
many technologies are pretty far from traditional Amateur
radio and hobby boards. The projects we are undertaking
involve professional skill sets in many fields. Those working
in these fields are accustomed to having tools able to do the
job at hand. We are counting on many Amateur Radio Enthusiasts
who are in fact professionals with relatively current skill
sets, many with high hourly value in commercial or government
settings. We are asking such hams and non-hams to contribute
to our projects on a volunteer basis. We don't expect them to
have to bring or buy their own software tool licenses, test
equipment, $3000 eval boards, or $2000 chips. We want their
skills - not their stuff. For these projects to succeed we
will find ways to supply the stuff - and the volunteers will
supply the much higher value engineering labor. Whatever
investments we make in tools will be those that are highly
leveraged.</div>
<div><br>
</div>
<div>4. You wouldn't make your own hammer, or drill, or CNC
machine - although you could with open source designs. It
might be fun to do that - but it would be a diversion taking
you away from the current mission. If you can get a carpenter
to build something for free labor - you wouldn't ask him to
make his own tools - just because he can. We won't build our
own spectrum analyzers or oscilloscopes - although we could.
We focus on our project and we will beg, borrow, steal, or buy
if necessary the tools and test equipment to complete the jobs
we are doing. </div>
<div><br>
</div>
<div>5. With regard to PC tools, the opinions that matter are
those of the people who will be doing the critical work and
what they need to perform their job. What tools are used for a
simple pi-shield don't matter much. What tool is used to
produce a 12 layer FPGA board with 5 DDR4's and a dozen
transceiver lanes may matter much - especially to the person
doing the work and the downstream fab, smt, and test
processes. Over the past few decades or so the roles of pcb
layout specialist and draftsman have all but disappeared.
Mechanical engineers themselves are married to solidworks, or
Catia, or whatever. EEs are married to Allegro, Altium, OrCad
or some other multi kilobuck per seat tool - and in relatively
rare cases some small companies may use Eagle Professional
multi-seat versions - some still living in Version 7 and
others having moved to Autocad Fusion. Mechanical and
Electrical groups often need close collaboration which is the
value that PCB/3dCAD integration brings to the table. Catia
handled this well at the high end if you have megabucks.
Fusion looks like it's workable for the low end. I've never
known of any organization doing commercial or military work
using KiCad. I suppose it's possible but it's usually a poor
choice economically - like asking engineers to work at
ping-pong tables sitting on folding chairs with CRT monitors.
These are certainly cheap and plentiful. But productively
comes from proper capitalization of workers - including
programmers and engineers. Time is money. Volunteer time may
have zero associated dollars but it has associated value that
we do not wish to squander - especially when it comes to the
most complex parts of our projects. </div>
<div><br>
</div>
<div>6. Our goals are to produce open source designs that anyone
is free to adapt to their specific needs. Some parts may
require specialized tools to use - we wish to minimize that,
but non-free non-open source tools may sometimes be required
to utilize the sources. We can limit IP and endeavor to avoid
purchasing IP beyond that included with the standard tools.
But I don't think we can afford not to use commercial tools
when they are the best choice for completing a particular set
of tasks. If we need Matlab to run a vendor's filter
generation tools - so be it. If someone wants to take on
converting this to Octave - please have at it. If you can
modify it and prove it's valid we'll be happy to use it.
Otherwise, we will just suck it up and use Matlab (beg'd,
borrowed, stolen, or purchased). </div>
<div><br>
</div>
<div>7. Eagle has a long following - many have used it since
Version 4 or early on Mac, Linux, and Windows. They captured a
lot of users a decade ago with free versions for hobbyist use,
free versions usable by board houses, and economic
professional versions with auto-routing etc. It's a bit
weird and quirky but generally extremely stable. I don't see
any reasonable argument against using Eagle. Nor KiCad for
those so inclined. But I am against mandating either the
forced use of open tools or particular tools. As projects
involving PC boards proceed - consensus will likely appear as
to what is appropriate for the task at hand. </div>
<div><br>
</div>
<div>8. While we are on the subject, PCB layout has some
esoteric black art skills - especially for RF - but a very
major part of the work load involves preparing footprints,
symbols, and 3d models for parts. While there are lots of
parts in standard libraries there is a rule that says that
many of the ones you want won't be there (unless you made them
before). There is a lot of effort required to make parts
correctly and to verify them. But this does not involve
special skills - just a normal skill with the tool and the
usual conventions (like what goes in what layers and what does
not. There are tools that will generate parts from generic
descriptions to the formats of popular cad tools - e.g.
Ultra-librarian and Library Loader - but they are often less
than ideal - particularly with complicated parts that should
have multiple symbols in functional groupings, not one big
block with 900 pins. Element14 also added a lot of parts
(thank you) to Eagle, but often with poor symbols. And a lot
of stuff you'll download from the Internet is poor or outright
wrong. If a part cannot be found, then considerable time will
need to be devoted to building and verifying the part before
the PCB layout can continue. Even if a part is found - is it
correct? What design rules are implied? Frankly, this is the
vast majority of all PCB design activities. So this is an area
where many hands could potentially help by contributing. There
will be ongoing needs to build parts, verify parts, and manage
libraries of proven good parts. Have a look at the oresat
project's Eagle libraries <a
href="https://github.com/oresat/oresat-eagle-libraries"
moz-do-not-send="true">https://github.com/oresat/oresat-eagle-libraries</a>.
They seem to have a workable approach for their needs. </div>
<div><br>
</div>
<div>9. PCB design software is more than schematic capture and
layout. It also involve simulation (e.g. Spice) and design
rule verification. Over the last decade, integration with 3D
mechanical tools has also become common. Those in the tool
business must continue to provide value to their customers.
Autodesk bought Eagle to add to their other offerings. Their
Fusion product is now pretty usable and economical at the low
end and integrates with their 3D. They continue to offer free
eagle versions but their main offering is now their $60/month
Fusion product. Several in this group use these tools
professionally and they are good value for money. The Autodesk
model is pretty workable as the tools are licensed per named
individual but they can be purchased month to month (or
longer). So they are a good match to specific board projects.
Part work can always be done with the free versions or the
very stable version 7. When we are designing and building
complex boards with $2000 parts a few months of Fusion for a
couple of people is in the noise. They are a wise use of
funding - especially when they leverage what would otherwise
be tens of thousands of dollars of engineering labor.</div>
<div><br>
</div>
<div>10. So I think that the original question that started this
thread should probably be rephrased as:</div>
<div><br>
</div>
<div>A. Who has available time and willingness in the coming
months (and reasonable skill) for building parts in X, or Y,
or X and Z including Footprints, Symbols (not just big
squares), and 3D models and/or verifying same keeping in mind
that it's usually best for building and verifying to be done
by different persons. What tools would be needed to take
advantage of those skills. </div>
<div><br>
</div>
<div>11. As to the complex boards, I think that is going to be
case by case as design/layout/design rules etc are pretty much
engineered together and difficult to partition within a single
board. Generally, the board designer(s) will be using the
tools. I'm sure expert advice on best practices for any tool
will always be encouraged and well received. </div>
<div><br>
</div>
<div>12. As a final note, Eagle/Fusion 360 in the latest
versions have a feature called "Design Blocks" which allow
grouping of components and traces to be made and treated as
one (other tools also have this but it has been notably
awkward to do this with Eagle in the past). This adds another
layer of library-like work. It's especially useful for things
like switching power supplies and audio circuits where
grounding and routing issues are critical. It's valuable to
have drop in blocks for such things that have been proven all
the way to hardware verification (including EMC). Generally
using these and the 3D fetures requires Fusion as well a
Fusion user in the Organization that hosts the resources. So
there might need to be at least one more or less permanent
fusion subscription by the organization in addition to
whatever month to month subscriptions are required by those
that are not already fusion subscribers. </div>
<div><br>
</div>
<div>As usual - this is only my $0.02 - your mileage may vary -
use at your own risk.</div>
<div><br>
</div>
<div>WU1Y</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jul 27, 2020 at 3:51
PM Bruce Perens via Ground-Station
<a class="moz-txt-link-rfc2396E" href="mailto:ground-station@lists.openresearch.institute"><ground-station@lists.openresearch.institute></a> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jul 27, 2020 at
9:32 AM Robert McGwier via Ground-Station
<a class="moz-txt-link-rfc2396E" href="mailto:ground-station@lists.openresearch.institute"><ground-station@lists.openresearch.institute></a>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">I wish to say that the issue of which
tool to be used should not be dependent on cost or
personal ability to pay. Don't ask me more than that,
but you are entitled to guess all you want.</div>
</blockquote>
<div><br>
</div>
<div>This is just fine if you are making a decision on
behalf of your university, Federated Wireless, or
Hawkeye 360.</div>
<div><br>
</div>
<div>We are Amateurs.</div>
<div><br>
</div>
<div>It is a given that we would be using these tools in a
personal capacity to build experience and achieve our
own projects. And then using them in a broader role.
Thus, a tool which is in our reach financially is indeed
important.</div>
<div><br>
</div>
<div>We also wish to teach with our tools. <i>Formal</i>
education is not a mission of ORI because of the need to
be licensed and accredited, and the fact that this would
have delayed our initial 501(c)3 acceptance. But we
still wish to teach through example, through the
opportunity to participate, and all of the things we
create.</div>
<div><br>
</div>
<div>When we first got money, we used it to license
proprietary software. This is ironic. It's certainly
less than optimal, and we should be using Open Source if
at all possible. Decisions to license proprietary
products should never be made lightly.</div>
<div><br>
</div>
<div> Thanks</div>
<div><br>
</div>
<div> Bruce</div>
<div> </div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>