3 ms·

I'm on my phone so I'll try to address each of your points in order (copy paste is painful on mobile). The tools available for that task are compact and I'd im

I'm on my phone so I'll try to address each of your points in order (copy paste is painful on mobile). The tools available for that task are compact and I'd imagine quite portable based on the OSes they are already supported on. Huge vendor downloads aside, I don't think the problem in the ecosystem is with those tools not being OSS. Intel's instruction set (ISA if you will, for those reading), is at a higher level than microcode. Microcode is specific to an architecture but not the instruction set. No programmer touches microcode and as far as I'm aware, it's secret and proprietary. The useful tools to be created that would be open are not related to bitstream formats. (This is actually an assumption that I cannot fully verify at this time.) I'm not not sure how to address the last point. I'm not trying to be pedantic at all. I'll come back to this as I wrap my head around it. Edit: I'm continuing to make small edits to grammar and wording.

sobkas 11y ago
Intel cpu is stll useful without pushing external microcode to it, while the point of fpga is the ability to program/configure it. Also there are many usefull tools that could be created if bitstream format was known. Some of with could be usefull for other devs, not only fpga devs. And there are so many things you could potentially do with your bitstream, like generating it on the fly. While floss tools would be nice,(gcc or llvm compiling a function to be accelarated by fpga, and then proper bitsream be genarated on startup by fpga driver) but just having alternatives from vendor suplied toolchain would be good.
- coderdude 11y ago
  I may not fully grok your argument at this time but I will come back and read this again later so that I can respond better. I do appreciate your feedback because this topic is of great interest to me.

sobkas 11y ago

Intel cpu is stll useful without pushing external microcode to it, while the point of fpga is the ability to program/configure it. Also there are many usefull tools that could be created if bitstream format was known. Some of with could be usefull for other devs, not only fpga devs. And there are so many things you could potentially do with your bitstream, like generating it on the fly. While floss tools would be nice,(gcc or llvm compiling a function to be accelarated by fpga, and then proper bitsream be genarated on startup by fpga driver) but just having alternatives from vendor suplied toolchain would be good.

coderdude 11y ago
I may not fully grok your argument at this time but I will come back and read this again later so that I can respond better. I do appreciate your feedback because this topic is of great interest to me.