Live data from Hacker News

Ask HN's FPGA users: FPGA tool woes & wants?

news.ycombinator.com

31–37 of 37 posts

Re: Ask HN's FPGA users: FPGA tool woes & wants?

#31
post #28
post #19

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 comp…

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 r…

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.

Re: Ask HN's FPGA users: FPGA tool woes & wants?

#32
post #15
post #13

Earlier quoted context omitted.

Thanks for your thoughts! Yes, I think it's beautiful to try to apply software/computer science/statistical methods to a hardware field. Making builds faster via parallelism, publishing statistics http://www.plunify.com/reports.php>statistics ; for an application and like you said, having some intelligent ways of indicating errors are things that we're very enthusiastic about. And it's great to read that people actua…

Maybe use 'survey' or 'audit' instead of 'testing' to describe the mass builds. It's a continous integration system for a notoriously fiddly set of toolchains, and right now you're pitching it at the beancounter that selects the parts. Send me an email about the flasher (see profile), I might be able to dig it out of an old home directory. Don't know if it still works, I only used it with one Utah on one dev board fo…

s/Utah/JTAG/ -- goddamn iPhone

Re: Ask HN's FPGA users: FPGA tool woes & wants?

#33
post #31
post #28

Earlier quoted context omitted.

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 r…

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.

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

Re: Ask HN's FPGA users: FPGA tool woes & wants?

#34
post #29
post #27

Earlier quoted context omitted.

Would that diminish the value of our service if it only runs on companies' internal servers and not enjoy benefits in parallelism that we can give them? I guess if they are too worried about IP, offering the downloadable service is perhaps the best alternative.

Another alternative is running in a VMWare virtual machine for them, or allowing them to upload it themselves to cloud providers.

Has hacker news not heard of Virtual Machine Appliances?

http://www.vmware.com/appliances/

You can buy VM Images that do all sorts of things with no configuration whatsoever. Multiple VMWare images running on customer hardware is an alternative solution for this company if they're trying to sell to people like Cisco and AT&T etc.

Re: Ask HN's FPGA users: FPGA tool woes & wants?

#36
post #33
post #31

Earlier quoted context omitted.

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.

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

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.

Re: Ask HN's FPGA users: FPGA tool woes & wants?

#37
post #36
post #33

Earlier quoted context omitted.

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

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.

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.

Post reply on HN