https://open-source-silicon.dev logo
Channels
aa
abcc
activity
adiabatonauts
analog-design
announce
announcements
b2aws
b2aws-tutorial
bag
basebands
beagleboard
bluetooth
board-respin
cadence-genus
cadence-innovus
cadence-spectre
cadence-virtuoso
caravan
caravel
caravel-board
chilechipmakers
chip-yard
chipignite
chipignite2206q_stanford_bringup
chisel
coalition-for-digital-environmental-sustainability
community_denmark_dtu
containers
courses
design-review
design-services
dffram
digital-design
digital-electronics-learners
discord-mods
dynamic-power-estimation
efabless
electric
events
fasoc
fault
foss-asic-tools
fossee-iitb-esim
fossee-iitb-google-sky130
fpga
funding
fuserisc
general
generative-ai-silicon-challenge
genius-vlsi
gf180
gf180mcu
hardware-beginners
help-
ieee-sscs-cac-23
ieee-sscs-dc-21q3
ieee-sscs-dc-22
ieee-sscs-dc-23
ihp-sg13g2
images
infiniband
j-core
japan-region
junk
klayout
latam_vlsi
layouteditor
lvs
lvs-analysis
magic
magical
maker-projects
maker-zone
microwatt
mpw-2-silicon
mpw-one-clean-short
mpw-one-silicon
neuro-mem
nydesign
open_pdks
open-pdk
openadiabaticlogic
openfpga
openhighqualityresonators
openlane
openlane_cloudrunner
openlane-development
openocd
openpositarithmetic
openpower
openram
openroad
opentitan
osu
pa-test-chip
paracells
pd-openlane-and-sky130
picosoc
pll
popy_neel
power
private-shuttle
rad-lab-silicon
radio
rdircd
reram
researchers
rf-mmw-design
rios
riscv
sdram
serdes
shuttle
shuttle-precheck
shuttle-status
silicon-photonics
silicon-validation
silicon-validation-private
sky130
sky130-ci
sky130-pv-workshop
sky65
sky90
skywater
sram
stdcelllib
strive
swerv
system-verilog-learners
tapeout-job
tapeout-pakistan
team-awesome
timing-closure
toysram
travis-ci
uvm-learners
vendor-synopsys
venn
verification-be
verification-fe
verilog-learners
vh2v
vhdl
vhdl-learners
vliw
vlsi_verilog_using_opensource_eda
vlsi_verilog_using_opensoure_eda
vlsi-learners-group
vlsi101
waveform-viewers
xls
xschem
xyce
zettascale
Powered by
Title
t

Tim Edwards

02/09/2023, 6:32 PM
@Stefan Schippers: Thank you for the webinar with Matt Venn! One point I'd like to make related to one of your last comments in the Q&A: It is possible to do co-simulation with iverilog, both in Xyce and in ngspice. Xyce has this written up here: https://xyce.sandia.gov/files/xyce/AppNote-MixedSignal.pdf (except this is a very technical and software-oriented application note, and I'm pretty sure there's one that is more user-oriented). The cosimulation between ngspice and iverilog is buried in an obscure branch and I need to bring it back out into the sunshine. Both are done in the same way, using one simulator as the primary one and setting up the other as a sub-process and communicating with it via a pipe. The ngspice version uses iverilog as the primary simulator, which then launches ngspice as a sub-process. Xyce does it the other way around, which makes more sense. At one time a few years ago, I started looking into the idea of writing a module for xspice which would read a compiled vvp file from iverilog and use it to generate xspice events. I never had the time to work on it but I think it is feasible and mainly involves ripping the vvp parser out of iverilog and rewriting it to use the xspice event queue.
🌍 1
s

Stefan Schippers

02/09/2023, 6:58 PM
Thank you for the question. Yes there are lot of interesting things that can be done. One thing to investigate is how synchronization works, and how to avoid interlocking/dead locks. One scenario for example is a digital block feeding some outputs fo the ngspice block and some ngspice outputs going as inputs to the digital block. ngspice does its time stepping calculation, so it needs inputs evaluated at a specific time. Event driven (digital) simulators on the other hand will jump to the next event, possibly skipping a huge time if nothing is changed. SO there must be some API for this, like the analog simulator generating an event in the future where the digital tool must stop at and dump the output values... I am not an expert in this area, however i have seen many cosimulations deadlocked for synhronization issues (analog waiting for digital to provide signals, digital blocked waiting for analog)...
In some cases the analog time step advance does not meet the required precision (error estimation) in this cases the analog simulator throws away the last point and advances with a smaller timestep. This happens for example if one signal is abruptly changing state, say from vss to vcc . So if there is a digital part cosimulating there must be some way to 'roll back' the digital engine.
I don't know how the ngspice transient analysis solver operates. If the analog simulator never throws away a time step (may be because it is smart enough to always estimate the correct time advance) then it will be much simpler...
This old 1996 paper does some investigation.
Usually much of the problems are avoided by intelligently splitting the circuits so there are synchronization devices (flops) at the domain boundaries.
🌍 1