A pattern based methodology for the design and implementation of multiplexed Master-Slave devices at the system-level use-case: Modeling a Level-2 Cache IP module at transaction level

In a customer driven environment, systems pose a great challenge to designers in terms of complexity and time-to-market. Thus, designers have to look at Commercial-Off-The-Shelf (COTS) based development techniques that rely on integrating components produced by various manufacturers. However, the vast range of components from various manufacturers leads to obscurity of interfaces between them, making system integration a dreadful task. Hence, large warehouses of IP modules comprising of various software simulation models of system components at different levels of abstraction that can be readily integrated to form a Virtual Prototype are highly beneficial towards the exploration of various architectures. In order to design and implement IP modules efficiently, we identify the Design patterns that they follow. We propose a Design pattern based methodology for modeling and implementing multiplexed Master-Slave devices. As an effort to showcase the methodology, we choose to model a Level-2 Cache (L2Cache) using SystemC. A technical specification document of the Motorola MPC2605 L2Cache is procured and modeled using hierarchical state machines that we implement using SystemC. The developed model is an integrated lookaside L2Cache supporting 4-way set-associative cache mapping and LRU replacement algorithm, compatible with the Simple Bus. The L2Cache module is then further parameterized to accommodate changes in L2Cache size, cache mapping strategies and replacement algorithms. In this paper, we present the proposed methodology through a description of the process of modeling and verifying an L2Cache IP module at system-level, using the “Master-Bus-Slave/Master-Bus-Slave” Design pattern. The test-bench involves a master (to generate transactions), a Simple Bus, the L2Cache Module and Slave Module (Simple memory). Various relevant test cases were generated to test the functionality of the developed module. The test-case outputs were routed to a debug file - - which is inspected to determine whether the output is as expected. We conclude by enunciating our learning from our experience with this methodology.