Ask HN's FPGA users: FPGA tool woes & wants?
12 comments
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.
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.
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>; 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.
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>; 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.
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.
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.
s/Utah/JTAG/ -- goddamn iPhone
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...
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...
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).
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).
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.
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.
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!
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!
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.
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.
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.
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.
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.
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.
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.
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!
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!
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.
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.
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?
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.
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.
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.
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!
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!
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.
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.
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.
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.
Are you targeting the hobbyist market? I'm not sure how much money they might have.
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?
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?
[deleted](1)
I'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.
Getting the necessary libraries to play nicely was a great pain.
After Virtualbox came out, running FPGA tools on my Mac became possible.
You'd think that, but no, there are often quirky issues. I've seen some apps port easier to cygwin on windows then to IntelMac.
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/]
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/]
Thanks, that picture has been updated with a link to the sample report page.
Are you accessing it from an iPhone by any chance? ;)
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/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).
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).
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!
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!
Any fellow FPGA users on HN? If you don't mind taking a moment to share your thoughts; it'll be really helpful!
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
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.
Existing tools don't seem to do these things, so we started building a webapp with the above features.
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)
Beta site: http://www.plunify.com
Thanks for reading; looking forward to your comments!