Memory Modules

The memory modules have been a key design point of HTSS. Although they are not crit- ical from the reliance point of view, a wrong approach would result in low performance (due to increased access times) and probably would lead to a lot of wasted resources in form of redundant data. As it is explained in Section 4.1, HTSS has three types of memory modules (i.e., TM, DM and VM) for storing meta-data of tasks, dependences of tasks and their subsequent versions. In Table 4.1, in Chapter 4, the characteristics of the memories of the base HTSS design were presented. Note that the capacities of the memory units presented in that table were selected only for VHDL coding of the modules of HTSS prototypes (i.e., HTSS.1, HTSS.2 and HTSS.3). Therefore, they were selected according to the preliminary elds of the memory entries.

After the design space exploration, the proper capacities of the memories have been determined. With the new selected memory entry sizes and the data obtained from the design space exploration, all the memories in the HPCConf system would have a total amount of: 60 Kbytes for the TM, 22 KBytes for the DM and 12 KBytes for the VM, distributed in 12 small memories (i.e., four TMs, four VMs and four DMs) able to manage up to 1024 in-ight tasks. This size could be further reduced by optimizing the TM that is the largest memory in the HPCConf system.

Table 6.2 shows the capacity of memories of the HPCConf conguration found in the previous chapter and the information stored in each entry with its size in bits, for every memory of the nal design of HTSS. Note that each memory module entry in this table is aligned to eight-bit word size (i.e., memory data bus is a multiplicand of eight), and there is a power of two number of memory entries. The number of entries for

1_{In this chapter, the base HTSS design means the preliminary design of hardware Task Superscalar}

before design space exploration with preliminary memory capacities, while the nal version of HTSS means an HTSS design with real memory capacities that resulted from design space exploration.

the HPCConf were determined in the design space exploration for each of the memory modules: 512 DM entries, 512 VM entries and 256 TM entries.

Table 6.2: Details of the memory modules of the nal HTSS design with HPCConf

DM (22 KBytes: 88×211₎ VM (12 KBytes: 48×211₎ TM (60 KBytes: 60×213₎

Capacity per module: 5.5 Kbytes # entries: 512

Entry size: 88 bits # modules: 4

Total HPCConf: 22 KBytes

Capacity per module: 3 Kbytes # entries: 512

Entry size: 48 bits # modules: 4

Total HPCConf: 12 KBytes

Capacity per module: 15 Kbytes # entries: 256 (1 entry  6 slots) Entry size: 80 × 6 = 480 bits # modules: 4

Total HPCConf: 60 KBytes

Field of a DM entry Size

(bits) Field of a VM entry Size (bits) Field of a TM entry: Slot 1 (for task) Size (bits) Field of a TM entry: Slots 2-6 (for 15 dependences, 3 dependences in each slot)

Size (bits)

valid bit 1 version ready 1 valid bit 1 version_id 9

dependency address 64 DM dependency entry 6 gtask_id 64 eORT_id 2

last version address 9 consumers exist 1 # dependences 4 chain dependency 1

dependency instances 10 last consumer TRS

address 14

# not ready

dependences 4 TM chain address 8

padding 4 next producer

existence 1 in_execution 1 TRS chain 2

next producer TRS

address 14 padding 4 chain dependency 4

version instances 10

valid bit 1

As Table 6.2 shows, every entry in the TM uses six slots: one to manage task information (slot 1 in Table 6.2) and the other ve to store information of a maximum of 15 dependencies. As the size of the information of the dependence is only 25 bits, three dependences can t in one TM slot, and only ve slots are needed. Those slots are statically assigned. However, as most tasks have only a small number of dependencies, this memory can be easily optimized by making a dynamic assignment of slots 2 to 6. This technique can lead to reduce the memory size to only 20 KBytes with nearly the same results, as it would be able to store up to 1024 in-ight tasks with up to three dependencies each, or 341 tasks with 15 dependencies each. With this optimization, the total amount of memory in all the modules in the system would be only 54 KBytes.

The memory conguration of the HPCConf of the nal HTSS version, resulting of the design space exploration, reduces around 6× (83.2%) the amount of memory necessary of the base designs. That can be observed comparing Table 6.2 and Table 6.3.

The memory modules of the base and nal version of HTSS have been implemented in both distributed and BRAM styles in order to have a perspective of the HTSS designs in both styles. In addition, using this information, the nal version of HTSS can be compared to the base HTSS design to highlight the signicant improvements applied to the base design.

Tables 6.3 and 6.4 depict the synthesis results of the memory modules of the base HTSS and the nal HTSS design for the HPCConf conguration, respectively. As the tables show, the number of LUTs depends on the capacity of the memories, but the number (and size) of registers depends on both capacity and structure of the memory modules. For instance, the number of registers and control sets of DM is much more larger than other memories since the way associatively has to be implemented. In BRAM style, the whole structure of TM and DM is embedded in the blocks of RAMs. DM includes eight separate RAMs to be implemented as an eight-way set-associative memory (see Figure 4.3) which are embedded in the blocks of RAM. The rest parts of DM are mapped onto the LUTs of target FPGA. Synthesis reports of the memory modules also show that all the memory modules are implemented with only RAMs and registers but DM, that also needs several comparators and multiplexers. The reason is the complex structure of DM, as an eight-way set associative memory.

As it was mentioned previously, the design of the memory modules has been done in a way that accessing to the memory units takes two pipelined cycles: one cycle for setting the control signals (enabling access mode) and the other for accomplishing the operation (e.g., writing or reading). The only exception here is in the DM. Reading from a way of DM takes three cycles. The memory modules have synchronous read and write enables. In all cases, the cycle of setting the control signals has been overlapped with the other operations of the FSMs.

Table 6.3: Synthesis results of the memory modules of the base HTSS design Task Memory (TM) Version Memory (VM) Dependency Memory (DM) Capacity

Capacity per module 200 KBytes 160 KBytes 200 KBytes

# modules 2 1 1

Total HTSS.3 400 KBytes 160 KBytes 200 KBytes

Distributed Style Slice Logic Utilization # Slice Registers 200 160 12321 # Slice LUTs 27633 22112 25264 # LUTs as Logic 2033 1632 6576 # LUTs as Memory 25600 20480 18688 Slice Logic Distribution

# LUT / FlipFlop (L/FF) pairs 27633 22112 33960 #L/FFwith unused Flip Flop 27433 21952 21639 #L/FFwith unused LUT 0 0 8696 # fully used LUT-FF pairs 200 160 3625

# unique control sets 2 1 722

BRAM Style # Block RAM 50 40 36

Table 6.4: Synthesis results of the memory modules of the nal HTSS design (i.e., HPC- Conf) Task Memory (TM) Version Memory (VM) Dependency Memory (DM)

Capacity 60KByte 12KByte 22KByte

Distributed Style Slice Logic Utilization # Slice Registers 80 48 1370 # Slice LUTs 11072 1640 2808 # LUTs as Logic 832 104 732 # LUTs as Memory 10240 1536 2077 Slice Logic Distribution

# LUT / FlipFlop (L/FF) pairs 11072 1640 3773 #L/FFwith unused Flip Flop 10992 1592 2404 #L/FFwith unused LUT 0 0 966 # fully used LUT-FF pairs 80 48 403

# unique control sets 1 1 80