11 ms·

> FPGAs are a programmable platform, but one designed by EEs for EEs rather than for programmers. This is the problem with FPGAs. Their performance and utility

• walkingolof 8y ago
  One exception, the ICE range from Lattice which have a open source tool-chain https://en.wikipedia.org/wiki/ICE_(FPGA) https://en.wikipedia.org/wiki/ICE_(FPGA)
  • davemp 8y ago
    AFAIK that tool-chain is thanks to the reverse engineering efforts of an individual and not Lattice itself. It's a step towards the right direction, but not really a first class vendor supported tool.
    • kbob 8y ago
      That's where GCC was circa 1988.
• xigency 8y ago
  > The EE world is notoriously closed/proprietary See the IEEE.
  • RandomInteger4 8y ago
    Can you elaborate?
    • Cyph0n 8y ago
      IEEE tracks a vast number of open standards and specifications (e.g., Ethernet, WiFi, Bluetooth). I guess the comment was pointing out that there is a degree of openness in EE.
      • anfilt 8y ago
        I agree the EE community as whole is not bad. I would say though companies that hire EEs tend be more secretive than mainly software companies.
      • dmitrygr 8y ago
        > IEEE tracks a vast number of open standards And demands mega-bucks for a PDF of any of those standards
        • jjoonathan 8y ago
          So that organizations with money that benefit from the standards pay for their creation. For everyone else, there's scihub.
        • Cyph0n 8y ago
          So how do you propose a non-profit like the IEEE make money?
          • dmitrygr 8y ago
            Collecting $ from member orgs, and not from hobbyists who just want to tinker? How else do you propose to raise the next generation of hackers? By charging them $6000 to simply see a spec they have a minute interest in tinkering with?
            • Cyph0n 8y ago
              Standards bodies usually give hobbyists access to documents if asked, but with strings attached, of course. In other words, they need to somehow prove that you will not be using the spec in a commercial setting. This was my experience with the TCG, for example. As for the IEEE 802 standards, it seems like individuals can get full access to all specification documents that are 6 months and older via the IEEE GET program: https://ieeexplore.ieee.org/browse/standards/get-program/page/series?id=68 https://ieeexplore.ieee.org/browse/standards/get-program/pag.... That sounds pretty fair, no? In general, standards groups provide access in a similar way to software companies that give out free (or low-cost) access to their tools for open source developers and university students.
• hinkley 8y ago
  From what I understand, chips are now laid out by an optimizer instead of by humans. The humans design an adder, but the software picks where to place it and how to arrange the gates. I took a couple undergrad classes in CE, which makes me dangerous, but can we be that far away from building a macro system to convert small bits of imperative code into FPGA logic?
  • jeffreyrogers 8y ago
    Naively translating imperative code to run on FPGAs won't do much in the general case. It takes time to get data to and from the FPGA so whatever you're doing on the FPGA has to be time consuming enough to make up for the time spent shuffling data around. FPGAs tend to excel at things that are highly parallel (e.g. routing) or streaming applications (e.g. audio/video codecs), so most applications don't have obvious ways to benefit from an FPGA.
    • tyingq 8y ago
      I'd also throw in "things that have precise timing considerations" to the list. Like driving an LED display, etc.
• sfifs 8y ago
  Actually I recently bought a Spartan 7 based FPGA board after taking the nand2tetris course and started playing with the free version of the Vivado suite. If your complaint is principle based on the stuff being non free software, then it holds. If it's on usability - not sure it does. While lengthy, the process of compiling and getting something running on silicon didn't seem any more complicated than Grade/Maven etc all based Android Studio builds.
  • ThePadawan 8y ago
    > While lengthy, the process of compiling and getting something running on silicon didn't seem any more complicated than Grade/Maven etc all based Android Studio builds. I'm not sure many people would share your opinion that Gradle/Maven are uncomplicated. Personally, I would say they belong to the 20% most complicated build toolchains I have encountered - which would make the FPGA process still not very uncomplicated in comparison.
    • sfifs 8y ago
      > Personally, I would say they belong to the 20% most complicated build toolchains I have encountered I actually agree which is why I used that as a comparison. Over a million developers deal with it every day of their work lives and the FPGA tooling I dealt with did not seem any more complicated than something that's very mainstream.
    • user5994461 8y ago
      Maven is just right click + build to build. Or file + import to import a project. The last time I worked with Vivado, I remember our interns couldn't manage to create a project or use an existing project after a whole week. It doesn't help that there are no tutorials from the vendor or the internet, or that projects can't be stored in source control.
      • noselasd 8y ago
        Maven is that simple when someone have gone through all the pain of setting things up - but someone have to do that too - it is a battle for all but the very simplest of projects.
• monocasa 8y ago
  The hard part AFAICT, is the modeling of the chip for timing analysis. Whereas all of the timing information is explicitly defined for programmers on CPUs, that timing information (and the models of how FPGAs are binned) is extremely proprietary for FPGA vendors, to the point of being treated as a trade secret. Since they use custom cell layouts, I've heard that they consider the timing information core to their IP. If another vendor got them, the could conceivably see what interesting points are optimized past a foundary's standard cells because of the tighter timing guarantees than they might should have. Now, I'm personally of the opinion that their competitors have taken their chips into one of those nifty 3d xrays and know the exact layout of the cells anyway, but it's hard to push that idea.
  • nickpsecurity 8y ago
    I saw some good reverse engineering of FPGA's like this work: https://vtechworks.lib.vt.edu/bitstream/handle/10919/51836/Soni_RK_T_2013.pdf https://vtechworks.lib.vt.edu/bitstream/handle/10919/51836/S... It has a lot of details on things that are clock-related. Since Im not hardware guy, I can't ssy if it has info needed, if another work could get it building on this, or what. So, what you think?
    • monocasa 8y ago
      It's not quite what I'm talking about, and what he has listed there is generally pseudo publicly documented. Xilinx for instance, more or less supports programming at the bitstream level rather than the HDL level for stuff like runtime reconfigurable blocks. So there isn't much there in his thesis that isn't covered in the docs. What he covers (for the purpose of this discussion) is how the clock blocks (straight up PLLs if you've done any embedded development) are connected to the rest of the fabric. That's sort of the digital side, and the hard part is the analog side. Ie. "what are the propagation delays of different configuration of LUTs and fabric, and who can you play games with in place and route in order to meet timing". It's an important feedback step in place and route. You can get neat trivial stuff running, but without decent timing analysis it'll be hard to tell if your design will have weird bugs at runtime. Or will lack optimizations that will help you meet timing with an equivalent design. I mean, that stuff is almost a black art even with high quality timing analysis.
• TomVDB 8y ago
  > The EE world is notoriously closed/proprietary making it incredibly difficult to explore novelty or customize tooling to suit specific needs. The EE world could use novelty tooling to increase the efficiency by which you create RTL. But that can easily be done today if you consider Verilog to be an intermediate representation. So I think you're talking about the tooling on the steps to go from RTL to bitstream? What kind of novel tooling do you have in mind? In Quartus and ISE, once you've set up the pin assignments, going from RTL to a bitstream is a matter of a single click.
  • atq2119 8y ago
    There's potentially tremendous value in having an open bitstream. To get the most out of hardware, you need feedback on how many LUTs each part of your design uses, where the critical dependencies are for the achievable clock rates, and so on. It's difficult to get this information in a usable way in practice today even when you're writing Verilog. Using Verilog as an intermediate language makes the problem significantly worse. Imagine there was the equivalent of LLVM for FPGA development. Without open bitstreams, that's never going to happen. (Even with open bitstreams, it'd need tremendous effort to get there, but at least there'd be a chance.)
    • TomVDB 8y ago
      > To get the most out of hardware, you need feedback on how many LUTs each part of your design uses, where the critical dependencies are for the achievable clock rates, and so on. In practice, if you code your Verilog with speed in mind (limited levels of combinational logic, plenty of pipeline stages, one-hot encodings, ...), the synthesis and fitter tool will do an excellent job of extracting high speed. The modern ones will do register clone, pull in registers into RAMs and DSPs etc. In case of timing problems, the timing analyzer will already show you the critical path, the amount of LUTs, and how the critical paths is routed. The hardest part of figuring out why a particular path is violating timing is not because of the reporting of the tools, it's because a blob of logic has been flattened and merged into a LUT, and it's hard to identify how a LUT corresponds to the RTL. Maybe a custom tool can help debugging these kind of things, but I think it's a very narrow case, and IMO not the kind of thing that makes EDA tools unergonomic. > It's difficult to get this information in a usable way in practice today even when you're writing Verilog. Using Verilog as an intermediate language makes the problem significantly worse. That was not my point. My point is: if your goal is to make FPGA design more ergonomic (whatever that means), there's a much higher !/$ in improving the front-end design process than the back-end.
• ChuckMcM 8y ago
  I too decry the lack of openness with respect to the data file encoding which would allow for more open source tools to be created. I had a hilarious discussion with Xilinx's VP of tools about this[1]. The interesting thing about HDLs and HDL work flows is that they can "look" like software and yet not be software. VHDL and Verilog are the only "languages" I know where you can write something that is both syntactically correct and cannot by inferred into logic by the synthesis part of the tool (equivalent of the code generator in a compiler). I am not aware of any equivalent to the Turing definition of computability which would prove for any legal construct in language X there was an implementation of synchronous logic Y that could implement it. Most of the bugs are easy to avoid once you know them though, things like a register value being assigned two different values in the same process block. That said, I've been playing lately with an "Ultra96"[2] board which is pretty freakin' cool. quad core 64 bit ARM CPU and a nice chunk of FPGA fabric to play with as well. I think it can be the basis for a pretty sweet SDR setup. [1] His assertion was that things had to be hidden so that they could protect the value of the software, when I countered they could put a 5% tax on every chip they sold and allocate it to software which would give his team more money than it had today, he argued he would lose sales to cheaper FPGAs, and I asked how the people trying to sell C compilers were holding up, and would anyone buy chips if they had to pay extra for their tools when a top chip maker gave away their tools for free? And then he said it needed to be proprietary to keep the quality up, and I went back and asked what C compiler he used, and he admitted they used GCC (when they were compiling for Petalinux etc) and I asked why they didn't use a proprietary C/C++ compiler? And he said they didn't keep up with the standards and gcc generated just as good code generally as the proprietary ones did. He was left with "just because" as his only rational for not making all of the documentation freely available and using the cost of the chips to leverage the tools cost (which I told him would go away as soon as the open source community had caught up with and surpassed Vivado) [2] http://zedboard.org/product/ultra96 http://zedboard.org/product/ultra96
  • esmi 8y ago
    The arguement in [1] doesn't make sense to me. Xilinx tools are free, as in beer, and the sale of ICs funds those tools so they are implementing your system of a "tax on every chip". Surely the VP of tools at Xilinx knows this. What problem are you unable to solve with an FPGA because you do not have the source code to Vivado? I understand why Xilinx doesn't want to release their source. They don't want to support it. Supporting code is a huge overhead and it's not clear, to me anyway, what Xilinx gains from the expendature.