If you want to present information meaningful to a user
the step-points (bit transitions vs voltage) ought to be
Calculator extracted from the results and histogramed
(though 5 iterations is statistically not-useful). These
transition points are your quantity of interest, code vs vin.
You want to understand what is driving the PP+MM
functional falling-apart, twon runs, one with and one
without MM enabled should put that plain. Then you
have to dive in and debug some of the worst ones,
which I think you can do by enabling the same MC
mode and only running the one iteration= variable
value.
It may be useful to add to your testbench, some
NMOS and PMOS devices that are the same geom
and bias as the PCM/WAT tests at the foundry, for
(say) VT and IDsat, anything you can get data for,
so you can criticize the devices as simulated against
the device advertised control ranges. High-sigma
MC simulation may put you far outside WAT limits
and you ought not to be on the hook for the circuit
performance when transistors are "not shippable",
modeling groups will sandbag statistics under direction
from the Methodology Harpies and you have to buck
that, sometimes. On one program way back when
MC was first becoming diktat, I ran the rack of WAT
tests, identified any MCCNT= value which made a
rejectable wafer, and implemented a MC mapping
that skipped unreasonable ones. I sold that story
to the Air Force andtheir tech monitor. But you do
need a solid sense of what's reasonable and
expectable from the fab (which is not the modeling
group) at the bottom of it all, and maybe you don't
get to have that for this exercise.