

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

(From two guys building a webapp for FPGA users)<p>Any fellow FPGA users on HN? If you don't mind taking a moment to share your thoughts; it'll be really helpful!<p>We'd love to hear about:
- what you dislike about existing FPGA tools
- what you'd want in FPGA tools; and
- whether we're building would be useful<p>Here's our take:
1) Dislikes:
- Being forced to choose a specific FPGA before compilation(synthesis, place-and-route etc.) when I don't even know which FPGA suits my application.
- Installing, maintaining, upgrading bulky software tools on local PCs.
- Taking weeks/months to learn a particular tool from just one FPGA vendor.
2) Wants:
- Ways to automatically match an FPGA app to the right FPGAs.
  - in terms of speed, size, power, etc.
- FPGA tools hosted and updated somewhere else.
- A single user interface that translates user inputs for all vendors' FPGA tools.<p>Existing tools don't seem to do these things, so we started building a webapp with the above features.<p>Ran the idea by the folks at YC and they had questions about how useful our webapp would be after the FPGA programming files are generated and the user needs to test on real hardware.
(Answer: Not very; our webapp will just ensure that the user ends up buying and using the most suitable hardware)<p>Beta site: http://www.plunify.com<p>Thanks for reading; looking forward to your comments!
======
blasdel
Just having builds go way faster would be awesome. Shove some static analysis
in there for warnings, and maybe collect user feedback to feed into a
statistical model of the likelihood that the warning was indicative of an
error. Take real advantage of being a webapp.

I think you should run far away from emphasizing the matching of a core to
it's most cost-effective target -- it's not something you need to do until you
actually have something nearing the need to buy a shitload of parts and ship.
You generally develop on one of several overpowered dev boards that you
already owned. Pitch the multi-hardware parallel build as _testing_ , not chip
selection: 'what targets is my build not totally broken on'.

When I was doing some rather oddball FPGA development (trying to do Alan Kay
style pedagogical CPU dev) I would have killed for this. I was attempting to
build stuff with as little HDL as possible for clarity purposes, and would
frequently fuck myself over when the Xilinx tools couldn't synthesize or
place-and-route it anymore for my Spartan-3 hardware. Some of it was just
their incompetence, where a hand-laid design could fit easily, but a lot of it
was just classic traveling salesman problem woes. It would have been a lot
easier to see what the real constraints I was hitting if I knew which chips it
didn't work on anymore.

The vendor compiler toolchains are fucking dogshit. Just having that hosted
and guaranteed not to collapse in on itself would be golden. You should also
develop simple desktop software for flashing the builds for at least Linux and
Mac OS X. At one point _I wrote my own flasher from scratch_ that sucked but
Xilinx's Windows flasher had shat itself on me and I couldn't get it to work
again (the Linux stuff never worked at all, ever). Make a simple drag-and-drop
flasher. You could even sell a rebranded USB-JTAG that's guaranteed not to
suck.

Simulators are ridiculously awful, but you're not going to come anywhere near
fixing that.

"that the user ends up buying and using the most suitable hardware" is a side
effect of some of your features, not the real use case you should be selling.
It feels somewhat greasy, because at some level you're just marketing hardware
to me. Even if you do try to monetize that through some kind of affiliate
thing, don't put it up front. You'll spook the engineers.

~~~
harnhua
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 <a
href="[http://www.plunify.com/reports.php>statistics</a>](http://www.plunify.com/reports.php>statistics</a>);
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 actually want such features.

Testing instead of chip selection? I guess I'm too used to the word "testing"
being used for actual hardware testing, but I can see how the change in
phrasing might appeal more.

I see; instead of greasy marketing talk, we should emphasize technical data in
order to win over our target customers--the engineers. Being engineers
ourselves, this makes complete sense. I wonder how we can appeal to the
"suits" too.

How we're currently presenting results is something like this: Here're all the
FPGAs that we've tested your application on. These are the ones who met your
frequency, size, power, and this is how much they cost.

For simulators, we're trying to see if providing the open source Icarus
Verilog and GHDL with custom libraries might work for people.

Can I ask you about that flasher that you wrote sometime? Not at all familiar
with how they work, but a universal USB-JTAG solution would be great.

Really appreciate your comments.

~~~
blasdel
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 for a few months a couple years ago.

~~~
blasdel
s/Utah/JTAG/ -- goddamn iPhone

------
miratrix
I don't think being locked down to a specific FPGA is as big a deal as you
think. In professional circles, FPGA choice is mostly a matter of your company
being an Altera shop or a Xilinx shop, and which FPGA they've used in the
past. For large customers, FPGA companies work quite closely with their
customers so things like support and availability of parts at the quantity
required means far more than exactly what features are in where. For many
hobbyists, typically what matters is what peripherals ship with the cheapest
dev kit as much as how many LUTs and memory blocks are on the chip.

But, on the flip side, some of the most annoying and agonizing decisions that
you end up making over a lifecycle of a project is whether to upgrade to the
newer / newest releases of various software. As you guys undoubtedly know,
setting up these software is not trivial, and getting it to a point where a
reasonable workflow exists can be pretty damn painful. And with every upgrade,
you might get a nice compilation and synthesis speed upgrade coupled with a
memory bug here and configuration but there. Something that some people might
have a use for, is ability to target not just across different chips, but
different versions of the software, not as a chip selection utility, but more
as a tool selection utility might make a little more sense, where you provide
fine control over exactly which version of tools are being used, as well as
commonly used knobs for configuring the various parameters of place and route
& synthesis options (of which there are plenty)

Even with that, though, I don't know if this is a service that a lot of people
will find useful. As sybreon points out, IP cores are a huge part of FPGA
development flow and I don't really see a way to easily handle that aspect of
things. Many of the IP cores spit out encrypted HDL and I think pretty much
every tool vendor has a different format that they can handle. Also, a lot of
people are pretty tied to their simulator of choice, with libraries and custom
TCL scripts to massage things just right, and I'd imagine it'd be difficult to
move things like that over (though I did not go through the signup process to
try things out myself).

I've been out of FPGA arena for couple of years now, but I think places to
focus within the FPGA marketplace, especially in areas where people will pay
real $$, is in testing and verification. Back in the days, many people used
FPGA like they would a software compiler - try few lines of code, hit compile,
check it out, rinse and repeat. With the increasing complexity of the designs
due to ever increasing gate count, trying to develop like that doesn't work so
well. If you could, for instance, take in a verilog or vhdl module, do some
simple analysis to figure out input / output ports and the sensitivity list,
and beat the crap out of it (using both user-defined data set and random /
smart / fuzz sets), you might have something there...

~~~
harnhua
Hmm... seems true, for example, in Japan we found that inter-company
relationships also matter a lot in FPGA decisions. Scalable support, alas,
would be hard for a startup like us to provide.

We are working on adding dev kit details for hobbyists though. That's
something which seems useful, like what you said.

So it seems like convenience rather than chip selection is something that we
can possibly get people to pay for? Specifically the convenience of exploring
different technical options in an automated design space exploration kind of
fashion.

It seems like we have features that people might like, but we have to position
it in ways different to what we currently believe would work?

Our webapp is pitching a minimalistic way of doing things, in that what the
libraries and TCL scripts that you mentioned do, will be done automatically.
Hopefully this will highlight the convenience factor more than the "change-in-
working-methods" factor.

Testing and verification definitely is a big market. Figuring out the port and
sensitivity list in Verilog/VHDL code doesn't seem hard, but coming up with
good test vectors automatically sounds pretty daunting (and interesting).

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

------
sybreon
With a web-app like this, I would be concerned about IP issues. Half the
industry is banking on IP unless they are open-source like the OR1K.
Otherwise, a proprietary house might be hesitant to upload HDL code even if it
is over a secure SSL connection.

For simulation with Icarus Verilog, it might be possible to upload the
compiled VVP binary. You can sell your computing power as a utility (ala cloud
computing) and help people save cost from buying an expensive server and save
time from having to wait days for results.

For FPGA selection, I personally doubt that your tool would be that useful
because this decision is primarily dictated by the cost of parts - rather than
the specific features. The hardware business is very cost-driven. What you can
do is to provide customers with the ability to perform synthesis over multiple
architectures for the purpose of 'testing' that their code works on them all.

~~~
harnhua
The IP issue is probably the top question from companies we talk to.

It may very well be the killer for this webapp, and we don't have a good
technical solution at the moment. However much we encrypt, the customer's IP
is going to sent to our Cloud anyway.

This reminds us of Dropbox in a way.

The non-technical "trust" factor seems to be very important here. Why would
one trust a consultant or a design service company with one's IP? Because of a
legally-binding contract and because of reputation / past interaction? That
probably plays a big part.

Some strategies we came up with:

If users don't trust us with their most important IP, we'll ask for their not-
so-important IP.

A support person probably has to meet the customer on a day-to-day basis,
which would somewhat defeat the purpose of a webapp, at first.

Yes, we would be selling computing power in a sense. But we're also trying to
do more to simplify working with FPGAs.

It's true that cost of parts is very important; that's why we're working on
reporting chip cost and availability too. Octopart is very helpful in that
respect!

Thanks for your comments!

------
Kirvy
Is there a way to tackle the problem of IP vendors not wanting to upload their
IP? The reason why we are online is that we can leverage on the cloud and make
things run 5X, 10x or 20x faster and cheaper.

But will we ever get the IP vendors to trust us? We once thought about doing
an 256bit AES client for them to encrypt their data before sending over. But
after chewing on it, we felt that the problem is a perception issue. It is a
matter of trust. It is like we use our credit cards online because we trust
the payment merchants with our details. Will this problem eventually be eroded
by time?

Oh btw, I am harnhua's cofounder. Thanks for all the wonderful views and
insights.

------
gte910h
I know many companies wouldn't allow your tool to be used for IP related
concerns. Perhaps you should make your tool into a downloadable service?

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

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

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

------
waratuman
I have only done a small amount of FPGA programming, so my comments may not be
that useful.

I have only ever used a Xilinx FPGA or CPLD, so seeing how an app would
compare on different FPGA's would be interesting, although for the apps that I
have developed it probably wouldn't matter that much.

I do agree that the current suits are often bulky and take a long time to
learn.

My comments may not be that useful, but I love seeing any thing that is
related to embedded programming on HN. Great work!

~~~
harnhua
That was pretty helpful - thanks!

When you mentioned that it probably wouldn't matter too much for the apps that
you developed, did you mean that they were too small/slow/<something> for you
to care?

Thanks for the encouragement. It's great fun shifting a traditionally desktop-
bound and kinda conservative application onto the web, and sort of distilling
the bare minimum features required to make it work.

~~~
waratuman
The apps that I have developed were so small and the requirements for the
projects did not require it to be fast. I hope to do a few more projects down
the road where speed will be an issue, but that is a ways away.

------
freescale
If you're targeting professional engineers, I'd worry that A. They could
figure out the answer to these questions on their own, or if not, B. one of
the large distribution companies would only be too happy to send out a sales
engineer to assist with the decision making process.

Are you targeting the hobbyist market? I'm not sure how much money they might
have.

~~~
harnhua
Thank you for your comments.

Some thoughts in response to your comments:

> professional engineers > A. They could figure out the answer to these
> questions on their own. [harnhua] True - what they would gain by using our
> webapp is convenience and automated testing/evaluation.

> B. one of the large distribution companies would only be too happy to send
> out a sales engineer to assist with the decision making process. [harnhua]
> Probably only if one is buying enough FPGAs/CPLDs to pay for that sales
> engineer? I reckon there should be many small-/medium-volume projects
> staffed by professional engineers who wouldn't attract such a level of
> customer service from the distributors. Sales engineers who're skilled in
> FPGAs are probably in short supply.

> hobbyist market [harnhua] Although there's little money there, we'd really
> like to make FPGAs easier to use for students and hobbyists as well.

Any thoughts?

------
ludwigvan
Cannot sign up. It says "Please tick on the checkbox below to agree to the
terms and conditions. Thank you." even if I click it.

~~~
harnhua
Sorry about that. That has been fixed.

Thanks for stopping by!

------
stevedekorte
I'd like tools for OSX.

~~~
blackguardx
Shouldn't OSX run most tools written for unix/linux?

~~~
harnhua
Before I started working on this webapp, I tried running the FPGA tools on Mac
OS X without much success. That was in the days of PowerPC Macs though.

Getting the necessary libraries to play nicely was a great pain.

After Virtualbox came out, running FPGA tools on my Mac became possible.

------
ableal
First thing I wanted to click: the pretty color bar picture
(<http://www.plunify.com/images/plunify_graph.gif> ); needs to link to a
bigger version.

Also, if you're using Flash for static charts, I'd suggest replacing with
pictures (no Flash player, nothing to see in
<http://www.plunify.com/reports.php> )

[clicky for the site: <http://www.plunify.com/>]

~~~
harnhua
Thanks, that picture has been updated with a link to the sample report page.

Are you accessing it from an iPhone by any chance? ;)

~~~
ableal
I'm just one of those eccentrics who think there's no Flash player like no
Flash player ;-)

But you made me interested enough to go fire up the page in another
machine/browser with Flash. Hmm ... spring-loaded animated charts ... in the
'Logic utilization' tab, there seems to be a mismatch between the full-scale
outline at the bottom and the section viewed.

I tried AOL's webpage tester (<http://www.webpagetest.org/result/100602_4TE/>
), to see how big was the Flash blob, but it timed out the first time.

A few other observations: you may want to add a line explaining how many
(equivalent) k-gates are in the sample design, and how long it took to get the
results (at the 1X speed ?).

Also, you may want to consider beefing up the 'How secure' answer in your FAQ.
Guaranteed to come up.

VNC session for GTKwave ? I think I saw some mention of VNC-in-browser
recently ...

Sign-up/sign-in worked OK. Thanks.

P.S. Forgive me, I'm sure you put a lot of work on those charts, but I would
really suggest exporting reports to a boring Open Office spreadsheet that
people could download, manipulate at will and print (or even view with Google
Docs or similar, if they're in all-web-all-the-time mode).

~~~
harnhua
No worries, please criticize as much as you like--that's how we can improve.

In fact, you've already convinced us to do the spreadsheet export thing. I see
your point there.

The Flash blob :) has a maximum width/height of 2880 pixels, I read.

Thanks again--we'll fix the charting bug and add the gatecount and runtime
information.

The VNC interface is a stop-gap that we're trying desperately to get rid of.
It's just too slow. Anything that requires installation is avoided as much as
possible. (Except for Flash, unfortunately :) )

A recent HN post talked about Smokescreen, an open source Javascript/HTML5
that sounded interesting. Doesn't seem to be ready yet though.

Thanks!

