A: This means that at the time that the simulation step ended, not all of the nodes in your simulation have settled. You can find out which nodes have pending events with the printp command.
If your circuit is still working, then even if you have pending events it is ok. However, this might be an indication that if your increase your clock speed much more, your circuit will begin to operate incorrectly.
Q: When I bring up IRSIM, it says that I have shorted transistors. What does this mean?
A: This means that you have some transistors that have their source and drain shorted together. So unless you are trying to build a capacitor, this is not a good thing.
Q: When I bring up IRSIM, it says that I have parallel transistors. What does this mean?
A: This means that more than one transistor have the same gate,source, and drain terminals. If you've folded transistors (like maybe for a large driver), then you will have transistors in parallel. This is not a bad thing, provided that you meant to have parallel transistors.
When running simulations including the pad frame, some groups have been frightened by the extremely high number of parallel transistors that irsim reports. Keep in mind that the pad frame alone has very many parallel transistors (large drivers with folded transistors). The pad frame alone reports: parallel txtors: n-channel=748 p-channel=714
Q: When I try to do ext2sim, I get a whole slew of warnings and errors. What could be the matter?
A: It is possible that ext2sim cannot find the subcells of your layout. Remember that .ext files have hierarchy. There is a way to have ext2sim expand its search path beyond the current directory. See the ext2sim manual page.
Q: What are the ext2sim options that are enabled in the setup file? What do they do? Why do we use them?
A: The ext2sim options that are enabled are -c 1 and -R. The -c 1 option sets the capacitance threshold to 1fF. This means that any cap smaller than 1fF will be ignored. This makes sure that you are not on the margin for problems like charge sharing.
The -R sets the resistance threshold to infinity.
Make sure that you have these options enabled when you run ext2sim.
Ext2sim options are explained more fully in the ext2sim man page and the extcheck man page.
Q: I want to save the state of my simulation, so that I don't have to keep running my dorky setup command file every time. How can I do this?
A: There are 2 ways to save the state of a simulation in irsim. The first way saves the state of the sim as well as the history. The second way only saves the state.
The command dumph will dump the history of the simulation to a specified file. The readh command will read that history back out. Please take a look at the irsim manual page for specifics.
The > command will write only the state (not the history) of a simulation to a file. The < command will read this back out. This is especially useful for running very long tests, where the history buffer of irsim gets huge. You can break up your test and at the end of each piece, write the state to a file. When you start up the next piece, just read that state back in.
Q: How do I flush out the history buffer?
A: When you run very long simulations, you will find that the hsitory buffer gets unmanageably large. The command "flush" will empty the history buffer. So you can put this in your .cmd files periodically, if you don't want the history buffer to get too large.
Q: Ifsim is seeding faults into the pad frame. These faults are in parts of the pad frame that we don't use, and thus don't care about. Since we don't detect theses faults, this seeding is artificially driving out fault coverage down. Is there a way to prevent ifsim from seeding faults in the pad frame?
A: Yes. It is a little tricky, but possible. You need to make ifsim think that the pad frame nodes are inputs. Then, it will not seed faults into those nodes. Here is the procedure:
nohup ifsim scmos100.prm chip.sim
h 3_*NOTE: The "3_*" may not correspond to the pad frame nodes in your layout. You need to check to see what the pad frame nodes are called and alter the above command accordingly. It is very important that you do not toss out any of the core nodes when you are trying to toss out the pad frame nodes. You can check your regexp by doing a display of all of those nodes in irsim and see if only pad frame nodes are listed.
s
x 3_*NOTE: The same reservations apply here that apply to the "h 3_*" step.
s
short
faultsim faultin faultout
Q: Running ifsim takes a long time. I don't want to have to sit in front of this machine for 4 hours. Is there a way to keep ifsim running even after I logout?
A: Yes. You can use the unix command nohup to keep processes running even after you logout.
elaineXX> nohup ifsim scmos100.prm chip.simThis will bring up ifsim like normal. Do everything that you need to do and issue the faulsim command. At this point, suspend the process (ctrl-z). Now stick the process in the background (bg), and it is safe for you to logout. When you login later, you should see that ifsim has dumped the faultsim results to the output file that you specified.
Q: Ifsim hung right after I issued the faultsim command. Arrgh!
A: It is possible that ifsim has hung, but probably it is just still crunching on the fault simultation. If you do a ctrl-c, you will stop ifsim, and you can see the status of the fault simulation (how many faults seeded, faults detected, etc). However, there is no way to resume where you left off.
If you can't wait around for ifsim to finish, try using the nohup command (described in previous question).
HINT: Running Ifsim
Before you run ifsim with a gonzo huge test vector, try it with a little tiny test vector just to get a feel for what it does. Also this lets you try out your faultsim input file without having to wait for 4 hours.
You can create a little test vector from a larger one by just using the first few hundred lines of the large vector. Use the unix "head" command to create a file that is only the first few hundred lines of the large vector.
head -500 versim.cmd >> small.cmdThe above will dump the first 500 lines of versim.cmd into small.cmd.
Q: I am confused about the faultsim input file. Can I see an example?
A: Here is a sample ifsim input file
seed 05The individual bits of the multi-bit signal Out1_s1 look like Out1_s1[0], Out1_s1[1], etc.
trigger phi1 1
Out1_s1[{0:4}]
***
trigger phi1 1 5
Out2_q1
***
For the signal Out2_q2 there is a 5ns delay from the rising edge of phi1 to when the signal is sampled.
5% of the nodes are seeded with faults.
Q: When we run faultsim we get this mysterious error:
(ifsimsetup,4): too many arguments in command
(ifsimsetup,5): too many arguments in command
What is going on, and how do I fix it?
A: In your input file to faultsim, you probably have a large number of signals triggering on one thing. Also you are probably using "{}" to expand out a vectorized signal. In doing all of that, your input file is overflowing one of the parsing buffers in ifsim.
To fix this, break up the larger trigger blocks into smaller ones. Also, you might have to break up the large multi-bit signals into smaller chunks. So instead of 0:15, break it up into 0:5, 6:10, and 11:15.