Hi everyone. I recently installed Xyce (version 7....
# xyce
v
Hi everyone. I recently installed Xyce (version 7.8) and I wanted to use it as an alternative simulator to ngspice for xschem. My project is currently on asynchronous digital design using caravel's user project template and I would like to implement some part of the design in xschem to produce the netlists (containing combinatorial loops that yosys does not like) which will be included as part of user project. Then, to verify the project's final netlist functionality, I would use Xyce to simulate its behavior. Since openlane creates a lot of filler, cap and diode cells for production, this means my project will include all these subcircuits in its netlist. Finally, my problem begins, where Xyce does not find a suitable model card for the diode, as seen in the following error (complete xyce log included): Netlist error in file /home/vasilis/Internship/asynch2024/caravel_user_project/dependencies/pdks/sky130A/libs.ref/sky130_fd_sc_hd/spice/sky130_fd_sc_hd.spice at or near line 6088 Model is required for device D0 and no valid model card found. This is of course related to this part of the sky130_fd_sc_hd.spice file describing the diode subcircuit: .subckt sky130_fd_sc_hd__diode_2 DIODE VGND VNB VPB VPWR D0 VNB DIODE sky130_fd_pr__diode_pw2nd_05v5 pj=2.64e+06 area=4.347e+11 .ends By including the file where sky130_fd_pr__diode_pw2nd_05v5 is defined also does not resolve the issue. I also saw other posts here regarding problems with diodes instantiation, especially about Xyce not supporting level 3 description of diodes (which this model is) as well as scale inconsistencies. For the latter, I have tried specifying .options parser scale=1e-6, but with no avail. One other possibility would that according to the Xyce logs, due to an older version of the other models version (BSIM 4.5), Xyce reverts back to the oldest available version. Maybe that creates incompatibility issues with diode instantiation, which I dont know how to solve. Thank you all for your help! 😁
s
Xyce does not recognize level=3 diode models. If level=3 is found it scraps the model completely. Ngspice does load the model, although I am not sure if it recognizes all level=3 parameters / equations or just takes the known parts. (@Tim Edwards Do you have more info?). The following example defines a standard D1N4007 discrete diode model with the addition of
level=3
. It does not work in Xyce unless you remove the level=3 model parameter.
Copy code
* Test showing Xyce inability to load a standard diode model if
* level=3 is present in model.

.subckt diode_subckt a b
D1 a b D1N4007

.model D1N4007 D level=3
+      IS=7.02767n RS=0.0341512 N=1.80803 EG=1.05743 XTI=5
+      BV=1000 IBV=5e-08 CJO=1e-11 VJ=0.7 M=0.5 FC=0.5 TT=1e-07

.ends diode_subckt

va a 0 0.7
vb b 0 0

X1 a b diode_subckt

**** ngspice
* .options savecurrents
* .control
*   save all
*   op
* .endc

**** Xyce
.op
.print dc i(va)
.end
***** Reading and parsing netlist...
Netlist error in file test.spice at or near line 5
Model is required for device D1 and no valid model card found.
Simulation aborted due to error.  There are 0 MSG_FATAL errors and 1 MSG_ERROR
errors
*** Xyce Abort ***
By removing the level=3 parameter Xyce and ngspice give the same I/V characteristics.
Update: I tried Xyce vs ngspice on the
sky130_fd_pr__diode_pw2nd_05v5
diode subcircuit by removing the
level=3
in the inner
ndiode
model. in this case both ngspice and Xyce work, but give different results. Even ngspice gives very different results with / without level=3. As of today i trust ngspice results (with models unchanged) a little more for these diodes than Xyce (without the level parameter)
Copy code
* diode test ngspice vs Xyce

**** change paths according to your PDK installation.
.lib /home/schippes/share/pdk/sky130A/libs.tech/combined/sky130.lib.spice tt
.include /home/schippes/share/pdk/sky130A/libs.ref/sky130_fd_sc_hd/spice/sky130_fd_sc_hd.spice


VVCC VCC 0 1.8
VA A 0 dc 1.8

X1 A GND GND VCC VCC sky130_fd_sc_hd__diode_2

**** ngspice
* .option savecurrents
* .control
*   save all
*   op
*   print i(VA)
* .endc

**** Xyce. Works only if level=3 is removed in ndiode model
**** inside sky130_fd_pr__diode_pw2nd_05v5 subcircuit in file 
**** .../share/pdk/sky130A/libs.tech/combined/continuous/models_diodes.spice
VGND GND 0 0
.op
.print dc i(VA)

.end
v
Thank you @Stefan Schippers. I tried changing level 3 to 2 but not completely removing the property. To be honest I also do not prefer using xyce, but dealing with the same netlist, ngspice requires 90m in my laptop while xyce merely a couple of minutes. Maybe the results maybe slightly incorrect but I trust that the grander behavior of the circuit is not affected. As for the solution I would hope not to mess with the pdk directory, but for now, Xyce hasn't released any support for simple level 3 diodes :/
s
@Vasileios Rizeakos 90min vs a 2 min is a great difference. Are you running Xyce on multiple machines ? If not then try to tune the ngspice netlist, because in my experience such a large difference in execution time is strange (Cc @Holger Vogt)
t
@Stefan Schippers (@Vasileios Rizeakos): The level 3 diode differs from other diodes in allowing the area and perimeter to be specified by physical units. Otherwise, all diode models that I am aware of just have an area scale factor, and the extraction tool needs to know what area is represented by a default scale of 1 (could be anything). ngspice only implements the physical scaling part of level 3 diodes; there are other obscure parameters that are proprietary (the level 3 diode model is proprietary, although I don't think there's anything wrong with creating diode equations involving physical units and calling it "level 3"; diodes generally have very simple models, so the other level 3 parameters are presumably minor n-th order effects). In your first example, you implemented a diode without specifying area and perimeter. In that case, the diode model falls back on the scale factor, and so I would expect the result to be the same. My vague understanding is that the very weird units for area and perimeter in the Sky130 models comes from adjusting the model such that if you don't specify area and perimeter, then the default scale factor is equivalent to a diode area of 1 micron squared, or something like that (difficult to figure out from the models themselves because of the built-in scalefactor in the Sky130 models, but it could be worked out by experimenting). Why anybody thought it was a good idea to have a device model that is valid for both physical dimensions and unitless dimensions is beyond me. . .