IRSIM(1)

📦

version 9.7.121 · 2 versions

9.7.121 · fedora 43, fedora 44 (latest)
9.7.104 · debian trixie, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

✨ NAME ✨

okay so <pink>irsim</pink> — an event-driven logic-level simulator for MOS circuits. this whole page is the IRSIM User's Manual, aka IRSIM(1), and bestie it is long, so buckle up. 💖

🌈 SYNOPSIS 🌈

irsim [-s] prm_file sim_file ... [+hist_file] [-cmd_file ...]

🦋 DESCRIPTION 🦋

IRSIM is an event-driven logic-level simulator for MOS (both N and P) transistor circuits. Two simulation models are available, and you get to pick your fighter:

switch — each transistor is modeled as a voltage-controlled switch. it's giving "quick and dirty" and that's a compliment — super useful for initializing the network or figuring out whether it even does the thing.
linear — each transistor is modeled as a resistor in series with a voltage-controlled switch, plus every node gets a capacitance. node values and transition times get computed from the resulting RC network, using Chorng-Yeoung Chu's model. and just so we're clear: Chris Terman's original model is not supported any more. it's gone, it's retired, we don't talk about it. 💀

If you pass the -s switch, then 2 or more transistors of the same type connected in series, with no other connections to their common source/drain, get stacked into a compound transistor with multiple gates. cute, efficient, slay.

The prm_file is the electrical parameters file that configures the devices to be simulated. it defines the capacitance of the various layers, transistor resistances, threshold voltages, etc... (see presim(1)). if prm_file does not specify an absolute path then IRSIM goes looking for it like this, in exactly this order:

./<prm_file> (in the current directory).
${CAD_ROOT}/irsim/<prm_file>
${CAD_ROOT}/irsim/<prm_file>.prm

the default search directory (nominally /usr/local/lib) can be overridden by setting the environment variable CAD_ROOT to the appropriate directory prior to running IRSIM (i.e. setenv CAD_ROOT /cad/lib). do it before, not after, bestie, timing is everything. 🫶

IRSIM first processes the files named on the command line, then — assuming the exit command has not been processed — it accepts commands from the user, executing each command before reading the next one.

File names NOT beginning with a '-' are assumed to be sim files (see sim(5)). quick note: this version does not require you to run the sim files through presim. these files get read and added to the network database. and here's the tea: there is only a single name space for nodes, so references to node "A" in different network files all refer to the same node. this feature lets you modularize a large circuit into several network files, which is great, but care must be taken to ensure no unwanted node merges happen because of an unfortunate clash in names. no cap, that will ruin your whole day. 😭

File names prefaced with a '-' are assumed to be command files: text files which contain command lines to be processed in the normal fashion. these files are processed line by line; when an end-of-file is encountered, processing continues with the next file. after all the command files have been processed, and if an "exit" command has not terminated the simulation run, IRSIM will accept further commands from the user, prompting for each one like so:

irsim>

The hist_file is the name of a file created with the dumph command (see below). if it's present, IRSIM will initialize the network to the state saved in that file. this file is different from the ones created with the ">" command, because it saves the state of every node for all times, including any pending events. ✨

This version supports changes to the network through the update command. also, the capability to incrementally re-simulate the network up to the current time is provided by the isim command. glow up, honestly. 💅

🎀 COMMAND SUMMARY 🎀

okay bestie, here's the whole menu. every single one, no skipping:

@ filename — take commands from command file
? wnode... — print info about node's source/drain connections
! wnode... — print info about node's gate connections
< filename — restore network state from file
> filename — write current network state to file
<< filename — same as "<" but restores inputs too
| comment... — comment line
activity from [to] — graph circuit activity in time interval
ana wnode... — display nodes in analyzer window
analyzer wnode... — display nodes in analyzer window
assert wnode [m] val — assert that wnode equals value
assertWhen nodeT valT node val — assert when a condition is met
back [time] — move back to time
c [n] — simulate for n clock cycles (default: 1)
changes from [to] — print nodes that changed in time interval
clock [node [val]] — define value sequence for clock node
clear — clear analyzer window (remove signals)
d [wnode]... — print display list or specified node(s)
debug [debug_level...] — set debug level (default: off)
decay [n] — set charge decay time (0 => no decay)
display [arg]... — control what gets displayed when
dumph filename... — write net history to file
hist [on|off] — turn history on or off
exit [status] — return to system
flush [time] — flush out history up to time (default: now)
h wnode... — make node logic high (1) input
has_coords — print YES if transistor coordinates are available
inputs — print current list of input nodes
ires [n] — set incremental resolution to n ns
isim [filename] — incrementally resimulate changes form filename
l wnode... — make node logic low (0) input
logfile [filename] — start/stop log file
model [name] — set simulation model to name
p — step clock one simulation step (phase)
path wnode... — display critical path for last transition of a node
powlogfile [filename] — start/stop power logfile
powtrace -[node]... — start/stop power tracing of specified node(s)/vector(s)
powstep — toggle the display of power estimate for each timestep
print comment... — print specified text
printp — print a list of all pending events
printx — print all undefined (X) nodes
q — terminate input from current stream
R [n] — simulate for n cycles (default: longest sequence)
readh filename — read history from filename
report[level] — set/reset reporting of decay events
s [n] — simulate for n ns. (default: stepsize)
stepsize [n] — set simulation step size to n ns.
set vector value — assign value to vector
setlog[file|off] — log net changes to file (off -> no log)
setpath — set search path for cmd files
stats — print event statistics
sumcap — print out the sum of the capacitance of all nodes
t [-]wnode... — start/stop tracing of specified nodes
tcap — print list of shorted transistors
time [command] — print resource utilization summary
until wnode [mask] value count — delayed assert based on the clock count.
u wnode... — make node undefined (X) input
unitdelay [n] — force transitions to take n ns. (0 disables)
update filename — read net changes from file
V [node [value...]] — define sequence of inputs for a node
vector label node... — define bit vector
vsupply voltage — set supply voltage for calculating power (default 5V)
w [-]wnode... — add/delete nodes from display list
wnet [filename] — write network to file
x wnode... — remove node from input lists
Xdisplay [host:n] — set/show X display (for analyzer)

💜 COMMAND DESCRIPTIONS 💜

Commands have the following simple syntax:

cmd arg1 arg2 ... argn <newline>

where cmd specifies the command to be performed and the argi are arguments to that command. the arguments are separated by spaces (or tabs) and the command is terminated by a <newline>.

If cmd is not one of the built-in commands documented below, IRSIM appends ".cmd" to the command name and tries to open that file as a command file (see the "@" command). so the command "foo" has the exact same effect as "@ foo.cmd". sneaky but iconic. 👑

Notation 📝

... — indicates zero or more repetitions
[ ] — enclosed arguments are optional
node — name of node or vector in network
wnode — name of node or vector in network, can include '*' wildcard which matches any sequence of zero or more characters. the pair of characters '{' and '}' denote iteration over the limits enclosed by it, for example: name{1:10} will expand into name1, name2 ... name10. a 3rd optional argument sets the stride, for example: name{1:10:2} will expand into name1, name3, ... name7, name9. wildcards are giving expressive. ✨
| comment... — lines beginning with a vertical bar are treated as comments and ignored — useful for comments or temporarily disabling certain commands in a command file.

Most commands take one or more node names as arguments. whenever a node name is acceptible in a command line, one can also use the name of a bit vector. in that case, the command will be applied to each node of the vector (the "t" and "d" treat vectors specially, see below).

vector label node... — define a bit vector named "label" which includes the specified nodes. if you redefine a bit vector, any special attributes of the old vector (e.g., being on the display or trace list) are lost. wild cards are not accepted in the list of node names, since you would have no control over the order in which matching nodes would appear in the vector. so don't try it, bestie.

The simulator performs most commands silently. to find out what's happened you can use one of the following commands to examine the state of the network and/or the simulator.

set vector value — assign value to vector. for example, the following sequence of commands:

vector BUS bit.1 bit.2 bit.3
set BUS 01x

the first command will define BUS to be a vector composed of nodes bit.1, bit.2, and bit.3. the second command will assign the following values:

bit.1 = 0
bit.2 = 1
bit.3 = X

value can be any sequence of [0,1,h,H,l,L,x,X], and must be of the same length as the bit vector itself. mismatched length? not the vibe. 🙈

💅 `d [wnode]...`

Display, bestie. No arguments? It shows the values of all nodes and bit vectors currently on the display list (peep the w command for that list). With arguments? Only shows the nodes or bit vectors you named. Also — if you want the display list printed out automatically at the end of certain simulation commands, go look at the display command. 👑

👀 `w [-]wnode...`

Watch/unwatch one or more nodes. Whenever a d command is given, each watched node will be displayed like so:

node1=0 node2=X ...

To remove a node from the watched list, preface its name with a -. If wnode is the name of a bit vector, the values of the nodes which make up the vector will be displayed as follows:

label=010100

where the first 0 is the value of first node in the list, the first 1 the value of the second node, etc. 🫶

🚨 `assert wnode [mask] value`

Assert that the boolean value of the node or vector wnode is value. If the comparison fails, an error message is printed. If mask is given then only those bits corresponding to zero bits in mask take part in the comparison, any character other than 0 will skip that bit. The format of the error message is the following:

                 (tty, 3): assertion failed on 'name' 10X10 (1010X)

Where name is the name of the vector, followed by the actual value and the expected value enclosed in parenthesis. If a mask is specified, then bits that were not compared are printed as -. 💀

⏳ `until wnode [mask] value count`

Acts just like the assert command except it requires an additional argument <count> which is the max number of clock cycles to run. Instead of just testing the current state, like assert, until tests for true and if false it runs clock cycles until condition becomes true or count runs out. No cap, it really does wait it out. 😭

🎀 `ana wnode...`

This is a shorthand for the analyzer command (described below). Periodt.

🌸 `analyzer wnode...`

Add the specified node(s)/vector(s) to the analyzer display list (see irsim-analyzer(3) for a detailed explanation). If the analyzer window does not exist, it will be created. If no arguments are given and the analyzer window already exists, nothing happens. Lowkey chill.

🖥️ `Xdisplay [host:display]`

You must be able to connect to an X-server to start the analyzer. If you haven't set up the DISPLAY environment variable properly, the analyzer command may fail. If this is the case you can use the Xdisplay command to set it from within the simulator. With no arguments, the name of the current X-server will be printed. ✨

🧹 `clear`

Removes all nodes and vectors from the analyzer window. This command is most useful in command scripts for switching between different signals being displayed on the analyzer. It's giving reset era. 🦋

🔍 `?` and `!` — the network time machine

? and ! allow the user to go both backwards and forwards through the network. This is a useful debugging aid. Fr fr, it's iconic.

❓ `? wnode...`

Prints a synopsis of the named nodes including their current values and the state of all transistors that affect the value of these nodes. This is the most common way of wandering through the network in search of what went wrong. The output from the command ? out looks like

out=0 (vl=0.3 vh=0.8) (0.100 pf) is computed from:
n-channel phi2=0 out=0 in=0 [1.0e+04, 1.3e+04, 8.7e+03]
pulled down by (a=1 b=1)  [1.0e+04, 1.3e+04, 8.8e+03]
pulled up [4.0e+04, 7.4e+04, 4.0e+04]

The first line gives the node's name and current value, its low and high logic thresholds, user-specified low-to-high and high-to-low propagation delays if present, and its capacitance if nonzero. Succeeding lines list the transistor whose sources or drains connect to this node: the transistor type ("pulled down" is an n-channel transistor connected to gnd, "pulled up" is a depletion pullup or p-channel transistor connected to vdd), the values of the gate, source, and drain nodes, and the modeling resistances. Simple chains of transistors with the same implant type are collapsed by the -s option into a single transistor with a "compound" gate; compound gates appear as a parenthesized list of nodes (e.g., the pulldown shown above). The three resistance values — static, dynamic high, dynamic low — are given in Kilo-ohms.

Finally, any pending events for a node are listed after the electrical information. 👑

❗ `! wnode...`

For each node in the argument list, print a list of transistors controlled by that node. It's the reverse angle, bestie.

🔌 `tcap`

Prints a list of all transistors with their source/drain shorted together or whose source/drain are connected to the power supplies. These transistors will have no effect on the simulation other than their gate capacitance load. Although transistors connected across the power supplies are real design errors, the simulator does not complain about them. 💀

Any node can be made an input — the simulator will not change an input node's value until it is released. Usually only specific nodes — inputs to the circuit — are manipulated using the commands below, but you can fool with a subcircuit by forcing values on internal nodes just as easily. Main character energy.

⬆️ `h wnode...`

Force each node on the argument list to be a high (1) input. Overrides previous input commands if necessary.

⬇️ `l wnode...`

Like h except forces nodes to be a low (0) input.

❓ `u wnode...`

Like h except forces nodes to be a undefined (X) input.

🚫 `x wnode...`

Removes nodes from whatever input list they happen to be on. The next simulation step will determine the correct node value from the surrounding circuit. This is the default state of most nodes. Note that this does not force nodes to have an "X" value — it simply removes them from the input lists. No cap.

📋 `inputs`

Prints the high, low, and undefined input lists. Slay.

It is possible to define a sequence of values for a node, and then cycle the circuit as many times as necessary to input each value and simulate the network. A similar mechanism is used to define the sequence of values each clock node goes through during a single cycle.

Each value is a list of characters (with no intervening blanks) chosen from the following:

1, h, H     logic high (1)
0, l, L     logic low (0)
u, U        undefined (X)
x, X        remove node from input lists

Presumably the length of the character list is the same as the size of the node/vector to which it will be assigned. Blanks (spaces and tabs) are used to separate values in a sequence. The sequence is used one value at a time, left to right. If more values are needed than supplied by the sequence, IRSIM just restarts the sequence again. 🔁

🧵 `V [node [value...]]`

Define a vector of inputs for a node. After each cycle of an "R" command, the node is set to the next value specified in the sequence.

With no arguments, clears all input sequences (does not affect clock sequences however). With one argument, "node", clears any input sequences for that node/vector.

🕰️ `clock [node [value...]]`

Define a phase of the clock. Each cycle, each node specified by a clock command must run through its respective values. For example,

clock phi1 1 0 0 0
clock phi2 0 0 1 0

defines a simple 4-phase clock using nodes phi1 and phi2. Alternatively one could have issued the following commands:

vector clk phi1 phi2
clock clk 10 00 01 00

With no arguments, clears all clock sequences. With one argument, "node", clears any clock sequences for that node/vector. 💖

After input values have been established, their effect can be propagated through the network with the following commands. The basic simulated time unit is 0.1ns; all event times are quantized into basic time units. A simulation step continues until stepsize ns. have elapsed, and any events scheduled for that interval are processed. It is possible to build circuits which oscillate — if the period of oscillation is zero, the simulation command will not return. If this seems to be the case, you can hit <ctrl-C> to return to the command interpreter. Note that if you do this while input is being taken from a file, the simulator will bring you to the top level interpreter, aborting all pending input from any command files. 😭

This is your emergency exit, bestie. Use it wisely.

When using the linear model (see the "model" command) transition times are estimated using an RC time constant calculated from the surrounding circuit. When using the switch model, transitions are scheduled with unit delay. These calculations can be overridden for a node by setting its tplh and tphl parameters which will then be used to determine the time for a transition.

⏩ `s [n]`

Simulation step. Propagates new values for the inputs through the network, returns when n (default: stepsize) ns. have passed. If n is specified, it will temporarily override the stepsize value. Unlike previous versions, this value is NOT remembered as the default value for the stepsize parameter. If the display mode is "automatic", the current display list is printed out on the completion of this command (see "display" command). 🔥

🔄 `c [n]`

Cycle n times (default: 1) through the clock, as defined by the "clock" command. Each phase of the clock lasts stepsize ns. If the display mode is "automatic", the current display list is printed out on the completion of this command (see "display" command). 🌈

👟 `p`

Step the clock through one phase (or simulation step). For example, if the clock is defined as above

clock phi1   1 0 0 0
clock phi2   0 0 1 0

then "p" will set phi1 to 1 and phi2 to 0, and then propagate the effects for one simulation step. The next time "p" is issued, phi1 and phi2 will both be set to 0, and the effects propagated, and so on. If the "c" command is issued after "p" has been used, the effect will be to step through the next 4 phases from where the "p" command left off. 💅

R [n] — run the simulator through n cycles (yes bestie, it's literally the c command, just vibing under a different name 💅). If you don't hand it an n, it just runs as long as the longest sequence. When display mode is automatic (peep the display command), the display prints at the end of every cycle. And every single R command restarts from the beginning of the sequence defined for each node — like, full reset energy ✨
back time — glide back to the specified time. This restores circuit state as of that time, effectively undoing every change in between. 🦋 Heads up though: you can't move past any previously flushed-out history (see the flush command below) because the history mechanism is what's doing the restoring. Super handy for undoing an oopsie in your input vectors, or for re-simulating the circuit at a different debug level 🔥
path wnode... — show the critical path(s) for the last transition of the node(s) you name. Critical path transitions get reported in this format:

node -> value @ time (delta)

where node is the node's name, value is the value the node transitioned to, time is when that transition happened, and delta is the delay through the node since its last transition. Like, for example:

critical path for last transition of Hit_v1:
     phi1-> 1 @ 2900.0ns , node was an input
     PC_driver-> 0 @ 2900.4ns    (0.4ns)
     PC_b_q1-> 1 @ 2904.0ns    (3.6ns)
     tagDone_b_v1-> 0 @ 2912.8ns    (8.8ns)
     tagDone1_v1-> 1 @ 2915.3ns    (2.5ns)
     tagDone1_b_v1-> 0 @ 2916.0ns    (0.7ns)
     tagDone_v1-> 1 @ 2918.4ns    (2.4ns)
     tagCmp_b_v1-> 0 @ 2922.1ns    (3.7ns)
     tagCmp_v1-> 1 @ 2923.0ns    (0.9ns)
     Vbit_b_v1-> 0 @ 2923.2ns    (0.2ns)
     Hit_v1-> 1 @ 2923.5ns    (0.3ns)

activity from_time [to_time] — print a histogram of how much the circuit was doing in that time interval. Real talk: it actually only shows the number of nodes whose most recent transition landed in the interval. 🙈
changes from_time [to_time] — print the list of nodes that last changed value inside the given time interval.
printp — print a list of all pending events, sorted in time. Each event's node and its scheduled time get printed. 👑
printx — print a list of every node with an undefined (X) value. 💀

Using the trace command, you can get way more deets about what's happening to one specific node. A lot of what comes next is described in much more detail in "Logic-level Simulation for VLSI Circuits" by Chris Terman, available from Kluwer Academic Press (iykyk 📚). When a node is traced, the simulator reports every change in that node's value:

[event #100] node out.1: 0 -> 1 @ 407.6ns

The event index increments for each event that gets processed. The transition itself is reported as

old value -> new value @ report time

Note that since the time an event is processed may differ from the event's report time, the report times for successive events might not be strictly increasing. That's not a bug bestie, that's just how it is 😭

Depending on the debug level (see the debug command), every calculation of a traced node's value gets reported too:

[event #99] node clk: 0 -> 1 @ 400.2ns
final_value( Load )  V=[0.00, 0.04]  => 0
..compute_tau( Load )
{Rmin=2.2K  Rdom=2.2K  Rmax=2.2K}  {Ca=0.06  Cd=0.17}
tauA=0.1  tauD=0.4 ns
[event #99: clk->1] transition for Load: 1 -> 0 (tau=0.5ns,
  delay=0.6ns)

In this example, a calculation for node Load is reported, caused by event 99 where node clk went to 1. When you're using the linear model (like here), the report shows

current value -> final value

The second line spills the info about the final value (or dc) analysis for node Load; the minimum and maximum voltages, plus the final logical value (0 in this case). 🫶

The next three lines show the timing analysis info used to estimate delays. The meaning of all those variables lives in Chu's thesis: "Improved Models for Switch-Level Simulation".

When the final value comes back as "D", that node isn't connected to an input, and it may be scheduled to decay from its current value to X at some later time (see the decay command). 🍓

tau is the calculated transition time constant, delta is when any consequences of the event will be computed; the difference between those two times is how IRSIM accounts for the shape of the transition waveform on subsequent stages (see that reference above for more). The middle lines of the report show the Thevenin and capacitance parameters of the surrounding networks — the parameters the transition calculations are based on, periodt.

✨ debug ✨

debug [ev dc tau taup tw spk][off][all] — set the debugging level. Clutch for debugging the simulator and/or the circuit at different levels of the computation. Here's what each level means:
- ev — display event enqueueing and dequeueing.
- dc — display dc calculation information.
- tau — display time constant (timing) calculation.
- taup — display second time constant (timing) calculation.
- tw — display network parameters for each stage of the tree walk; this applies to dc, tau, and taup. You usually only need this level of detail when you're debugging the simulator itself.
- spk — displays spike analysis information.
- all — shorthand for specifying every one of the above. ✨
- off — turns off all debugging information.

If a debug switch is on, then during a simulation step, every time a watched node gets encountered in some event, that fact is shown to you along with some event info. If a node keeps showing up in this printout, chances are its value is oscillating. And flip side: if your circuit never settles (i.e., it oscillates), you can use the debug and t commands to find the node(s) causing the problem. 🕵️‍♀️

With no arguments at all, the debug command prints the current debug level.

✨ t ✨

t [-]wnode... — set the trace flag for a node. This enables all the various printouts described above. Put a - in front of the node name to clear its trace flag. If wnode is the name of a vector, then whenever any node of that vector changes value, the current time and the values of all traced vectors get printed. This is lowkey perfect for watching the relative arrival times of values at nodes in an output vector. 🌈

✨ System interface commands ✨

> filename — write the current state of each node into the specified file. Great for making a breakpoint in your simulation run. It only stores values, so it's not really useful for "dumping" a run for later use — i.e., the current input lists, pending events, etc. are NOT saved in the state file. 💀
< filename — read from the specified file, reinitializing the value of each node as directed. Note that the network must already exist and be identical to the network used to create the dump file with the > command. These state-saving commands exist so that complicated initializing sequences only need to be simulated once. 🎀
<< filename — same as the < command, except this one restores the input status of the nodes as well. It does not, however, restore pending events.
dumph [filename] — write the history of the simulation to the specified file — that is, all transitions since time = 0. The resulting file is a machine-independent binary file, and it contains all the info required to continue simulation at the time the dump takes place. If you don't specify a filename, it gets constructed by taking the name of the sim_file (from the command line) and appending ".hist" to it. 🦋
readh filename — read the specified history-dump file into the current network. This restores the state of the circuit to that of the dump file, overwriting the current state.
flush [time] — if memory consumption from history maintenance becomes prohibitive, this command frees the memory consumed by the history up to the specified time. With no arguments, all history up to the current point in the simulation is freed. ⚠️ Flushing out the history may invalidate an incremental simulation, and the portions flushed will no longer appear in the analyzer window. So, like, be careful bestie.
setpath [path...] — set the search-path for command files. path should be a sequence of directories to search for ".cmd" files, with . meaning the current directory. For example:

setpath . /usr/me/rsim/cmds /cad/lib/cmds

With no arguments, it prints the current search-path. Initially this is just ".".

print text... — simply prints the text on your console. Useful for keeping the user posted on progress through a long command file. 💅
logfile [filename] — create a logfile with the specified name, closing the current log file if there is one; with no argument, just close the current logfile. All output that appears on your console also lands in the logfile. Output to the logfile is cleverly formatted so that logfiles themselves can serve as command files. 👑
setlog [filename | off] — record all net changes, plus any resulting error messages, to the specified file (see the update command). Net changes are always appended to the log-file, and each sequence of changes is preceded by the current date. If the argument is off, then net-changes won't be logged. With no arguments, the name of the current log-file is printed.

The default is to always record net changes; if no filename is specified (via the setlog command) the default filename irsim_changes.log gets used. The log-files are formatted so that log-files may themselves be used as net-change files. ✨

wnet [filename] — writes the current network out to the file you name 💾. No filename? No problem, bestie — it'll build one for you by grabbing the name of the sim_file (the one from the command line) and gluing .inet onto the end. The file it spits out can be fed into a future simulation run exactly like a sim file. It's a machine independent binary file, usually like 1/3 the size of the sim file and roughly 8 times faster to load. Slay.
time [command] — no argument? It prints a lil summary of the time the simulator has used ⏱️. Give it arguments and it times that specified command, printing the summary once it finishes. The summary format is Uu Ss E P% M, where:
- U => User time in seconds
- S => System time in seconds
- E => Elapsed time, minutes:seconds
- P => Percentage of CPU time (((U + S)/E) * 100)
- M => Median text, data, and stack size use
q — terminates the current input stream 🚪. Typed at top level? The simulator exits back to the system. Otherwise, input just reverts to the previous input stream. Very "bye then, not goodbye".
exit [n] — exits to the system, and n is the reported status (default: 0) 👋.

Simulator parameters are set with the following commands, bestie. With no arguments, each one of them just prints the current value of that parameter. So cute, so informative ✨.

decay [n] — sets the decay parameter to n ns (default: 0). If it's non-zero, it tells you the number of ns it takes for charge on a node to decay to X. A value of 0 means no decay at all, periodt. You cannot specify this parameter separately for each node, but this turns out not to be a problem — see the report command 🌸.
display [-][cmdfile][automatic] — sets/resets the display modes, which are:
- cmdfile — commands executed from command files get displayed to the user before executing. The default is cmdfile = OFF.
- automatic — prints out the current display list (see the d command) after the s or c command finishes. The default is automatic = ON.

Put a - in front of either of those and it turns that display option off 💅.

model [name] — sets the simulation model to one of these:
- switch — models transistors as voltage controlled switches. This model uses interval logic levels and doesn't account for transistor resistances, so circuits with fighting transistors may not be accurately modelled 😬. Delays may not reflect the true speed of the circuit either.
- linear — models transistors as a resistor in series with a voltage controlled switch. This model uses a single-time-constant computed from the resulting RC network, and uses a two-time-constant model to analyze charge sharing and spikes.

The default is the linear model. You can change the simulation model at any time — even with events pending — because only new calculations are affected 🫶. With no arguments, this command prints the current model name.

report [level] — when level is nonzero, it reports all nodes that are set to X because of charge decay, regardless of whether they're being traced 👀. Setting level to zero disables the reporting, but not the decay itself (see the decay command).
stepsize [n] — specifies the duration of a simulation step or clock phase. n is in ns (nanoseconds) ⏳. Floating point numbers with up to 1 digit past the decimal point are allowed. Any further decimals get truncated (i.e. 10.299 == 10.2).
unitdelay [n] — when nonzero, forces all transitions to take n ns. Setting the parameter to zero disables this feature. The resolution is the same as for the stepsize command.
stats — prints event statistics, like this:

changes = 26077
punts (cns) = 208 (34)
punts = 0.79%, cons_punted = 16.35%
nevents = 28012; evaluations = 27972

Where changes is the total number of transitions recorded, punts is the number of punted events, and (cns) is the number of consecutive punted events (a punted event that punted another event) 💀. The penultimate line shows the percentage of punted events with respect to the total number of events, plus the percentage of consecutive punted events with respect to the number of punted events. The last line shows the total number of events (nevents) and the number of net evaluations.

🧚 Incremental simulation commands 🧚

Irsim supports incremental changes to the network and resimulation of the resulting network 🔥. This happens incrementally so that only the nodes affected by the changes — directly or indirectly — get re-evaluated. Efficiency queen.

update filename — reads net-change tokens from the specified file. The following net-change commands are available:

add     type gate source drain length width [area]
delete  type gate source drain length width [area]
move    type gate source drain length width [area] g s d
cap     node value
N       node metal-area poly-area diff-area diff-perim
M       node M2A M2P MA MP PA PP DA DP PDA PDP
thresh  node low high
Delay   node tplh tphl

For a detailed description of this file see netchange(5). Heads up: this is an experimental interface and is likely to change in the future 🙈.

Also note that this command doesn't resimulate the circuit, so it may leave the network in an inconsistent state 😭. Usually this command will be followed by an isim command (see below); if that's not the case, then it's up to you to initialize the state of the circuit. This command exists only for historical reasons and will probably disappear in the future. Its use is discouraged.

isim [filename] — reads net-change tokens from the specified file (see netchange(5)) and incrementally resimulates the circuit up to the current simulation time (not supported yet) 🦋.
ires n — the incremental algorithm keeps track of nodes deviating from their past behavior as recorded in the network history 📜. During resimulation, a node is considered to deviate from its history if its new state is found to be different within n ns of its previous state. This command lets you change the incremental resolution. With no arguments, it prints the current resolution. The default resolution is 0 ns.
powlogfile [filename] — opens filename for writing nodal transition reports 📝. The format of the report is the same as what you get when you trace a node normally. With no arguments, powlogfile just closes the opened logfile and prints out a power dissipation summary. Nodal transitions in inputs are not included in the transition count 🔌.
powtrace [[-]node...] — the syntax of this command is the same as the normal t (trace) command 👑. Want to trace and report power dissipation for all the nodes? Just use powtrace *. Want to exclude some nodes? Use powtrace -node.
powstep — toggles whether dynamic power estimation is displayed after each timestep ⚡. The dynamic power displayed will only be for the nodes that have been selected using the powtrace command.
vsupply voltage — sets the V variable for use in the P=CV^2/(2t) expression, where C is capacitance switched and t is the timestep. The default value for vsupply is 5.0 Volts 🔋.
sumcap — gives a sum of all nodal capacitances, not just the ones selected with the powtrace command 💖.

🌈 SEE ALSO 🌈

presim(1) (now obsolete)
rsim(1)
irsim-analyzer(3)
sim(5)
netchange(5)

And that's a wrap on the whole page, bestie 🎀 This icon of a manual page comes to you from the 3rd Berkeley Distribution, and the page itself is IRSIM(1). Go forth and simulate, you main character 💅✨🦋

📦 where this page comes from

fedora 43: irsim 9.7.104-15.fc41 · GPLv2
fedora 43: irsim 9.7.121-1.fc43 · GPL-2.0-only
fedora 44: irsim 9.7.121-1.fc44 · GPL-2.0-only
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-10-13: a language model's rewrite of the original, under its terms

IRSIM(1)

✨ NAME ✨

🌈 SYNOPSIS 🌈

🦋 DESCRIPTION 🦋

🎀 COMMAND SUMMARY 🎀

💜 COMMAND DESCRIPTIONS 💜

💅 d [wnode]...

👀 w [-]wnode...

🚨 assert wnode [mask] value

⏳ until wnode [mask] value count

🎀 ana wnode...

🌸 analyzer wnode...

🖥️ Xdisplay [host:display]

🧹 clear

🔍 ? and ! — the network time machine

❓ ? wnode...

❗ ! wnode...

🔌 tcap

⬆️ h wnode...

⬇️ l wnode...

❓ u wnode...

🚫 x wnode...

📋 inputs

🧵 V [node [value...]]

🕰️ clock [node [value...]]

⏩ s [n]

🔄 c [n]

👟 p