Whether Refresh can rebuild without asking: have the inputs held their default values for the whole run so far, so that restarting loses nothing the user set? With the .NET simulator that question cannot be asked here - the whole run is in the sidecar, and this process's arrays were never written - so the one it CAN ask is asked instead: do the inputs match their defaults at the clock on screen. The two differ only for an input that was changed and then put back, where this says nothing was changed and Refresh does not stop to ask. Reading the run's history over the wire is what would give the exact question back.

Advance whichever simulator is running TOWARDS `cycle`, for at most one chunk, and say what clock it reached. **One chunk, not a run.** A second of simulation, or the cycle asked for, whichever comes first. Getting all the way there is the caller's business: `simulateWithProgressBar` asks again until it arrives, which is the same shape the waveform simulator's run has and for the same reasons - the loop is in the update function, nothing is ever interrupted, and stopping is not asking for the next chunk. Both simulators can do this. `FastRun.runFastSimulation` takes a time budget and says where it stopped; `SidecarSession.runChunk` does the same over the wire. So there is nothing to estimate and no per-simulator arithmetic: how far a second gets is measured, by running for a second. Local: the FastSimulation is run here and `whenReady` is called at once, exactly as before. Sidecar: the session is run a chunk and the panel's signals read back into StepPanelData, then `whenReady`. If the sidecar does not hold the design, a build is STARTED - an operation, with the model saying so until it answers - and this advance does nothing; the next one finds a session and runs it.

The clock a run should advance FROM: what the panel is showing now. Locally the FastSimulation's own tick and the model's are the same number - the model is incremented by exactly what was run - and the FastSimulation's is used because it is the one that cannot be stale. In sidecar mode the local simulation is built and never run, so its tick is 0 for ever; the sidecar's own clock is not the answer either, since it only ever goes forwards while the panel can be stepped back. The model's clock is what is on screen.

One step of the step-simulation run's cascade: issue the next piece of sidecar work the run needs, or finish, or - if the wire is held by something else - do nothing. The sequencing is Elmish and nothing else. The cascade is STARTED by a command (StartStepRun); every completion comes back as a message whose handler records the fact and calls this to issue the next chunk - so the set of places the run can continue from is exactly the reply handlers (AnsSteppedTo, AnsBuilt, and AnsFetched for a panel read that borrowed the wire), never "after every message". Cancelling is clearing StepRunTarget - closing the bar does it - and the next completion finds nothing to issue, which is the cancellation's response. The renderer's own simulator never comes through here: its chunks are synchronous and message-sequenced (SimulateWithProgressBar), so nothing can interleave with them.

get the position and rotation for inserting a new component next to the given port at a given distance the rotation is such that the original left side of the component (input side) faces the given port returns None if another symbol is in the way

The panel's top-level input or output values, from whichever simulator is running.

Issue the .NET build a step simulation needs: the START's operation - StartSimulation and the goto's cascade both come here, and nothing else ever builds for the step simulator. Its completion (AnsBuilt) creates the session the reads and runs require.

Pretty print a label with its width.

Read one memory from the .NET simulator and open the diff against its initial contents. No cache and no held state, unlike the waveform simulator's RAM table: this happens when a button is pressed, and a button press can wait for a reply the way any other click can. What makes the table different is that it is drawn from `view`, which cannot wait for anything. A diff needs the whole memory on both sides, so the request asks for a listing and nothing else. A window coming back means the memory is written in too many places to read whole - `RamStore.Constants.maxSlotsForWholeRead` - which is the same answer the local button gives by disabling itself, said after the fact because only the far side knows.

Where the step panel is after a chunk that was aiming for `target`, given what the chunk answered: the clock it reached, and whether it got there. **Not the clock the simulator reports.** Those are different numbers - section G2 of docs/dev/sidecarInvariants.md says so in as many words: the simulator's clock is how far it has RUN, the panel's is where the user is LOOKING, and stepping back to a cycle still inside the circular buffer needs no running at all. `runFastSimulationCore` answers such a step `RunCompleted` with its clock untouched and AHEAD of the target, which taken for the panel's position sent a goto backwards forwards instead - to wherever the simulation happened to have run to, with the progress bar past its own maximum. So a chunk that finished puts the panel at the cycle that was asked for, and one that ran out of budget puts it at the clock reached, which is honest progress towards it. The local simulator has always been read this way (`RunCompleted -> cycle`); this is the same rule said once, for both.

One clock of the panel's signals, named the way the sidecar names them. Every one is an output port 0: an input's own value, an output's value, a viewer's, or a register's state.

The top-level memories the stateful panel offers a View button for. They are not part of `statefulValues` in sidecar mode - a memory's contents live in its store rather than on a wire, so they are not a signal to be read with the rest - and are listed here instead, to be read only when the button is pressed.

How many clock cycles of history the RENDERER's own step simulation holds. The same as the simulation's, when the renderer is running it. When the .NET simulator is, this copy is built for its structure and never run - the panel's values, its memories and its clock all come from the sidecar - so it holds the least a built simulation can. What the SIDECAR holds is `stepSimArraySize` either way: that is the history the step simulator can be stepped back through, and it is a fact about the design rather than about which process is running it.

Set a top-level input at the shown cycle, on whichever simulator is running, and make the panel's values for that cycle current again. Locally that is one call: changeInput sets the value and re-runs the combinational logic at that step. Over the wire it is SimSetInputs and then a re-read, because the values the panel is showing were computed from the input this just changed. **Values up to 2^53.** SimSetInputs carries a value as two 32-bit words, so a wider input cannot be set from here yet; it is refused by name rather than sent truncated, which would show the user a value the simulation is not running on.

The panel's stateful rows, from whichever simulator is running. In sidecar mode this is the registers and counters only - their state is Outputs[0], so it is a signal like any other - and a memory is left out because its contents cannot be read over the wire yet. `ramsAreLocalOnly` below is what tells the user that, rather than a table of whatever the unrun local simulation happens to hold.

How many clock cycles of history the step simulator can afford on this design, or why it cannot be simulated at all. The waveform simulator has a configuration dialog that prices the design and refuses a last clock that will not fit (`FastCreate.maxLastClockFor`, `UIPopups`); the step simulator has no dialog and used to take `Constants.maxArraySize` whatever the design cost - so a design too big for it was refused by the build's own memory check, in words about a waveform configuration the user was not looking at. The budget binds here instead, on the one number this simulator has. It asks for the full array - enough past to step back through - and takes what fits if that is too much, down to `minStepArraySize`. Below that the design is refused, with a message about the design. Priced from the design's merged graph, so this allocates nothing: the check happens before the arrays it is deciding the size of exist, which is the whole point of it.

Write one sheet, and everything below it, as a Verilog file beside the project. The sheet is a parameter rather than always the open one, so any sheet can be written from its pill in the sheet menu. Verilog output was already rooted at a single sheet and flattened over its subtree - buildFastSimulation inlines custom components, and getVerilog emits one module called main - so this only makes explicit which sheet is the root. TODO: the simulation error display here is shared with step simulation and also waveform simulation - maybe it should be a subfunction.

The panel's viewer values, from whichever simulator is running. The LIST is the design's, so both simulators show the same viewers under the same names in the same order; only where the value comes from differs, which is the one thing that should.