5 ms·

It's not the bitstream format that is stopping you. It's the comprehensive tooling in this field that is not open which holds you back. Bitstream formats are n

It's not the bitstream format that is stopping you. It's the comprehensive tooling in this field that is not open which holds you back. Bitstream formats are nothing. It's like not having access to GCC but complaining to Intel about their microcode. There is so much more to the process of creating something useful with an fpga. Worrying about open bitstream formats is like worrying about Intel not disclosing how their microcode affected a single chip. It's not useful for much beyond a single chip, in the same way that many cpus in a family have different microarchitectures. The most useful tools in fpga dev have little to do with the part of translating the Verilog/Vhdl into something the fpga understands. Just going to add this: I had to install VMware (on OS X) and load an Ubuntu ISO just to play with Xilinx's tooling. I dev on win, Ubuntu, and OS X. Primarily Ubuntu. But just a heads up to anyone reading this that can positively affect this: if even I am on a Mac, it's time to expand your offering.

sklogic 11y ago
You need a synthesis tool - and there are open source alternatives. You need a cell library - a direct derivative of knowing a bitstream format. You need a place and route tool - as soon as format is known such tools would appear (as it happened with ice40). You need timing analysis, probably the hardest piece for community to produce without having an insider knowledge enjoyed by the vendors. All this stuff, including the libraries, can be pretty compact. There is no justification whatsoever for the ISE and Vivado bloat. The essential tools should be very compact. There are multiple copies of a microblaze toolchain, for example. WTF? I need none exactly. Zero. Nil. Stop bundling all the crap, please! Put it in a separate package so everybody could happily ignore it.
- coderdude 11y ago
  Many of the tools are command line. A few do require Gui to be useful. I absolutely agree that there is no need for the 8-10-20gb downloads that people endure to get this functionality. It's great to hear an experienced dev add to this discussion.
- nickpsecurity 11y ago
  "There is no justification whatsoever for the ISE and Vivado bloat. The essential tools should be very compact. There are multiple copies of a microblaze toolchain, for example. WTF? " That they were trying to include or support most of their devices or use cases in one distribution was my guess as to the reason for the bloat. Thanks for confirming it. I'll add that they'd do even better writing it in a LISP or ML-like language with macro's plus efficient compiler. The code would be readable, robust, efficient, and take no more space than necessary.
  - sklogic 11y ago
    They already wrote all of their GUI in a nice and compact Tcl. Still such a bloat. Cadence is using Lisp extensively, and their distributions are also not very small and are hard to maintain.
    - nickpsecurity 11y ago
      Didn't know about those lol... We already covered that the complex functionality and everything but the kitchen sink is reason for much of the bloat. With Cadence, it could be that plus legacy and/or coders that aren't good enough (or deadlines). Who knows. I just think they could be several times smaller if they only included necessary functionality and added extra's repo-style depending on one's device, use-case, and so on. Btw, is Lisp used for extensions over there or the whole application? And which LISP?
      - sklogic 11y ago
        They're using it for scripting, not for the core code, although there is a lot of Lisp code there. https://en.wikipedia.org/wiki/Cadence_SKILL https://en.wikipedia.org/wiki/Cadence_SKILL And, yes, it's about a time for the monolithic distros to die. People are already spoiled by package managers, there is no justification for 10gb downloads any more.
        nickpsecurity 11y ago
sobkas 11y ago
>It's not the bitstream format that is stopping you. It's the comprehensive tooling in this field that is not open which holds you back. It's like not having access to GCC[...] I don't think that having a tool that can't produce working binaries(bitstream or native code) would be that useful. Can you imagine a GCC that can't produce native code but instead have to generate COBOL sources(with almost random feature set) to be compiled by vendors tools? >[...]Intel about their microcode[...] Intel have a widely known instruction set that can be used with their cpus, there are many compilers, interpreters(and more) that generate and use it without problems, so I don't see how this analogy is relevant >There is so much more to the process of creating something useful with an fpga. You need tools and potential creators of such tools need access to bitstream format used by fpgas to create useful tools >The most useful tools in fpga dev have little to do with the part of translating the Verilog/Vhdl into something the fpga understands. But without the ability to translate your code(any code not just vhdl/some variant of verilog) into bitstream, where you would run* it on? It's hard to consider tool useful for fpga development when it can't produce something that can be run* on fpga... *oh come one, don't be pedantic
- coderdude 11y ago
  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.
pjc50 11y ago
The most useful tools in fpga dev have little to do with the part of translating the Verilog/Vhdl into something the fpga understands. Those tools generally are more "barely tolerable necessities" than "useful". Also, I think we're overdue some more languages for hardware development; both Verilog and VHDL are about 30 years old.
- lmm 11y ago
  Talk to /u/aninhumer about better alternatives and the difficulty of getting them adopted.
marcosdumay 11y ago
No, it's like complaining that Intel didn't document their processors opcode, so that nobody can ever write gcc.
- nickpsecurity 11y ago
  No, it's more like the micro-code. The RTL that matches their LUT's, etc are the opcodes. There's already academic and open tools targeting those. They just suck compared to proprietary ones because every aspect of EDA (even FPGA's) is Mega-Hard to do.

sklogic 11y ago

You need a synthesis tool - and there are open source alternatives. You need a cell library - a direct derivative of knowing a bitstream format. You need a place and route tool - as soon as format is known such tools would appear (as it happened with ice40). You need timing analysis, probably the hardest piece for community to produce without having an insider knowledge enjoyed by the vendors. All this stuff, including the libraries, can be pretty compact. There is no justification whatsoever for the ISE and Vivado bloat. The essential tools should be very compact. There are multiple copies of a microblaze toolchain, for example. WTF? I need none exactly. Zero. Nil. Stop bundling all the crap, please! Put it in a separate package so everybody could happily ignore it.

coderdude 11y ago
Many of the tools are command line. A few do require Gui to be useful. I absolutely agree that there is no need for the 8-10-20gb downloads that people endure to get this functionality. It's great to hear an experienced dev add to this discussion.
nickpsecurity 11y ago
"There is no justification whatsoever for the ISE and Vivado bloat. The essential tools should be very compact. There are multiple copies of a microblaze toolchain, for example. WTF? " That they were trying to include or support most of their devices or use cases in one distribution was my guess as to the reason for the bloat. Thanks for confirming it. I'll add that they'd do even better writing it in a LISP or ML-like language with macro's plus efficient compiler. The code would be readable, robust, efficient, and take no more space than necessary.
- sklogic 11y ago
  They already wrote all of their GUI in a nice and compact Tcl. Still such a bloat. Cadence is using Lisp extensively, and their distributions are also not very small and are hard to maintain.
  - nickpsecurity 11y ago
    Didn't know about those lol... We already covered that the complex functionality and everything but the kitchen sink is reason for much of the bloat. With Cadence, it could be that plus legacy and/or coders that aren't good enough (or deadlines). Who knows. I just think they could be several times smaller if they only included necessary functionality and added extra's repo-style depending on one's device, use-case, and so on. Btw, is Lisp used for extensions over there or the whole application? And which LISP?
    - sklogic 11y ago
      They're using it for scripting, not for the core code, although there is a lot of Lisp code there. https://en.wikipedia.org/wiki/Cadence_SKILL https://en.wikipedia.org/wiki/Cadence_SKILL And, yes, it's about a time for the monolithic distros to die. People are already spoiled by package managers, there is no justification for 10gb downloads any more.
      - nickpsecurity 11y ago

sobkas 11y ago

>It's not the bitstream format that is stopping you. It's the comprehensive tooling in this field that is not open which holds you back. It's like not having access to GCC[...] I don't think that having a tool that can't produce working binaries(bitstream or native code) would be that useful. Can you imagine a GCC that can't produce native code but instead have to generate COBOL sources(with almost random feature set) to be compiled by vendors tools? >[...]Intel about their microcode[...] Intel have a widely known instruction set that can be used with their cpus, there are many compilers, interpreters(and more) that generate and use it without problems, so I don't see how this analogy is relevant >There is so much more to the process of creating something useful with an fpga. You need tools and potential creators of such tools need access to bitstream format used by fpgas to create useful tools >The most useful tools in fpga dev have little to do with the part of translating the Verilog/Vhdl into something the fpga understands. But without the ability to translate your code(any code not just vhdl/some variant of verilog) into bitstream, where you would run* it on? It's hard to consider tool useful for fpga development when it can't produce something that can be run* on fpga... *oh come one, don't be pedantic

coderdude 11y ago
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.

pjc50 11y ago

The most useful tools in fpga dev have little to do with the part of translating the Verilog/Vhdl into something the fpga understands. Those tools generally are more "barely tolerable necessities" than "useful". Also, I think we're overdue some more languages for hardware development; both Verilog and VHDL are about 30 years old.

lmm 11y ago
Talk to /u/aninhumer about better alternatives and the difficulty of getting them adopted.

marcosdumay 11y ago

No, it's like complaining that Intel didn't document their processors opcode, so that nobody can ever write gcc.

nickpsecurity 11y ago
No, it's more like the micro-code. The RTL that matches their LUT's, etc are the opcodes. There's already academic and open tools targeting those. They just suck compared to proprietary ones because every aspect of EDA (even FPGA's) is Mega-Hard to do.