https://open-source-silicon.dev logo
Join Slack
Powered by
<@U02UAUGSQ22> I just pulled your latest container...
# open_pdks
b
@Harald Pretl I just pulled your latest container and it seems to use the above new hash. But, my original issue is somehow still not addressed. Here's a test case:
Copy code
* old binned models
*.lib /foss/pdks/sky130A/libs.tech/ngspice/sky130.lib.spice tt
* new continuous models
.lib /foss/pdks/sky130A/libs.tech/combined/sky130.lib.spice tt

.param mc_mm_switch=0
.param lx=0.15 wx=162.5 nfx=40 idx=0.5m
.save @m.xm1a.msky130_fd_pr__nfet_01v8_lvt

XM1a d g s 0 sky130_fd_pr__nfet_01v8_lvt L={lx} W={wx} nf={nfx} ad='int((nf+1)/2) * W/nf * 0.29' as='int((nf+2)/2) * W/nf * 0.29' pd='2*int((nf+1)/2) * (W/nf + 0.29)'
+ ps='2*int((nf+2)/2) * (W/nf + 0.29)' nrd='0.29 / W' nrs='0.29 / W' sa=0 sb=0 sd=0 mult=1 m=1
XM1b d g s 0 sky130_fd_pr__nfet_01v8_lvt L={lx} W={wx} nf={nfx} ad='int((nf+1)/2) * W/nf * 0.29' as='int((nf+2)/2) * W/nf * 0.29' pd='2*int((nf+1)/2) * (W/nf + 0.29)'
+ ps='2*int((nf+2)/2) * (W/nf + 0.29)' nrd='0.29 / W' nrs='0.29 / W' sa=0 sb=0 sd=0 mult=1 m=1
vg  g  0  1
vd  d  0  1
is  s  0  {2*idx}

.control
  op
  *show
  print @m.xm1a.msky130_fd_pr__nfet_01v8_lvt[gm]
  print @m.xm1a.msky130_fd_pr__nfet_01v8_lvt[cgg]
.endc
.end
m
@Tim Edwards In case you don’t see the other tag. Could this be related to the changes for 
0fe599b2afb6708d281543108caf8310912f54af
open_pdks 1.0.493?
t
This is the change for git hash 
0fe599b2afb6708d281543108caf8310912f54af
. I'm doing a full rebuild on my end and then try to figure out what's going on.
đź‘Ť 1
@Boris Murmann: I am not using containers so I can't verify what's going on with your (Harald's) setup. I did try with an update to volare and your example runs without issues, so there doesn't seem to be any problem with the open_pdks or volare updates.
h
@Tim Edwards which nhspive version are you using? In the last image we have 43.
t
I am using ngspice 42+. I was not aware of an update to 43.
h
We just now switched in the last image version. Maybe this causes the issue.
t
If true, that would be unfortunate. I am updating ngspice now to check.
@Harald Pretl: Can you confirm the issue that Boris is seeing on your end? If you do 
cat /foss/pdks/sky130A/libs.tech/combined/continuous/models_fet.spice | grep nf\ = | grep param
do you get this?:
Copy code
.param  w = 5 l = 0.7 nf = 1 sa = 0 sb = 0 sd = 0
.param  nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = 0 nrs = 0 sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w}
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w}
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  nf = 1 w = 5 l = 0.7 sa = 0 sb = 0 sd = 0
.param  nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = 0 nrs = 0 sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
(Namely, 
nf = 1
should never be at the end of the .param line)
FYI, after an update of ngspice to version 43, I am not seeing any issue; I still have no problem running Boris' example.
h
I’ll take a look, give me a few minutes….
Test 1: Checking volare hash: in 
2024.08
image we have `0fe599b2afb6708d281543108caf8310912f54af installed, that matches the above quoted one — check.
Test 2: Run 
cat /foss/pdks/sky130A/libs.tech/combined/continuous/models_fet.spice | grep nf\ = | grep param
, I get this:
Copy code
/foss/designs > cat /foss/pdks/sky130A/libs.tech/combined/continuous/models_fet.spice | grep nf\ = | grep param
.param  w = 5 l = 0.7 nf = 1 sa = 0 sb = 0 sd = 0
.param  nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = 0 nrs = 0 sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w}
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w}
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  nf = 1 w = 5 l = 0.7 sa = 0 sb = 0 sd = 0
.param  nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = 0 nrs = 0 sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = {0.14/w} nrs = {0.14/w} sa = 0 sb = 0 sd = 0
Looks pretty similar to Tim’s output I would say.
Test 3: Running Boris’s example. OK, now I know what is going in. Running 
ngspice test_boris.spice
I get all kind of weird errors, that also Boris reports. Running 
ngspice -n test_boris.spice
works fine. In our image, I have in the user home the following `.spiceinit`:
Copy code
* Set to 4 threads, if not changed otherwise
set num_threads=4
* Load the PDK-specific .spiceinit
source $PDK_ROOT/$PDK/libs.tech/ngspice/.spiceinit
This means (I guess) that when sourcing the PDK-provided 
.spiceinit
the problem shows up. @Tim Edwards Could you please try to replicate?
t
Trying it now. . .
No, I'm not getting an issue either with the PDK 
.spiceinit
or with 
num_threads
set.
h
It is definitely the 
.spiceinit
call in the user home. If I remove the file the error is gone. It is this line that triggers the error: 
source $PDK_ROOT/$PDK/libs.tech/ngspice/.spiceinit
OK, my bad. I modify the PDK .spiceinit during image build, and it looks like this:
Copy code
* ngspice initialization for sky130
* assert BSIM compatibility mode with "nf" vs. "W"
set ngbehavior=hsa
* "nomodcheck" speeds up loading time
set ng_nomodcheck
set enable_noisy_r
@Tim Edwards could you please try this file?
@Tim Edwards Hah, this looks like a buffer overflow in ngspice 🙂 If I copy the .spiceinit from the PDK to /tmp, and I do this:
Copy code
source /foss/pdks/volare/sky130/versions/0fe599b2afb6708d281543108caf8310912f54af/sky130A/libs.tech/ngspice/.spiceinit
the error shows up (I did this test to check whether the symbolic link is the issue, but it is not.. the resolved path length is). If I now do this (sourcing the exact same file) everything is fine:
Copy code
source /tmp/.spiceinit
So the issue is in ngspice of a buffer size somewhere, coupled with the volare PDK setup that causes pretty long path lengths due to the symbolic links.
@Tim Edwards Is there any way you could try to replicate this issue before we open a ngspice bugreport?
b
@Harald Pretl thanks for this great detective work! And what a weird coincidence...
t
@Harald Pretl: I'm not even sure how to set that up. Usually when I'm using volare I refer to the PDK through the symbolic link from 
~/.volare/
which avoids the 
versions/<long_hash_value>/
in the path. But it sounds like you gave it the symbolic link and it expanded it and then caused a buffer overrun. Or was it the expansion of 
$PDK_ROOT/$PDK
(I know that support of environment variables passed directly to ngspice is new, so more likely to have bugs not previously encountered by anyone)? I'd say go ahead with the bug report.
h
I further dug into it, and the long path is also not the issue, at least only part of the issue. I am now confused, the only thing that does not fail is to have no 
source
statements in a 
.spiceinit
. I will provide an updated image which avoids this, I am currently in the build and test stage. This a very weird failure.
23 Views
Open in Slack
PreviousNext
Powered by