Hate Verilog? Detest VHDL? You're not the only one. Xilinx rolls out easier-to-use free FPGA programming tools after developer outcry If you hate writing Verilog, VHDL, and other hardware design languages, used to craft computer chips and configure FPGAs, you're far from the only one. This Register vulture wrote Verilog for gate arrays in the early 2000s, and how did that work out? He ran screaming into the, at the time, more exhilarating world of journalism …
Easy to use but inefficient software as a boost to hardware sales is nothing new.
It might be interesting to see how inefficient it is, how much more hardware it needs to get all but a couple of optimized jobs done, and how much easier it is to use for various types of users.
If it's good, it'll help with the basic tradeoff - in security we call that one usability vs security - usually it's nearly a perfect trade between one and the other. The real goal is to increase the total (for which I've overloaded "dynamic range") - so, more usability with equal or better security, or more security without losing usability.
This is an analogous case - if it truly increases the "dynamic range" - it's great. Else, remember, code is an NRE - you pay once. Hardware is pay per sale.
Yes, you have to change your thinking fairly seriously between CPU programming and FPGA (or for that matter any hardware).
So far, I've not seen great examples of automatic parallelization translators. It's a hard problem to just generalize, and if they've managed, it has applications far beyond mere FPGA tooling.
Else why do many many programs on even this Linux box just use up 100% of one core...it's not like no one has the source, and if such a tool existed - even between relatively like domains - they'd all scale to more cores, right?
Time to market might matter for some things than others. Until one recent fiasco, it was considered a fatal flaw to need to reboot something during a fighter airplane takeoff -
I did both hardware and software design and realization for boxes that didn't have a reset button - that was a service call at minimum. Lots of 9's. Not all problems are just the most common web-monkey stuff. Forget "ship it and we'll promise to update later" for some things. Especially the ones that matter, vs the froth intended to collect VC money.
Where life is on the line - the medical biz - you'd hope that somewhat more care was taken than for some social media "killer app" (could be a vain hope of course).
Where life is on the line - the medical biz - you'd hope that somewhat more care was taken than for some social media "killer app" (could be a vain hope of course).
Not so vain. I've got friends in the medical device biz, and coworkers who used to work at the biggest names in the biz, and I can say that the amount of care they take is both amazing and frustrating. From architectural chip sims where even changing the slightest thing requires approval from 3 levels of management, to simulations where even 9-sigma design margins have to pass, to years and years of measuring lead wire designs in various configurations, aging conditions, etc are required.
We'll turn a new chip in 9 months in a new technology and get something to work and release it a couple of months after that.
It'll take 7+ years to make the smallest change to a pacemaker, much longer if there's any change to something like the silicon inside it. And you know, I think I like it that way.
But there are times that it's frustrating to see how conservative the FDA is. There are biohackers who are taking old Medtronic insulin pumps, rooting them, then connecting them to blood sugar monitor watches and making an "artificial pancreas" where the monitoring a correction of blood sugar is automatic and far superior to the way things are done now (not controlling blood sugar well leads to damage that accumulates over time, and the closed loop feedback minimizes time that blood sugar gets too high, as well as eliminates the risk of it going too low and the person going into shock or a coma, which is even more dangerous) . In fact, one of the board members of the JDRF, the main Type I diabetes research foundation, does just that and is extremely pleased with the results. But Medtronic and the other manufacturers are moving very, very slowly on that path because of the FDA and concerns that they would be "practicing medicine" if they do more than provide information and be far more liable if something went wrong. The engineers would like to get a prototype system out there for those willing to take a chance, but the regulatory system and management are pretty firmly against it. Management is mostly doctors, and the regulators want well structured test groups, double blind studies, constant monitoring, human subjects regulations followed, etc. In other words, it'll be a long, long time before the public gets something through them, rather than engaging in the hacking subculture now going on in the diabetes community.
Time to market matters but if you can not debug your design then how quickly you got to gates does not matter one iota. Software development tools permit straight forward debugging techniques. Not so with logic designs, and especially not ones from C/C++ which actually make the problem 10-100 times worse!
"...if you can not debug your design then how quickly you got to gates does not matter one iota."
In my book, "time to market" includes ironing out the biggest bugs. And the kids will be able to use these tools to do that. Yes, they'll miss or dismiss the more subtle bugs. But the management will be happy. And the more talented ones will learn the lower level stuff.
Nearly all my work ends up as an ASIC, so I need to a language that I can send to the Wafer Wizards, or convert to something they understand. Plus I need compatibility with FPGAs made by someone other than Xilinx.
But I might not move to a new language anyway. I've been cranking out VHDL for 20 years now and started with Ada a few years before that. As bad as it is, its still the devil I know and can work with.
I've also seen far too many fiascoes caused by companies declaring that they have created the new 'end-all and be-all' of languages, and, at best end up with yet another language programmers have to deal with in addition to the stuff they already need to work with.
Vivado HLS - which I assume is the language in question - has been around for several years now. It's very good at getting area efficiency close to that of RTL code.
However... it's a C (or C++) based language that, to be efficient, requires a coding style rather different from CPU code.
And Intel's FPGA HLS (which is C++ based, mostly, and without STL) also demands that you write the code in hardware-description patterns. The Intel HLS emphasizes throughput over area efficiency
As things stand, HLS designs are unlikely to be portable between the two vendors.
I have heard an RTL engineer say that the main use of HLS is rapid prototyping of hardware designs; having settled the hardware architecture it is still best to write the final code in RTL.
My experience so far working with HLS and P4 is that Xilinx tools crank out the code very quickly for the result but it is close to impossible to debug what is going wrong with out months of guess work. If your *entire* design is made with one of these languages then okay. Hook up custom code around that core and you are screwed if things do not work.
Mostly with an FPGA you are simulating hardware. If there is volume it will be automatically translated to an ASIC, which optionally might have a standard CPU core.
Verilog looks a little like C, except it's not a programming language, it's a HARDWARE description language. More obvious with VHDL. The design becomes a configuration. It's not a program executed at runtime.
So a C like actual programming language is only going to be appropriate for one part of the FPGA design and has to be translated to a hardware configuration. This is a bad idea.
Far better is designing a custom cpu like "machine" that executes a separate runtime program, written by a programmer. I think this tool is for people unskilled to design FPGAs. FPGA design isn't programming. Pretending it is programming is daft. It's hardware design using a specification language instead of a schematic. I've used FPGA DSP and Scilab to develop the DSP filter tables which are imported and FPGA simulated by a Xilinx tool. Then at run time these the design and coefficients are loaded from Flash to the FPGA. If replaced by an ASIC (massively lower power) the filters would be defined in silicon and the coefficients would still be loaded from Flash to RAM to allow updates or changes to the DSP performance / filter etc.
Verilog looks a little like C, except it's not a programming language, it's a HARDWARE description language. More obvious with VHDL.
I think that that concept is the hardest to communicate to folks coming in from a traditional software framework.
For an HDL, you get the concept that, unless you specify otherwise, everything runs in parallel, which is hard to communicate to a non-hardware person. And in VHDL in particular you can blow out the size of your design if you're not careful to specify how you create your states and wind up generating far more hardware than you expect. It was one of my bigger complaints about VHDL versus Verilog. In Verilog you are much closer to the hardware and it tends to be a bit harder to be stupid about what you're doing in terms of hardware utilization. At the system level Verilog is harder to deal with, and VDHL is a better choice, but neither of them fit the traditional programming paradigm at all.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
