4 ms·

Well done Google. But there is still problem with EDA tool license... Is there any replacement for Cadence Virtuoso tool for chip design?

stephen_g 6y ago
The efabless people that the talk mentions a bunch of times are using a fully open-source design flow but I think it's a bit hacky (as in, a bunch of command line tools from various open source projects, some of which may be unmaintained judging by the commit logs). They seem to have successfully fabricated a RISC-V based SoC with it though, which is crazy cool. As somebody with a decent amount of FPGA experience, having a go at setting this software up and seeing if I can get anything to synthesise and through place and route is something I've been intending to have a play with, but I haven't had the spare time. It uses yosis for synthesis and a few other tools for the rest of the process, and is called Qflow - http://opencircuitdesign.com/qflow/index.html http://opencircuitdesign.com/qflow/index.html
- quyleanh 6y ago
  It is a bit complicated, isn't it? I do hope someday, there is solution which is fully opensource for this problem. And it's seems that this day will be long.
- MayeulC 6y ago
  IIRC there are a couple ways to produce the intended design. At the end of the day, fabs often take layouts in the GDSII format, which is documented and open. The Klayout open source visualizer is industry-standard in my experience. Now, how do you generate these layouts? It depends on what you are doing. If more on the experimental side of things, writing scripts to generate structures is fine, as long as these conform to the fab-provided design rules. Technically, that's still what everyone is doing at the industrial level, except the scripts -- often written in tcl -- are provided by the fab. Now if you have some FPGA experience, you are probably interested in logic synthesis tools. There are a few ones, I've seen some academic with their own place-and-route stage, for instance. https://open-src-soc.org/program.html#T-CHAPUT https://open-src-soc.org/program.html#T-CHAPUT does that, I think. The slides linked above outline one of the possible ways to do this: leverage chisel ( https://www.chisel-lang.org/ https://www.chisel-lang.org/) and the FIRRTL intermediate representation for RTL description. A few tools can ingest the output and try to come up with a layout. Hammer (https://github.com/ucb-bar/hammer https://github.com/ucb-bar/hammer) is such a tool, but I don't think that PDK is available with it just yet. To be honest, I don't think commercial tools are that advanced, and it would be fairly doable to catch up. There is some interesting work in this field, but since fabbing is expensive, it tends to be more within the academic community than the free software one. I'd look for papers, not on Github, though that's slowly changing. The chip design world is a slow beast to turn around: everything in the fabrication process is optimized to maximize yield, hence very little leeway is allowed: "If it ain't broken, don't fix it" is the motto, for good reason: if changing humidity levels 0.2% can make a fab lose millions; they won't try to use new and experimental software. I'm watching this space, notably with Verilog alternatives such as Migen. The open source community starts to embrace FPGA, wich is already great. I wish more manufacturers opened up their bitstream, so maybe we need an open FPGA? Though this free fabbing offer would be a great fit for Wi-Fi chips, I think. I wonder if People at openwifi (https://github.com/open-sdr/openwifi https://github.com/open-sdr/openwifi) are interested? I hope that gives a few interesting pointers to whoever reads this :)
  - orbifold 6y ago
    Hammer is just a driver for tools that cost >100k to license. And that doesn't include access to memory compilers, which you would also need.
    - MayeulC 6y ago
      Thanks for the answer, I had forgotten about this. I looked at hammer some time ago, but we decided to go for PoC-like, less complex designs.
    - seldridge 6y ago
      There is an open PR adding support for the OpenROAD tools [^1]. So, there should be a flow that uses open source VLSI tools eventually. The Google 130nm library is still filling a huge gap as all the open PDKs up to this point were "fake" educational libraries, e.g., FreePDK [^2]. You can run them through the a VLSI flow, but you can't tape them out. [^1]: https://github.com/ucb-bar/hammer/pull/584 https://github.com/ucb-bar/hammer/pull/584 [^2]: https://www.eda.ncsu.edu/wiki/FreePDK https://www.eda.ncsu.edu/wiki/FreePDK
PopeDotNinja 6y ago
Maybe we could get Cadence to open source 20 year old software for the 20 year old 130nm chips!
- MayeulC 6y ago
  I wouldn't count on it: I don't think Cadence internals have changed much since then. And if they were to, I'd say that Cadence itself isn't especially easy to use, nor complicated to replicate. It would feel more like a lock-in attempt. The gEDA project would be a good place to start a new layout-level EDA. It has the necessary tools for simulation, already. Synthesis and place-and-route tools exist, but there are many alternatives, documentation is lacking, and I am not sure that PDK is compatible. I don't know of a good open-source drawing tool, but it shouldn't be too complicated to make a basic one. The more complex part would be to integrate it with DRC (design rule check). An then the usual Layout Schematic Extraction to perform LVS (Layout Versus Schematic) simulation, antenna rules, etc. Thinking about it, it's a good thing that node isn't too advanced. It reduces the design rules complexity by a few orders of magnitude.
  - quyleanh 6y ago
    > The more complex part would be to integrate it with DRC (design rule check) If you have open-source design tool (including schematic simulation and verification), I think you will have open-source tool for physical verification. Assume that we still use rule check standard from Mentor Calibre, Assura. > Thinking about it, it's a good thing that node isn't too advanced. It reduces the design rules complexity by a few orders of magnitude. The complexity depends on process. The smaller process, the more complex. There is thousands of rule check even on the old process (180nm, 130nm...).
    - MayeulC 6y ago
      > If you have open-source design tool (including schematic simulation and verification), I think you will have open-source tool for physical verification Right, though the manufacturer will usually automatically run design rules checks on the submitted designs (they don't want you to endanger other people's components due to density or antenna rules). But I was mostly thinking of it being integrated with a manual layout drawing tool: that's a nice-to-have, but not necessary, and more complex for a drawing tool. If you leave that out, creating a drawing tool should be pretty straightforward. > The smaller process, the more complex. Hence my point: it's easier to start with a less-complex process.

stephen_g 6y ago

The efabless people that the talk mentions a bunch of times are using a fully open-source design flow but I think it's a bit hacky (as in, a bunch of command line tools from various open source projects, some of which may be unmaintained judging by the commit logs). They seem to have successfully fabricated a RISC-V based SoC with it though, which is crazy cool. As somebody with a decent amount of FPGA experience, having a go at setting this software up and seeing if I can get anything to synthesise and through place and route is something I've been intending to have a play with, but I haven't had the spare time. It uses yosis for synthesis and a few other tools for the rest of the process, and is called Qflow - http://opencircuitdesign.com/qflow/index.html http://opencircuitdesign.com/qflow/index.html

quyleanh 6y ago
It is a bit complicated, isn't it? I do hope someday, there is solution which is fully opensource for this problem. And it's seems that this day will be long.
MayeulC 6y ago
IIRC there are a couple ways to produce the intended design. At the end of the day, fabs often take layouts in the GDSII format, which is documented and open. The Klayout open source visualizer is industry-standard in my experience. Now, how do you generate these layouts? It depends on what you are doing. If more on the experimental side of things, writing scripts to generate structures is fine, as long as these conform to the fab-provided design rules. Technically, that's still what everyone is doing at the industrial level, except the scripts -- often written in tcl -- are provided by the fab. Now if you have some FPGA experience, you are probably interested in logic synthesis tools. There are a few ones, I've seen some academic with their own place-and-route stage, for instance. https://open-src-soc.org/program.html#T-CHAPUT https://open-src-soc.org/program.html#T-CHAPUT does that, I think. The slides linked above outline one of the possible ways to do this: leverage chisel ( https://www.chisel-lang.org/ https://www.chisel-lang.org/) and the FIRRTL intermediate representation for RTL description. A few tools can ingest the output and try to come up with a layout. Hammer (https://github.com/ucb-bar/hammer https://github.com/ucb-bar/hammer) is such a tool, but I don't think that PDK is available with it just yet. To be honest, I don't think commercial tools are that advanced, and it would be fairly doable to catch up. There is some interesting work in this field, but since fabbing is expensive, it tends to be more within the academic community than the free software one. I'd look for papers, not on Github, though that's slowly changing. The chip design world is a slow beast to turn around: everything in the fabrication process is optimized to maximize yield, hence very little leeway is allowed: "If it ain't broken, don't fix it" is the motto, for good reason: if changing humidity levels 0.2% can make a fab lose millions; they won't try to use new and experimental software. I'm watching this space, notably with Verilog alternatives such as Migen. The open source community starts to embrace FPGA, wich is already great. I wish more manufacturers opened up their bitstream, so maybe we need an open FPGA? Though this free fabbing offer would be a great fit for Wi-Fi chips, I think. I wonder if People at openwifi (https://github.com/open-sdr/openwifi https://github.com/open-sdr/openwifi) are interested? I hope that gives a few interesting pointers to whoever reads this :)
- orbifold 6y ago
  Hammer is just a driver for tools that cost >100k to license. And that doesn't include access to memory compilers, which you would also need.
  - MayeulC 6y ago
    Thanks for the answer, I had forgotten about this. I looked at hammer some time ago, but we decided to go for PoC-like, less complex designs.
  - seldridge 6y ago
    There is an open PR adding support for the OpenROAD tools [^1]. So, there should be a flow that uses open source VLSI tools eventually. The Google 130nm library is still filling a huge gap as all the open PDKs up to this point were "fake" educational libraries, e.g., FreePDK [^2]. You can run them through the a VLSI flow, but you can't tape them out. [^1]: https://github.com/ucb-bar/hammer/pull/584 https://github.com/ucb-bar/hammer/pull/584 [^2]: https://www.eda.ncsu.edu/wiki/FreePDK https://www.eda.ncsu.edu/wiki/FreePDK

PopeDotNinja 6y ago

Maybe we could get Cadence to open source 20 year old software for the 20 year old 130nm chips!

MayeulC 6y ago
I wouldn't count on it: I don't think Cadence internals have changed much since then. And if they were to, I'd say that Cadence itself isn't especially easy to use, nor complicated to replicate. It would feel more like a lock-in attempt. The gEDA project would be a good place to start a new layout-level EDA. It has the necessary tools for simulation, already. Synthesis and place-and-route tools exist, but there are many alternatives, documentation is lacking, and I am not sure that PDK is compatible. I don't know of a good open-source drawing tool, but it shouldn't be too complicated to make a basic one. The more complex part would be to integrate it with DRC (design rule check). An then the usual Layout Schematic Extraction to perform LVS (Layout Versus Schematic) simulation, antenna rules, etc. Thinking about it, it's a good thing that node isn't too advanced. It reduces the design rules complexity by a few orders of magnitude.
- quyleanh 6y ago
  > The more complex part would be to integrate it with DRC (design rule check) If you have open-source design tool (including schematic simulation and verification), I think you will have open-source tool for physical verification. Assume that we still use rule check standard from Mentor Calibre, Assura. > Thinking about it, it's a good thing that node isn't too advanced. It reduces the design rules complexity by a few orders of magnitude. The complexity depends on process. The smaller process, the more complex. There is thousands of rule check even on the old process (180nm, 130nm...).
  - MayeulC 6y ago
    > If you have open-source design tool (including schematic simulation and verification), I think you will have open-source tool for physical verification Right, though the manufacturer will usually automatically run design rules checks on the submitted designs (they don't want you to endanger other people's components due to density or antenna rules). But I was mostly thinking of it being integrated with a manual layout drawing tool: that's a nice-to-have, but not necessary, and more complex for a drawing tool. If you leave that out, creating a drawing tool should be pretty straightforward. > The smaller process, the more complex. Hence my point: it's easier to start with a less-complex process.