| Previous journal: | Next journal: |
|---|---|
| 0201-2024-05-11.md | 0203-2024-05-20.md |
I want to try running a full SPICE simulation of the layout I submitted to TT06, including SPICE simulation of the embedded digital block. This will hopefully give a better idea of how well the 24-bit digital drivers into the DACs will work, and hence the expected output of the DACs, including parasitics from all wires, etc.
NOTE: In doing this, I should also check currents, e.g. load on power rails, and probably also on DAC resistors.
I did it as shown below, using my tt-vga-fun repo because at this point in time it still is using the exact layout I submitted to TT06, and the sim will be done from extraction of that layout only.
-
Full SPICE extraction of the entire design layout:
cd mag #NOTE: No PROJECT_NAME=... prefix needed as Makefile already specifies 'tt_um_algofoogle_tt06_grab_bag' make tt_um_algofoogle_tt06_grab_bag.sim.spice
This produces a 6.5MB
tt_um_algofoogle_tt06_grab_bag.sim.spicefile. Note that I saw the following warning about "current technology is "minimum" Sourcing design .magicrc for technology sky130A ..."... I think this is OK. -
Took Matt's
full_spice_sim.cir, blending it with aspects of mymixed.cirto try and make a suitable testbench.See also: More notes on SPICE for full extraction simulation
-
Tried an initial simulation and found it took way too long, but I managed to improve it by fiddling with more things...
-
I built the latest version of ngspice ("ngspice-42+"):
sudo apt install libomp-dev # Not sure this is actually required. cd ~ git clone git://git.code.sf.net/p/ngspice/ngspice ngspice-source cd ngspice-source chmod a+x compile_linux.sh sudo ./compile_linux.sh
NOTE: This should build and install the latest commit of ngspice (
b2c0f85c6d62433a651c9cff75668501199f43bb? Commit dates are out of order, and most recent appears to be44d0991af04dc6b1bdc52cbd7b52e0aae98ebff6). -
I created a
.spiceinitwhich is based on ngspice's recommendations for sky130. This might be outdated, or it might be the most recent recommendation; I don't know. It includes info about ngspice-42 (which is pretty recent):echo Using tt-vga-fun/sim/.spiceinit set ngbehavior=hsa ; set compatibility for reading PDK libs set skywaterpdk ; skip some checks for faster lib loading set ng_nomodcheck ; don't check the model parameters set num_threads=14 ; CPU processor cores available set xtrtol=10 option noinit ; don't print operating point data option klu ; select KLU as matrix solver optran 0 0 0 100p 2n 0 ; don't use dc operating point, but transient opNote also that I've configured it to use 14 threads (out of my total of 16 vCPUs in the VM I'm using). It seems to use one core at 100%, and the rest at about 15~22%.
Overall, I found this combination runs much faster than my initial attempt (in point 3). It's still slow, but at least it can do a full VGA line in about 8 hours (rather than what would've been more like 30 hours, I think).
-
To actually run the simulation:
ngspice full_spice_sim.cir
...or now use my Makefile:
time make cleanfull
My extracted tt_um_algofoogle_tt06_grab_bag.sim.spice seems to have the ports in a bit of a funny order:
.subckt tt_um_algofoogle_tt06_grab_bag_parax
+ clk
+ ena
+ rst_n
+ ua[3]
+ ua[4]
+ ua[5]
+ ua[6]
+ ua[7]
+ ui_in[1]
+ ui_in[6]
+ uio_in[0]
+ uio_in[1]
...
Note that it adds the suffix _parax (which I think comes from Matt's Makefile).
Note also that my first simulation attempt was EXTREMELY slow (from memory it took hours to simulate just a few microseconds), it was eating huge amounts of RAM, and generating massive .raw files. I optimised this a bit. Read on...
These are the things I did in my full_spice_sim.cir:
- Included lines which attempt to disable mismatch simulation and Monte Carlo, but I know neither whether this is a good idea, or makes any difference on performance, or even if they are correctly taking effect as expected:
* Disable mismatch: .param mc_mm_switch=0 * Disable Monte Carlo: .param mc_pr_switch=0 - Matched the weird port ordering of my overall TT tile layout (from extraction, as mentioned above), but also created port names with no brackets (just in case):
xtt + clk + ena + rst_n + ua3 + ua4 + ua5 + ua6 + ua7 + ui_in1 + ui_in6 + uio_in0 + uio_in1 ... - Added estimated TT pin loading.
- Used 1.8V throughout in contrast to Matt using 3.3V in some cases. I expect 1.8V matches actual VCC and digital inputs on-chip.
- Tried an example of pass-thru mode (my VGA controller's "mode 0") alternating between high and low analog outputs on alternating pixels by using
h0/p0in the MSB. Commented out for now. Seemed to work (and slews were bad, as expected). - Set up the test to do the "mode 3" (XOR) test for its main run.
- Shortened the reset time so it only takes about 100ns at the start of the test (and actual mode selection is stable by 120ns, if not sooner).
- Only store data for the things we care about to avoid chewing up too much memory (or writing a multi-GB
.rawfile). - Write those respective data values to a raw file named
full_spice_sim.raw. - Only try to simulate up to 256 lines. It takes up to 8 hours per line (!) so I'll never get that far anyway, unless I can find another way to speed up/optimise the sim.
- Current version of sim does about 4.3us per hour.
- Would it make any difference if the DAC was biased so that it looks like it has a 0.9 Vref?
- If you gracefully stop an ngspice simulation with Ctrl-C, it's possible to continue it with
resume - Using the ngspice
stopcommand sets a breakpoint (I think in parallel with a running simulation), and may allow for us to periodically stop at specific times, write out a .raw file, and thenresume. Search the manual forStop: Set a breakpoint. - ReJ message re transistor sizing for current: https://discord.com/channels/778248761054986292/1220788705778733086/1240712234150137956
- SPI interfacing mode
- ui_in can be 'hot' for options other than mode 0 (passthru).
- Fix extra mode settings, inc. gated/ungated, registered
- Option to offset XOR pattern by some amount that makes hard transitions more obvious in the first line
- Implement 'bars' mode
- Mode for a specific binary pattern that is useful within the first (say) 64 pixels (2.56us).
- Make first (or last) 10 (or 16?) pixels output a 0/255 (black/white) bit pattern to show the current (effective/offset) line number.
- In XOR mode, some bits to specify a different start line, and maybe sample every HSYNC, e.g. for
ui_in:- (NOTE: 9th bit, e.g. actual display line MSB, could be used in some way to flip another bit that otherwise can't be accessed, e.g. bit 0?)
- During reset: t011sssr:
- t is VGA timing mode
- 011 selects mode 3 (XOR)
- sss is start line number:
- 0 = 0
- 1 = 1
- 2 = 2
- 3 = 3
- 4 = 8
- 5 = 32
- 6 = 127 (deliberately not 128)
- 7 = 192
- r is: 0=unregistered; 1=registered
- During HSYNC (or at HSYNC's falling edge?):
- Either: x011xxxx: Continue
- Or: sSSSssss:
- sssss: Upper 5 bits of start line
- SSS: Lower 3 bits XORed with 011
- Examples:
- 00110000: CONTINUE (above), but otherwise would be 0.
- 00100000: Line 1
- 00010000: Line 2
- 00000000: Line 3
- 01110000: Line 4
- 01100000: Line 5
- 01010000: Line 6
- 01000000: Line 7
- 00110001: CONTINUE (otherwise would be 8)
- 00100001: Line 9
- 00010001: Line 10
- 01001111: Line 127
- 10100000: Line 129 (1000_0000 + 001)
- 11001111: Line 255 (1111_1000 + 111)
- NOTE: This enables (say) selection of line 127, rendering it and then lines 128 and 129 subsequently.