This is a fascinating glimpse into a world I know less than nothing about. I don't anticipate ever needing to code in Verilog, but I'll try to keep this in mind and look for other places where a little effort can save a lot of time.
I wonder what this has to say about type systems in general. Projects like Clojure's core.typed let you add static typing as a library where you feel like you need it, but then you don't get the benefit of statically checking everyone's code, all of the time. Perhaps a company policy on what functions need to be typed would do the trick, but at that point the compiler might as well enforce it for you.
Hardware programming is THE area where you need static types always on.
Basically, you have to write everything in goto statements, no while's or for's. You also have to check that size always match, otherwise you will have errors. You also have to check that you do not accidentally drive one input from two outputs, otherwise you will also get errors.
As you discover errors through very slow simulation (small circuit takes about 4 days of simulation for measly 2 seconds and it stays about 60% of time idle, e.g., not doing much), you really need to face any possible errors ASAP.
Another option is code generation from some high level model, but then you can miss something important like critical path delay or latency (in clock ticks) and you have to bring that information into the model. While this can be done in Clojure or Python or something alike, it is not a panacea, not even close to that.
As someone who spends 40 hours a week (and 60 - 70 lately) coding Verilog for FPGAs I'm always excited when something domain-specific hits the front page. I have no idea what a PL Troll is, though, so I think I missed the point of the entire post. Anyone care to elaborate? Google is not helpful.
A programming languages troll would be someone who suggests using obscure programming languages or techniques (you should use Agda here, you should write a type checker) to solve systems problems "because it's safer" regardless of practicality.
The programming language trolling in the article is building a language with strong static types controlled entirely by naming convention, specifically hungarian notation, rather than normal type declaration. http://en.wikipedia.org/wiki/Hungarian_notation
EDA tools vary in license costs, from a few thousand
dollars per machine license per year, to half a million
per core license per year. Timing tools aren’t all the way
at the top end, but they’re not cheap.
I have never in my life touched software this expensive. It's interesting to me how this warps workflows - e.g. automated testing tools can only test one build every two days, not because running in parallel is computationally expensive, but because licensing is too expensive in cash terms. Given the zero marginal costs (to software vendors) of existing customers running extra copies, this sounds completely insane to me.
It's nothing at all to do with the marginal cost and all to do with extracting marginal _value_ from your tiny customer base with a high cost of sales.
I worked in an EDA startup for a decade before we were bought by Cadence. Getting people to evaluate our tool generally took a few months of a technical presales person's time. We only ever acquired a few dozen customers: there aren't all that many ASIC companies. Most required at least one custom feature. Therefore there's an elaborate commercial negotiation to take as much money as possible from the customer in order to amortize the R&D.
Given manufacturing fixed costs of $250k, spending $250k on software to get it right starts to look reasonable.
In my experience, software tailored for specific industries, sciences and academia, the electronics industry specificly, typically have prices in this range.
The narrower the field and harder the science, the fewer (and more expensive) candidates will be sufficiently competent to implement the software and the lesser audience for the software-publisher to recoup their RnD investment with, so prices tends to go up.
Once you need software to support engineering-disciplines not software, they know you will be able to pay the bill and find the software worthwhile compared to doing the same work manually with expensive engineers.
I use these types of software day to day. The true price is veiled behind multi milkion dollar contract negotiations. You should see the inverse relationship between price and lack of bugs.
What's more of a challenge is trying to use techniques like continuous integration when your compile time is a week!
Anyone who needs a Verilog with proper typing should check out Bluespec. It has the Haskell type system and it transpiles to Verilog. Due to type inference, it doesn't need to be verbose. Don't let my refernce to "Haskell" scare you, you decide yourself how general your code is. If you don't want to worry about monads, you don't need to.
Spent the last 2 years doing high-speed comm designs on FPGAs. (I don't know if 5 Gbps currently count as high speed though).
The tools are quite mature and will mostly prevent you from doing stupid things.
Somewhere here I saw a comment saying that you must time your design taking in account the logic delay or will get weird errors, but that's impossible. The tool chain (both quartus and Xilinx ISE) will report the max clock speed with a big bold red font if you try to go faster.
There's a step in every design flow called DRC (Design rule-checker), basically a bunch of warnings if you do dumb things with anything including the high-speed transcievers. You must pay attention to the warnings.
Neverd did any ASIC but I know they have about 10X the testing and simulation that FPGA have. I would believe you don't get random errors if you follow the standard design flow and tests.
I believe the answer in this case is you latch the signal, and use a local copy. Sort of like how it is good practice to use local variables when coding.
To some extent his advice suffers from the same problem that many books suffer from, in that it comes from the ASIC world while a large share of Verilog work these days is probably done to target FPGAs. For reasons too long to elaborate upon here, you can get away with a lot of things on FPGAs that may not be such a good idea on ASICs.
Yeah, I didn't understand that first part either. A module isn't very useful unless it's connected to other modules. I think he means something different, but I can't tell what.
Being that HN is permeated by software developers it might be important to point out that Verilog code is not software but rather hardware description. The developer --in this case typically an EE-- either explicitly or through inference describes circuit structures with something that looks like a C-like programming language.
Concepts such as modules don't translate directly into the software world. A module is a grouping of circuit elements. The criterial for grouping them can be varied. One typically creates modules for functional blocks that are easy to plug into the overall circuit. And, much like a subroutine, the other motivation is when one must use the circuitry multiple times. The difference is that a subroutine is called and exited. A module instantiation creates real and permanent circuitry on the chip (ignoring FPGA reconfiguration techniques).
I've been working with HDL's for quite some time. Frankly, every attempt I've seen to get away from hardware development and making it look like software development is crippled in some way or another. I equate this to the idea of, for example, tools that allow you to write mobile apps using something other than the native language and framework of the platform. It works. Until it doesn't.
As far as the article is concerned, no issues with any of it. It's an interesting approach. That said, I've never used anything similar to this and can't remember the last time I had such problems. This isn't criticism. Just one data point.
Three minor additions to what should become a HN FAQ every time there's a vaguely FPGA/ASIC article:
This is hardly official and not a perfect analogy but github is to software devs as opencores.org is to FPGA devs. Thats why when you go to github and search for Verilog and only get 259 hits for stuff written in Verilog you're going to the wrong place.
The other FAQ is verilog looks like C because C looks like the incredibly orthogonal PDP-11 addressing modes chart. So pretty much if you can imagine it as an addressing mode, the PDP-11 could do it, so thats explains the weird compatibility between something that looks like C and something that can define the hardware of a CPU. Its not a perfect analogy but it kind of describes why the HDL look very C like rather than Ruby like, for example. If you could build it out of basic logic gates in 1970 using TTL chips, its probably supported by the old PDP-11 and therefore in C.
Finally you need a FAQ for old timers that home-scale FPGA / CPLD stuff has collapsed in price over the last decade or two. Yes, in 1990 you needed four figures to do anything so no one did anything at home. Now you need at minimum a $50 board and a (multi-gig) free download. Its maybe 3dB more expensive than fooling around with arduino stuff. The small scale stuff doesn't scale well to larger stuff; I think its "weird" when a simple gray code decoder or quadrature decoder takes a minute to synth, so yes doing a complete CPU does take a long time to synth even on fairly high end hardware. Back to the old days of batch computing, sorta.
This reads more like a succession of notes rather than a coherent article to me, I had some trouble understanding what the author was getting at. It's still worth reading IMO, but I doubt people who have no background on hardware design understood what TFA was talking about.
Also, I really don't understand what the author meant by "PL troll". Writing static code checkers is trolling nowadays?
In high speed designs, it’s an error to use a signal that’s sourced from another module
Not sure if I agree here, at least in these absolute terms. Sometimes you cannot afford to unnecessarily capture every I/O signal, and it is indeed not always necessary.
In ASIC RTL, two really important things should be considered. DFT implementable and synthesis friendly. Verilog with those two can only compete. In that sense, ARM is one of the best at it.
I am not sure if a static checker meant 'lint' but Verilog writer can be better being good at static check and static checker at next end.
[+] [-] NoodleIncident|12 years ago|reply
I wonder what this has to say about type systems in general. Projects like Clojure's core.typed let you add static typing as a library where you feel like you need it, but then you don't get the benefit of statically checking everyone's code, all of the time. Perhaps a company policy on what functions need to be typed would do the trick, but at that point the compiler might as well enforce it for you.
[+] [-] thesz|12 years ago|reply
Basically, you have to write everything in goto statements, no while's or for's. You also have to check that size always match, otherwise you will have errors. You also have to check that you do not accidentally drive one input from two outputs, otherwise you will also get errors.
As you discover errors through very slow simulation (small circuit takes about 4 days of simulation for measly 2 seconds and it stays about 60% of time idle, e.g., not doing much), you really need to face any possible errors ASAP.
Another option is code generation from some high level model, but then you can miss something important like critical path delay or latency (in clock ticks) and you have to bring that information into the model. While this can be done in Clojure or Python or something alike, it is not a panacea, not even close to that.
[+] [-] aortega|12 years ago|reply
Sorry for the stalking but you must realize you posted in a site called "hacker news"
[+] [-] bhb916|12 years ago|reply
[+] [-] lincolnq|12 years ago|reply
Source: being a PL troll :)
[+] [-] lmeyerov|12 years ago|reply
[+] [-] MaxGabriel|12 years ago|reply
[+] [-] chas|12 years ago|reply
[+] [-] azernik|12 years ago|reply
[+] [-] pjc50|12 years ago|reply
I worked in an EDA startup for a decade before we were bought by Cadence. Getting people to evaluate our tool generally took a few months of a technical presales person's time. We only ever acquired a few dozen customers: there aren't all that many ASIC companies. Most required at least one custom feature. Therefore there's an elaborate commercial negotiation to take as much money as possible from the customer in order to amortize the R&D.
Given manufacturing fixed costs of $250k, spending $250k on software to get it right starts to look reasonable.
[+] [-] josteink|12 years ago|reply
The narrower the field and harder the science, the fewer (and more expensive) candidates will be sufficiently competent to implement the software and the lesser audience for the software-publisher to recoup their RnD investment with, so prices tends to go up.
Once you need software to support engineering-disciplines not software, they know you will be able to pay the bill and find the software worthwhile compared to doing the same work manually with expensive engineers.
[+] [-] StringyBob|12 years ago|reply
What's more of a challenge is trying to use techniques like continuous integration when your compile time is a week!
[+] [-] jacquesm|12 years ago|reply
[+] [-] iso-8859-1|12 years ago|reply
[+] [-] smilekzs|12 years ago|reply
[+] [-] tcas|12 years ago|reply
How else are you supposed to get I/O from one module to another, say a 32bit data bus? Also, what's the definition of high speed here?
"unless you like random errors"
And very hard to diagnose errors until you realize that you messed up your clock domains.
[+] [-] aortega|12 years ago|reply
Somewhere here I saw a comment saying that you must time your design taking in account the logic delay or will get weird errors, but that's impossible. The tool chain (both quartus and Xilinx ISE) will report the max clock speed with a big bold red font if you try to go faster.
There's a step in every design flow called DRC (Design rule-checker), basically a bunch of warnings if you do dumb things with anything including the high-speed transcievers. You must pay attention to the warnings.
Neverd did any ASIC but I know they have about 10X the testing and simulation that FPGA have. I would believe you don't get random errors if you follow the standard design flow and tests.
[+] [-] sliverstorm|12 years ago|reply
I believe the answer in this case is you latch the signal, and use a local copy. Sort of like how it is good practice to use local variables when coding.
what's the definition of high speed
Last I heard, 100MHz+
[+] [-] CamperBob2|12 years ago|reply
[+] [-] zhemao|12 years ago|reply
[+] [-] robomartin|12 years ago|reply
Concepts such as modules don't translate directly into the software world. A module is a grouping of circuit elements. The criterial for grouping them can be varied. One typically creates modules for functional blocks that are easy to plug into the overall circuit. And, much like a subroutine, the other motivation is when one must use the circuitry multiple times. The difference is that a subroutine is called and exited. A module instantiation creates real and permanent circuitry on the chip (ignoring FPGA reconfiguration techniques).
I've been working with HDL's for quite some time. Frankly, every attempt I've seen to get away from hardware development and making it look like software development is crippled in some way or another. I equate this to the idea of, for example, tools that allow you to write mobile apps using something other than the native language and framework of the platform. It works. Until it doesn't.
As far as the article is concerned, no issues with any of it. It's an interesting approach. That said, I've never used anything similar to this and can't remember the last time I had such problems. This isn't criticism. Just one data point.
[+] [-] VLM|12 years ago|reply
This is hardly official and not a perfect analogy but github is to software devs as opencores.org is to FPGA devs. Thats why when you go to github and search for Verilog and only get 259 hits for stuff written in Verilog you're going to the wrong place.
The other FAQ is verilog looks like C because C looks like the incredibly orthogonal PDP-11 addressing modes chart. So pretty much if you can imagine it as an addressing mode, the PDP-11 could do it, so thats explains the weird compatibility between something that looks like C and something that can define the hardware of a CPU. Its not a perfect analogy but it kind of describes why the HDL look very C like rather than Ruby like, for example. If you could build it out of basic logic gates in 1970 using TTL chips, its probably supported by the old PDP-11 and therefore in C.
Finally you need a FAQ for old timers that home-scale FPGA / CPLD stuff has collapsed in price over the last decade or two. Yes, in 1990 you needed four figures to do anything so no one did anything at home. Now you need at minimum a $50 board and a (multi-gig) free download. Its maybe 3dB more expensive than fooling around with arduino stuff. The small scale stuff doesn't scale well to larger stuff; I think its "weird" when a simple gray code decoder or quadrature decoder takes a minute to synth, so yes doing a complete CPU does take a long time to synth even on fairly high end hardware. Back to the old days of batch computing, sorta.
[+] [-] simias|12 years ago|reply
Also, I really don't understand what the author meant by "PL troll". Writing static code checkers is trolling nowadays?
[+] [-] sliverstorm|12 years ago|reply
Not sure if I agree here, at least in these absolute terms. Sometimes you cannot afford to unnecessarily capture every I/O signal, and it is indeed not always necessary.
[+] [-] hclee|12 years ago|reply
I am not sure if a static checker meant 'lint' but Verilog writer can be better being good at static check and static checker at next end.
[+] [-] jahagirdar|12 years ago|reply