I probably will soon since you took the time to show up. :) I think what I'll do is form a list of questions to assess the nature and capabilities of your method. These will represent what a lot of different kinds of people would ask. Then, your answers might get packaged up in FAQ's, blog posts, whatever that clarify things for more people than just me. How's that sound?
That's like saying that buffer overflows are not due to how strings are represented in C. Yes a bug is the programmer's fault, but languages can make it harder to have bugs in the first place (for instance you can't have buffer overflows in any other higher level language than C).
In the case of the hardware industry, we see a language with a weak type system (Verilog). So the "solution" is to use lint tools to check that your design is properly typed. Similarly, nothing in VHDL/Verilog prevents you from accidentally creating latches, or crossing domains badly, or many other small bugs. So again, the "solution" is to do extensive verification. That's the Haskell VS Python debate: you can either make it impossible to have a certain class of bugs (and detect them very early), or you can just write a lot of tests (which, in the case of hardware, take forever to run).
The same logic extends at a higher level. You can have a language that models common patterns (like a synchronous loop, a "ready before valid" port) so you can reduce the amount of verification needed because you don't need to always re-verify everything. One could even argue that having such higher-level mechanisms would also make static verification easier, since you might reason in terms of transactions rather than updates to registers.
Latches are caught by the synthesis tools generally. Designers usually run a unconstrained synthesis as a matter of course to determine whether they have written junk.
As for the other bugs, I look forward to this new paradigm of spotting them early without verification effort.
Reasoning about transactions is already how verification works. It is transaction based. UVM is a library of SystemVerilog classes aimed at abstracting the verification to higher levels.
> For an engineer it does not matter about the language that describes the circuit. [...] Typing it in is the easiest part.
Well... once upon a time, people were writing software with assembly, and they probably didn't care about the number of lines either. After all, typing was easy, in fact the only problem was just porting your program to a different architecture :-)
You talk about the complexity of a SoC, and you are right it is complex. But software is complex, too: an application relies on hundreds of millions of lines of code, counting everything between the hardware and the application (OS, network stack, HTTP server, all libraries, database, etc). So how do software engineers manage all that? They use better languages than assembly. Because what matters is the performance/expressiveness ratio (which is why C is still relatively popular) and how hard it is to shoot yourself in the foot (which is why C is not as popular as it once was :D).
> They are all toys aimed at newbies. They address problems that are no problem at all to a qualified engineer in the profession.
I think this kind of attitude is one of the main problems of the hardware design industry (the other one is the conservative mindset). Today's beginners could be tomorrow's hardware designers, instead they switch to software because the culture is much more open and friendly. Besides, you know what they say about asking users what they want: if Henry Ford has asked his customers what they wanted, they'd have asked for a faster horse ;-)
> So how do software engineers manage all that? They use better languages than assembly.
Well, better languages than assembly, yes, but the situation is not so simple. In the past 40 years or so in the software industry, there were two, and exactly two, language-related major productivity leaps in the production of "serious" software: C and Java. Java didn't add too much in expressivity over C (in fact, it added less than C++ had), and neither did C add a lot of expressivity over assembly (more convenient syntax but not too many new abstractions) -- but both added a lot in terms of safety, modularity, portability and the like.
The problem is that we haven't been able to make yet another significant jump. Much of current PL research focuses on expressivity and proof of correctness -- two things that aren't the really painful problems for the software industry these days, and aren't what made C and Java such productivity boosters, either. In both cases, productivity was enhanced not through some clever language syntax design, but through the ecosystem the language supported (i.e. extra-linguistic features).
Yes, some other languages like Ruby added some productivity benefits, but mostly in the "toy" application department -- the same kind of applications people used to use MS Access or VB for, or other "application generators" prior to those -- and you see Ruby shops transitioning to Java as they become "serious". The thing is that with modern hardware, even toy software projects are quite usable, but this isn't the case with hardware design.
Good point about the reasons of productivity leaps. Funnily enough, I recall that one of the main selling points of Java was portability (the famous "Write Once Run Everywhere"), even though C was already supposed to be portable; but the environment wasn't, and you still had to develop OS-specific code.
Anyway, yes I agree the ecosystem is key. This is why a lot of new languages are either running on the JVM (like Clojure and Scala) or are interoperable with C (like Rust and Nim). In other cases, languages have managed to create an entire ecosystem very rapidly (Node.js and Javascript in general, Ruby and others).
> The thing is that with modern hardware, even toy software projects are quite usable
You're right. I must admit I'm not a big fan of this "throw more at the problem" approach, and I wonder for how long this approach will work. After all, Moore's law is slowing down, as the unit cost per transistor has stopped decreasing after 28nm.
> but this isn't the case with hardware design.
Yes, for one because if you design hardware that is sub-optimal, in other words that requires more transistors, that translates into higher costs, and lower margins. That's some powerful incentive IMO. Not to mention that if the hardware is not powerful enough, the toy software projects that you mention will have trouble running ^^
Therefore I think a central question is the loss of performance compared to the gain in productivity. A naive translation of C to assembly leads to disastrous performance. For years (decades?) people had to resort to assembly for speed-critical routines, and you can still find assembly in video decoders for instance. But the productivity is so much higher than the loss of performance is acceptable.
I must be too old. The new guys can come and bring their new tools. I am retired now.
Back when I started, we used to care how the older engineers did stuff. The academics who trained us at uni had never worked in industry and had no real clue. Hence we had to learn the real stuff from the older guys. These days we are the old guys but just treated like yesterday's newspaper.
Not necessarily, I am a beginner in hardware design, and I am creating a new programming language and IDE for hardware design.
> The academics who trained us at uni had never worked in industry and had no real clue. Hence we had to learn the real stuff from the older guys.
I can relate, this is by talking to older designers that my co-founder and myself learned that CDC is a big thing to address for instance. But a lot of times we were just dismissed as too young and inexperienced. Anyway, I'm curious, in your opinion what would be the biggest pain points in digital hardware design today?
Verification and synthesis are the pain points. Projects revolve around them not the design. In HW, the design of each module itself is usually pretty conservative. We are a conservative bunch remember! But it's feature creep that crams in more and more modules to handle the variety of ways a single SoC can be applied to multiple markets.
The end result is multiple clock domains and buses going everywhere, multiple RAM modules, lots of different clock gating options to shut down parts of the system not in use. Etc.
When I look at a large design, I don't worry about the design effort. The first thing that comes to mind is the verification effort. You spend about four times or more the amount of effort verifying the design because you cannot afford any mistakes. That effort is building everything around the ports of a design that makes it thoroughly verifiable. The stimulus is constrained randomly generated transactions on every input to the design and checkers of every output. Coverage determines whether the random transactions have covered every case. And it not just every combination of inputs. Every module has state internally: you have to cover every possible state transition.
One of the older guys at my old company joked that: These days the design is done by the verification team.
The behavior of the design is modeled by the verification engineer so they can detect when the design has a bug. Often the verification team is working with an empty stub because they get ahead of the design team. It gets to the extreme case of the verification team telling the design team how to write everything.
To whomever downvoted this: would you mind telling me why? Have I offended you in some way? Is it because of the criticism of the hardware industry? Or the sarcasm?
That's the beauty (and sometimes the curse) of hardware design: it doesn't need a processor to run. You essentially describe an electronic circuit, and "program" (configure would be more appropriate) an FPGA to act like the circuit you described. A circuit can be as simple as you want (like a sequential counter) or very complex (people have implemented entire H.264 and HEVC decoders in hardware).
This is so powerful that in fact you can even describe your own processor, and prototype it on an FPGA for testing.
Interesting, I feel like you would like what we've done with the Cx language at Synflow. Probably the exact opposite of CλaSH, the language is sequential imperative (C-like even) and focuses on making the sequential part easier (Cx still has first class support for parallel tasks and hierarchical descriptions though). You have synchronous "for", "while", "if", this kind of thing :-)
http://cx-lang.org
Enjoy!
I've actually had a brief look at Cx a couple of months ago, and it looked very promising! Unfortunately, due to private and job-related reasons I didn't have the time to look at it in depth.
There's one thing that irritated me though: Reading from a port twice seems to trigger a clock cycle (did I get that right?). My intuition tells me that this is a huge source of bugs, comparable to the infered-latch-instead-of-combinational problem in VHDL/Verilog. I might be wrong though, since I haven't actually designed anything with it.
> Reading from a port twice seems to trigger a clock cycle (did I get that right?)
You did! It is by design that reading from the same port twice will trigger a clock cycle :-) There are several reasons why we did it this way. First, having to always explicitly declare a new clock cycle (rather than having it inferred) is kind of ugly, because your code is full of "fence;" instructions. The second reason is that we thought this would actually prevent bugs ^^ (the third is for symmetry with writes I think)
The thing with Cx is that, unlike VHDL/Verilog, reading a port can mean more than accessing a single signal, and similarly writing to a port can be more than writing a single signal. For example "sync" ports have an additional "valid" signal that is set to true for one cycle when data is written to the port. This is very handy, allowing synchronization between tasks (read becomes blocking) and is useful as a control signal (the "valid" signal serves as the write enable on a RAM for example). We also have a "sync ready" that adds an additional "ready" signal computed asynchronously and again useful for back-pressure control in pipelines, FIFOs, etc.
I agree, it is an interesting idea. I suspect that just having "Haskell" got the link a lot of upvotes :-) As stated on the "Why CλaSH", the advantage is obvious for combinational circuits. But it doesn't seem to help much for synchronous logic (which arguably represents the majority of hardware designs). You'll still be writing everything as "how to update register X in state S".
Helpful explanation. Thanks! Looking at this I have a very specific question, from a practical getting work done point of view, is this better than what we have, or just different to what we have. If the answer is "different" I don't mind, but it will hinder my adoption ;-) I guess this is why I want to see a side-by-side comparison of real hardware constructs. Things I use regularly. It would aid greatly in understanding the (potential) benefit of expressing things these ways.
Hard to say, it depends on what you consider better. It certainly is more concise than the equivalent Verilog (just like Haskell is more concise than pretty much any language I know). This seems especially true when you want to describe repetitive structures (such as their FIR filter).
CλaSH also has a much better type system than Verilog (again, thanks to Haskell), but if you wanted a good type system when describing hardware, you might as well just switch to VHDL ^^
My concern is with the description of state machines. You need to specify if you want a Mealy or a Moore machine, something that is usually implicit. And you're still describing the transfer function between states; CλaSH does not seem to allow you to describe your program in a structured way (such as loop until x becomes true, wait for 3 cycles, read z, while z > 0 decrement z, etc.)
Well, when I used VHDL back in college, I noticed that it had a really hard time with math. So for example it could do look up tables all day (basically switch commands) but if you tried to encode that logic into the kind of math we're used to in a C-based language where A = B (insert operator here) C, it fell down hard and the circuit would be so unstable that it would only run a few cycles before spinning off into some exceptional state that was nothing like we expected.
I think that's because humans have a hard time considering the ramifications of things like boundary conditions and edge cases with respect to types. So maybe we can visualize one register being added to another, but we can't intuitively extrapolate what happens when one is signed and one is unsigned, or their widths are different, or one is floating point, etc etc etc. VHDL doesn't touch on all of these edge cases very well (because for one thing they are hard!) it just does exactly what it’s told. That often flies in the face of intuition, once we’ve analyzed the circuit and seen how much we underestimated the complexity of what we were asking. In other words elegant math doesn’t always translate to simple circuits, and vice versa. So it really needs a meta language that can grapple with these subtle nuances and compile to VHDL without a lot of friction.
Probably what’s going to happen is we’ll see DSP logic (and limited subsets of it like GPU shaders/OpenCL/CUDA) and VHDL/Verilog merge into a functional concurrent language that can cover all of it. It won’t be as explicit as Rust because it will infer what the user is after but allow for overriding default assumptions. It won’t have opaque syntax either like most functional languages today. I’m thinking probably it will look more like MATLAB/Octave but have access to some of the more concise notation of Mathematica. So think Excel except having cells arranged arbitrarily in some ND space rather than 2D, and we’ll be able to specify formulas on groups of cells rather than individually, and in any language we desire that’s then compiled to Lisp and either run on distributed economy hardware or translated to a hardware description language. CλaSH probably isn’t it, but its approach and open source license is certainly a start.
Realized I didn't answer the question - different yes, but probably not different enough to be compelling for mainstream use at this point. Without having ever used it, I have concerns that circuits will still fall down or take up gratuitous chip area because handling the edge cases is one of the more complex problems to solve, and I'm not convinced that functional programming alone is enough.
How well HLS does highly depends on the source code (this is in general and not specific to Vivado HLS). If your code is a simple loop over an array and you add a vendor-specific #pragma directive (such as #pragma unroll) the tool will unroll your loop and extract the parallelism from there. This actually works quite well in practice for regular DSP code (like FIR and FFT) and floating point. Anything else is another story though.
The thing is that unless you're writing your code as the tool expects it, with the proper pragmas etc. there's no way it can be transformed to fast hardware. A way around that is for vendors to ship "customizable IP" kind of like Altera's Megafunctions... so much for portability and high-level.
I'm not sure which tool OP is referring to though, I remember Altera had a C2H tool that they discontinued in favor of their OpenCL SDK.
Really? Aren't they using VHDL generics/Verilog parameters?
Cx supports specialization of entities with this kind of semantics, so you give an instance parameters and the compiler generates specialized code (so there's no more need for Perl scripts thankfully ^^). Right now you can't enable or disable things, but this is something that would be excellent: modify the hierarchy, add or remove ports, all depending on which flags the entity was instantiated with.
As I explained in another comment a few minutes ago, we're not so much about syntax as we're about better semantics and higher level description (I agree this isn't very clear on the website). Your remark about the ecosystem is perfectly right, and this is what makes EDA a tough market.
I don't know enough about verification to comment. I know SystemVerilog is very powerful but very complex, I've read about UVM and stuff, some people use SystemC. I wonder how they even manage to get hardware validated!
Yes it is still in use, and the simulation capabilities are quite advanced! It remains a HDL, better than VHDL and Verilog, so you still have to worry about resetting, clocks and state machine.
Just a word of caution the cycle accurate simulator is still a bit experimental (don't use big numbers, and bit accurate signed arithmetic is not finished yet... we're working on it)
