[harnhua]

Oooo, 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]

Avoid 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]

>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]

As 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]

Because 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.