@dwisehart Check the repository : https://chips4makers.io/blog/open-source-mixed-rtl-synthesis.html#open-source-mixed-rtl-synthesis
@dwisehart As far as I understand, ultimate goal would be to just run "make" after proper configuration and get GDSII. Surely it will work that easy only for digital-only designs without RAM blocks. But I assume first public run will require much more manual work. At least that is what I am preparing myself for :)
Goot question @Fatsie_gitlab : because that is what I am familiar with in my professional work. I am trying to find out what capabilities are possible with open source tools and I wanted to be clear that I am looking to do physical layout for tape out to an ASIC, not just FPGA layout and routing. The personal project I am working on can be done in 65 nm TSMC and might be possible in 130 nm (or do we still call it 0.13 um?) but not "less advanced" than that. Thanks for the reply.
Thanks @Zeptobars_twitter I will check the repo. How far away is the ultimate goal?
@dwisehart Only @Fatsie_gitlab might know... Anyways, let's not think that far ahead. Next tapeout might be somewhere around the middle of 2020 (as it was mentioned in the blog). 'Full auto" was never promised actually, only open source was the goal. But surely "full auto" flow will make it much more accessible to people who can only do FPGA.
@dwisehart Chips4Makers is now focusing 0.35um with some funded development work ongoing on 0.18um. My main target audience is people who now are playing with FPGAs and fancy making their own ASIC. It's not directly targeting companies who want to save some bucks by replacing their proprietary EDA tools with open source ones. We are long way of on having a flow with similar features; things like IR-drop analysis, signal integrity, timing driven placement etc are currently missing from the flow.
For synthesis it would be yosys. For place-and-route it will Qflow, Coriolis or OpenROAD. Likely one of the latter two as Qflow author is now looking into OpenROAD.
In the blog linked to by @Zeptobars_twitter I do mention now being able to do synthesis on mixed Verilog/VHDL but it only works with Verilog top and VHDL blocks not being interlinked or using Verilog blocks. Also a lot of advanced SystemVerilog features are missing from open source version of Yosys.
For open source standard cells you have the osu cells delivered with Qflow, you have sxlib/nsxlib from Coriolis and some on http://vlsitechnology.org.
(I am used to talking about 'point-thirteen', 'point-eighteen' and 'point-thirtyfive' when talking about 0.13um, 0.18um and 0.35um technology, but I noticed that term is confusing for people not in the business)
For synthesis it would be yosys. For place-and-route it will Qflow, Coriolis or OpenROAD. Likely one of the latter two as Qflow author is now looking into OpenROAD.
In the blog linked to by @Zeptobars_twitter I do mention now being able to do synthesis on mixed Verilog/VHDL but it only works with Verilog top and VHDL blocks not being interlinked or using Verilog blocks. Also a lot of advanced SystemVerilog features are missing from open source version of Yosys.
For open source standard cells you have the osu cells delivered with Qflow, you have sxlib/nsxlib from Coriolis and some on http://vlsitechnology.org.
(I am used to talking about 'point-thirteen', 'point-eighteen' and 'point-thirtyfive' when talking about 0.13um, 0.18um and 0.35um technology, but I noticed that term is confusing for people not in the business)
Thanks for the info @Fatsie_gitlab. For me, I would like to see the synthesis tool support the Verilog primitives
pmos and nmos with varying drive strengths, because that is where much of my work is done. If it could also optimize to infer AOI and OAI where appropriate, that would be great. Mixed synthesis is not important to me because any VHDL IP I convert into (System)Verilog.
For standard libraries it would be nice if the placement tools could use a PDK I supply, since they are available from the foundries, but they are covered by NDA. I will take a look at OpenROAD: thanks for the pointer.
Interestingly, at work we are doing 7nm, talking about 5nm and starting to plan for the next step, which is not called 3.5nm but 35 Ångstrom.
@dwisehart yosys uses abc for standard cell mapping and uses AOI and OAI gates where appropriate. Likely not very well optimized for small nodes as it only looks at input gate capacitance for the fanout and does not use wireload models or other estimated interconnect parasitics.
Am interested to know what the use case is for the varying drive strenghts modeling ? I would think this is verification stuff, not synthesis.
Am interested to know what the use case is for the varying drive strenghts modeling ? I would think this is verification stuff, not synthesis.
@Fatsie_gitlab different drive strengths are a good way to meet timing on different routes, as the switching time of the FETs changes based on how much capacitance it is driving and how much drive strength it has. I see FETs with different drive strength used during the HDL design phase to mark routes that are going to be difficult to route using the default drive strength. If a route is difficult because of fan-out the routing tool can usually figure it out for itself, but the hint doesn't hurt. If a route is difficult because it is expected to be long, you can save the routing tool a lot of time trying to pack too much into too small of a space.
The OpenROAD reference is a real good one. UC San Diego has a four-year DARPA grant to develop an open source tool chain from RTL to GDS. There was an
alpha release in July 2019. For this year: The OpenROAD v1.0 tool, to be released in July 2020, will be capable of push-button, DRC-clean RTL-to-GDS layout generation in a commercial FinFET process node. The FinFET process node they are targeting is 14/12 nm: a lot finer than what I need. Thanks again for the pointer, @Fatsie_gitlab and @Zeptobars_twitter https://vlsicad.ucsd.edu/NEWS19/OpenROAD%20RTL-to-GDS%20v1.0%20Expectations.pdf
@dwisehart But this is handled by the timing information in the .lib file, not by different drive strength modeling in verilog. A standard cell will indeed have at least buffers of different drive strengths but may also contain other gates of different drive strengths. Typically these are cells with names ending in 'Xn' or 'Dn' with n representing the relative drive strength.
These cells will then have a smaller delay in the lookup tables of the .lib file for the same capacitance load. The place-and-route tool will use this information to do buffer insertion or replace cells used in synthesis with higher drive strength ones.
These cells will then have a smaller delay in the lookup tables of the .lib file for the same capacitance load. The place-and-route tool will use this information to do buffer insertion or replace cells used in synthesis with higher drive strength ones.
that i mentioned
it builds a buildroot linux, and boots it into an emulator
I am waiting for my ECP5 light board to try it out myself
I was thinking to do some fundraising in order to make chip
because this is like 2.5 years I have been waiting for an affordable RISCV board that can boot Linux
PS: I also see which Dimitri you mean now...
Only problem is that there can be only very little on-chip RAM so no cache or only very minimal.