3 ms·
The HORRIBLE point facing FPGA creation is the tools just don't tell you when you've accidentally made silly circuits. There should be much better errors/warn
by gte910h 16y ago
The HORRIBLE point facing FPGA creation is the tools just don't tell you when you've accidentally made silly circuits.
There should be much better errors/warnings letting you know when you've written VHDL/Verilog that doesn't turn into standard logic gates and systems, when you've done things that have easy to identify race conditions, and when you've written things that just don't make sense.
After working with computer code compilers, and analyzers like lint and clang, it is still sad to look at the errors (and lack of errors) coming out of VHDL/Verilog tool chains and not see something even 2 orders of magnitude of useful as far as toolchain output. WAY too much Field application engineer time is spent on junior engineering problems that can't be effectively delegated due to this insufficient machine error checking.
I mean, half the time you generate something that will simulate differently than run in real life, that's OBVIOUS from the code structure. But no, the toolchain doesn't identify that, bench checking the specification to the VHDL is the only way to find that (or a code review by another engineer).
So TLDR: Make VHDL or Verilog spit out REAL errors and warnings when used somewhat incorrectly, or likely incorrectly. Bring the tools up to the standard of sequential coding tools, or even more in that direction instead of the morass it still is today for hardware specification languages.
- harnhua 16y agoOooo, an intelligent parser of FPGA code would be lovely. The parallel nature of hardware code presents very interesting challenges for such a parser, I think. Recently I came across a company called www.sigasi.com that promised lovely things about VHDL development but I haven't really looked into them yet. Existing FPGA tools spit out a LOT of warnings that are potentially helpful but are too verbose for anyone to remain sane trying to decipher all of them. Thanks!
- blasdel 16y agoAvoid ever referring to it as code. There'll be a few cases where it's valid nomenclature, but most of the time it gets you headed in the wrong direction. The trick would be a synthesis that preserves line-number metadata, and then a linting place-and-route that just creates idealized graphs and lets you see where your design is exploding or clocked funny or whatever.
- gte910h 16y ago>Avoid ever referring to it as code I tend to call verilog or VHDL "VHDL Hardware Specification". Try to make it sound as un codelike as possible After all VHDL was the way that military contractors came up with to specify their parts to the Govt in case they went belly up.
- harnhua 16y agoAs I was trained in Verilog and know little about VHDL, to be honest, I'm not quite sure why "code" is inappropriate. But thinking about your(blasdel's and gte910h's) comments, I'm beginning to see how error-checking can and should be different for FPGA development.
- blasdel 16y agoBecause neither Verilog nor VHDL is code. HDL is a slightly handwavey description of the graph of a machine, not something that runs on a machine. You have wires, not variables: real physical wires connecting gates and LUTs. Since you're dealing with real-world electrical current, each wire can be in one of four binary states (null, low, high, grey). There's no concept of time beyond the speed of light itself unless you deliberately bind a clock line from the outside to a wire.