How long one chunk of a step simulation's run may take, in ms. The same second the .NET simulator's chunk takes, and for the same reasons: it is how often a progress bar moves and how soon a cancellation is noticed. Applied to the renderer's own simulator too, so that a run is the same sequence of chunks whichever is running and nothing has to estimate how many clocks a chunk should be.

How old a sheet backup has to be before closing the project deletes it. A backup is what the last few edits were before the save, and it is worth having for as long as an accident might still be discovered - which is this session and the next one. Beyond that the saved .dgm is what the user meant, and the backups are a folder of files nobody will ever open. Two days keeps yesterday's work and clears out the term's.

The share of the heap budget its expanded design may take before a simulation is started at shortStartClock rather than at what it was configured for.

How long after an edit the Simulation tab works out whether the design still builds. The check flattens the whole hierarchy, so this is what stops a burst of edits - drawing a run of wires, dragging out a selection - costing one flatten each. Long enough to cover the gap between two deliberate edits, short enough that the button follows the design rather than lagging behind it.

The absolute ceiling on a waveform simulation's last clock, whatever fits in memory: past this the viewer itself cannot display the whole waveform nicely.

The fewest clock cycles of history the step simulator will build for. A design whose per-cycle cost leaves room for fewer than this is refused rather than simulated: below it there is not enough past to step back through, and every step would be a rebuild.

Needed to prevent possible overrun of simulation arrays. Defined in CommonTypes, beside WSConfig, because FastCreate's memory check must agree with the dialog about the array size a configuration implies; aliased here for the many existing readers.

How tall the project browser's list of folders is. Fixed, and scrolling inside itself, so that a folder of 200 subfolders does not push the path bar off the top of the dialog.

How often the project browser re-reads the folder it is showing, so that a folder made or renamed outside Issie appears without being asked for. Listing a folder is one directory read plus one per subfolder in it - a millisecond or so for an ordinary folder, and 14ms for the worst one on a typical Windows machine - so this costs nothing worth measuring.

How many clock cycles the RENDERER's own step arrays hold while the .NET simulator is the one simulating: two, which is as close to none as a built simulation can get. Enough to be a working simulation and no more. In that mode the renderer builds a FastSimulation for its STRUCTURE - the wave index, the drivers, the names and widths the selector and the viewer are built from - and reads none of its data: the waveforms come off the wire, and what still reads the local arrays (the RAM tables, the schematic probe) is reading a simulation that is never run whatever its size. Sizing them for the configured run instead cost the whole run twice over. Four million cycles of 3cpu is 9GB of typed arrays in the renderer, allocated to be left at zero, and stopping and starting such a simulation asked for the second 9GB while the first was still held - which fails, with `RangeError: Array buffer allocation failed` from inside the step arena, on a machine that has the memory for either one alone. The .NET side is unaffected: it is sized from the configuration, which is what it is simulating. Two rather than none because the build itself writes a step: ordering reduces every component once at step 0, and a clocked component reads the step before the one it writes, which needs the two to be different slots. It was 1203 while things still read those arrays in this mode - the schematic probe, the RAM tables, a ROM's hover comment, the step panel's inputs - and all of them read a simulation that had never been run, so what they showed was an unrun array's zeros. Each now either comes over the wire or says nothing, so the arrays hold nothing worth keeping. Measured on a 120,000-component design, building the same sheet twice in one session: the renderer's build allocates 241 MB where it allocated 821 MB, and takes 2.4s rather than 2.8s. The 580 MB was step arrays that nothing read.

initial number of clock cycles navigated by the scrollbar.

Where a waveform simulation of a big design starts, in clock cycles. Enough to watch a design work; short enough that starting one is seconds rather than minutes.

How many cycles a waveform simulation must hold beyond its last clock. Zooming out samples every Nth cycle, and reading the last sample can run a multiplier past LastClock - so the arrays carry a margin of one. It used to be the largest multiplier there is, whatever the simulation was: a 200-cycle simulation allocated 1203 cycles of arrays, six times what it could use. A multiplier bigger than LastClock samples nothing, so the margin is the largest that is not, and the one in use whatever that is - the zoom menu offers the current multiplier back even when the configuration has since shrunk under it.