RamView (issie)

RamView Module

Namespace: global
Assembly: Renderer.dll

The rows a RAM table shows at one clock, worked out from a simulation that holds the memory. Below the UI because two simulators produce it: the renderer's own, and the .NET sidecar, which has a `FastSimulation` of its own and answers `SimReadRam` from exactly this code. That is the point of the module - the alternative is the sidecar reimplementing which row counts as read and which as written, and two answers that agree until they do not. `SimInterface` named the obstacle: reading a RAM "needs a row type that is declared in the waveform UI and has to move first". This is that move. `WaveSimStyle` keeps the styling. What is NOT here is display: the radix, the padding, the comment column, and the collapsing of a run of zero locations into one "0x0100 ... 0x01FF" row. Those are the table's own business and stay in `WaveSimRams`, which is why this returns locations and values rather than strings.

Types

Type	Description
RamKey	What a held set of rows answers: the clock, how many locations were worth listing rather than windowing, and where the window starts. Everything that changes the rows. The request that goes out and the table that reads the result are built from the same key, so a table cannot ask for one thing, be sent it, and then look for another.
RamRow
RamRowType	Whether the design read or overwrote this location at the clock being shown. A write lands one clock after the address and write-enable that caused it; a read is the same clock for an asynchronous memory and one after for a synchronous one.
RamView	Which of the two displays a table is showing, and its rows.

Functions and values

Function or value Description

Function or value	Description
`ofFastSim fs (arg2, arg3) cycle sparseUpTo start rows` Full Usage: `ofFastSim fs (arg2, arg3) cycle sparseUpTo start rows` Parameters: fs : `FastSimulation` arg1 : `ComponentId` arg2 : `ComponentId list` cycle : `int` sparseUpTo : `int` start : `bigint` rows : `int` Returns: `Result<RamView, string>`	The rows a RAM table shows at one clock. `sparseUpTo` is the most non-zero locations worth listing: below it every one of them is returned, above it a window of `rows` locations from `start` instead. A caller that wants a window whatever the memory holds asks for `sparseUpTo = 0`. Which of the two comes back is the implementation's to decide, not the caller's, because only it knows how much the memory holds - and knowing that is the walk being decided about. `RamStore.sparseUpTo` is bounded whatever the answer; see docs/dev/ramOverTheWire.md. fs : `FastSimulation` arg1 : `ComponentId` arg2 : `ComponentId list` cycle : `int` sparseUpTo : `int` start : `bigint` rows : `int` Returns: `Result<RamView, string>`


                
                  
                    
                      ofFastSim fs (arg2, arg3) cycle sparseUpTo start rows

Full Usage: ofFastSim fs (arg2, arg3) cycle sparseUpTo start rows

Parameters:

fs : FastSimulation

arg1 : ComponentId

arg2 : ComponentId list

cycle : int

sparseUpTo : int

start : bigint

rows : int

Returns: Result<RamView, string>

The rows a RAM table shows at one clock. `sparseUpTo` is the most non-zero locations worth listing: below it every one of them is returned, above it a window of `rows` locations from `start` instead. A caller that wants a window whatever the memory holds asks for `sparseUpTo = 0`. Which of the two comes back is the implementation's to decide, not the caller's, because only it knows how much the memory holds - and knowing that is the walk being decided about. `RamStore.sparseUpTo` is bounded whatever the answer; see docs/dev/ramOverTheWire.md.

fs : FastSimulation
arg1 : ComponentId
arg2 : ComponentId list
cycle : int
sparseUpTo : int
start : bigint
rows : int

Returns: Result<RamView, string>