Gate-level Netlist Design Flow

[mtseng15]

Prompt

There are some design cases for mixed-signal designs where it makes sense to design the digital portions of the design in a schematic editor such as Xschem rather than writing behavioral verilog. Example cases include if the digital portions of the design are quite small or more importantly if the timing requirements are extremely high so a spice based simulation is preferable to an event based simulation (my current case). However, it would be quite nice to still be able to utilize OpenLane to layout the digital design portion of the design.

Xschem can export a gate-level verilog netlist and I have attempted to bypass the synthesis step as described here and here. However, so far I have been unsuccessful. I am starting on digging deeper into OpenLane to understand better how to perform this task, but I thought I would also open an Issue here to see if anyone here has any thoughts.

Thank you all so much! OpenLane is so cool and I'm excited to continue learning. Please let me know how I can help best.

Proposal Workflow

1. Design the full mixed signal design in Xschem with the digital portions as subcircuits utilizing only standard cells.
2. Export a gate-level netlist from Xschem
3. Input the gate-level netlist into OpenLane, bypassing/disabling synthesis and starting at floor planning
4. Get out some nice GDS of the digital portion of your design.

[maliberty]

Are you planning to do post-P&R spice simulation with annotated parasitics? I expect so, if you timing is so tight, which will be another flow challenge.

Bypassing yosys shouldn't be too complicated. You can put your verilog where yosys would have placed its output and then run the flow using "-from floorplan" to start the flow there.

[donn]

@mtseng15 Try the configuration variable SYNTH_ELABORATE_ONLY: if you set it to "1" (or true if you're using a JSON config file), yosys will basically only flatten the design. However, I must confess it's not in our CI so as such it might be broken, but please do report any bugs you find.

[mtseng15]

Hello @maliberty,

Thank you for the quick reply!

Yes, the idea in my head was to use OpenLane to layout the GDS, then take the GDS into Magic to perform parasitic extraction and then run that back in spice and make adjustments from there. It's not an automated workflow, but as of now with the toy problem tests I don't see any issues with the principals. Do you see any issues with this?

Ok, so just to verify: I should place my gate-level netlist in the /designs/<design name>/runs/<run_name>/results/synthesis directory? Since the are newly generated, is there a way to start OpenLane from a previous run?

[maliberty]

That should work. You can use -tag name to fix the dir

[mtseng15]

Hi @donn,

Thanks for your help!

I had adjusted my configuration variables from the old post to SYNTH_ELABORATE_ONLY since SYNTH_TOP_LEVEL was depreciated. I get the following errors:

[ERROR]: during executing: "yosys -c /openlane/scripts/yosys/elaborate.tcl -l /openlane/designs/demux2/runs/RUN_2022.10.10_22.17.29/logs/synthesis/1-synthesis.log |& tee /dev/null"
[ERROR]: Exit code: 1
[ERROR]: Last 10 lines:

[TCL: yosys -import] Command name collision: found pre-existing command `cd' -> skip.
[TCL: yosys -import] Command name collision: found pre-existing command `eval' -> skip.
[TCL: yosys -import] Command name collision: found pre-existing command `exec' -> skip.
[TCL: yosys -import] Command name collision: found pre-existing command `read' -> skip.
[TCL: yosys -import] Command name collision: found pre-existing command `trace' -> skip.

1. Executing Verilog-2005 frontend: /openlane/designs/demux2/src/demux2.v
/openlane/designs/demux2/src/demux2.v:21: ERROR: Parameter x1.VGND with non-constant value!
child process exited abnormally

With the following config.json

{
    "DESIGN_NAME": "demux2",
    "VERILOG_FILES": "dir::src/*.v",
    "CLOCK_PORT": "clk",
    "CLOCK_PERIOD": 10.0,
    "DESIGN_IS_CORE": false,
    "SYNTH_ELABORATE_ONLY": true
}

And Verilog:

// sch_path: /foss/designs/sky130-10-bit-SAR-ADC/xschem/src/demux2/demux2.sch
module demux2
(
  output wire OUT_0,
  output wire OUT_1,
  inout wire VDD,
  inout wire VSS,
  input wire S,
  input wire IN
);
wire net1  ;

and2_0
#(
.VGND ( VSS ) ,
.VNB ( VSS ) ,
.VPB ( VDD ) ,
.VPWR ( VDD ) ,
.prefix ( sky130_fd_sc_hd__ )
)
x1 ( 
 .A( net1 ),
 .B( IN ),
 .X( OUT_0 )
);

and2_0
#(
.VGND ( VSS ) ,
.VNB ( VSS ) ,
.VPB ( VDD ) ,
.VPWR ( VDD ) ,
.prefix ( sky130_fd_sc_hd__ )
)
x2 ( 
 .A( S ),
 .B( IN ),
 .X( OUT_1 )
);

inv_1
#(
.VGND ( VSS ) ,
.VNB ( VSS ) ,
.VPB ( VDD ) ,
.VPWR ( VDD ) ,
.prefix ( sky130_fd_sc_hd__ )
)
x3 ( 
 .A( S ),
 .Y( net1 )
);

endmodule

In comparing gate-level verilog netlists, I'm wondering if there is perhaps a standard confliction. I don't know much about verilog standards, but I vaguely remember from school that they are a bit loose. What do you think?

[donn]

#(
.VGND ( VSS ) ,
.VNB ( VSS ) ,
.VPB ( VDD ) ,
.VPWR ( VDD ) ,
.prefix ( sky130_fd_sc_hd__ )
)

I must confess that is a rather unorthodox method of using parameters and indeed I am not sure if it's valid. I'm assuming this is generated by xschem?

[mtseng15]

@donn Yes, it is generated by Xschem. So perhaps this is something with Xschem...

Here is the schematic that generated that Verilog netlist: demux2.

I wrote a Makefile target to consistently extract the verilog. The important flag is -w for verilog and everything else is just disabling the gui and telling it to quit.

# Extract the Verilog netlist from xschem
.PHONY: extract_xschem_verilog
extract_xschem_verilog:
ifndef component
    $(error component is not set)
endif
    cd ./xschem; xschem -n -w -q --no_x  ./src/$(component)/$(component).sch -o ./src/$(component)/
    cp ./xschem/src/$(component)/$(component).v ./OpenLane/designs/$(component)/src/

[mtseng15]

@donn @maliberty Ok, so I wrote a hacky little python script to strip out the parameters from the gate level net list and then set:

"SYNTH_ELABORATE_ONLY": true, 
"SYNTH_READ_BLACKBOX_LIB": true

(in addition to adjusting the core size etc.) And I got the flow to work! The GDS looks about right, but I haven't run LVS (or extracted a spice netlist) yet to make sure.

What are the benefits (or downsides) of leaving Yosys in the tool chain with this method vs. bypassing it and starting from floor plan?

[RTimothyEdwards]

@mtseng15 : There are various benefits to using the verilog post-processed output from yosys. I have done that before (not in the openlane flow), and the output is generally much easier for tools to work with. Even without synthesizable language in the code, yosys will still get rid of definitions and arrayed instances and such, producing something that is less human-readable but more machine-parseable.

[mtseng15]

@RTimothyEdwards That all makes sense. Thanks for explaining more!

[mtseng15]

@donn @maliberty I have been using this workflow for a bit now and it seems to work well. The only hitch I've run into is with the conb standard cell. I placed it in a schematic, I see it in the verilog after Yosys has processed the inputted verilog, but I don't see that in the GDS and I am uncertain that it replaced it with a wire. There are no LVS errors, but I feel a little uneasy about it.

Could you tell me how OpenLane handles conb?

[maliberty]

If they are in the yosys output then OR should treat it like any other cells and place it. You can look at the net it is connected to and see what is happening.

[mtseng15]

Hi @maliberty,

Thanks for your help! I don't see it in the GDS of klayout and if I extract a spice netlist from the mag file it is also not listed. Am I missing something? I have attached the run output.

RUN_2022.11.07_18.33.20.zip

[maliberty]

I would look in the final DEF where you still have connectivity first.

[mtseng15]

By connectivity, you mean looking to see if it was wired directly to the VPWR? Or look for the conb cell? I don't see a conb cell...

[maliberty]

What net is the conb connected to? You could see what is connected to it.

[mtseng15]

Hmm...so I've found the net in the DEF file, but there is only one connection which is the one opposite to the conb cell. And there is no metal defined for it...

[maliberty]

You can 'make all_defs' to get a DEF for every step of the flow. At what point does it disappear?

[mtseng15]

I'm sorry. Forgive my ignorance. Where do I run make all_defs?

[maliberty]

Sorry wrong flow. Can you open the various odb files in the OR GUI and inspect there? If not perhaps you can package up a test case.

[mtseng15]

I'm not sure how to view things with the GUI from OpenLane. Is there a quick tutorial on it? I have the openroad tool...just not sure how to open the files.

By package a test case, do you mean submit a bug issue?

[maliberty]

You can start 'openroad -gui' and then use 'read_db ' to load a .odb file from your run area. Otherwise you can attach the results to this issue.

[mtseng15]

Thank you! I will take a crack at the gui in the morning. The run results are attached below. Thank you! RUN_2022.11.07_18.33.20.zip

[maliberty]

There is a problem in repair_tie_fanout here. I think what is new here is that both tie ports of the conb are connected to a net even though one net is a dangle. Usually we just see one port in use. I'll fix it up.

[mtseng15]

Huh. Interesting! Thank you for your help!

[maliberty]

As a workaround I would remove the .LO output in the controller.v as it isn't doing anything and having it disconnected should work.

[mtseng15]

Ah! Perfect! That works! Thank you!

[maliberty]

Fixed with https://github.com/The-OpenROAD-Project/OpenROAD/pull/2476