Consistency check review

[d-m-bailey]

This is the summary of the current active Consistency checks in precheck (latest version 0941bdc - disclaimer: actually checked version e143b32 from Apr 26, 2023 but the consistency check hasn’t been modified).

• ports: Check that the user project netlist port names match the golden user project netlist port names.
• layout: Check that the cells in the top hierarchy of the layout match the cells in the top hierarchy of the netlist, ignoring certain cells (doesn’t ignore Cadence via cells)
• modeling: Checks that if a user netlist is a verilog file, then the the netlist must be a structural and not a behavioral model.
• complexity: Checks that there is at least 1 cell in the netlist.

For digital designs, there are 2 additional checks.

• power: For cells other than standard library cells, check that at least one of the vdda*, vssa*, vccd*, or vssd* nets is connected.
• port_types: check that the port directions of the user netlist top cell matches the port directions of the golden netlist. (user netlist in and out ports also match golden inout ports).

These are the main problems that the users were seeing:

• layout cell names not matching user netlist cell names in analog or cadence generated circuits. This was often due to layout cells that have no schematic correspondence such as via cells or analog routing. To “solve” this, some users totally flattened their submitted layout.
• netlist parser not being able to handle spice format output from xschem (PININFO comment continuation lines I think).

There is no requirement that the submitted user netlist matches the actual layout. Without that condition, I think the port, layout, complexity, and power checks should not be required. To resolve any above issues, users often submitted modified user netlists that passed precheck, but did not match the layout. Maybe the consistency checks could be left as warnings.

Regarding the remaining modeling and port_type checks, the modeling check is only necessary to verify that the user netlist is suitable for the other consistency checks. If the user netlist matches the layout in a digital design, then the port_type check could be helpful to ensure that the intended port usage matches the specification.

There is a missing check. The layout XOR check verifies that the ports have not been moved. The consistency port check verifies that the same port names are both in the user netlist and the layout. What is not checked is whether or not the port names have been switched in the layout.

These are my suggestions:

• Remove the layout cell check. It can’t handle some third party designs and is covered by LVS.
• Remove all checks for analog designs.
  1. xschem spice output is not supported.
  2. netlist location is non-standard and undocumented (currently netgen/user_analog_project_wrapper.spice)
• Add a new required check for port names and locations. This might be more appropriately implemented as part of the XOR check rather than a consistency check.

[d-m-bailey]

@marwaneltoukhy @a-omla @RTimothyEdwards

[RTimothyEdwards]

@d-m-bailey : I agree that there should not be a layout cell check. That was just an ill-conceived lousy substitute for LVS and never should have been implemented.

I would like to see a port direction check on digital ports for both analog and digital designs Obviously that is easier for digital designs because the port direction has to be declared in verilog. However, it should be possible to make basic checks that digital connections are not made input-to-input or output-to-output, which is something that nearly burned me twice. It is easy to get wrong because full top-level simulation is difficult with analog designs, and the signal names are confusing.

[d-m-bailey]

@RTimothyEdwards With CVC, these are the current default power settings for user_analog_project_wrapper.

vccd* power 1.8
vdda* power 3.3
vssa* power 0.0
vssd* power 0.0
io_analog[*] input min@0.0 max@1.8
wb_clk_i input min@0.0 max@1.8
wb_rst_i input min@0.0 max@1.8
wbs_stb_i input min@0.0 max@1.8
wbs_cyc_i input min@0.0 max@1.8
wbs_we_i input min@0.0 max@1.8
wbs_sel_i[*] input min@0.0 max@1.8
wbs_dat_i[*] input min@0.0 max@1.8
wbs_adr_i[*] input min@0.0 max@1.8
la_data_in[*] input min@0.0 max@1.8
la_oenb[*] input min@0.0 max@1.8
io_in[*] input min@0.0 max@1.8
io_in_3v3[*] input min@0.0 max@3.3
user_clock2 input min@0.0 max@1.8
io_out[0] expectMin@0.0 expectMax@1.8
io_out[1] expectMin@0.0 expectMax@1.8
io_out[26] expectMin@0.0 expectMax@1.8
io_oeb[0] expectMin@0.0 expectMax@1.8

Output signals (not listed or defined with expectMin or expectMax) will yield floating errors when connected as gate inputs.
I don't think there is a way to check for user output to input signals though. Might not be too hard to add, though. I could probably flag any input signals connected to potentially active devices or with simulated logic values.

[RTimothyEdwards]

@d-m-bailey : vdda* power can be anything from 1.8V to 5.5V (or left unconnected).
io_analog[*] are minimum 0V maximum 3.3V, not 1.8V.
Is there a reason that all the digital outputs (wbs_dat_o, wbs_ack_o, and la_data_out) are not in the list?
Why are only indexes 0, 1, and 26 called out for io_out[*], and only index 0 for io_oeb? (I assume this means they're allowed to be no-connects? Is there any specific check if they are connected?)
What happened to the irq outputs? (Likewise, allowed to be no-connects?)
What happened to the io_clamp_high and io_clamp_low pins? (Ditto)
How about gpio_analog and gpio_noesd? (Ditto)

[d-m-bailey]

@RTimothyEdwards Thanks for the feedback.

Is there a reason that all the digital outputs (wbs_dat_o, wbs_ack_o, and la_data_out) are not in the list?
What happened to the irq outputs? (Likewise, allowed to be no-connects?)
What happened to the io_clamp_high and io_clamp_low pins? (Ditto)
How about gpio_analog and gpio_noesd? (Ditto)

Currently, there is no definition for these (possibly unconnected) output signals in CVC. What would we want to check?

Why are only indexes 0, 1, and 26 called out for io_out[*], and only index 0 for io_oeb? (I assume this means they're allowed to be no-connects? Is there any specific check if they are connected?)

These signals are buffered in caravel_core. If they are unconnected, there is a potential leak due to Hi-Z input. The connection checks are part of the separate OEB check.

[RTimothyEdwards]

@d-m-bailey:

1. I'm not sure what exact checks CVC is capable of. However, in general I would want to check any "optionally connected" signal, if it is connected, for the correct voltage level and direction. I assume it's possible to trace any of these signals to a terminal and determine if it is a gate or a drain, and if it is a thick- or thin-oxide transistor. That consistency check would have saved me from two near-fatal errors when submitting the Chipalooza test chips (fortunately both were caught in time). The problem with large analog projects is that currently there is no instruction on how to simulate the full chip (something I want to work on---It should be doable now since ngspice version 42, using verilator to simulate the digital core), so most analog projects are submitted without simulation at the top level, and consistency checks on the pins (especially the logic analyzer) are critical.

2. Any io_out[*] or io_oeb[*] that is buffered on the user project side should be flagged as an error in Caravel and fixed before the next tapeout, instead of rewriting the consistency checks around it.

[d-m-bailey]

@RTimothyEdwards Just to be clear, you mean this, right?

2. Any io_out[*] or io_oeb[*] that is buffered on the user project caravel_core/caravan_core side should be flagged as an error in Caravel and fixed before the next tapeout, instead of rewriting the consistency checks around it.

[RTimothyEdwards]

@d-m-bailey : I was trying to indicate GPIO control and data pins that were connected to the user project area.