https://open-source-silicon.dev
Join Slack
Is there any way to run an antenna check through magic? Looking through previous slack messages it s...
# magic
w
Is there any way to run an antenna check through magic? Looking through previous slack messages it seems like the antenna checks are only done in openlane but my design is entirely hand routed
t
Run the "antennacheck" command.
w
Is there a way to get it to print a log? it seems to have made some of my routed tracks stripey, but some are a bit confusing
Also, what is the recommended way of resolving violations? There does not seem to be an antenna diode cell in the HVL logic library. I guess I should make my own?
t
"antannacheck debug" followed by "antennacheck"
That will give you the full output dump. For each violation, though, just put the cursor box over some part of the "stripey" nets and type "feedback why".
sky130_fd_sc_hvl__diode_2.mag
is the antenna tie-down cell.
w
It seems that it is flagging one of my decap cells, which is quite confusing.
Copy code
% feedback why
device missing 1 terminal;
 connecting remainder to node VGND
device missing 1 terminal;
 connecting remainder to node VPWR
it does not seem to be connected any differently than the other decap cells...
t
That's an extraction error. Do "feedback clear" before running the antenna check so that you don't get and pre-existing feedback entries.
w
I feel dumb, I should have seen this coming and added antenna diodes on all my logic block inputs 😕
At least the opamps dont seem to violate the antenna rules
Is this a warning I should be worried about: "connect(1): no such node power_stage_0/w_21300_n1200#"
Copy code
Effective antenna ratio 8925.38 > limit 400
lol\
Will the antenna check run on all gates, or only logic gates from the cell library?
It also does not seem to be checking all the gates, it starts out saying it only checked 100 gates and I know I have more than that
Copy code
Running antenna checks.
   100 gates analyzed.
t
"connect(1)" errors are also from extraction and generally arise from magic having issues with generating parasitic caps into read-only cells for which it does not have enough information to figure out what goes where.
The antenna check should run on all nets, but it will not analyze anything that is obviously not an antenna.
w
Cool. Once again, thanks for all the clarification!
I am getting close to having a final design. Its been a long journey 😅
@Tim Edwards it does not seem like the diodes go through extraction correctly. In the cell library they are
Copy code
.subckt sky130_fd_sc_hvl__diode_2 DIODE VGND VNB VPB VPWR
X0 VNB DIODE ndiode_h p=5.88e+06u a=6.072e+11p
.ends
but under extraction they are
Copy code
.subckt sky130_fd_sc_hvl__diode_2 DIODE VGND VNB VPB VPWR
D0 VNB DIODE sky130_fd_pr__diode_pw2nd_11v0 pj=5.88e+06u area=6.072e+11p
.ends
should I just modify the cell library to use that cell definition? If I make a modification like that will it pass the submission checks?
t
Crud, it's been fixed in some of the libraries but not in others (like HVL). Go ahead and fix it; I'll see what I can do in the open_pdks install. . . It appears to be my own patch that fixes the HD library diode cell, and I just missed the HVL library.
Oh, probably because I did a substitution on pw2nd_05v5 which misses the pw2nd_11v0 in the HVL library. . .
Yep, that was it. Fix to open_pdks will go out shortly.
🙌 1
The fix has been pushed (to the opencircuitdesign.com repo).
w
Also, something funky is going on with decap extraction
Is it not supposed to be extracted at all?
I previously added a kludge of a nmos and pmos so the decap cells would match, now it is throwing a property mismatch error. It seems to be flattening but not combing the combined capacitance
so I get a property error
t
I feel like I'm not actually fixing errors in netgen but just pushing them around. Please post an example. Decap cells should be extracted since they contain valid devices; they aren't going to just get optimized away. They should all be combined in parallel since they have all the same connections to power and ground.
w
switch_control_xschem.spice,switch_control_extract.spice
switch_control_xschem.spiceswitch_control_extract.spice
these two match, despite that the extract has 18 decap cells and the switch control schematic only has a 1.5um and 2um dummy fet (the contents of one dummy cell)
looking through the logs it seems it is directly merging all of the decap cells before flattening.
Copy code
Contents of circuit 1:  Circuit: 'switch_control'
Circuit switch_control contains 101 device instances.
  Class: sky130_fd_sc_hvl__mux2_1 instances:   5
  Class: sky130_fd_sc_hvl__and2_1 instances:   4
  Class: sky130_fd_sc_hvl__nor2_1 instances:   2
  Class: sky130_fd_sc_hvl__diode_2 instances:  12
  Class: sky130_fd_sc_hvl__inv_1 instances:  48
  Class: sky130_fd_sc_hvl__inv_4 instances:   9
  Class: sky130_fd_sc_hvl__decap_8 instances:  18
  Class: sky130_fd_sc_hvl__nand2_1 instances:   1
  Class: sky130_fd_sc_hvl__or2_1 instances:   2
Circuit contains 85 nets.
Contents of circuit 2:  Circuit: 'switch_control'
Circuit switch_control contains 85 device instances.
  Class: sky130_fd_sc_hvl__mux2_1 instances:   5
  Class: sky130_fd_sc_hvl__and2_1 instances:   4
  Class: sky130_fd_sc_hvl__nor2_1 instances:   2
  Class: sky130_fd_sc_hvl__diode_2 instances:  12
  Class: sky130_fd_pr__nfet_g5v0d10v5 instances:   1
  Class: sky130_fd_sc_hvl__inv_1 instances:  48
  Class: sky130_fd_sc_hvl__inv_4 instances:   9
  Class: sky130_fd_sc_hvl__nand2_1 instances:   1
  Class: sky130_fd_sc_hvl__or2_1 instances:   2
  Class: sky130_fd_pr__pfet_g5v0d10v5 instances:   1
Circuit contains 85 nets.

Circuit was modified by parallel/series device merging.
New circuit summary:

Contents of circuit 1:  Circuit: 'switch_control'
Circuit switch_control contains 84 device instances.
  Class: sky130_fd_sc_hvl__mux2_1 instances:   5
  Class: sky130_fd_sc_hvl__and2_1 instances:   4
  Class: sky130_fd_sc_hvl__nor2_1 instances:   2
  Class: sky130_fd_sc_hvl__diode_2 instances:  12
  Class: sky130_fd_sc_hvl__inv_1 instances:  48
  Class: sky130_fd_sc_hvl__inv_4 instances:   9
  Class: sky130_fd_sc_hvl__decap_8 instances:   1
  Class: sky130_fd_sc_hvl__nand2_1 instances:   1
  Class: sky130_fd_sc_hvl__or2_1 instances:   2
Circuit contains 85 nets.
Also, I have another question. My top level design has separate power domains for the ground connections between the control circuitry and power stage
not all of the power stage is in a deep n-well, so there are a few substrate taps
this is leading to the two grounds getting merged into one net, even though there is no metal connection between them
Whats the correct way of dealing with this? I guess it makes sense because they are sorta connected via the substrate. However, they are basically electrically isolated from each other
t
You mean that the two grounds are really connected through the substrate (as opposed to one being in an isolated pwell in a deep nwell structure)?
w
Yah.
I think this is done in real designs?
I migrated my NMOS to a deep nwell but did not migrate my gate driver
I guess I should just merge the nets and manually keep track of what goes where 😕
the deep nwell is mainly to stop reverse conduction of the nmos into the substrate
t
Yes, but usually through some sort of substrate isolation marker. This can be done in one way in magic, which is to alter the tech file to remove "space" from the definition for substrate. Then, you will need to have the "pwell" layer drawn underneath all N devices, but then you can draw regions of pwell that represent your sort-of-isolated substrate regions.
There will be a better way to do this once I fix the issues with extracting deep nwell structures correctly.
w
perhaps I should just spend the time this weekend to migrate the gate driver to the deep nwell. I just need to move the pmos from the nmos a bit and redo a bit of layout...
8 Views
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by