WTF Xilinx

[kfnight]

50 GiB disk space to install Vivado 2020.1 and 100+ GiB to install it with Vitis. 

[BrianHG]

For all your future projects, I wonder what actual % of that 150GB you will ever access.

I say less around 10%.

[asmi]

For all your future projects, I wonder what actual % of that 150GB you will ever access.

I say less around 10%.

You don't have to install everything if you aren't going to use it all, or space is at premium.

[Berni]

Well you do also get 10s of GB with Altera/Intel Quartus tools too.

I don't really mind it is as the big name tools ware always big on disk. But if your aim is to install it on a SSD i could see the size of it being a pain.

By the way i hear that some Xilinx tools leave behind installation logs that are a few GB is size, so you could reclaim that.

[BrianHG]

For all your future projects, I wonder what actual % of that 150GB you will ever access.

I say less around 10%.

You don't have to install everything if you aren't going to use it all, or space is at premium.

Unfortunately, except installing support for FPGAs you never expect to use, you will never know what you may end up using.
It's just such a hassle to lateron re-run the install to add a feature while in the middle of work.
This even includes support for the other FPGAs which you might have never intended to use just as your current project may expand into new territory.
Even worse, after re-running the installer may crash or go funky in the middle of changing the list of supported features corrupting your current install leaving you to restore a system backup, or re-installing the entire development studio.

I say all this since all of this has happened to me with Quartus over the past 15 years.
I just do the complete install and bite the space.  In fact, I have multiple full complete key versions installed at once and still mostly develop with an older version which has proven to be completely stable and at times faster than the latest studio.

[james_s]

Even ISE is over 18GB and the old version of Quartus I use is almost 10GB. I've long been curious what it's doing with all that space, I know very little about how the software works internally.

[filssavi]

Even ISE is over 18GB and the old version of Quartus I use is almost 10GB. I've long been curious what it's doing with all that space, I know very little about how the software works internally.

All FPGA tools take a massive amount of space because each supported part needs it’s own model, that specifies not only features bitstream format etc but also all the detailed timing info to run routing, synthesis etc. Thus the higher end the supported parts are the bigger the models, and you have probably hundreds of them (a model might be “Only” Few hundreds megs of data, however you).

there was a talk by the open source FPGA toolchain folks where they talked this (I don’t remenber the exact title).

As for Vitis I was honestly a bit puzzled to, however if yocto has taught me anything is that embedded software stuff can easily eat up tons of space

[hamster_nz]

Wow! That is like $15 worth of space if installed on an SSD, or maybe $2.50 is you use a HDD...

[Someone]

Even ISE is over 18GB and the old version of Quartus I use is almost 10GB. I've long been curious what it's doing with all that space, I know very little about how the software works internally.

All FPGA tools take a massive amount of space because each supported part needs it’s own model, that specifies not only features bitstream format etc but also all the detailed timing info to run routing, synthesis etc. Thus the higher end the supported parts are the bigger the models, and you have probably hundreds of them (a model might be “Only” Few hundreds megs of data, however you).

Same as for ISE, the models are the major disk use. It used to be optional in the installer which parts you wanted to support (who's ever planning to touch space graded parts?) but you can still strip them out manually.

[Fred27]

It's bad, isn't it? There's also the version support hell that means you may well want 3 or so different versions of Vivado installed if you want to run through examples, courses, etc.

It does help if you remove support for devices you won't/can't use. Even after doing this I still found a 1.8GB folder of Versal data on a WebPACK installation of Vivado. At the time Versal was yet to be released and being fairly high-end wasn't supported by the free WebPACK anyway. Deleting it didn't cause any problems.

[0db]

Yesterday I bought a HONOR MAGICBOOK 14 because it's decent and powerful enough for daily use and very cheap (paid 500 euro) and I don't want to use my Mac because it's dedicated for video editing.

Now I have a problem. My MAGICBOOK only has 80Gbyte of storage. I'd best replace it with a bigger one.

[NorthGuy]

I've long been curious what it's doing with all that space, I know very little about how the software works internally.

This is mostly bloat - inefficient use of resources which takes space and makes software slow and buggy. However, I guess most people think that this is because what the software is doing is incredibly complex and cannot be done any other way.

[asmi]

This is mostly bloat - inefficient use of resources which takes space and makes software slow and buggy.

Every time I see someone's saying that I know he has no idea what he's talking about unless...

However, I guess most people think that this is because what the software is doing is incredibly complex and cannot be done any other way.

The only person who ever can talk about bloat that the one who demonstrates his own software that does the same thing but without all of that "bloat".

So - care to show us your lightweight, very fast software with zero bugs that does P&R for all Xilinx parts at least as good as Vivado does? Or it's the usual trash-talking?

[filssavi]

I've long been curious what it's doing with all that space, I know very little about how the software works internally.

This is mostly bloat - inefficient use of resources which takes space and makes software slow and buggy. However, I guess most people think that this is because what the software is doing is incredibly complex and cannot be done any other way.

If you can do so much better why don’t you do it yourself, of course you need to produce a functionally equivalent product, in comparable amount of time and with  comparable , and with roughly the same performances.

The reality is that apart from very very few collaborative projects (the Linux kernel springs to mind), or the hyperscalers,  most other software projects have just enough resources to work on features and fix the most critical bugs.

Optimising something for size requires dedicating large amount of resources, and also probably worsening performances (the ever present time vs memory trade-off in computer science).

Let’s not forget that Vivado in particular and Xilinx FPGAs are not targeted at hobbists in emerging countries, but at professional engineers and companies, so even the most basic pc will have at least a TB of Storage (or that can be upgraded for 100$ or less, why waste money I ask?

Look at an example yocto, the initial download is few hundred mega, however after a full compile of a non trivial distro the folder will be Several tens of GB, mine even approached 100. Is it bloat and crap?

Absolutely not, the space is occupied with various levels of cache, so your next build will not take 1 and a half hours but just 5 to 10 minutes.

Petalinux for example (which is mostly a repackaged and customised yocto install) download is IIRC 8 gigs.

Is the additional space wasted?

No they just included in the download part of the caches, so even the first builds will not take 1 hour

[james_s]

This is mostly bloat - inefficient use of resources which takes space and makes software slow and buggy. However, I guess most people think that this is because what the software is doing is incredibly complex and cannot be done any other way.

Are you basing this on something in particular or is it just an assumption? I could certainly believe there's a good deal of bloat, but in that case what specifically is that bloat? You're implying that you know something that most people don't, it's the specifics that I'm interested in.

I suppose support for all kinds of chips I'll never use could be lumped under bloat, it would be nicer if there was an easy way to choose what device support is added on a more granular basis. I may typically use a small handful of parts among 2 or 3 different families.

[SiliconWizard]

Managed to get Vivado install down to ~30GB with a custom install and removing support for the higher end parts like Virtex.
That's still a lot of data.
My ISE install takes ~17GB.

[ejeffrey]

At least with Intel the thing that gets me isn't so much the disk space (which is huge) but the download time.  The last time I downloaded Quartus it took over an hour on a very fast connection due to the download images being so huge and also the download went quite slowly.  I don't know if Intel just cheaped out on their CDN but I can usually only download at about 20 megabit from there even on 150 megabit or gigabit network links that have no problem sustaining those speeds to other sites.

[ejeffrey]

Let’s not forget that Vivado in particular and Xilinx FPGAs are not targeted at hobbists in emerging countries, but at professional engineers and companies, so even the most basic pc will have at least a TB of Storage (or that can be upgraded for 100$ or less, why waste money I ask?

Well, even in the US plenty of engineering desktop computers still have 256 or 512 GB SSDs -- even brand new machines much less the ones that have been on peoples desk for 5 years because replacing it is a hassle and CPU performance hasn't increased that much.  But yes, for under $200 you can buy a fast M.2 SSD with 1 TB of capacity and that costs less than a single part of the high end FPGAs that drive the storage requirements up so much. 

[DIPLover]

What surprised me is the sudden doubling in size (15 to 30GB) of the minimal Vivado install from 2018 to 2019.

And to the "So - care to show us your lightweight, very fast software with zero bugs that does P&R for all Xilinx parts at least as good as Vivado does?" crowd :

Yeah, right, whatever. Vivado has been a slow buggy mess for 7 years now... But keep worshipping the mythical Xilinx engineers...

ISE was a mess too, but at least for medium-size designs in medium-sized parts, it was reasonably fast.

Good software exists, it does not have to be built by ME (or YOU, or HIM) to prove that it's possible.

[Fred27]

I see that Vivado 2020.1 is just out. I suspect it'll be even bigger than 2019!

[Edit: Clearly I missed the 2020 in the first post. ]

[filssavi]

Yeah, right, whatever. Vivado has been a slow buggy mess for 7 years now... But keep worshipping the mythical Xilinx engineers...

First we were talking about space requirements, not speed, or bugginess
But most importantly Intel quartus prime alone (no SDK) can take up to 75GB as per the manual, so, also altera/intel engineers are crap with this mentality
Lattice radiant takes 3 GB to support less then 10 tiny parts, which  is probably a device or cumulative FPGA resources supported (LUTS DSP RAM etc) to GB ratio is probably even worse than xilinx, and so on

If all the serious FPGA tools are huge there must be a reason apart from bloat, don't you think?

If everybody converged to a huge install size despite having clear drawbacks even for the company (it costs much more in term of outbound bandwidth/cdn/servers since the download will be also larger)  there must be a valid engineering reason, we might not understand it, however as a users of a tool, and not a developers we must not be so full of ourselves to think that only we have all the answers and what everybody else does is crap

[helius]

If all the serious FPGA tools are huge there must be a reason apart from bloat, don't you think?

Hardware engineers don't read Fred P. Brooks, "The Mythical Man-Month".

Related: Do these tools still completely fail at supporting version control?

[daqq]

If all the serious FPGA tools are huge there must be a reason apart from bloat, don't you think?

I'm guessing that yes and no. While I'm sure that there's a reason the tools need a lot of space, there's also a growing culture of simply not giving a damn about disc usage at all and cleaning up after yourself. See:
https://www.eevblog.com/forum/fpga/free-2gb-of-store!-just-delete-the-bloody-install-xilinx-log/

[NorthGuy]

Are you basing this on something in particular or is it just an assumption? I could certainly believe there's a good deal of bloat, but in that case what specifically is that bloat?

The biggest drag is Tcl/Tk - nothing is done natively. Synthesis and  Implementation are not cohesive, but operate in a sequence of step, each of which access huge network of Tcl/Tk. Even simple operations take long time, such as writing bitstream may take 20 seconds. Should take a fraction of a second. Or opening a project ... why is that taking so long? Even a tiny project with everything placed and routed manually still takes several minutes from VHDL to bitstream.  I once wrote a script to enumerate all the BELs of a small FPGA (Artix-7 50). This is not a big output file really - 170 MB - I had to run  the script overnight. If the object access was efficient, It should've taken seconds, minutes at worse. When the routing algorithms operate on this object basis this is also painstakingly slow, no matter how good the algorithm is.

The only person who ever can talk about bloat that the one who demonstrates his own software that does the same thing but without all of that "bloat".

This is not about talking. Whatever I say doesn't change the reality. Vivado is in front of you. Look how it operates and draw your own conclusions.

[james_s]

The biggest drag is Tcl/Tk - nothing is done natively. Synthesis and  Implementation are not cohesive, but operate in a sequence of step, each of which access huge network of Tcl/Tk. Even simple operations take long time, such as writing bitstream may take 20 seconds. Should take a fraction of a second. Or opening a project ... why is that taking so long? Even a tiny project with everything placed and routed manually still takes several minutes from VHDL to bitstream.  I once wrote a script to enumerate all the BELs of a small FPGA (Artix-7 50). This is not a big output file really - 170 MB - I had to run  the script overnight. If the object access was efficient, It should've taken seconds, minutes at worse. When the routing algorithms operate on this object basis this is also painstakingly slow, no matter how good the algorithm is.

This is not meant as an attack on you, but none of that really answers my question. I suspect that nobody outside of Xilinx or Altera/Intel truly know what makes the software as big and slow as it actually is. It's easy to look at it from the outside and say it's slow and should be faster, but what I'm curious about is *why* it's slow, maybe it's perfectly reasonable given what it's doing, maybe it's not, but I'm not seeing any answers here, well other than someone else mentioning that it's mostly the models of all the different supported parts that take up space.

Like someone else said though, if you think something that takes 20 seconds takes to long then I'd love to see you write a program that does the same thing faster.

[0db]

Just ordered a 256Gb SSD module. Problem solved.

[NorthGuy]

Like someone else said though, if you think something that takes 20 seconds takes to long then I'd love to see you write a program that does the same thing faster.

I have a simple program which reads a bitstream, reads my script which describes the sequence of actions, builds a BRAM image for my state machine, injects BRAM contents into the bitstream, recalculates checksum and writes the new bitstream to a file. IMHO, this is the amount of work similar to what Vivado's "write bitstream" does. Mine takes much less than a second.

Few people here suggested that I should abandon my life, spend three years writing an extremely efficient P&R software and post it here, which would supposedly give me moral ground to discuss Vivado. They themselves don't seem to need anything to express their admiration. This is certainly funny.

[0db]

I have a simple program which reads a bitstream

Is it a verifiable news? Is there a source code i can test?

Few people here suggested that I should abandon my life, spend three years writing an extremely efficient P&R software and post it here ...

Send your CV to Xilinx, get hired and if you are so brilliant you will be paid for doing it.

edit: typo

[NorthGuy]

I have a simple program which reads a bitstream

Is it a verificable news? Is there a source code i can test?

Wow! May be I also need to deposit my salary to your bank account?

Write your own. I'm sure you can write bitstreams faster than Vivado. Or look at ISE. It does most of the stuff faster than Vivado.

[mark03]

I never would have guessed calling Vivado "bloated" could be controversial.  That is some serious Stockholm syndrome
Believe what you want.  Writing a replacement is sufficiently complex that no one person or small team could realistically do it in a year, probably not a decade, even if they were sufficiently wealthy, altruistic, and provided full device models and bitstream documentation by Xilinx.

Haven't you wondered why so many of the things we do on computers today feel just as slow as they did in the 80s and 90s, despite exponential increases in raw computational power and storage?  (Compare Visicalc with MS Excel, or Wordperfect with Word.)  Programs are bloated because the space and the MIPS are there, and humans are lazy.  Make no mistake, most large programs could be 1/10 their current size, with significant improvement in speed, but for that to happen we would have to care.

Also, it takes longer to write less code.

[hamster_nz]

I think the reason is pretty simple. On the list of design goals "Smallest disk footprint" and "fastest time to implement" were way down the bottom.

Other things like "sanity check inputs and DRC as much as possible at each stage", "scale across all supported parts", "cross platform OS support", "minimal external software dependencies" and "try to reduce coupling of dependencies between different tools" were higher up.

[james_s]

I never would have guessed calling Vivado "bloated" could be controversial.  That is some serious Stockholm syndrome
Believe what you want.  Writing a replacement is sufficiently complex that no one person or small team could realistically do it in a year, probably not a decade, even if they were sufficiently wealthy, altruistic, and provided full device models and bitstream documentation by Xilinx.

I wasn't so much referring to Vivado as ISE and Quartus, but the real point is that I'm not saying that it's not bloated, it certainly has the appearance of bloat, I just truly don't know how it works internally. I have nothing on which to base an assertion on, I don't know why it's so huge, maybe it's a bunch of lazy bloat or maybe the immense complexity is actually necessary. I recognize that the fact I don't understand what something does doesn't mean it doesn't need to be there. Stating "it's bloated" doesn't really tell me anything, it's the precise nature of the bloat that interests me, what parts are actual bloat and what parts are big because they are integral to working with incredibly complex hardware.

I've worked in the software industry long enough to have seen more than a few times people start out claiming something is bloated and start on a replacement but then by the time the replacement does everything the product it is replacing does, it has grown to be just as bloated if not more so.

[ejeffrey]

This is not meant as an attack on you, but none of that really answers my question. I suspect that nobody outside of Xilinx or Altera/Intel truly know what makes the software as big and slow as it actually is. It's easy to look at it from the outside and say it's slow and should be faster, but what I'm curious about is *why* it's slow, maybe it's perfectly reasonable given what it's doing, maybe it's not, but I'm not seeing any answers here, well other than someone else mentioning that it's mostly the models of all the different supported parts that take up space.

I don't know about vivado, but in quartus just launching the basic tcl interpreter (quartus_sh) takes 3.5 seconds from a completely hot disk cache on my relatively fast Xeon desktop with an SSD.  The first invocation took considerably longer but I didn't time it (5-10 seconds at a guess).  That means that hello world written in tcl takes 3-4 seconds.  If you have a job that requires starting multiple tcl interpreters from scratch, that keeps adding up.

Compare that with bash, python, perl, or plain tclsh all of which have broadly similar intrinsic capability but can execute trival programs 3 orders of magnitude faster.

Of course the quartus_sh is doing stuff during that wait: presumably initializing the gabs of modules that quartus needs for its environment.  But that is all just wasted effort if your actual job doesn't require that and is all thrown away when the job completes.  Well designed interpreted environments try to limit startup work to what is needed for the task at hand.

[Nominal Animal]

Send your CV to Xilinx, get hired and if you are so brilliant you will be paid for doing it.

Xilinx and other vendors are not interested in "brilliant" software developers who can do stuff better than existing software.
They are only interested in developers who can produce a shippable product with the least overall cost.

Writing better software than is absolutely required is insubordination in todays corporate environments – at least if the higher ups or the marketing department find out.

Worse, if you write software that works without issues for years, you're simply forgotten: out of sight, out of mind.  Ask me how I know.

You'd think it'd matter to hardware vendors like Xilinx, but it doesn't.  Only in smaller companies and startups do developers get to pick their tools.  In larger companies, those tools are more often chosen by nontechnical higher-ups based on nontechnical reasons, and imposed on developers because such investments cannot be left for mere developers to decide.  Developers soon grow a thick skin (or bail out to smaller companies or other fields, no matter how brilliant), and get on with the job with the tools at hand.  Stockholm syndrome is common, be it compiler, OS, toolkit, dev environment, framework, or libraries, because eating shit every day is easier if you convince yourself that it tastes good.

Ignoring the above rant, the point is that software quality just does not matter at all in the corporate world.  (There are exceptions, of course, but as usual, they're rare.)

[0db]

Write your own

I do stuff myself, and I rarely chatter about it because it's useless for others unless I have something to release to them.

All the Xilinx stuff is mostly for free, and you don't pay a penny for it. So, why should you complain about?

Because their tools now take a lot of space on the harddrive? Buy a bigger disk, like I did yesterday.
Because it's getting slower? Well, buy a powerfull computer, or try improve something along the workflow.

What is the meaning of chattering in a forum that you are "supposed" to have improved the Xilinx' stuff, but you are not willing to release anything?!?

[Nominal Animal]

All the Xilinx stuff is mostly for free, and you don't pay a penny for it. So, why should you complain about?

Well, the first post and the title is a question...

I don't have Vivado (I don't have any FPGAs at all, yet!), but I have looked at quite a few "Software Development Kits" for vendor-provided Linux distributions intended for embedded devices; in particular, those for wireless routers.

Oh boy are they bloated utter shit.

The "best" one I saw didn't have any documentation with it, but had three separate installations for GCC for ARM (different versions) and three different Linux kernel source trees (all different), plus a dozen or so other devkits that were completely unrelated to building any kind of software for the target architecture, and a couple of gigabytes of various source trees, none of which were even remotely up to date when the products were first launched (so this was not a case of bit rot due to the devices being released such a long time ago and not getting any updates since then; this was a case of starting with ancient software from the get go).

I haven't seen anyone else mention how... ahem, utterly inanely bloated and full of crap these so-called SDKs are, so the conclusion is obvious: this is typical, and nothing strange to embedded devs.

[0db]

Send your CV to Xilinx, get hired and if you are so brilliant you will be paid for doing it.

Xilinx and other vendors are not interested in "brilliant" software developers who can do stuff better than existing software. They are only interested in developers who can produce a shippable product with the least overall cost.

I visited a Microsoft new building in Europe. They spent a fortune to make all the openspace rooms more comfortable. I saw a dozen of giant round tables with motorized flower pot in the center that goes up and down according to the purpose of the meeting, a lot of flowers and plants, a lot of soundproof rooms, a tiny gym with ministepper machines, a kitchen induction cookers and several kinds of coffee machines, a lot of mini bars, and even a swimming pool.

All in the same corporate building.

I think it's done to improve the productivity, but it's also done to attract brilliant person.

Worse, if you write software that works without issues for years, you're simply forgotten: out of sight, out of mind.  Ask me how I know.

how do you know it? 

You'd think it'd matter to hardware vendors like Xilinx, but it doesn't.  Only in smaller companies and startups do developers get to pick their tools.  In larger companies, those tools are more often chosen by nontechnical higher-ups based on nontechnical reasons, and imposed on developers because such investments cannot be left for mere developers to decide.  Developers soon grow a thick skin (or bail out to smaller companies or other fields, no matter how brilliant), and get on with the job with the tools at hand.  Stockholm syndrome is common, be it compiler, OS, toolkit, dev environment, framework, or libraries, because eating shit every day is easier if you convince yourself that it tastes good.

I guess I got your point.

Ignoring the above rant, the point is that software quality just does not matter at all in the corporate world.  (There are exceptions, of course, but as usual, they're rare.)

Dunno, it's not my field.

I use CPLD and FPGA only to give a hand to my colleagues.

Last time we designed and installed several trap-photo devices to catch shots about dangerous animals as well as shots about poachers trying to kill them.

This kind of equipment needs to work for years.

[NorthGuy]

What is the meaning of chattering in a forum that you are "supposed" to have improved the Xilinx' stuff, but you are not willing to release anything?!?

I think you misunderstood me. James asked how did I know that 20 seconds for writing bitstream is too long. I simply said that I wrote programs which do similar things which helps me to estimate how long it would normally take, which is milliseconds.

You can do your own estimates very easily - create a LED blinker in the FPGA, then, when you implemented it, go to the FPGA editor and fix all the places and routes. Now all the P&R is already done, so you know that nothing complex needs to be done. Go back and do full synthesis - implementation - write bitstream. Measure how long it takes to produce the bitstream on your very fast computer. All of this time is bloat.

[Nominal Animal]

They spent a fortune to make all the openspace rooms more comfortable.

Branding.

a lot of soundproof rooms, a tiny gym with ministepper machines, a kitchen induction cookers and several kinds of coffee machines, a lot of mini bars, and even a swimming pool.

They want their developers to be there all the time.

but it's also done to attract brilliant person.

No, it is done for branding, and to attract the kind of developers they want: productive ones.

Brilliant developers don't tend to be that productive, nor are they that interested in the environs.

If you want an example, look at DJB.  Then, for fun, count the number of security holes in Bind and Sendmail.  Yet, how many people even know about DJB, or Qmail, or DJBDNS?  Excellence does not correlate with popularity, and even less with being desirable hire in the corporate world.

Worse, if you write software that works without issues for years, you're simply forgotten: out of sight, out of mind.  Ask me how I know.

how do you know it? 

Experience, both personal and cow-orker.  It's the noisy ones who get the kudos, not the ones who never cause problems for anyone, and just quietly keep the wheels turning.  A squeaky wheel gets oiled more often, and so on.

This kind of equipment need to work for years.

The number of companies providing guarantees or even recommendations on product lifetime in years is rare nowadays, and usually that costs a big premium.

[SiliconWizard]

Send your CV to Xilinx, get hired and if you are so brilliant you will be paid for doing it.

Xilinx and other vendors are not interested in "brilliant" software developers who can do stuff better than existing software.
They are only interested in developers who can produce a shippable product with the least overall cost.

Yep.

Writing better software than is absolutely required is insubordination in todays corporate environments – at least if the higher ups or the marketing department find out.

Absolutely. And it's also a problem if you work in a team, as your colleagues will also resent you for this.

Worse, if you write software that works without issues for years, you're simply forgotten: out of sight, out of mind.  Ask me how I know.

Yep!

You'd think it'd matter to hardware vendors like Xilinx, but it doesn't.  Only in smaller companies and startups do developers get to pick their tools.  In larger companies, those tools are more often chosen by nontechnical higher-ups based on nontechnical reasons, and imposed on developers because such investments cannot be left for mere developers to decide.  Developers soon grow a thick skin (or bail out to smaller companies or other fields, no matter how brilliant), and get on with the job with the tools at hand.  Stockholm syndrome is common, be it compiler, OS, toolkit, dev environment, framework, or libraries, because eating shit every day is easier if you convince yourself that it tastes good.

Ignoring the above rant, the point is that software quality just does not matter at all in the corporate world.  (There are exceptions, of course, but as usual, they're rare.)

Mostly agree.
Point is - it IS possible to write "better" and less bloated software, but not in the current corporate world.

[ejeffrey]

Send your CV to Xilinx, get hired and if you are so brilliant you will be paid for doing it.

Xilinx and other vendors are not interested in "brilliant" software developers who can do stuff better than existing software.
They are only interested in developers who can produce a shippable product with the least overall cost.

My understanding is that their software team is basically constantly having to justify their budget.  For a hardware company software is a cost sibk.
 They don't make anywhere near enough money on the software licenses to pay for the development costs. They make it because they have to or nobody will be able to buy their chips, but beyond features that will help them get design wins it is hard to justify any improvement.

Plus they have decades of legacy cruft, customer and partner workflows they want to preserve.  They can release a new development environment or new system builder tools but rearchitecting the underlying technology would probably cost them customers rather than gain them.

[james_s]

I visited a Microsoft new building in Europe. They spent a fortune to make all the openspace rooms more comfortable. I saw a dozen of giant round tables with motorized flower pot in the center that goes up and down according to the purpose of the meeting, a lot of flowers and plants, a lot of soundproof rooms, a tiny gym with ministepper machines, a kitchen induction cookers and several kinds of coffee machines, a lot of mini bars, and even a swimming pool.

All in the same corporate building.

I think it's done to emprove the productivity, but it's also done to attract brilliant person.

If they want to attract (and retain) brilliant people, they should shift back to private offices instead of these trendy open space layouts that engineers almost universally hate. The open plan offices look especially ridiculous after the Covid epidemic.

[NorthGuy]

Plus they have decades of legacy cruft, customer and partner workflows they want to preserve.  They can release a new development environment or new system builder tools but rearchitecting the underlying technology would probably cost them customers rather than gain them.

Xilinx dropped ISE abruptly about 6 years ago and switched to Vivado. The move was so abrubt that only 2 chips are common between ISE and Vivado - Artix-7 100 and 200. This is a new development from scratch, not compatible to ISE. They said theis was a completely new design from scratch which took them 5 years to develop. That's a titanic effort, and Vivado has really good ideas. For example, FPGA editor is miles better than in ISE. So they are indeed trying hard. But still Vivado is bloated more than ISE and ISE generates better results.

[Someone]

Plus they have decades of legacy cruft, customer and partner workflows they want to preserve.  They can release a new development environment or new system builder tools but rearchitecting the underlying technology would probably cost them customers rather than gain them.

Xilinx dropped ISE abruptly about 6 years ago and switched to Vivado. The move was so abrubt that only 2 chips are common between ISE and Vivado - Artix-7 100 and 200. This is a new development from scratch, not compatible to ISE. They said theis was a completely new design from scratch which took them 5 years to develop. That's a titanic effort, and Vivado has really good ideas. For example, FPGA editor is miles better than in ISE. So they are indeed trying hard. But still Vivado is bloated more than ISE and ISE generates better results.

Look at the parts library in ISE, there is a much larger overlap than 2 parts from a single series. What Xilinx recommend to use and what is possible (or even best) to use don't always line up.

[0db]

If they want to attract (and retain) brilliant people, they should shift back to private offices instead of these trendy open space layouts that engineers almost universally hate.

Actually there are also private rooms, even soundproofed rooms for one person or for four persons.

The open space rooms are made mostly for "meeting", "conference" and "brainstorming". Attached two pics abot the round tables with the motorized flowerpot. That staff is amazing. I like it.

One more interesting thing is that nobody has his/her private desk. You enter the building, you have your private locked box in the wall and that's all. You can leave your personal laptop there, and get it ever morning when you get in.

Then you can daily choose where to sit and with whom, and that's a very very good idea to improve social relations.

So sociologists and psychologists said. As far as I understood during my one day visit.

[Fred27]

If they want to attract (and retain) brilliant people, they should shift back to private offices instead of these trendy open space layouts that engineers almost universally hate.

Is this true? I know some people don't like open plan offices, but I do and I've certainly met others who do too.

[SiliconWizard]

Plus they have decades of legacy cruft, customer and partner workflows they want to preserve.  They can release a new development environment or new system builder tools but rearchitecting the underlying technology would probably cost them customers rather than gain them.

Xilinx dropped ISE abruptly about 6 years ago and switched to Vivado. The move was so abrubt that only 2 chips are common between ISE and Vivado - Artix-7 100 and 200. This is a new development from scratch, not compatible to ISE. They said theis was a completely new design from scratch which took them 5 years to develop. That's a titanic effort, and Vivado has really good ideas. For example, FPGA editor is miles better than in ISE. So they are indeed trying hard. But still Vivado is bloated more than ISE and ISE generates better results.

Yep.
Note that this is mainly about all the user interface and additional GUI-based tools.
I'm pretty sure all the underlying synthesis, map, PAR tools, which AFAIK are just still command-line tools, are on the same code base and were not rewritten from scratch.

[NorthGuy]

Yep.
Note that this is mainly about all the user interface and additional GUI-based tools.
I'm pretty sure all the underlying synthesis, map, PAR tools, which AFAIK are just still command-line tools, are on the same code base and were not rewritten from scratch.

They may have reused some of the code, but there's no doubts that the internals are different, XDC is new, P&R works differently. I don't think it was GUI-only change.

[Nominal Animal]

So sociologists and psychologists said.

Pity they don't actually measure the creative output qualitatively and quantitatively, before deciding being "pro-social" is a good thing.  Then again, finding a psychologist or sociologist who has a good grasp of software development is expensive.

I for one cannot get shit done in an open plan office.  I need a minimal distraction environment, like a small cupboard or something.  An open plan office with people whizzing by, I'm as productive as a pebble in your shoe.  When on the cusp of solving a problem, I'm definitely antisocial; for example, I like to mutter curses.  (That has been proven to increase ones pain tolerance, so it's not about being crass or "that way"; it enhances my productivity.)

That said, I do do my best work in a team, so having spaces where a team can hash out stuff is important, and it's nice to know some companies actually provide those.   It's just that in my experience, it doesn't take more than say 20% of ones time, with 50% or more being productive creative work (that I cannot do in a non-quiet environment).

[Mr. Scram]

Wow! That is like $15 worth of space if installed on an SSD, or maybe $2.50 is you use a HDD...

With that attitude you're going to need that space worth $15 many times over.

[Mr. Scram]

Actually there are also private rooms, even soundproofed rooms for one person or for four persons.

The open space rooms are made mostly for "meeting", "conference" and "brainstorming". Attached two pics abot the round tables with the motorized flowerpot. That staff is amazing. I like it.

One more interesting thing is that nobody has his/her private desk. You enter the building, you have your private locked box in the wall and that's all. You can leave your personal laptop there, and get it ever morning when you get in.

Then you can daily choose where to sit and with whom, and that's a very very good idea to improve social relations.

So sociologists and psychologists said. As far as I understood during my one day visit.

Research shows open plan offices actually reduce interaction and social relations. People tend to withdraw more in an attempt to regain some of their concentration and privacy. Open plan offices are usually a cost saving measure which ends up being ridiculously expensive due to lost production and increased stress and unhappiness.

[Mr. Scram]

Is this true? I know some people don't like open plan offices, but I do and I've certainly met others who do too.

I'm not sure it's almost universal but we've been looking into this and a significant majority seems to have issues with open plan offices, especially when these are combined with a flex concept which further limits people's ability to shape their environment to their needs.

[0db]

Pity they don't actually measure the creative output qualitatively and quantitatively, before deciding being "pro-social" is a good thing.  Then again, finding a psychologist or sociologist who has a good grasp of software development is expensive.

They told me that all the process was managed in a "scientific way".

Psychologists and sociologists talked with developers, listened to people to collect statistical data, then talked to architects, and then architects built all the amazing things.

I do not have any competence to judge. I simply felt it was "amazing", and in a couple of area I really felt like if I was at home.

I visited the "Pulsar" department, where they co-develop Windows CE/embedded.

[Bassman59]

If they want to attract (and retain) brilliant people, they should shift back to private offices instead of these trendy open space layouts that engineers almost universally hate.

Is this true? I know some people don't like open plan offices, but I do and I've certainly met others who do too.

i can’t stand the open-office thing. This happens all the time: I’m at my desk, finally settled in and working, and someone walks in and seats to someone else, “ DID YOU SEE THE GAME LAST NIGHT!” and the thought train is derailed.

[Bassman59]

If all the serious FPGA tools are huge there must be a reason apart from bloat, don't you think?

Hardware engineers don't read Fred P. Brooks, "The Mythical Man-Month".

Related: Do these tools still completely fail at supporting version control?

They are openly hostile to version control.

By the end of ISE, Xilinx finally got it. All you needed to put in your repo were the sources, the .xise project file, and the .ucf. I have no fucking idea how to deal with Vivado and it’s maddening.

[Siwastaja]

They told me that all the process was managed in a "scientific way".
..
I do not have any competence to judge. I simply felt it was "amazing", and in a couple of area I really felt like if I was at home.

You were exposed to a thing called "marketing", which clearly worked, as expected! "Science" has been a marketing buzzword for a long time.

The fact it's marketed and sugar coated to you does not prove it's bad, but it doesn't prove it's good either. Only the time will tell.

I'm almost 99% certain that whatever "science" went into this won't exceed the bare minimum limits of what is considered scientific. Things like setting objective metrics to assess the results against, repeatability, openness to the scientific community, and eliminating possible outside sources of influence.

[0db]

Only the time will tell.

I see bias, but it's ok. Only facts really matter. And facts are that I will have a collaboration with them. Probably the next year. This means a lot of occasions to "verify" how things really are.

I only wish I had a pass for Xilinx.  Unfortunately I am not qualified enough for them.

[Sal Ammoniac]

there's also a growing culture of simply not giving a damn about disc usage at all and cleaning up after yourself.

This. It's not just disk space, but memory and CPU cycles as well. When I first started working in the embedded industry 35 years ago we were lucky to have a 4 MHz CPU with 2K of RAM and 4K of EPROM. We used assembly language because compilers weren't available.

Nowadays kids are coming out of school believing you can't do anything without megabytes or gigabytes of memory, GHz CPUs, and a Linux OS of some sort, even in the smallest embedded system. Throw in some huge C++ libraries and pile on layers upon layers of abstraction and you end up with a big mess. Efficiency is no longer valued.

[asmi]

Nowadays kids are coming out of school believing you can't do anything without megabytes or gigabytes of memory, GHz CPUs, and a Linux OS of some sort, even in the smallest embedded system. Throw in some huge C++ libraries and pile on layers upon layers of abstraction and you end up with a big mess. Efficiency is no longer valued.

The explanation is very simple - it's simply cheaper to buy more hardware to improve performance, rather than investing into optimization. Engineers are expensive, and hardware is cheap. 1Tb M.2 SSD is now goes for about $150, which is a price of about 1 hour of engineer's time. This is a pocket change for all but the smallest companies.
This is also why scripting languages are so popular nowadays. They save development time at the expense of performance.

[Sal Ammoniac]

If you want an example, look at DJB.  Then, for fun, count the number of security holes in Bind and Sendmail.  Yet, how many people even know about DJB, or Qmail, or DJBDNS?  Excellence does not correlate with popularity, and even less with being desirable hire in the corporate world.

IMO, the reason more people don't use DJBDNS and Qmail is due more to DJB's personality than anything else. I use both on my AWS instances, but hope I never have an issue because DJB tends to be snarky and rude

[Sal Ammoniac]

Nowadays kids are coming out of school believing you can't do anything without megabytes or gigabytes of memory, GHz CPUs, and a Linux OS of some sort, even in the smallest embedded system. Throw in some huge C++ libraries and pile on layers upon layers of abstraction and you end up with a big mess. Efficiency is no longer valued.

The explanation is very simple - it's simply cheaper to buy more hardware to improve performance, rather than investing into optimization. Engineers are expensive, and hardware is cheap. 1Tb M.2 SSD is now goes for about $150, which is a price of about 1 hour of engineer's time. This is a pocket change for all but the smallest companies.
This is also why scripting languages are so popular nowadays. They save development time at the expense of performance.

I'm not talking about development tools and hardware--I'm talking about the products themselves.

[Bud]

Then you can daily choose where to sit and with whom, and that's a very very good idea to improve social relations.

No wonder that Windows is such a mess now.

[asmi]

I'm not talking about development tools and hardware--I'm talking about the products themselves.

It's the same thing - TTM is the most important factor nowadays, so there is no time for optimizations.

[NorthGuy]

TTM is the most important factor nowadays

I'm sure if Vivado worked 50 times faster than now, it would shorten TTM and decreased development costs for thousands of companies big and small alike. But nobody seems to care. Apparently, TTM and development costs are of no concern to all these companies.

[Berni]

Well on the topic of slow horribly optimized FPGA tools have a look at the Lattice Diamond bitstream programmer utility.

When you click the program button it takes >30 seconds to flash a small FPGA (4k LEs) with a bitstream that is only 64KB in size. But the worst part is that the part of the process that actually loads stuff into the chip takes like 5 seconds. How it actually goes is that you click program. It prints into the IDE console that the programming is started and sits there for 5 seconds, then it barfs some stuff out to the IDEs console about looking for a JTAG programmer, this is followed by a 5 second pause, then it prints out what FPGA it is expecting to see on JTAG, another 5 second pause, then it prints out the ID of the FPGA it actually found on the bus, few seconds later it starts programming and the progress bar actually starts to move from 0% to 100%. Then it pauses for a second and it starts verifying while the progress bar goes again from 0% to 100% but twice as quickly, says its done, then locks up for a second or two before all the setting buttons in the programmer window stop being grayed out and you can continue using it.
...
WHY?!

[Daixiwen]

Probably because it didn't work at first, and the developer started adding random pauses in different parts of the process until it did.
And when it started to work, the manager just said "ship it!" before the developer could use a bit of time to debug and remove the unnecessary pauses.

No, not talking from experience 

[Nominal Animal]

No, not talking from experience 

I've gotten a stern talking to several times, for not doing it that way.

When Linux started to support close-on-exec file descriptors, I immediately wrote my own "fork and run a helper binary" function, that uses a separate close-on-exec pipe for the parent to detect if the actual executable was started or not.  Many think it is overly paranoid, but having the parent process know why a helper process could not be started is very useful to the users – since usually it is a misconfiguration; and the child printing the reason to stderr isn't always acceptable.

The typical solution is to wait a couple of seconds, then check if the child process is still alive (by reaping it if it is dead).  "Good enough!", they say.   

[Sal Ammoniac]

I'm not talking about development tools and hardware--I'm talking about the products themselves.

It's the same thing - TTM is the most important factor nowadays, so there is no time for optimizations.

Yes, unfortunately it is. That practice does leave the door open for companies who do spend the time optimizing things--I've seen examples of this many times in my career where the well-engineered product displaces the quick-and-dirty solution.

[0db]

When Linux started to support close-on-exec file descriptors, I immediately wrote my own "fork and run a helper binary" function, that uses a separate close-on-exec pipe for the parent to detect if the actual executable was started or not.  Many think it is overly paranoid, but having the parent process know why a helper process could not be started is very useful to the users – since usually it is a misconfiguration; and the child printing the reason to stderr isn't always acceptable.

The typical solution is to wait a couple of seconds, then check if the child process is still alive (by reaping it if it is dead).  "Good enough!", they say. 

That's really usefull. Great idea!

[Nominal Animal]

The typical solution is to wait a couple of seconds, then check if the child process is still alive (by reaping it if it is dead).  "Good enough!", they say. 

That's really usefull. Great idea!

NOOOOOOOOOOOoooooooooo_{ooooooooooooooooooooo}

Just kidding, I know you meant the O_CLOEXEC pipe.  I have the parent read from it, and the child ignore it except write the errno to it if it fails.  That way, parent will `read() == 0` if the exec succeeds, and obtain the failure reason otherwise (and can reap the child immediately).

I usually use a version that takes the executable name or path, and an array of arguments.  But, if you want pipe() like features, you can exec `/bin/sh` with `-c` and the command string as parameters instead.

If you make the parent ends of the pipes nonblocking, then one can use a `communicate()` -like function (similar to Python subprocess') to read and write (buffered) data to/from the child process bidirectionally without blocking.  It does not make the other ends nonblocking, so it should not affect the child process at all.  This is very useful for filters and converters and user delegates (running at reduced privileges, perhaps with a seccomp filter blocking most syscalls).

When I've shown my own implementations, even after showing how this avoids executing the shell (efficiency) and any quoting issues (because the parameters are an array) and makes problem tracking much easier (because the parent gets the exact error code if any syscalls in the chain fail), about 67% of the time I get the "why not just use popen()?" question.  Usually with derision.  We don't get raises or praises for writing this kind of robust, low-level janitorial code: it isn't a selling point.

[Berni]

Yeah this does show pretty well with Altium Designer.

There are lots of little quirks (possible bugs or just half missing features) in its functionality that is still unchanged for many years while they keep introducing shiny new features. Sometimes the shiny new features are actually good, but sometimes the way these new features work is done in a weird silly backwards way, showing the feature was clearly the idea of someone who never did PCB layout in his life.

But its the shiny new features that sell yearly subscription licenses or make it seam like the software is worth the hiked up initial license price.

[Nominal Animal]

the feature was clearly the idea of someone who never did PCB layout in his life

This.  This is the core problem in many, if not most applications.

When I create tools, or help others create better tools, observing and learning how people do it is the very first step.  It is crucial.  Then, if you have an user interface specialist or someone with enough analytical and observational skills, you can examine the process, and find ways to make it more efficient.  Then, you design the interfaces needed for humans to efficiently do what they need to do, leaving enough extensibility so that you can enhance the tool when you get real world data on how it works, what works well, and what needs more effort.  Then you write the code.  This works, but it takes a lot more time and effort than just writing out some software that can be marketed for the purpose.

It also kinda sorta explains why free/open source software can have so odd/crude interfaces.  The developers create them for their own needs, their own use cases, and they often have learned the way to do it on their own, and may be far from the most efficient known workflows – but it works for them, and learning anything new is a chore that may not prove worth the effort, so...

I guess here is the difference between programming, computer science, and software engineering, eh?

[SiliconWizard]

I guess here is the difference between programming, computer science, and software engineering, eh?

Not only that, but I think UI design should (in general) not be left to software developers.
Just because you can craft software (even if you can do that well) doesn't mean you can design anything usable.

[NorthGuy]

The developers create them for their own needs, their own use cases, and they often have learned the way to do it on their own, and may be far from the most efficient known workflows – but it works for them

Unlike most people, I don't like doing things graphically with a mouse. I am a programmer, so I prefer writing text files then compile them and watch the result. Long time ago I created a small program to generate PCB traces for the one-sided PCBs which I was doing by myself - for prototyping, as well as different gadgets for my own use. I invented a simple language (although language is too big of a word for it) for this. Then, during the years, as I wanted to do more with it, I was adding new features. So, I added objects, multi-layer, mirroring, auto-bending, gifs, gerbers, bom, length matching etc. I wasn't planning these features, I just added them when I felt an effort of adding a feature would save me a supposedly bigger effort of getting by without it. As a result, I still use it to make gerbers for the PCBs I order. And it works perfectly for me. I can create new PCBs very quickly, and exactly the way I want. So, having software which is designed specifically for you is rather a good thing.

But I'm not delusional, I understand that most other people would rather be dragging their mouse over the screen. So, I'm not trying to push my little software to other people. It will die with me.

[Berni]

There is a good reason GUI applications have become so common.

For some things being able to do stuff graphically is a big advantage. Yes for most programing-ish tasks any sort of graphics are more of a hindrance than advantage. I have yet to see any connect blocks together kind of approach to programing that was actually useful or didn't look like a mess. But when i comes to things that naturally live in multiple dimensions then working on them in a graphical environment is usually much more productive. Things like editing a MS Word document would get really awkward in large complex documents if all you had was HTML-like source code and a command line utility that renders it to a PDF. Especially if you had to do an edit to someone elses document that uses a different coding style. Things like SPICE simulators also have graphical editors even tho the actual simulator part just gets fed an ASCII netlist. These raw spice netlists might seam quicker with only 10 parts on it, but once start putting together very large schematics it all just turns into a unreadable mess, good luck opening someone else's spice netlist with 100 components and understand what it does without actually drawing it out on paper. Similar thing for drawing a PCB using code, im sure it works fine, but doing any large dense board is just going to be time consuming and impossible to make sense of to someone else.  It doesn't all have to be done with a mouse either. You can use as many keyboard shortcuts as you want. For example when drawing my PCBs in Altium Designer i rarely use the mouse for clicking on menus. When i want to measure distance between two things i hit R then M then click one object then click other object. When i want to place down a text i hit P then S then Tab to open the editor, type in the text, hit Enter to close it, then click where i want to put it.

Same reason why a lot of software development environments have a graphical GUI editor where you can just draw buttons onto a window. Its faster than trial and error iterating by changing numbers in code. Same reason why all big game engines have graphical editors bundled with them.

Bringing this back on the topic of FPGAs i do like using the graphical netlist viewers in the IDEs. Okay i don't use schematics to wire up stuff in a FPGA because the schematic editor UI in pretty much every FPGA IDE is straight from the 90s and so horrible that it is indeed faster to use code. But when it comes to viewing the compiled results of my code i do really like to look trough the auto generated schematic. It makes it so much easier to see what goes where and make sure the HDL compiler actually did what i wanted it to do.

But as SiliconWizard and  Nominal Animal said. It is indeed hard to make a really good UI. Any tools i make that do end up having a GUI look like shit, but i don't care because they are mostly for my own use. I knowingly take shortcuts in the GUI design that result in less coding work to implement rather than doing it the best way. Programmers making GUIs often do that without even realizing. So its all too easy to make a crappy GUI that actually wastes time rather than saves it.

[Bud]

Even if we make crappy GUI, there are common principles that if applied, make it easier to use. For instance, logical flow of menus items from left to right, i.e. File menu on the lefthand side of the menu bar is where you start working on a net new document. Help menu on the righthand side since it is an auxiliary item and not often used. But some people make GUIs so unintuitive you have no idea where to begin, as they place the entry menu somewhere in the middle of the menu bar, or worse yet no menu bar but a bunch of buttons, like two dozens of them in a random order.

[SiliconWizard]

I knowingly take shortcuts in the GUI design that result in less coding work to implement rather than doing it the best way. Programmers making GUIs often do that without even realizing. So its all too easy to make a crappy GUI that actually wastes time rather than saves it.

You're making a good point, which is another reason why UI design is best done by non-developers. Not only is that a skill in itself (that many developers don't have), but as you said, most developers will, even if just not consciously, make UI decisions based on how easy or hard it is to implement.

In other words, and to IMHO summarize the current "problem" with software development which is on-topic here, development teams (/management) tend to favor makiing their own life easier (lower dev costs/etc.) rather than trying to make their customers' life easier. They put their own needs above those of their users.

The result is what we have now, with very few exceptions.

[NorthGuy]

When i want to place down a text i hit P then S then Tab to open the editor, type in the text, hit Enter to close it, then click where i want to put it.

People are different. I find it easier to type

Code: [Select]

moveto Target
move 100 100
chars 8 "My Text"
then press the Compile button and observe the results. What's more important to me - I have not only placed the text, I also tied it to the point named "Target", which means that if the Target moves, the text moves too.

or I can type

Code: [Select]

def text_offset_x 100
def text_offset_y 100
def text_size 8

...

moveto Target
move text_offset_x text_offset_y
chars text_size "My Text"
After this, I copy and paste the bottom part 50 times and change the point names and texts - I have placed 50 labels which are all located at exact same relation to their respective targets, and will move with the targets wherever they go. Now I see that the text it to small, so I scroll up and change

Code: [Select]

def text_size 8
to

Code: [Select]

def text_size 10
press the Compile button and observe the results. Or I can tweak offsets in a similar way. In my mind, this saves me lots of time.

I don't know how you change the position of 50 labels relative to their respective targets simultaneously with Altium. I tried such things. You spend time to make sure you click on the text, not on a myriad other things around, then you start dragging. You want to move 5 points directly to the left, but the stubborn mouse wants to move up and down as well, and it takes really long time to achieve good placement. Then you repeat this 50 times. I am really bad at this. Changing the text and compiling is much easier for me. Of course, graphical editing may work better for you. People are different.

[0db]

Long time ago I created a small program to generate PCB traces for the one-sided PCBs which I was doing by myself - for prototyping, as well as different gadgets for my own use. I invented a simple language (although language is too big of a word for it) for this. Then, during the years, as I wanted to do more with it, I was adding new features. So, I added objects, multi-layer, mirroring, auto-bending, gifs, gerbers, bom, length matching etc. I wasn't planning these features, I just added them when I felt an effort of adding a feature would save me a supposedly bigger effort of getting by without it. As a result, I still use it to make gerbers for the PCBs I order. And it works perfectly for me. I can create new PCBs very quickly, and exactly the way I want. So, having software which is designed specifically for you is rather a good thing.

EagleCad has ULP scripting. Which is ok for this.

[Berni]

Then again you also need the right kind of professional UI/UX designers working on it.

For example the UI for Windows fell off a cliff after Win 7 and it still has not fully recovered with Win 10. It was like they are trying to outdo Apple in making things look simplistic, but missed the mark by a mile. Half the menus and UI elements still feel like badly made half finished phone apps.

In this regard i applaud Xilinx for giving there IDE a refresh, it lets them bring it up to spec for what a modern application looks like. The tools from Altera/Intel are still stuck in the 90s and include all the 90s UI quirks. Same for LT Spice.

press the Compile button and observe the results. Or I can tweak offsets in a similar way. In my mind, this saves me lots of time.

I don't know how you change the position of 50 labels relative to their respective targets simultaneously with Altium. I tried such things. You spend time to make sure you click on the text, not on a myriad other things around, then you start dragging. You want to move 5 points directly to the left, but the stubborn mouse wants to move up and down as well, and it takes really long time to achieve good placement. Then you repeat this 50 times. I am really bad at this. Changing the text and compiling is much easier for me. Of course, graphical editing may work better for you. People are different.

Yes this is where the good UI is separated from bad UI

If i need to do mass changes then there is the "Find similar" tool that pops up a window with all the properties of the currently selected object so that i ca quickly generate a search query in a few clicks that selects all the relevant objects or masks them for editing. So i can for example find all text objects on the top overlay layer that use a 2mm high Arial font, then drag a selection box around the ones i want to mess with, then change the size to 3mm for all of them using the inspector window. If i need to generate a bunch of objects programmatically then i create one manually, open the List window, copy the spreadsheet into excel as a starting point, generate a table of objects i want then paste the table back in to have the objects appear.

PCB tools with a crap UI might have you going around and changing the text one by one. Not that Altium has a perfect UI tho, there are plenty of stupid quirks but overall it tends to be better than a lot of other tools.

But i am pretty curious how those PCBs look like since its not easy programming a PCB package from scratch.

[NorthGuy]

If i need to do mass changes then there is the "Find similar" tool that pops up a window with all the properties of the currently selected object so that i ca quickly generate a search query in a few clicks that selects all the relevant objects or masks them for editing. So i can for example find all text objects on the top overlay layer that use a 2mm high Arial font, then drag a selection box around the ones i want to mess with, then change the size to 3mm for all of them using the inspector window.

Do you find it difficult to change a single number in the source text file compared to all these manipulations?

And, if I understand you correctly, if you have any other unrelated labels with 2mm Arial which are not the ones you can change, the tool will find them too, and you would have to manually separate labels into "do" and "don't" categories every time you need to make a mass change. Certainly not as bad as changing one by one, but still a lot of work, isn't it?

[asmi]

People are different. I find it easier to type

then press the Compile button and observe the results. What's more important to me - I have not only placed the text, I also tied it to the point named "Target", which means that if the Target moves, the text moves too.

If you haven't yet, you should give a try to Cadence Orcad/Allegro PCB - everything can be scripted there and/or typed in a command in a command line, I use it a lot when creating footprints.

[NorthGuy]

But i am pretty curious how those PCBs look like since its not easy programming a PCB package from scratch.

This is not a package - a small program - 6k lines of source, 125KB executable.

PCBs look well, although it depends on the manufacturer, not on how you generate gerbers. Here's a screenshot of my program along with the corresponding fragment of the real PCB. This is a 6-layer PCB generated from 12k lines of source, although, as you can see on the screenshot, these lines of code are very short.

Screenshot:



PCB:

[Berni]

Do you find it difficult to change a single number in the source text file compared to all these manipulations?

And, if I understand you correctly, if you have any other unrelated labels with 2mm Arial which are not the ones you can change, the tool will find them too, and you would have to manually separate labels into "do" and "don't" categories every time you need to make a mass change. Certainly not as bad as changing one by one, but still a lot of work, isn't it?

It all depends on the circumstances. Is my cursor already on the number i need or do i first need to find the number in a 800 line long file? Did i have the foresight when doing it to put all the things i needed to change under a single definition? Or do i have to hunt down 3 other definitions to change all the stuff i wanted to change. Or do things i don't want to change also use this same defined number, in that case i need to define a new number and manually go back and update the ones i don't want to change to the new definition.

I personally find i need GUI help even when navigating trough source code. Its alright to start with, but once i have to find my way around a few 1000s of lines of code then i start getting annoyed working with it in a plain text editor. I can no longer remember what each function looks like or where it is. Sure i group things together logically, but that doesn't help when one module of code spans many 100s of lines and i need to find that one thing im looking for in there. So instead i tend to use smart code editors that understand the programing language i use, this gets me autocomplete of function names or variable names (saving me time in not having to remember the exact name, reducing errors due to remembering the wrong name and in some cases saving a good bit of typing), it gives me live preview of a function while i am filling out its arguments, it lets me jump to the definition of a function with just one keypress, a few more let me find all the places where this function is used, a few more let me rename the function while also renaming all references to it in all the rest of the code automatically. I can collapse down parts of code im not working on like a tree. It helps me in finding what brackets go with what by highlighting them. It highlights syntax errors as i type in order to save a few compile iterations due to silly typos...etc

At first i didn't think i need such fancy pants smart code editors, but then i tried a few and afterwards tried to do things without them again, that's when it hit me how clumsy and slow i was with a plain text editor. A normal text editor suddenly felt like soldering with boxing gloves on. Yet i was perfectly happy with one before.

Oh and on the topic of automation. Altium does have scripting support but mostly in the form of Delphi, tho i hear you can use VB or JS too. Did have some fine tweaks for documentation generation done in it but its pretty annoying. As for making footprints, there is a footprint generator wizard that just needs to be told what type of package it is (SMD Resistor, SOIC, TQFP, QFN, BGA...etc) and given a few key measurements from the datasheet, few clicks later it spits out a finished ready to use footprint including a 3D model of the chip placed on top of it. It will do a similar thing for schematic symbols if the datasheet contains a pinout in any copy pastable form. I find these wizards quicker than coding it.

[Berni]

But i am pretty curious how those PCBs look like since its not easy programming a PCB package from scratch.

This is not a package - a small program - 6k lines of source, 125KB executable.

PCBs look well, although it depends on the manufacturer, not on how you generate gerbers. Here's a screenshot of my program along with the corresponding fragment of the real PCB. This is a 6-layer PCB generated from 12k lines of source, although, as you can see on the screenshot, these lines of code are very short.

That does actually look rather neat.

Tho i do wonder how it is wrangling traces around in tight spots with just numbers. As well as how do you keep track of what connects to what on a board of this complexity (I quickly got used to the computer taking care of that for me).

[NorthGuy]

It all depends on the circumstances. Is my cursor already on the number i need or do i first need to find the number in a 800 line long file? Did i have the foresight when doing it to put all the things i needed to change under a single definition? Or do i have to hunt down 3 other definitions to change all the stuff i wanted to change. Or do things i don't want to change also use this same defined number, in that case i need to define a new number and manually go back and update the ones i don't want to change to the new definition.

This is the same as in C. You figure out what to define, and, of course you may make mistakes.

Its alright to start with, but once i have to find my way around a few 1000s of lines of code then i start getting annoyed working with it in a plain text editor.

In this particular case it's very easy. You just click the object and it'll take you to the line where it is defined.

Tho i do wonder how it is wrangling traces around in tight spots with just numbers. As well as how do you keep track of what connects to what on a board of this complexity (I quickly got used to the computer taking care of that for me).

There's no assurance, but the traces go from pin to pin, so it's easy to check. For example

Code: [Select]

layers T
tracewidth TrF
moveto A.T3
trace -20 20
Via
layers S1
trace -120 0
trace -230 -230
trace 0 -60
trace -680 -680
trace 0 -1190
Via
layers T
bendto OHB.In1
You can see how it jumps to the signal layer, then makes few bends, then comes out back to the top and connects to the destination. "bendto" means it goes at 45 degree angle then turns vertical or horizontal and arrives to the object. "angleto" would make it go vertical or horizontal then arrive to the object at 45 degree angle. "Via" is an object which is defined at the beginning of the file as:

Code: [Select]

class Via
  layers T S1 S2 V G G2
  round ViaSize
  hole ViaDrill
end

If the next trace is similar you can simply copy and paste. Then you would need to correct few numbers, but not that much. Say the trace next to the one described above is:

Code: [Select]

layers T
tracewidth TrF
moveto A.T4
trace -20 20
Via
layers S1
trace -20 -20
trace -132 0
trace -218 -218
trace 0 -60
trace -680 -680
trace 0 -1208
Via
layers T
bendto OHB.In2
Of course, a very long and windy trace may take couple minutes to sort out.

[Nominal Animal]

NorthGuy, there is nothing odd in that approach.  Others may find it useful too.

It is the same approach to PCBs as OpenSCAD has to 3D objects, or POV-Ray has to describing scenes to be rendered/raytraced.  OpenSCAD is extremely common for 3D printed objects, because you can easily make them parametric.  POV-Ray is useful when exploring procedural graphics, like realistic trees or grass or such, that have way too much individual detail (sub-objects or bifurcation) to do "by hand".

Just like Graphviz is a superior tool to auto-generating graphs (it too uses a simple language to describe the relationships; its various sub-tools will generate different types of graphs from those relationships), and makes it easy for others to generate graphs from e.g. internal structure of their programs or their data structures, or even e.g. website navigation charts (I've done all three), making it a valuable development tool; given a suitable interface, some enterprising developers might experiment with different algorithms for auto-routing for yours. (It is not that easy to experiment with this stuff in existing EDA packages like KiCAD, because examining exactly how the generated net is "bad" is a critical part of the development, and you need the coordinates in human-readable form for that – AIUI autorouter developers use their own "test-benches" for this, and that adds to the initial hurdle of developing new autorouting schemes.)

[Berni]

Ah so it does have a bit of interactivity to it.

It does look like a nice compact language. I can see this making a lot of sense for digital circuitry that typically goes directly from pin to pin. But for analog stuff that tends to branch a lot, there i don't think i would be able to follow along the text without having the schematic on paper in front of me. Especially since i tend to mangle analog circuitry PCB layouts in to a shape very different than the schematic in an attempt to squeeze it together into a smaller area of the board or avoid vias.

Certainly a good approach in making a simple compact PCB tool.

But still i don't think such text based editing would be faster than a well made GUI all together. Where text might have an advantage is being more flexible, like if you suddenly want hexagonal shaped via pads for some reason, while some GUI PCB packages might not support that, so making it happen would be a clumsy manual hack there.

[0db]

OpenSCAD

bah, I have seen it a lot of times, and every time I talked with a mechanical engineer, he/she told ... pfft OpenSCAD. They seem to prefer tools with a GUI.

[Nominal Animal]

OpenSCAD

bah, I have seen it a lot of time, and every time I talked with a mechanical engineer, he/she told ... pfft OpenSCAD. They seem to prefer tools with a GUI.

That's mostly because they either have the components in their CAD programs, or because they can do prototyping on real metal using CNCs.  It's a different niche.  OpenSCAD is for those who know what properties the object needs, but not necessarily exactly what shape that is.  Rather interesting, eh?

[NorthGuy]

It is the same approach to PCBs as OpenSCAD has to 3D objects

Great. Thank you. I like it. and 0db's reaction prove the point I had all along. There are many approaches, which have different flows and different GUIs. Different people prefer different interfaces and different flows.

[NorthGuy]

I can see this making a lot of sense for digital circuitry that typically goes directly from pin to pin. But for analog stuff that tends to branch a lot, there i don't think i would be able to follow along the text without having the schematic on paper in front of me.

You're absolutely right. I only do digital. Even interfaces to ADCs are still digital point-to-point traces. Branching is rare and often trivial, such as in power distribution or pull-ups. I don't know how would it fare if I had to build a big amplifier with lots of transistors.

[0db]

It's a different niche.  OpenSCAD is for those who know what properties the object needs, but not necessarily exactly what shape that is.  Rather interesting, eh?

I would also consider Pro/E, Blender, Maya and Wildfire.

In particular Blender and WF have some scripting capabilties.
Somethink like the ULP scripting we can find in EagleCad.

Not to bad as "GUI-oriented but with scripting capabilities" 

[NorthGuy]

Not to bad as "GUI-oriented but with scripting capabilities" 

These are different approaches which cannot be combined. Either you write the source and the tool uses it, but does not touch it. Or the tool maintains the source in its own format and you use the tool to modify the source.

[0db]

These are different approaches which cannot be combined.

In EagleCAD, you can make circuits without the GUI, just typing commands on the console, you can make circuits with the GUI, and you can also write ULP scripts to parametrize certain actions, like BOM? Labels adjustuments? or even making parametric components, like copper pcb resistors? copper pcb spirals? copper pcb flat motor inductors?, you write the script, job done; and not only you can use the script in graphic mode, but you can also define a button in your 3D mouse to call the right script on demand!





Yesterday I wrote a script to created the stuff I am talking about. And in 1 second it made a copper pcb resistor, a wire of 20000 meters mm of length twisted several times to stay in 20x60mm of area. Its attributes are all parameters filled in a GUI that I wrote inside the script itself.

If you do it by hands, designing that long copper pcb resistor will take more time, and if you do a mistake with some of the parameters, or if you change your mind about its properties (too low resistance? too high resistance? too big area?),  you have to delete an go back to the beginning of the whole process.

ULP also allows you to operate with the routing algorithm, and this means you can implement your own routing strategy for certain weird components.

Maya, Blender,  (Pro/E) Wildifire do the same but for the mechanical stuff.

I don't know what KiCad offers.

edit:
typo

[NorthGuy]

Yesterday I wrote a script to created the stuff I am talking about. And in 1 second it made a copper pcb resistor, a wire of 20000 meters of length twisted several times to stay in 20x60mm of area.

Even with 0.05 mm trace width/spacing, you can only fit 20x60/(0.05*2) = 12000 mm = 12 meters of wire into that space. 20 km would require 1667-layer PCB, not counting the space for vias.

I guess you could've created a script which produced the whole PCB, which would then be compiled into Eagle's brd file and then to gerber by the second pass. But how would you combine this with GUI? Whatever changes you made to PCB with GUI wouldn't change your script. And vise-versa - as soon as you pass the result of your script and edit it with GUI, any changes you make to the script won't affect it any more.

[0db]

But how would you combine this with GUI? Whatever changes you made to PCB with GUI wouldn't change your script

You use a text notepad to change the text of the script, and you use the GUI to apply the script to the pcb, to the schematic, or to the library. The GUI simplifies how you apply the script. E.g. you can select group, use the 3D mouse to zoom, rotate, and select/deselect all the items to be passed to the script.

[0db]

20000 meters

it's 20000 mm not meters. Typo.

[NorthGuy]

You use a text notepad to change the text of the script, and you use the GUI to apply the script to the pcb, to the schematic, or to the library. The GUI simplifies how you apply the script. E.g. you can select group, use the 3D mouse to zoom, rotate, and select/deselect all the items to be passed to the script.

Your script simply extends the capabilities of the GUI. It doesn't change the principle.

[0db]

Your script simply extends the capabilities of the GUI. It doesn't change the principle.

It's not "my script", it's how EagleCad, Wildifire, Maya, and a lot of tools do thier job.

And I have never written it has to change the principle.

It's always the same principle, although things have improved a lot.

Pro/ENGINEER 1 - 1987
Pro/ENGINEER 14.0 - 1994

Before 1995, Pro/E only had limited GUI features, therefore you had to know things manually on the console. It meant you have to master solid conceps about linear algebra, geometry, and tensor calculation. This in order to extend the capabilities of the limited GUI.

[Nominal Animal]

Your script simply extends the capabilities of the GUI. It doesn't change the principle.

It's not "my script", it's how EagleCad, Wildifire, Maya, and a lot of tools do thier job.

And I have never written it has to change the principle.

But I did, kinda sorta:  it is a different approach.  That's the key point here.

Lets compare OpenSCAD to say Fusion 360.  Fusion 360 lets you parametrically define the features of the objects, and create objects parametrically.  OpenSCAD generates objects and collections of objects using a simple language based on solid geometry; the language isn't even procedural, although it has loops and such.  For individual features or sub-objects, you can create modules.

What's the difference, then?

In one, if you find your commands or script didn't do what you wanted, you delete and rewrite it.
In the other, you simply modify part of the description of the modeled system.

The same difference exists between SVG and other vector formats used on the web, like web fonts.  SVG is verbose and human-readable, but it is also modifiable in real time by Javascript on the web page; not so for web fonts.

The core difference I am trying to convey here, is that in EagleCAD etc., the scriptlets produce objects as if they were created by hand in the GUI.  If you rerun the scriptlet, you get another object.  The scriptlets are essentially macros for human GUI actions played back at amazing speed.
In OpenSCAD and NorthGuys PCB program, the script actively describes the objects; by modifying the script, you modify the object.

Why isn't the latter implemented in GUI-based tools?

Because it is rarely possible to translate the human actions via the GUI back to the underlying script describing the objects.

It is possible for 2D (demonstrably; Inkscape does it that way, and even allows you to modify the source by hand during editing), and it is possible for solid geometry in general, but usually the "human by hand" and "generated via GUI" are very different, for a number of reasons.

(As an example, even Inkscape has a "Save as Optimized SVG" mode, which more closely resembles how humans and efficient scripts generate SVG code, but the end result lacks many of the niceties of the default/GUI-generated objects, like rotation centres, often layers, and so on.  I personally tend to even fine-tune that further. And it isn't hard to crash Inkscape by careless modification of the underlying XML code either.)

This means that a tool which used an underlying domain-specific descriptive language exposed for user editing to describe the work at hand, but allows simultaneous modification to the underlying language by hand and via the GUI, is going to have to make compromises that make no sense to users that use predominantly one approach over the other.

That does not mean one is superior to the other: it depends on how the tool is used.  The root principle, or paradigm.

You well know the idiom "if all you have is a hammer, all problems look like nails."  As I've already told you, asking dozens of "house frame-builders" (who predominantly use a hammer and a saw to make the wooden frame, in this analog), you for sure get the answer that screwdrivers and industrial adhesives are meh because a hammer does the job much faster and easier.  OpenSCAD in particular solves a different problem than Fusion 360: it lets one describe the object needed via solid geometry, and it'll show you how it looks like; whereas Fusion 360 lets you design any object with set constrains that you can imagine.

While designing a PCB is seemingly a single problem, NorthGuy has already mentioned they wouldn't use their own tool for analog designs; and rather created it to simplify working with a specific type of digital circuit (to simplify, lots of pins and simple traces).  If you think about it, that actually makes sense to describe using a simple language.

A good example is a circuit I've been playing with recently: a simple Arduino-programmable display module accelerator.  An ARM microcontroller in QFP64/LQFP64 package with 22 or so pins connected to a display module, and the rest of the I/O pins exposed as a pin header, with a crystal/resonator, bypass capacitors, and maybe a 5V-to-3.3V LDO or DC-DC converter on the board.
There are 16 orientations for the microcontroller with respect to the display module flex connector pins: 4 aligned and 4 diagonal on the same side of the board, and 4 aligned and 4 diagonal on the other side of the board.  The flex connector pins are basically the only thing fixed on the board, everything else is up to me.

To be honest, I'm very tempted to write a simple Python program to investigate those 16 orientations, to find out how many trace crossings each one involves, and whether there is a simple two-layer solution – i.e., to qualify each of the 16 orientations before I really start looking into how to draw the traces.  It is easier for me than trying to do all 16 in an EDA, or even to just pick one and work it through even if it is sub-optimal.

When I know which one has least problems, I'll be quite happy to use any GUI EDA tool – I like EasyEda – to design the actual board.

(Also, I know that if someone has read this far, they have ideas on how to accomplish this using their own favourite tools.  That is perfectly okay, but it is important to realize that having a favourite tool does not make it optimal.  And just like there are *lots* of say woodworkers using only hand tools, it is perfectly okay to use the tools you like; but it isn't okay to use that as a basis for claiming there is no need for any other kinds of tools, or even that you can do everything those other tools can do with your own favourite ones, because the underlying preference is dependent on personal features and varies from individual to individual.  It is, however, perfectly okay to tell how oneself likes to do those things using their own preferred tools, because that can give others new ideas without asserting a comparison between tools, and we all stand to gain.)

[NorthGuy]

You well know the idiom "if all you have is a hammer, all problems look like nails."

I'm a programmer. Everything looks like a program to me

[coldfiremc]

In This thread we figured out what stuff is bloating Vivado. Pls check

https://support.xilinx.com/s/question/0D52E00006hpOUpSAM/vivado-installation-is-at-least-14-gb-too-large?language=en_US


Also don't forget to make more noise commenting or giving some likes. The installer is flawed, just that

[coldfiremc]

Vivado is not slow because of tcl or scripting languages, is just slow because the implementation is crappy. The IDE just talks to the console polling files. Also, the console talks to executables just using a pipe. Is kind of primitive. A better approach would be to make binary executables as modules, like in Xcircuit

[pbernardi]

Last time I dared to download a recent Vivado version, it lasted around one hour in my computer before I uninstall it. Really useless stuff: big, slow, unusable. 

I am amazed of how good are older software compared to newer versions. I use Vivado 2018.3, but only because it has support to the FPGA family I use, and personally think ISE 14.7 was much better in general. With Vivado, I learned that I must not, in any case, ever, try to use the embedded text editor because it simply does not work for real codes. Once I realized this, my life changed and I could smile again, and since then I find Vivado 2018.3 a palatable software.

And this happens not only for Vivado or Xilinx, for most software available. When I want to use some stuff without restrictions, ads or even when I want a better software I just look for older versions. I am almost never disappointed.

[SiliconWizard]

This is often the case indeed, but not always. Lattice tools are IMO an exception. Both Diamond and Radiant are simple, unbloated (relatively...) and fast. Newer versions tend to be better rather than worse. Now this may change, if, like others, Lattice suddenly decides to rewrite Diamond with a brand new team and brand new language, but I don't think it's gonna happen anytime soon. They seem to be focusing on Radiant for their newer parts, Radiant is still relatively "new" (so I doubt they're gonna rewrite it completely for many years to come) and was a decently good surprise when they released it.

Of course none of these two are as complex or as featureful as Vivado, though. Lattice tends to use a different path - standalone applications for special features, instead of cramming it all in a single one.

[coldfiremc]

If you turn off sigasi Syntax checking, goes way better

[pbernardi]

If you turn off sigasi Syntax checking, goes way better

That´s true. However, then I need to check logs or files to look for errors.

And if I need to do this, what is the benefice of using the Vivado text editor? I mean, I have to disable the only useful feature because it turns my job is painfully slow. Better to use any other IDE instead.

[coldfiremc]

If you turn off sigasi Syntax checking, goes way better

That´s true. However, then I need to check logs or files to look for errors.

And if I need to do this, what is the benefice of using the Vivado text editor? I mean, I have to disable the only useful feature because it turns my job is painfully slow. Better to use any other IDE instead.

You can use check_syntax from tcl console. Is faster than elaborate

[coldfiremc]

Last time I dared to download a recent Vivado version, it lasted around one hour in my computer before I uninstall it. Really useless stuff: big, slow, unusable. 

I am amazed of how good are older software compared to newer versions. I use Vivado 2018.3, but only because it has support to the FPGA family I use, and personally think ISE 14.7 was much better in general. With Vivado, I learned that I must not, in any case, ever, try to use the embedded text editor because it simply does not work for real codes. Once I realized this, my life changed and I could smile again, and since then I find Vivado 2018.3 a palatable software.

And this happens not only for Vivado or Xilinx, for most software available. When I want to use some stuff without restrictions, ads or even when I want a better software I just look for older versions. I am almost never disappointed.

2021 is way faster than 2018/2019, but sigasi by default on is not helping to make it shine