3 ms·

>> "Most importantly, we have to change the culture of hardware design. Today, we don’t have open sharing … " I'll have popcorn ready for the eventuality where

by rixrax 8y ago

>> "Most importantly, we have to change the culture of hardware design. Today, we don’t have open sharing … " I'll have popcorn ready for the eventuality where IP blocks are widely available under GPL type of FOSS licenses and Intel|AMD|ARM|TI|... is eventually found to include one or more of those open sourced blocks with incompatible license in their chips.

ur-whale 8y ago
The exact same arguments have been perused ad nauseam by old-timers in the software industry in the 80's and 90's when they clamored against open-source being anti-capitalist and un-american. Not sure how and why H/W is different.
- wrs 8y ago
  Different level of liability. When GPL missteps are discovered in software, the offender can usually just re-release the software without the GPL code and move on. In hardware…it's soldered into a bunch of devices all over the place. Consider Intel taking a $475 million hit for the FDIV bug (requiring a hardware replacement) vs the invisible bugfixing through microcode (i.e., software) they do now.
  - phkahler 8y ago
    You don't skip validation just because you use open source.
  - ummonk 8y ago
    They would just need to pay a fee to the copyright owner for the violations, not replace all the existing hardware.
- rixrax 8y ago
  I was thinking this mostly from the standpoint of viral nature of GPL-kind of FOSS licenses. E.g. somehow, somewhere someone manages to inject a GPL licensed IP block into a commercial CPU, after which, with my layman understanding, chip manufacturer now owes under the terms of GPL everyone who happens to have purchased one of those chips a full VHDL, Verilog etc. source code of the entire chip. In software you can always replace a library that had incompatible license with another. Not sure how this would work with a chip. As for attempts to modernize EDA industry, I welcome that in open arms. And if in the process we end up open sourcing a lot of current IP blocks (think of USB, HDMI, etc. designs) - all the better.
  - fjsolwmv 8y ago
    That is an absurdly wrong interpretation of both the GPL and how the courts exercise common sense.
    - dahauns 8y ago
      How would you interpret the GPL in above situation? Intuitively I'd thought something similar, but IANAL and could be completely wrong, of course :)
analognoise 8y ago
This will never, ever happen, so why ponder it?
JoachimS 8y ago
Not sure what cores will be needed for you to break out the popcorn. But there are actually quite a few cores available under open and free licenses. First off, the RISC-V community is based on the open ISA. There are several open implementations of the ISA. And the RISC-V community is meaking good headways in developing open tools, peripheral cores etc. https://riscv.org/ https://riscv.org/ Secondly there are at least two attempts at collecting and tracking open cores for FPGA- and ASIC-implementations. LibreCores is the newer project. They have collected quite a few projects: https://www.librecores.org/ https://www.librecores.org/ https://www.librecores.org/project/list https://www.librecores.org/project/list Related to LibreCores is the SoC-builder and core package handler Fusesoc by Olof Kindgren. Fusesoc makes creating your SoC easy: https://github.com/olofk/fusesoc https://github.com/olofk/fusesoc The older project is OpenCores. OpenCores has been quite tightly related to the OpenRISC CPU core, the wishbone set of on-chip interconnect solutions. They have been used in many FPGAs and ASICs https://opencores.org/ https://opencores.org/ https://openrisc.io/ https://openrisc.io/ Then you have projects like Cryptech that develops a complete, totally open, Hardware Security Module capable of doing certificate signing, OpenDNSSEC signing etc. The Cryptech Alpha design from PCB to FPGA cores and SW including pkcs11 handling is open. The project has amassed quite a few cores. The PCB design is available in kiCAD. (disclaimer: I'm part of the Cryptech core team doing a lot of the FPGA design work.) https://cryptech.is/ https://cryptech.is/ https://trac.cryptech.is/wiki/GitRepositories https://trac.cryptech.is/wiki/GitRepositories Speaking of tools like KiCAD, there are aqtually quite a few open tools for HW design. For simuation there are Icarus Verilog, Verilator, cver for example. They might not be as fast as VCS by Synoptsys. But they do work. I use them daily. http://iverilog.icarus.com/ http://iverilog.icarus.com/ https://www.veripool.org/projects/verilator/wiki/Intro https://www.veripool.org/projects/verilator/wiki/Intro For synthesis, P&R the state is less good. For implementation in Altera and Xilinx devices you currently have to use the cost free tools from the vendors. But there is work ongoing to reverse engineer Xilinx Spartan devices. I don't know the current state though. But what has been reverse engineered are the ICE40 FPGA devices from Lattice. And for these you can use the open tool Yosys by Clifford Wolf (also mentioned below by someone else). http://www.clifford.at/yosys/ http://www.clifford.at/yosys/ And if you are looking for open implementations of crypto functions etc I have quite a few on Github and try to develop more all the time: https://github.com/secworks https://github.com/secworks The sha256 and aes cores has been used in quite a few FPGA and ASIC designs. Right now I'm working on completing cores for the Blake2b and Blake2s hash functions. I agree that we in the HW community is waay behind the SW community in terms of open tools, libraries (i.e. cores). But it is not totally rotten, and it is getting better. RISC-V is to me really exciting.

by rixrax 8y ago

ur-whale 8y ago

The exact same arguments have been perused ad nauseam by old-timers in the software industry in the 80's and 90's when they clamored against open-source being anti-capitalist and un-american. Not sure how and why H/W is different.

wrs 8y ago
Different level of liability. When GPL missteps are discovered in software, the offender can usually just re-release the software without the GPL code and move on. In hardware…it's soldered into a bunch of devices all over the place. Consider Intel taking a $475 million hit for the FDIV bug (requiring a hardware replacement) vs the invisible bugfixing through microcode (i.e., software) they do now.
- phkahler 8y ago
  You don't skip validation just because you use open source.
- ummonk 8y ago
  They would just need to pay a fee to the copyright owner for the violations, not replace all the existing hardware.
rixrax 8y ago
I was thinking this mostly from the standpoint of viral nature of GPL-kind of FOSS licenses. E.g. somehow, somewhere someone manages to inject a GPL licensed IP block into a commercial CPU, after which, with my layman understanding, chip manufacturer now owes under the terms of GPL everyone who happens to have purchased one of those chips a full VHDL, Verilog etc. source code of the entire chip. In software you can always replace a library that had incompatible license with another. Not sure how this would work with a chip. As for attempts to modernize EDA industry, I welcome that in open arms. And if in the process we end up open sourcing a lot of current IP blocks (think of USB, HDMI, etc. designs) - all the better.
- fjsolwmv 8y ago
  That is an absurdly wrong interpretation of both the GPL and how the courts exercise common sense.
  - dahauns 8y ago
    How would you interpret the GPL in above situation? Intuitively I'd thought something similar, but IANAL and could be completely wrong, of course :)

analognoise 8y ago

This will never, ever happen, so why ponder it?

JoachimS 8y ago

Not sure what cores will be needed for you to break out the popcorn. But there are actually quite a few cores available under open and free licenses. First off, the RISC-V community is based on the open ISA. There are several open implementations of the ISA. And the RISC-V community is meaking good headways in developing open tools, peripheral cores etc. https://riscv.org/ https://riscv.org/ Secondly there are at least two attempts at collecting and tracking open cores for FPGA- and ASIC-implementations. LibreCores is the newer project. They have collected quite a few projects: https://www.librecores.org/ https://www.librecores.org/ https://www.librecores.org/project/list https://www.librecores.org/project/list Related to LibreCores is the SoC-builder and core package handler Fusesoc by Olof Kindgren. Fusesoc makes creating your SoC easy: https://github.com/olofk/fusesoc https://github.com/olofk/fusesoc The older project is OpenCores. OpenCores has been quite tightly related to the OpenRISC CPU core, the wishbone set of on-chip interconnect solutions. They have been used in many FPGAs and ASICs https://opencores.org/ https://opencores.org/ https://openrisc.io/ https://openrisc.io/ Then you have projects like Cryptech that develops a complete, totally open, Hardware Security Module capable of doing certificate signing, OpenDNSSEC signing etc. The Cryptech Alpha design from PCB to FPGA cores and SW including pkcs11 handling is open. The project has amassed quite a few cores. The PCB design is available in kiCAD. (disclaimer: I'm part of the Cryptech core team doing a lot of the FPGA design work.) https://cryptech.is/ https://cryptech.is/ https://trac.cryptech.is/wiki/GitRepositories https://trac.cryptech.is/wiki/GitRepositories Speaking of tools like KiCAD, there are aqtually quite a few open tools for HW design. For simuation there are Icarus Verilog, Verilator, cver for example. They might not be as fast as VCS by Synoptsys. But they do work. I use them daily. http://iverilog.icarus.com/ http://iverilog.icarus.com/ https://www.veripool.org/projects/verilator/wiki/Intro https://www.veripool.org/projects/verilator/wiki/Intro For synthesis, P&R the state is less good. For implementation in Altera and Xilinx devices you currently have to use the cost free tools from the vendors. But there is work ongoing to reverse engineer Xilinx Spartan devices. I don't know the current state though. But what has been reverse engineered are the ICE40 FPGA devices from Lattice. And for these you can use the open tool Yosys by Clifford Wolf (also mentioned below by someone else). http://www.clifford.at/yosys/ http://www.clifford.at/yosys/ And if you are looking for open implementations of crypto functions etc I have quite a few on Github and try to develop more all the time: https://github.com/secworks https://github.com/secworks The sha256 and aes cores has been used in quite a few FPGA and ASIC designs. Right now I'm working on completing cores for the Blake2b and Blake2s hash functions. I agree that we in the HW community is waay behind the SW community in terms of open tools, libraries (i.e. cores). But it is not totally rotten, and it is getting better. RISC-V is to me really exciting.