4 ms·

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 al

by thesz 13y ago

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.

Jach 13y ago
Have you ever used the Python library MyHDL? http://www.myhdl.org/doku.php http://www.myhdl.org/doku.php It's been successfully used for both FPGA projects and ASIC designs.
- thesz 13y ago
  No. But I had a look at it a year or two ago. I wasn't very impressed precisely because it does not have flexible types and typechecking.
npsimons 13y ago
So, not surprisingly, the fine article and the original quote seem to be at odds, and both are more than a little obtuse. First, if you're going to have a statically typed language with no type declarations, how else are you going to do type checking? Sure, it's generally agreed that Hungarian warts are unnecessary in this day of tools (editors, IDEs, what have you) that will tell you what type a variable is in an instant, but if you're playing some silly game of "let's set arbitrary constraints to see how convoluted we can get", then you very well might come up with required Hungarian warts. Second, if hardware programming is a place where static type checking would be a boon, could it not be said that any language which doesn't have it built in is less than ideal for the task? It's been a while since I've programmed in Verilog, but surely there must be other off the shelf tools (both OSS and otherwise) that would be better suited. Even if you stick with Verilog and go the route that the article describes, that's not trolling, that's just practicality. This article is interesting in and of itself, and I'm glad to see it hit the front page, but the author could have left off the quote and not claimed to be a PL troll.
robomartin 13y ago
> Hardware programming is THE area where you need static types always on. It's not "hardware programming". It's hardware design. It's no different from connecting raw gates and chips on a breadboard. This is a very important distinction that is often glossed-over in HN conversations. Verilog is a tool with which you explicitly or by inference DESCRIBE hardware. You are not programming hardware. That's software. At some level this concept of static types is nonsensical. You have registers made up of flip-flops that move data around from circuit block to circuit block. That's it. Data types, in many ways, are software constructs, they don't really exist in hardware. One would not look at a breadboard full of chips or an old-school PCB with latch and flip-flop chips and discuss static data types. Maybe you'll talk about fixed with data busses that implement this or that encoding, but that's about it. One could argue that a specialized floating point processor has a data type. That's one way to interpret it. Another way is to say that it has a, say, 64 bit architecture that, by convention, is interpreted in order to be able to represent floating point numbers within certain constraints. If by that we mean "static data type" then, well, I suppose I can go with that.
- thesz 13y ago
  Take, for example, Avalon streaming interfaces: http://www.altera.com/literature/manual/mnl_avalon_spec.pdf http://www.altera.com/literature/manual/mnl_avalon_spec.pdf Yes, it is a bunch of flip-flops and gates, but in the end the interface with "empty" signal is different from interface without it. The same is for error signal. To connect those sinks and sources properly you have to match types. E.g., you have to deal with the absence of "empty" on one end. Otherwise you will surely make some obvious mistake. And, finally, Avalon streaming interface is a tuple: type ASI a = (SOP, EOP, a) data SOP = NoSOP | SOP -- SOP and EOP equivalent to boolean data EOP = NoEOP | EOP And parameter "a" can be anything - raw value without empty or error, tuple of value and empty, tuple of value and error, triple of value, empty and error. They all are different. Even if their connection is no-op, like inventing "always good" value for error field, this no-op should be specified. Otherwise, you make discovery of the error very distant.

by thesz 13y ago

Jach 13y ago

Have you ever used the Python library MyHDL? http://www.myhdl.org/doku.php http://www.myhdl.org/doku.php It's been successfully used for both FPGA projects and ASIC designs.

thesz 13y ago
No. But I had a look at it a year or two ago. I wasn't very impressed precisely because it does not have flexible types and typechecking.

npsimons 13y ago

So, not surprisingly, the fine article and the original quote seem to be at odds, and both are more than a little obtuse. First, if you're going to have a statically typed language with no type declarations, how else are you going to do type checking? Sure, it's generally agreed that Hungarian warts are unnecessary in this day of tools (editors, IDEs, what have you) that will tell you what type a variable is in an instant, but if you're playing some silly game of "let's set arbitrary constraints to see how convoluted we can get", then you very well might come up with required Hungarian warts. Second, if hardware programming is a place where static type checking would be a boon, could it not be said that any language which doesn't have it built in is less than ideal for the task? It's been a while since I've programmed in Verilog, but surely there must be other off the shelf tools (both OSS and otherwise) that would be better suited. Even if you stick with Verilog and go the route that the article describes, that's not trolling, that's just practicality. This article is interesting in and of itself, and I'm glad to see it hit the front page, but the author could have left off the quote and not claimed to be a PL troll.

robomartin 13y ago

> Hardware programming is THE area where you need static types always on. It's not "hardware programming". It's hardware design. It's no different from connecting raw gates and chips on a breadboard. This is a very important distinction that is often glossed-over in HN conversations. Verilog is a tool with which you explicitly or by inference DESCRIBE hardware. You are not programming hardware. That's software. At some level this concept of static types is nonsensical. You have registers made up of flip-flops that move data around from circuit block to circuit block. That's it. Data types, in many ways, are software constructs, they don't really exist in hardware. One would not look at a breadboard full of chips or an old-school PCB with latch and flip-flop chips and discuss static data types. Maybe you'll talk about fixed with data busses that implement this or that encoding, but that's about it. One could argue that a specialized floating point processor has a data type. That's one way to interpret it. Another way is to say that it has a, say, 64 bit architecture that, by convention, is interpreted in order to be able to represent floating point numbers within certain constraints. If by that we mean "static data type" then, well, I suppose I can go with that.

thesz 13y ago
Take, for example, Avalon streaming interfaces: http://www.altera.com/literature/manual/mnl_avalon_spec.pdf http://www.altera.com/literature/manual/mnl_avalon_spec.pdf Yes, it is a bunch of flip-flops and gates, but in the end the interface with "empty" signal is different from interface without it. The same is for error signal. To connect those sinks and sources properly you have to match types. E.g., you have to deal with the absence of "empty" on one end. Otherwise you will surely make some obvious mistake. And, finally, Avalon streaming interface is a tuple: type ASI a = (SOP, EOP, a) data SOP = NoSOP | SOP -- SOP and EOP equivalent to boolean data EOP = NoEOP | EOP And parameter "a" can be anything - raw value without empty or error, tuple of value and empty, tuple of value and error, triple of value, empty and error. They all are different. Even if their connection is no-op, like inventing "always good" value for error field, this no-op should be specified. Otherwise, you make discovery of the error very distant.