Skip to content


Michael Adler edited this page Mar 3, 2015 · 1 revision


LEAP scratchpads are hierarchical storage structures, providing memories that have the same interface as block RAMs but permitting the allocation of arrays larger than would fit on an FPGA. A typical scratchpad builds a private L1 cache, shares an L2 cache in a large memory (e.g. on-board SDRAM) and is backed by host-side virtual memory. Like block RAM, scratchpad modules implement a MEMORY_IFC interface. In user code, mkScratchpad may replace any mkBRAM. Aside from memory size, the only visible difference will be the latencies of operations.

The base mkScratchpad() module takes two arguments: a user-provided UID to identify the scratchpad and a boolean indicating whether to allocate a cache hierarchy. Cached scratchpads allocate a private L1 cache. L1 caches are connected to a last-level cache that is shared, dynamically, among all scratchpads. Scratchpads are initialized with zeros.

mkMultiReadScratchpad() builds a scratchpad with multiple read ports. The read ports share the same L1 cache read port. Output read response buffering is provided, allowing reads on one port to bypass unconsumed reads on another port.

Scratchpad Architecture

Scratchpad Configuration

Initializing Scratchpads

Scratchpads may be initialized from file. This is achieved by mmap-ing the file to the backing scratchpad address space at LEAP initialization time.

@let matrixAFileName <- getGlobalStringUID(“matrixA.dat”);
SCRATCHPAD_CONFIG sconf = defaultValue;
sconf.initFilePath = tagged Valid matrixAFileName;

Because mmap is used as an underlying implementation, some care must be taken in laying out the underlying data file , since mmap will map data directly. However, basic CPU-friendly like arrays will work.

You can’t perform that action at this time.