Welcome to my site. My name is Luis Angel D. Bathen, but please call me Dr. Danny, j/k :) Danny is good enough. I am a Research Staff Member at IBM.

I think of myself as a philosopher, master inventor... j/k... humor is a big part of my life, as it helps me get through the tough times and enjoy the good times even more. I hold two patents granted by the USPTO related to caching technologies for storage controllers and real-time compression for the cloud, and have filed/published several other inventions in the fields of storage management software and multi-many core memory management. 

I have a best paper nomination for my work on scratch-pad memory virtualization at the International Conference on Hardware/Software Codesign and System Synthesis (CODES+ISSS), awarded on October, 2011 and a best interactive presentation award for my work on memory variability at the Design, Automation, and Test in Europe (DATE) conference, awarded on March, 2013. 

I completed and filed my dissertation on May, 2012. I hold a Ph.D. in Information and Computer Science with specialization in Embedded Systems from UC-Irvine under the supervision of Professor Nikil D. DuttThe title of my thesis is: PHiLOSoftware: A Low Power, High Performance, Reliable, and Secure Virtualization Layer for On-Chip Software-Controlled Memories. My framework can be downloaded from: PHiLOSoftware @ SourceForge

I hope to start adding more documentation support as time goes by. Our group is also planning a release on a variation-aware linux kernel at ViPZonE @ SourceForge

Find me on Google ScholarMicrosoft AcademicACM, and DBLP.

In short, the idea is to add 'colors' to the virtual address space, where each 'color' represents a characteristic (e.g., low-power, secure, fault-tolerant, etc.). These colors are represented in the form of policies, which are user/compiler defined and enforced by the run-time system. 

PHiLOSoftware Concept:

In order to support the integration and deployment of SPMs in many-core platforms, designers must carefully consider four mutually dependent constraints: Performance, Low Power, Security, and Reliability (Figure 1).

Figure 1: Considerations for Future Generation Memory Hierarchies.

  • Performance: In order to support multi-tasking, virtualization of various soft- ware stacks, and shared distributed memories, SPM space management needs support from the runtime (OS/Hypervisor), as traditional SPM-management techniques have predominantly focused on a single application or a fixed num- ber of pre-defined applications in the case of multi-core as target platforms.

  • Power/Energy: Aside from efficiently managing on-chip memory resources, de- signers must take into account techniques used to reduce both dynamic and static power. As sub-micron technology continues to scale, leakage power will overshadow dynamic power consumption. Since SRAM-based memories (SPMs) consume a large portion of the die, they are a major source of leak- age in the system and a major issue for multi-core platforms as shown by ITRS projections. To reduce leakage and dynamic power, designers have proposed voltage scaling the memory subsystem, and by doing so, expo- nentially exacerbating the vulnerability of their on-chip memories to soft-errors and process variation induced errors. Furthermore, hardware variability (e.g., chip-to-chip power consumption variation) due to technology scaling is quickly becoming a major concern for the design community. ITRS predicts that over the next decade performance variability will increase from 48% to 66%, while total power consumption variability will increase by up to 100%. Another approach to reduce leakage power is the introduction of emerging Non- Volatile Memories (NVMs) into the on-chip memory hierarchy; however, the management of NVM and SRAM-based software-controlled memories requires major changes to the traditional programming model as SRAM-based memories and NVMs have very different physical characteristics.

  • Reliability: A byproduct of technology scaling and the adoption of techniques such as voltage scaling to reduce dynamic and leakage power is the increased vulnerability to errors (transient and permanent) of the memory subsystem. This is a much bigger issue for future generation many-core platforms, whose memory hierarchy area is expected to dominate (ITRS predicts that the memory subsystem will occupy up to 90% of the total area of the system).

  • Security: With the adoption of open-environments where users can download- /install/run new applications, sharing of the same physical memory space may lead to unintended or malicious tampering of the memory contents.

    To address the challenge of managing the memory space of future generation many- core platforms, we need a lightweight runtime system that allows for efficient man- agement of the software-controlled on-chip memory resources in the presence of pro- cess variations, multi-tasking, memory technology (e.g., SRAM, DRAM, MRAM, PRAM, etc. Fortunately, informed programmers (through an- notations) and compilers (through static analysis) can provide us with the necessary information about a given application to decide how to best manage its data, thereby reducing the complexity of the dynamic-allocation of memory space at run-time.

Figure 2. PHiLOSoftware’s Heterogeneous Address Space.

In this work, we propose PHiLOSoftware, a low power, high performance, reliable, and secure virtualization layer for on-chip software-controlled memories. PHiLOSoft- ware consists of a compilation flow that exploits software annotations and static analysis of the application to generate virtual memory allocation policies with differ- ent guarantees (e.g., security, fault-tolerance, etc.). PHiLOSoftware achieves this by defining secure, reliable, low power, and high-performance virtualized memory address spaces (as shown in Figure 2) and mapping the application’s data and instruc- tions to one of these spaces (referred to as allocation policies). The PHiLOSoftware Run-Time System (RTS) will take the application’s allocation policies and enforce them at run-time by dynamically allocating the physical memory resources accord- ingly (e.g., highly utilized read-only data to on-chip Non-Volatile Memory). For the sake of illustration, Figure 2 shows various address spaces defined by the pro- grammer, each address space will have different requirements (e.g., 1-9), ranging from (1) low-voltage and mid-latency on-chip address space (e.g., aggressively volt- age scaled SRAM), (2) low-power fault-tolerant on-chip address space (SRAM), (3) nominal-voltage high-performance on-chip memory space (SRAM), (7) non-volatile remotely allocated non-volatile on-chip space (NVM), to (8) low-power off-chip mem- ory space (DRAM). Each address space is created on-demand, and their allocation policies are generated by the programmer and/or compiler, while the run-time sys- tem (PHiLOSoftware RTS) enforces each policy best effort. PHiLOSoftware captures three key ideas: 1) Application intent (requirements), 2) memory management for scalability, and 3) adaptability to changes in the memory subsystem.