234 karma · joined September 7, 2012
I wonder what AI will do to RTL/verification, the rigid nature of VHDL may be a better target for AI than Verilog.
No sane hardware engineer would want randomness in their simulation unless they get to control it.
It's also the most used language for FPGA in Europe but that's probably mostly cultural.
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.
https://www.amd.com/en/newsroom/press-releases/2024-5-21-amd...
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 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).
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.
And the flexibility of the type system and the advanced type inference.
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.
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++.
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.
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.
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.
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.
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.
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.
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'.
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.