WTF Xilinx

[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.