11–20 of 37 posts
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/]
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 yo…
Yes, I think it's beautiful to try to apply software/computer science/statistical methods to a hardware field.
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/ ]
Are you accessing it from an iPhone by any chance? ;)
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 yo…
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…
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.
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/ ]
Thanks, that picture has been updated with a link to the sample report page. Are you accessing it from an iPhone by any chance? ;)
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).
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.
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...
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.
I'd like tools for OSX.
