https://open-source-silicon.dev
Join Slack
Menu
Home
Archive
<@U03H5SD02TY>: Can you synthesize such that every output is buffered by its own buffer cell? The ...
# openlane
t
@Jake Ke: Can you synthesize such that every output is buffered by its own buffer cell? The problem is that several pins are connected together (as you noted), specifically the 
io_oeb[...]
pins, and so only one shows up as a pin in magic. This situation is normally resolved by putting a metal resistor in the path between two pins to virtually separate the net. I'm not aware that the synthesis tools have any option to do that, so the next best thing is just to force the synthesis tools to separate every net to every pin by buffering.
✅ 1
m
@Tim Edwards With nets combined with 
assign
in verilog, it looks like netgen is using the first net on the left of the first assign statement while the innovus verilog is using the net on the right. For example, from 
design.lvs.v
Copy code
assign io_oeb[31] = io_oeb[29];
   assign io_oeb[30] = io_oeb[29];
Of the 3 nets listed here, only 
io_oeb[29]
is actually used in the gate level verilog and only 
io_oeb[29]
is extracted in the layout. When there is a net conflict during extraction, do you remember which net is chosen? Using the same method to chose the net in netgen may solve the problem. @Jake Ke You might try switching the order of the nets in the assign statements. For example,
Copy code
assign io_oeb[29] = io_oeb[31];
   assign io_oeb[30] = io_oeb[31];
j
Hi @Tim Edwards, I tried adding buffers during synthesis with the following constraints
Copy code
set_isolate_ports -type buffer [all_outputs]
set_fix_multiple_port_nets -outputs -buffer_constants
All output ports are buffered in the netlist. However, 
design.lvs.v
still has those assign statements. And that does not get rid off the lvs mismatches. As @Mitch Bailey pointed out, innovus and magic extractions put the wires on the opposite sides of the equation.
m
I believe innovus and magic are chosing the same ports, but that netgen choses the (an) other when reading the innovus verilog.
j
@Mitch Bailey Oh okay, thank you for the correction. I think swapping the order in the assign statements would work but just requires editing all the connections. I have many of those assignments too
m
I don't think you need to edit all the connections, just the assign statements.
j
Looking at the verilog, For:
Copy code
assign io_oeb[31] = io_oeb[29];
   assign io_oeb[30] = io_oeb[29];
only io_oeb[29] gets the output from a buffer. If I switch to:
Copy code
assign io_oeb[29] = io_oeb[31];
   assign io_oeb[30] = io_oeb[31];
don't I need to make io_oeb[31] connect to the output pin of the buffer? I am not familiar with LVS. If I change the instance connection, could that cause LVS errors else where?
m
I believe the assign statements make all the nets electrically equivalent. Any of the 3 will refer to the same net.
j
That's something interesting I just learned about assign. I tried swapping pins for those assign statements but same violations. I think it is still the issue with netgen? Would I still need to change the instance connections?
t
If buffering individual outputs can't solve the problem, then there needs to be some option for the verilog parser in netgen to preserve all the pins. So maybe several option varieties, one to preserve the left-hand assignment, one to preserve the right-hand assignment, and one to keep them both.
j
Do we have the option for the netgen verilog parser? If not, is it okay if I ignore these errors and proceed with netgen lvs with gds?
t
@Jake Ke: No, I was just considering that as a possible quick bit of development. You can ignore the errors if you think that those are the only LVS errors. If the LVS report isn't obviously flagging other nets, then it's a pretty safe bet.
✅ 1
m
@Jake Ke Sorry for the bad advice. I thought I'd swapped the assign on another design to get LVS to pass, but when I tested your design, I got the same results as you did. I tried commenting out the assign statements and that gives a topology match, but there are extra disconnected ports in the verilog which results in LVS failing. If magic and netgen would short nets the same way, I think we'd be ok.
✅ 1
j
Thanks you Mitch and Tim! I will ignore these mismatches for now.
m
I've just seen this too, with assignment at user project wrapper level. If you put the oeb driver down one level, so it's in your macro, then that works for me
j
The oeb driver is in our macro. I was running lvs just on our macro (not with the user project wrapper)
m
Oh
But i tristate these so each line has its own buffer
j
oh okay, so you put tristate buffers for the mprj_io ports in your macro? The tristate buffers probably did the trick?
m
Yes
But im sure other people dont do that
Maybe take a look at some other designs on mpw6
j
okay thanks
Hi @Tim Edwards, will you update the netgen verilog parser any time soon? We realized that after those pin mismatches, netgen quits early. We do not get to run other LVS net checks.
t
I'll take a look at it tomorrow morning and see what I can do.
👍 1
@Jake Ke: It occurs to me that I did add a method to deal with this, not in netgen, but in magic. If the extraction in magic adds the setup command 
ext2spice short voltage
, then when pins of a subcircuit in magic are shorted together, the SPICE netlist will keep both pins and connect them together with an ideal voltage source at zero volts (
ext2spice short resistor
does the same thing with an ideal zero-ohm resistor). Netgen knows how to recoginize the zero-volt sources and zero-ohm resistors and treats them as net separators. I am not 100% sure that this will solve your LVS issue, but I think it will. ---Update: There is a small error in netgen's SPICE parser that prevents it from reading the value of a voltage source, so use 
ext2spice short resistor
, not 
ext2spice short voltage.
m
What I'm interested to know is why is this only cropping up now?
What happened before with oenb?
Like this
t
@Matt Venn: Not sure. In this case, there are multiple 
io_oeb
pins being driven by the same net, but 
io_oeb
is not a constant.
I found that it is not the verilog parser at fault. The verilog parser keeps both pin names in the verilog from the assignment expression. There is a routine that finds duplicate ports and deletes them, and it is only checking the port's net number, not the name, so it is deleting one of the ports. I have it now where both sets of pin names in both netlists are present at the time of pin matching; now I just need to get the pin matching algorithm to understand that they may be in any order.
j
@Tim Edwards Thanks! 
ext2spice short resistor
works for magic extraction! All pins are preserved in the spice file. Now, I think netgen just needs the the pin matching algorithm fix that you are talking about, correct?
Copy code
(no matching pin)                          |io_oeb[37]                                 
(no matching pin)                          |io_oeb[35]                                 
(no matching pin)                          |io_oeb[33]                                 
(no matching pin)                          |io_oeb[31]                                 
(no matching pin)                          |io_oeb[28]                                 
(no matching pin)                          |io_oeb[24]                                 
(no matching pin)                          |io_oeb[16]                                 
(no matching pin)                          |io_oeb[13]                                 
(no matching pin)                          |io_oeb[11]                                 
(no matching pin)                          |io_oeb[9]                                  
(no matching pin)                          |io_oeb[7]                                  
(no matching pin)                          |io_oeb[5]                                  
(no matching pin)                          |io_oeb[3]                                  
(no matching pin)                          |io_oeb[1]                                  
io_oeb[37]                                 |(no matching pin)                          
io_oeb[35]                                 |(no matching pin)                          
io_oeb[33]                                 |(no matching pin)                          
io_oeb[31]                                 |(no matching pin)                          
io_oeb[28]                                 |(no matching pin)                          
io_oeb[24]                                 |(no matching pin)                          
io_oeb[16]                                 |(no matching pin)                          
io_oeb[13]                                 |(no matching pin)                          
io_oeb[11]                                 |(no matching pin)                          
io_oeb[9]                                  |(no matching pin)                          
io_oeb[7]                                  |(no matching pin)                          
io_oeb[5]                                  |(no matching pin)                          
io_oeb[3]                                  |(no matching pin)                          
io_oeb[1]                                  |(no matching pin)
m
@Jake Ke Can you post your netlist that you extracted with 
ext2spice short resistor
?
j
Hi Mitch, i have attached both spice and netlist. The netlist still had the assign statements. We actually made a quick fix to pass netgen-lvs-def by using buffers for every output and set dont_touch.
design_extracted.spicedesign.lvs.v
t
@Jake Ke: Sounds like I'm a few hours late, then, but I have just checked in a fix for netgen (netgen version 1.5.223) that deals with the issue directly, in netgen's pin matching algorithm. I hand-edited the SPICE netlist to add zero-voltage sources (I also fixed the parsing of these), but with that, it now passes LVS cleanly in netgen.
✅ 1
Technically, there is one error in the netlist and I need to figure out why netgen doesn't flag it; The SRAM does not have power pins in the verilog netlist. Being marked as a "black box", the pins should be required to match exactly on both sides, so I'm not sure why netgen let that pass with "Cell pin lists are equivalent". I assume the power supplies are missing only because the netlist didn't include a version of the SRAM with power pins, as it ought to for LVS.
j
This is all good. Thank you for the fix! I will try that netgen version. The reason we did a work around was because we got the same output port problem in Calibre LVS. We did not yet know how to keep all the output pins in Calibre. Thank you for pointing out the sram power pin error! I noticed that too, but I thought they can be ignored because it is treated as a black box. We are currently debugging it.
Thanks, Tim. The Netgen update works for me.
t
@Jake Ke: You can ignore the SRAM power pin error, as long as you see that the power pins are connected in the layout. There isn't necessarily an error there, just that you probably need to pass 
USE_POWER_PINS
. You can just add a ``define USE_POWER_PINS` at the top of your project wrapper verilog.
j
Ah, that's why! Thank you!
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