3 ms·

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

by blasdel 16y ago

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 16y ago
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&#62 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 16y ago
  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 16y ago
    s/Utah/JTAG/ -- goddamn iPhone

by blasdel 16y ago

harnhua 16y ago

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&#62 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 16y ago
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 16y ago
  s/Utah/JTAG/ -- goddamn iPhone