Issie
SidecarSession Module
The one simulation session the sidecar holds, and the renderer's picture of it. The sidecar simulates one design at a time - `SimSession` keeps a single session and every build replaces it - so there is one place here that knows what it is holding, rather than one per feature. The waveform simulator and the step simulator both draw on this, and because they share it neither can build over the other's session without the other finding out: a command naming a session the sidecar no longer holds is refused by name. This module is deliberately below the UI. It was extracted from `WaveProvider` when the step simulator needed the same two operations, and `SimulationView` compiles long before that. **None of this is model state.** It is what a separate process is believed to hold, which the model cannot know and has no better place for (docs/mutableState.md). WHICH simulator is running IS a model fact - `Model.SimulateInRenderer` - and is passed to the callers rather than mirrored here, because a second copy of a model fact is a thing that can disagree with it.
Nested modules
| Modules | Description |
Functions and values
| Function or value | Description |
Full Usage:
build design arraySize
Parameters:
SimpleDesign
arraySize : int
Returns: Promise<Result<int, SidecarFailure>>
|
Build the design on the sidecar, and answer with the session epoch that build issued. **Unconditional.** Whether a build is needed at all is a question about what the sidecar is believed to hold, which is `Model.SidecarBuild`, and it is answered before this is called - by the update function, synchronously, from the model. This module used to hold that belief and decide for itself, which put a fact the UI has to draw somewhere the UI could not read. **One caller at a time, by construction rather than by guarding.** Issie runs one simulation: starting the waveform simulator ends the step simulator and starting the step simulator ends the waveform one (Update.endWaveSimulation), and a build is now a message, so the model is in `SidecarBuilding` from the moment one starts until it answers - which is what stops a second being started while the first is in flight. It matters that this stays true: a design is uploaded one sheet per message and index 0 begins an upload, discarding any abandoned one, so two builds interleaving leave the sidecar holding half of each. That is reported rather than silent - the build fails with "no sheet called X in the design" - but it is a simulation the user asked for and did not get.
|
|
The failure a sidecar reply carries, or None when it is not one. Every reply that can fail answers with a JSON object whose "error" is the message written for the user (a refused build says exactly what to set the cycle count to) and whose "kind" says whether the sidecar broke or declined - so the envelope never reaches a screen, and the kind decides the severity. The decoding itself is `SidecarClient.failureOfPayload`, which every other reader of an error reply also goes through: one decoder, so a change to the envelope cannot leave half the readers behind.
|
Full Usage:
parseJson text
Parameters:
string
Returns: obj
|
|
Full Usage:
runChunk epoch cycle
Parameters:
int
cycle : int
Returns: Promise<Result<(int * bool), SidecarFailure>>
|
Run the session towards `cycle` for one chunk, and answer with the clock it reached and whether it got there. **One chunk, not a loop.** A run is a SEQUENCE of these and the sequence belongs in the update function, which is where the sequencing of everything else on this protocol lives. **No operation is ever cancelled in the middle.** Every one runs to completion and answers - this one answers with the clock it reached and whether that was the cycle asked for. Cancelling a run is deciding not to ask for the next chunk, which needs nothing of the protocol, nothing of the sidecar, and nothing of the promise already running. Reaching into an operation in flight would be a mechanism this protocol has nowhere else, and the whole reason a run is chunked at all is so that it does not need one. It is also what lets the clock be model state - `SidecarSession`, updated by each answer - so that a progress bar is drawn from it like anything else. The loop that used to be here reported progress through a callback and checked no cancellation. Every caller passed `ignore`, so ten round trips a second bought neither of the two things chunking is for.
|