HN user
VHDL mostly lost the ASIC consumer market and for some that's the only market that matters, but the hardware design ecosystem is much bigger than that.
I wonder what AI will do to RTL/verification, the rigid nature of VHDL may be a better target for AI than Verilog.
(System)Verilog has delta cycles too you know, they call it an event queue, but it's basically the same. It's the direct variable updates that happen outside of this mechanism that cause all the issues. Imho it was a poor attempt at simulation optimization, and now you can't take it out of the language anymore.
It's important to have deterministic simulations and semantics that you can reliably reason about. Both VHDL and SystemVerilog offer this to some extent, but in the case of (System)Verilog the order of value updates is not as strictly enforced. In practice, this means that if you switch to another or a newer simulator, suddenly your testbenches will fail. The simulator vendors love this of course. This hidden cost is underestimated.
No sane hardware engineer would want randomness in their simulation unless they get to control it.
VHDL still dominates in medical, military, avionics, space etc. and it's generally considered the safer RTL language, any industry that requires functional safety seems to prefer it.
It's also the most used language for FPGA in Europe but that's probably mostly cultural.
And I wish you read the article, you're comments are completely off topic.
Jim was involved in the early versions of Zen & M1, I believe he knows.
Apples M series looks very impressive because typically, at launch, they are node ahead of the competition, so early access deals with TSMC is the secret weapon this buys them about 6 months. They also are primarily laptop chips, AMD has competitive technology but always launches the low power chips after the desktop & server parts.
Microsoft recently announced that they run chatgpt 3.5 & 4 on mi300 on Azure and the price/performance is better.
https://www.amd.com/en/newsroom/press-releases/2024-5-21-amd...
AMD is already competitive on inference
Any sensor that captures a ton of data that needs realtime processing to 'compress' the data before the data can be forwarded to data accumulator. Think MRI or CT scanners but industrially there are thousands of applications.
If you need a lot of realtime processing to drive motors (think industrial robots of all kinds), FPGAs are preferred of micro-controllers.
All kinds of industrial sorting systems are driven by fpgas because the moment of measurement (typically with a camera) & the sorting decision are less than a milisecond apart.
There are many more, it's a very 'industrial' product nowadays, but sometimes an FPGA will pop up in a high-end smartphone or TV because they allow to add certain features late in the design cycle.
The transformer engine is a fairly recent development (april this year I think) so I don't think they're very far behind.
They have improved their software significantly in the last year, but there is a movement that's broader than AMD that wants to get rid of CUDA.
The entire industry is motivated to break the nvidia monopoly. The cloud providers, various startups & established players like intel are building their own AI solutions. Simultaneously, CUDA is rarely used directly, typically a higher level (Python) API that can target any low-level API like cuda, PTX or rocm.
What AMD is lacking right now is decent support for rocm on their customer cards on all platforms. Right now if you don't have one of these MI cards or a rx7900 & you're not running linux you're not going to have a nice time. I believe the reason for this is that they have 2 different architectures, CDNA (the MI cards) and RDNA (the customer hardware).
If you're looking for fair comparisons don't ask nVidias marketing department, those guys are worse than Intel.
What AMD did was a true comparison, while nvidia is applying their transformer engine which modifies & optimizes some of the computation to FP8 & they claim no measurable change in output. So yes, nvidia has some software tricks left up on their sleeve and that makes comparisons hard, but the fact remains that their best hardware can't match the mi300x in raw power. Given some time, AMD can apply the same software optimizations, or one of their partners will.
I think AMD will likely hold the hardware advantage for a while, nVidia doesn't have any product that uses chiplets while AMD has been developing this technology for years. If the trend continues to have these huge AI chips, AMD has a better hand to economically scale their AI chips.
refers to scalability of the syntax
And the flexibility of the type system and the advanced type inference.
Well you're wrong, you can't run VS Code on the cloud.
There are many examples: a pci-express bus or an application optimized ddr controller or a full tcp/ip stack or a caching/prefetch system or any advanced processor with feedback .... these kinds systems require precise control.
It can be done but all the advantages of HLS are gone. The code is filled with a ton of pragmas that make the code unreadable and a lot longer than the VHDL or SV equivalent.
Register-rebalancing (other companies call it retiming) is a very old technique. You can do it with SV & VHDL, just add delays & the synthesizer will know what to do. Vivado has caught up with the solutions from Altera but there are better (more expensive) synthesizers that easily beat both, the have supported this feature for at least 15 years.
Where did you get %20 percent number?
I get the 20% number from a real world case, guys who converted a huge existing vhdl design into HLS with the help of several Xilinx FAEs, the application was ideal for HLS.
On the other hand, if you write code in a way that naturally maps to the hardware you are using then the results can be every bit as good RTL
You only believe this if you're deep in the Xilinx marketing bubble. HSL covers maybe ~20% of the usecases of FPGAs. Even the guys who teach HLS will not tell you it's a general solution.
I think that this has more to do with the quality of the current compilers, not some inherent limitation with the concept.
This concept has been researched for more than 25 years, C to FPGA has failed except for the aforementioned case. Btw, I'm not saying that a general high-level synthesis solution isn't possible, I'm saying that it should never be based on C or C++.
This is a very old (I think > 15 years ago) competition, the results say nothing about the situation today, both language have changed a lot.
It was a PR stunt by the Synopsys guys who a that time wanted to kill VHDL. The VHDL guys had to work with slow & broken VHDL simulators. The the problem was devised by verilog enthusiasts. All VHDL engineers who showed up (in much smaller numbers than verilog engineers) felt like they they didn't have a fair chance.
Let me guess, you were downcasting everything to std_logic_vector? If you have to cast things all the time in VHDL you're not using it correctly.
But please enjoy (System)Verilog with it's random often undefined coercion, implicit wire declarations, non-deterministic simulation and lack of any meaningful compile-time checks. Honestly, as a huge Haskell fan, I can't believe you're a Haskell fan.
The verbosity of VHDL isn't 2x it's more like 20% bigger on average and since VHDL 2008 it's pretty much the same. VHDL can be wordy but it also reads a lot easier & it looks more structured.
Verilog isn't C, it's C-ish, just different enough to make me make mistakes all the time like 'not' in verilog is '~' instead of '!', or the lack of overloading, the weird rules with signed & unsigned numbers and the implicit wire declarations etc. Verilog is full of surprises.
Do you like determinism? Have you ever tried running the same (System)Verilog design on multiple simulators? Almost every time you get different results, VHDL doesn't have this issue.
No they haven't and they are not even close.
OpenCL is a bad language for synthesis. The strength of an FPGA is deeply-pipeline-able sequential algorithms. C-based languages just aren't good at expressing/controlling pipelining, so the synthesizer/compiler has to infer this but that problem is too hard. You could change 1 line of code, a minor fixup and the clever optimizer fails and your design is suddenly 10x as big.
VHDL is an old version of ADA combined with a build-in discrete event simulator. The syntax, type system, general semantics are all copied from ADA.
This is actually a good thing, Verilog (and even more SystemVerilog) is designed by people who don't have a clue about language design resulting in an incredible mess of a language.
Be honest though, HLS works well for DSP-like applications, not for anything else. Not every digital design is image processing and if it works well you're still sacrificing ~20% of your LUTs.
I'm surprised that you found it to be inconsistent. Care to give some examples?
How could that dirt be worse than what we have/had on Trump? Does it even matter?
We're 2017, VHDL 2008 was released 9 years ago, and this book is using VHDL 93.
Go is a language that is a bit tedious to write, no doubt about that, but it's very easy to read. I spend a lot of my time reading other people's code and I really appreciate that.
Figuring out 1000 lines of code that could have been 10 and verbosity caused by a lack of generics is not going to help you understand code quicker. Figuring out what 10 lines of Scala do may take more time compared to 10 lines of go, but that's not a measure of velocity, the information density of go is just too low. At least 10 lines of scala fit on my screen, 1000 lines of go don't.
Code style issues imho are a team issue, if you do reviews these issues can be managed.
not all of us are unaware of the amazing "progress"
Look at Rust, at least they did their homework. With Rust out there I can't see any reason to use Go except maybe their crappy GC.
though I find the syntax aesthetically offensive
Well that's indeed your opinion, whenever I write code in a language with old fashioned statements I die a little inside. I have a lot of experience with ADA too, at it's core it's still a procedural language prohibiting good abstractions, it's very safe but also extremely verbose.
I learned Scala after I learned Haskell, ~7 years ago, maybe that's why I had a different experience. Since I learned haskell I think in types & transformations, it has made me a much better programmer. Clojure has sortof the same mindset, but I would call it 'shapes & transformations'.
It's funny that both java & c# seem to be picking up many scala features in their latest & future versions like traits, lambdas, tuples, pattern matching, case classes, closed hierarchies, declarative generics... Your language isn't incoherent if you can build features on top of each other with is exactly what scala does.
The way you describe your experience with Scala makes me think you only had a very superficial look at it.
At it's core Scala is very simple & the syntax is very regular, far more than Go or Java and a lot less complex than C++. It's the most expressive typed language on the JVM, so if you like to think in types & you're on the JVM it's your best option.
Clojure is untyped, I hear many people praising it but I don't know any big project done in Clojure. So if you're doing short-lived projects I'm sure it can shine but for software that will be around for more than 5 years I would stay away from it. Btw, if misused, just like Scala, Clojure code can be extremely cryptic.
Go likes it's superficial simplicity, syntactic irregularity & stubbornly refuses to accept that PL design has evolved since the 80-90ies, but I'm sure it's appealing to people who are used to languages from that era.