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.
How to Write Safe Verilog: Become a PL Troll
51–53 of 53 posts
Re: How to Write Safe Verilog: Become a PL Troll
#52Earlier quoted context omitted.
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 circui…
Have you ever used the Python library MyHDL? http://www.myhdl.org/doku.php It's been successfully used for both FPGA projects and ASIC designs.
I wasn't very impressed precisely because it does not have flexible types and typechecking.
Re: How to Write Safe Verilog: Become a PL Troll
#53Earlier quoted context omitted.
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 circui…
> 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 so…
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.