31–40 of 53 posts
Also, I really don't understand what the author meant by "PL troll". Writing static code checkers is trolling nowadays?
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.
Earlier quoted context omitted.
So, essentially feeding it into something like BUF? I thought those were optimized out on modern FPGAs. I can see the sourcing issue when trying to fan out too much from a single module, but I don't see any issue doing a high speed interconnect between them as long as you're intelligent about where the modules are going to be placed in regards to chip I/O. i.e. don't have a high speed serdes unit on one bank try and…
I don't remember what a BUF represents in FPGA tools- the name implies an inverter pair, e.g. buffer, but I don't remember for sure. Anyway, I mean a sequential element, such as a latch or a flip-flop. (If you don't know what those are, please pay a quick visit to Wikipedia- they are fundamental ) It is a placement/distance problem. Sometimes one module needs to talk to a module on the other side of the chip, and the…
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…
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.
Source: being a PL troll :)
"In high speed designs, it’s an error to use a signal that’s sourced from another module" 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.
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…
My spouse designs CPUs for a major CPU manufacturer (you've used them). She is responsible for physical design for one tile (there are many tiles, each of which has other physical designers). Her single tile, by itself, is substantially larger than almost all ASIC designs in the world today. At that scale, most of the standard FPGA design tools don't even work. Designing in that space is substantially different than FPGA or even ASIC design.
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.
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…
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…
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…
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…
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.