5 ms·

I don't know if they realize this, but imo all they cause it having less people working with FPGA's. As a result it's not a tool people will reach to when it co

I don't know if they realize this, but imo all they cause it having less people working with FPGA's. As a result it's not a tool people will reach to when it could be used.

buserror 11y ago
Yeah, what stops me usualy plonking one in my project is the 20GB of IDE I'll have to install to have the pleasure of seeing it take /forever/ to do it's thing. However this has just changed. There is an excellent project at http://www.clifford.at/icestorm/ http://www.clifford.at/icestorm/ that has reversed the format for a series of the Lattice FPGA and provide an open source end-to-end solution... And AFAIK they haven't been told off for doing so. I therefore have one of their USB stick evaluation board on my desk to have a play with as soon as I can. They also have 'hacker friendly' packages.
- swiley 11y ago
  I bought one and definitely recommend it. I played around writing a brainfuck machine in verilog to learn it and it's very different.
coderdude 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. 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.

I don't know if they realize this, but imo all they cause it having less people working with FPGA's. As a result it's not a tool people will reach to when it could be used.

buserror 11y ago

Yeah, what stops me usualy plonking one in my project is the 20GB of IDE I'll have to install to have the pleasure of seeing it take /forever/ to do it's thing. However this has just changed. There is an excellent project at http://www.clifford.at/icestorm/ http://www.clifford.at/icestorm/ that has reversed the format for a series of the Lattice FPGA and provide an open source end-to-end solution... And AFAIK they haven't been told off for doing so. I therefore have one of their USB stick evaluation board on my desk to have a play with as soon as I can. They also have 'hacker friendly' packages.

swiley 11y ago
I bought one and definitely recommend it. I played around writing a brainfuck machine in verilog to learn it and it's very different.

coderdude 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. 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.