9 ms·

I believe the major disruption waiting to happen in chip design is open source tools, and the hardware languages. Frankly, the closed source tools are pretty a

I believe the major disruption waiting to happen in chip design is open source tools, and the hardware languages. Frankly, the closed source tools are pretty awful from a user interface perspective. Under the hood, amazing things happen, but the tools are pretty awful to use. and the languages... ugh, the languages. Our big leap forward was SystemVerilog. It's a bastardization of three languages: of 80's c++, 80's Verilog, and an interesting constraint solver in a distinct dialect. We need (in my humble opinion): * Open source high performance discrete event simulator (language agnostic, use an intermediate representation like a source mapped netlist) * Said simulator, but distributed (multi core, process, data center) * An ecosystem that encourages language development (Said simulator could help) * An open source synthesis framework that can read the intermediate representation netlist. * GUIs that don't cause eye hemorrhaging and monitor punching.

pjc50 9y ago
Having spent about a decade in a chip design software startup that was eventually bought by Cadence, I'll say: - you're absolutely right that the tools are horrible to use, and Verilog's time is up - existing chip design companies are extremely conservative and hate adopting anything new even from their own preferred vendor, because risk - a lot of the key knowledge is spread by apprenticeship and oral culture; analog IC engineers are another culture altogether
- phlipski 9y ago
  I spent over a decade doing circuit design and I can corroborate your points. Chip design is maddening! One of the most interesting differences between software and hardware engineering is how many blogs and writing on the web you can find about software. You can almost self teach a masters in CS through online blogs and various postings! The only writing you find online about hardware is either patent's or IEEE white-papers. There is still something magical when a new chip design comes back from the fab and boots up!
adapteva 9y ago
Working on it... https://www.fbo.gov/spg/ODA/DARPA/CMO/HR001117S0054/listing.html https://www.fbo.gov/spg/ODA/DARPA/CMO/HR001117S0054/listing....
- deepnotderp 9y ago
  I especially like your focus on physical design, as it (along with verification) is usually the bottleneck in modern cutting edge node chip development. Any plans to update the public about progress?
- ebcode 9y ago
  I don't see how this will ever work. The needs of the defense sector are just fundamentally at odds with the needs of the commercial sector. On the hardware side you get things like Intel and AMD trying to hide "chips within chips", and on the software side you get things like foreign governments demanding to inspect proprietary software before they'll allow it to be imported. The past and present are mired in "national interests"; but the real obstacle seems to be the idea that you can prevent other people from having what you have (an idea, a weapon, a key, etc.). EDIT: I was responding to this quote from your link: "The goal of the ERI is to more constructively enmesh the technology needs and capabilities of the defense enterprise with the commercial and manufacturing realities of the electronics industry." I didn't mean to imply that what your company is working on won't work. Unless, of course, that is what your company is working on.
dbcurtis 9y ago
I worked in EDA for several years, late 80's/early 90's. Its tough. Yes, the current tools are miserable. But the market isn't huge, so there are only so many development dollars to go around. And the interfaces between tools are information-lossy kludges held together with duct tape and string. Open source is hard, because without access to the data, it is hard to do a good tool like a timing analyzer. Heck, when you do have access to the data and you can talk to the physical chemist that designed the process because his desk is 5 rows over it is still hard to get it better than "close enough". I've thought many times about doing an open source event-driven logic simulator. At one point, I was a top guru of that technology. The thing is, I doubt if a sufficient number of people would care, and it is basically worthless without all the tools that feed it and drive it.
- deepnotderp 9y ago
  Email me (email in profile) please, would love to connect.
- FPGAhacker 9y ago
  I would be happy if all my bullet points applied only to cycle accurate sims. I think the market would create itself with the right ingredients present. I think a high level language, a well defined intermediate representation with an eye toward synthesis but initially just targeting simulation, and a cycle accurate high performance simulator for said intermediate language would be explosive. (bonus points for writing the sim in WASM, heh)
  - dbcurtis 9y ago
    WASM? Well, if I'm going to tilt at windmills, I'll use the project to learn Rust while I'm at it. Explosive? I remain unconvinced. There just aren't enough people doing that kind of work. I am excited to see progress in open source FPGA fitters. I've always felt those would be hard to do because without access to the performance model, it is hard to do a good job of auto-placement. So that is cool, even though the current open source tool (I forget the name...) only does a few FPGAs.
deepnotderp 9y ago
Heh, #1 and #2 we are developing internally. Bonus points is that it supports analog/mixed signal as well through the chosen abstraction (SPICE level black box), models leakage, power consumption and thermals as well. Email me (on profile) if you want to connect. For a public example, our simulator is very similar to Level 2 of the PARADISE flow being developed at LBNL.
lambda 9y ago
On the languages front, there is Chisel, which looks promising. I'm not a hardware guy, but Chisel looks a lot more reasonable to work with than VHDL/Verilog, and it's good enough for doing real work on RISC-V. As someone who has thought about dabbling in this space, I'm curious about the thoughts of anyone who has worked with it: https://chisel.eecs.berkeley.edu/ https://chisel.eecs.berkeley.edu/ For the rest; yeah, it looks like it's pretty eye-bleeding and hacked together from decades worth of odd little one-off tools: http://opencircuitdesign.com/qflow/ http://opencircuitdesign.com/qflow/, https://opencores.org/howto/eda https://opencores.org/howto/eda, https://chitlesh.fedorapeople.org/papers/FEL12ReleaseNotes.pdf https://chitlesh.fedorapeople.org/papers/FEL12ReleaseNotes.p...
- anfilt 9y ago
  I would stick with VHDL and SystemC. Any tools that could actual synthesize your designs are going to handle VHDL and Verilog. I do prefer VHDL to verilog. My main reason is Verilog does not make a distinction between variables and other objects. Verilog treats almost everything as if it were an assignment type. Furthermore, variables in verilog are shared by default. VHDL shows how it should be done. There is a clear distinction between signals and variables. Additionally, variables are local by default. My opinion of course. Although VHDL can be bit more wordy. However, that's least of my worries (wordiness) when designing something. I would rather have clear semantics for me and other people on what the heck is going on. However, Verilog is just as capable.
  - lambda 9y ago
    Chisel compiles to Verilog, so you can use that to bridge to other tools for actually synthesizing your designs. But it brings with it the full flexibility of a general purpose programming language which makes it a lot easier to make parameterizable designs which can be more easily reused.
  - tails4e 9y ago
    SystemVerilog is much more capable than either verilog or VHDL, and has brought many of the VHDL safety features to make design with it safer by construction, plus more, without the wordiness. Yes you can still write bad code, but any decent hardware flow, or synthesis step will catch basic things like mis-sharing of variables etc. I agree it's a language weakness it's not an issue in practical hardware design. In addition to The design enhancements, the fact it's got pretty powerful verification features makes it my language of choice today, at least among the low level HDLs.
tails4e 9y ago
I'm not sure open source EDA will happen and be as competitive as open source software has been in general. Many of the tools are extremely complex. For your example of just a simulator and systemverilog: the spec for SV is more than 10 years old, yet the best oss can do today is compatability with a small subset of it, and orders of magnitude slower than a commercial simulator. The reason? The skill set to write one of these not only needs very solid programming skills and knowledge of advanced algorithms for performance, but also some domain knowledge to understand how the tool should work from the user side and he side. This last point is the reason most oss EDA today is written by hw engineers who know some programming, rather than true software developers. Of course you will get some cases where a single engineer knows both areas well and produces some nice/interesting tools like vloghammer, icarus, ventilator, etc. However these folks are rare, and for oss EDA to be truly competitive it needs many contributors with this skillset. Thats why a language as big as SystemVerilog has not once been fully implemented in open source yet. So hard to see the other, arguably harder, challenges like Place and route, STA (on smaller nodes), analog simulation, parasitic extraction, etc being taken on in oss EDA for anything but older technologies, or with very limited capabilities. Open source IP on the other hand could take off.
- FPGAhacker 9y ago
  I read all that as an indictment of SystemVerilog rather than of simulators. I agree with the assessment of hw engineers doing software.
  - tails4e 9y ago
    So why has it not happened in your opinion for SV, or spice or place and route despite there being references for each of these available for in some cases decades? There are free implementations of these but in each case they don't come close to a commercial offering.

pjc50 9y ago

Having spent about a decade in a chip design software startup that was eventually bought by Cadence, I'll say: - you're absolutely right that the tools are horrible to use, and Verilog's time is up - existing chip design companies are extremely conservative and hate adopting anything new even from their own preferred vendor, because risk - a lot of the key knowledge is spread by apprenticeship and oral culture; analog IC engineers are another culture altogether

phlipski 9y ago
I spent over a decade doing circuit design and I can corroborate your points. Chip design is maddening! One of the most interesting differences between software and hardware engineering is how many blogs and writing on the web you can find about software. You can almost self teach a masters in CS through online blogs and various postings! The only writing you find online about hardware is either patent's or IEEE white-papers. There is still something magical when a new chip design comes back from the fab and boots up!

adapteva 9y ago

Working on it... https://www.fbo.gov/spg/ODA/DARPA/CMO/HR001117S0054/listing.html https://www.fbo.gov/spg/ODA/DARPA/CMO/HR001117S0054/listing....

deepnotderp 9y ago
I especially like your focus on physical design, as it (along with verification) is usually the bottleneck in modern cutting edge node chip development. Any plans to update the public about progress?
ebcode 9y ago
I don't see how this will ever work. The needs of the defense sector are just fundamentally at odds with the needs of the commercial sector. On the hardware side you get things like Intel and AMD trying to hide "chips within chips", and on the software side you get things like foreign governments demanding to inspect proprietary software before they'll allow it to be imported. The past and present are mired in "national interests"; but the real obstacle seems to be the idea that you can prevent other people from having what you have (an idea, a weapon, a key, etc.). EDIT: I was responding to this quote from your link: "The goal of the ERI is to more constructively enmesh the technology needs and capabilities of the defense enterprise with the commercial and manufacturing realities of the electronics industry." I didn't mean to imply that what your company is working on won't work. Unless, of course, that is what your company is working on.

dbcurtis 9y ago

I worked in EDA for several years, late 80's/early 90's. Its tough. Yes, the current tools are miserable. But the market isn't huge, so there are only so many development dollars to go around. And the interfaces between tools are information-lossy kludges held together with duct tape and string. Open source is hard, because without access to the data, it is hard to do a good tool like a timing analyzer. Heck, when you do have access to the data and you can talk to the physical chemist that designed the process because his desk is 5 rows over it is still hard to get it better than "close enough". I've thought many times about doing an open source event-driven logic simulator. At one point, I was a top guru of that technology. The thing is, I doubt if a sufficient number of people would care, and it is basically worthless without all the tools that feed it and drive it.

deepnotderp 9y ago
Email me (email in profile) please, would love to connect.
FPGAhacker 9y ago
I would be happy if all my bullet points applied only to cycle accurate sims. I think the market would create itself with the right ingredients present. I think a high level language, a well defined intermediate representation with an eye toward synthesis but initially just targeting simulation, and a cycle accurate high performance simulator for said intermediate language would be explosive. (bonus points for writing the sim in WASM, heh)
- dbcurtis 9y ago
  WASM? Well, if I'm going to tilt at windmills, I'll use the project to learn Rust while I'm at it. Explosive? I remain unconvinced. There just aren't enough people doing that kind of work. I am excited to see progress in open source FPGA fitters. I've always felt those would be hard to do because without access to the performance model, it is hard to do a good job of auto-placement. So that is cool, even though the current open source tool (I forget the name...) only does a few FPGAs.

deepnotderp 9y ago

Heh, #1 and #2 we are developing internally. Bonus points is that it supports analog/mixed signal as well through the chosen abstraction (SPICE level black box), models leakage, power consumption and thermals as well. Email me (on profile) if you want to connect. For a public example, our simulator is very similar to Level 2 of the PARADISE flow being developed at LBNL.

lambda 9y ago

On the languages front, there is Chisel, which looks promising. I'm not a hardware guy, but Chisel looks a lot more reasonable to work with than VHDL/Verilog, and it's good enough for doing real work on RISC-V. As someone who has thought about dabbling in this space, I'm curious about the thoughts of anyone who has worked with it: https://chisel.eecs.berkeley.edu/ https://chisel.eecs.berkeley.edu/ For the rest; yeah, it looks like it's pretty eye-bleeding and hacked together from decades worth of odd little one-off tools: http://opencircuitdesign.com/qflow/ http://opencircuitdesign.com/qflow/, https://opencores.org/howto/eda https://opencores.org/howto/eda, https://chitlesh.fedorapeople.org/papers/FEL12ReleaseNotes.pdf https://chitlesh.fedorapeople.org/papers/FEL12ReleaseNotes.p...

anfilt 9y ago
I would stick with VHDL and SystemC. Any tools that could actual synthesize your designs are going to handle VHDL and Verilog. I do prefer VHDL to verilog. My main reason is Verilog does not make a distinction between variables and other objects. Verilog treats almost everything as if it were an assignment type. Furthermore, variables in verilog are shared by default. VHDL shows how it should be done. There is a clear distinction between signals and variables. Additionally, variables are local by default. My opinion of course. Although VHDL can be bit more wordy. However, that's least of my worries (wordiness) when designing something. I would rather have clear semantics for me and other people on what the heck is going on. However, Verilog is just as capable.
- lambda 9y ago
  Chisel compiles to Verilog, so you can use that to bridge to other tools for actually synthesizing your designs. But it brings with it the full flexibility of a general purpose programming language which makes it a lot easier to make parameterizable designs which can be more easily reused.
- tails4e 9y ago
  SystemVerilog is much more capable than either verilog or VHDL, and has brought many of the VHDL safety features to make design with it safer by construction, plus more, without the wordiness. Yes you can still write bad code, but any decent hardware flow, or synthesis step will catch basic things like mis-sharing of variables etc. I agree it's a language weakness it's not an issue in practical hardware design. In addition to The design enhancements, the fact it's got pretty powerful verification features makes it my language of choice today, at least among the low level HDLs.

tails4e 9y ago

I'm not sure open source EDA will happen and be as competitive as open source software has been in general. Many of the tools are extremely complex. For your example of just a simulator and systemverilog: the spec for SV is more than 10 years old, yet the best oss can do today is compatability with a small subset of it, and orders of magnitude slower than a commercial simulator. The reason? The skill set to write one of these not only needs very solid programming skills and knowledge of advanced algorithms for performance, but also some domain knowledge to understand how the tool should work from the user side and he side. This last point is the reason most oss EDA today is written by hw engineers who know some programming, rather than true software developers. Of course you will get some cases where a single engineer knows both areas well and produces some nice/interesting tools like vloghammer, icarus, ventilator, etc. However these folks are rare, and for oss EDA to be truly competitive it needs many contributors with this skillset. Thats why a language as big as SystemVerilog has not once been fully implemented in open source yet. So hard to see the other, arguably harder, challenges like Place and route, STA (on smaller nodes), analog simulation, parasitic extraction, etc being taken on in oss EDA for anything but older technologies, or with very limited capabilities. Open source IP on the other hand could take off.

FPGAhacker 9y ago
I read all that as an indictment of SystemVerilog rather than of simulators. I agree with the assessment of hw engineers doing software.
- tails4e 9y ago
  So why has it not happened in your opinion for SV, or spice or place and route despite there being references for each of these available for in some cases decades? There are free implementations of these but in each case they don't come close to a commercial offering.