Issie logo Issie

FastBuild Module

Functions and values

Function or value Description

buildFastSimulation simulationArraySize diagramName graph

Full Usage: buildFastSimulation simulationArraySize diagramName graph

Parameters:
Returns: Result<FastSimulation, SimulationError>

A build with everything, which is what a simulation interrogated in this process needs.

simulationArraySize : int
diagramName : string
graph : SimulationGraph
Returns: Result<FastSimulation, SimulationError>

buildFastSimulationFData simulationArraySize diagramName graph

Full Usage: buildFastSimulationFData simulationArraySize diagramName graph

Parameters:
Returns: Result<FastSimulation, SimulationError>
simulationArraySize : int
diagramName : string
graph : SimulationGraph
Returns: Result<FastSimulation, SimulationError>

buildFastSimulationWith waveTables simulationArraySize diagramName graph

Full Usage: buildFastSimulationWith waveTables simulationArraySize diagramName graph

Parameters:
Returns: Result<FastSimulation, SimulationError>

Create a fast simulation data structure, with all necessary arrays, and components ordered for evaluation. This function also creates the reducer functions for each component similar to the reducer builder in Builder, but with inputs and outputs using the FastSimulation mutable arrays `waveTables` says whether to build the structures only a wave VIEWER reads - see WaveTables. Everything else about the build is the same either way, deliberately: the two simulators must run identical code over identical structures, or they agree until they do not.

waveTables : WaveTables
simulationArraySize : int
diagramName : string
graph : SimulationGraph
Returns: Result<FastSimulation, SimulationError>

createFastArrays comps fs

Full Usage: createFastArrays comps fs

Parameters:
Returns: FastSimulation

The three arrays the run loop and the ordering pass iterate, taken from `comps` - every component of the build, in the order the gather created them. Not just to avoid building three throwaway Maps to filter with, though it does that. The components are ALLOCATED in gather order, so walking them in that order walks memory forwards; walking them through a map keyed by (ComponentId, access path) - which is what a built simulation offered when this was written - visits the same objects in an order unrelated to where they sit. On a 15,000-component design that difference was worth more than everything else in this phase put together - and it applies to every pass that walks all the components, which is why determineBigIntState and addWavesToFastSimulation take the array too.

comps : FastComponent array
fs : FastSimulation
Returns: FastSimulation

installReducers fs

Full Usage: installReducers fs

Parameters:
Returns: FastSimulation

Bind each simulated component's reducer to the component itself, once, when the simulation is built. The loop then calls a component's own code rather than dispatching on FType for every component of every step. EvalCompiled.reducerFor returns None for a type it does not handle yet, and that component keeps the general fastReduce. This must run last. The reducers capture the step arrays their ports currently point at, and linkFastComponents, reLinkIOLabels and addWavesToFastSimulation all re-point ports; a reducer installed before them could hold an array the simulation no longer uses. It is also why only the components that are actually reduced get one - the custom-component FastComponents that addWavesToFastSimulation re-points exist for waveform display and are never reduced.

fs : FastSimulation
Returns: FastSimulation

Type something to start searching.