[Ground-station] How are we set for layout tools?

[Hugh Blemings]

Dear All,

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 :)

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.

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.

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.

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 OrangeCrab <https://github.com/gregdavill/OrangeCrab> 
This board is of course simpler than what we will need for the project, 
but I believe illustrates the feasibility of the endeavour.

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.

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.

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 :)

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 
OpenPOWER <https://github.com/antonblanchard/microwatt> and RISC-V 
<https://github.com/enjoy-digital/litex> cores/SoCs using only these tools.

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.

We're seeing increasingly complex full system synthesis/emulation too - 
for example Renode <https://renode.io/>.

Within this calendar year we'll see the first production of 
microprocessors and other ICs using entirely open source tooling 
<https://www.theregister.com/2020/07/03/open_chip_hardware/>.  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.

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.

Thank you for reading :)

vy 73
Hugh
VK3YYZ/AD5RV



On 28/7/20 10:50 am, Wally Ritchie via Ground-Station wrote:
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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).
>
> 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.
>
> 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 
> https://github.com/oresat/oresat-eagle-libraries. They seem to have a 
> workable approach for their needs.
>
> 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.
>
> 10. So I think that the original question that started this thread 
> should probably be rephrased as:
>
> 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.
>
> 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.
>
> 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.
>
> As usual - this is only my $0.02 - your mileage may vary - use at your 
> own risk.
>
> WU1Y
>
>
>
>
>
>
>
> On Mon, Jul 27, 2020 at 3:51 PM Bruce Perens via Ground-Station 
> <ground-station at lists.openresearch.institute> wrote:
>
>
>
>     On Mon, Jul 27, 2020 at 9:32 AM Robert McGwier via Ground-Station
>     <ground-station at lists.openresearch.institute> wrote:
>
>         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.
>
>
>     This is just fine if you are making a decision on behalf of your
>     university, Federated Wireless, or Hawkeye 360.
>
>     We are Amateurs.
>
>     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.
>
>     We also wish to teach with our tools. /Formal/ 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.
>
>     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.
>
>         Thanks
>
>         Bruce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20200728/b814034c/attachment-0001.html>