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?
Ask HN's FPGA users: FPGA tool woes & wants?
21–30 of 37 posts
Re: Ask HN's FPGA users: FPGA tool woes & wants?
#22Is 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.
Re: Ask HN's FPGA users: FPGA tool woes & wants?
#23With 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 h…
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!
Re: Ask HN's FPGA users: FPGA tool woes & wants?
#24I'd like tools for OSX.
Shouldn't OSX run most tools written for unix/linux?
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.
Re: Ask HN's FPGA users: FPGA tool woes & wants?
#25I 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 fea…
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).
Re: Ask HN's FPGA users: FPGA tool woes & wants?
#26Earlier quoted context omitted.
Thanks, that picture has been updated with a link to the sample report page. Are you accessing it from an iPhone by any chance? ;)
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/re…
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!
Re: Ask HN's FPGA users: FPGA tool woes & wants?
#27I 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?
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.
Re: Ask HN's FPGA users: FPGA tool woes & wants?
#28The 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 remain sane trying to decipher all of them.
Thanks!
Re: Ask HN's FPGA users: FPGA tool woes & wants?
#29I 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?
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.
Re: Ask HN's FPGA users: FPGA tool woes & wants?
#30I 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…
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/ 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.
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.