A Layered Architecture For Noc Design Methodology
A LAYERED ARCHITECTURE FOR NOC DESIGN METHODOLOGYA. Agarwal,R. Shankar,aagarwa2@fau.edu, ravi@cse.fau.edu,Dept of Computer Science and Engineering, Florida Atlantic University,Boca Raton, FL-33431Such computation power has posed some challengeswhich include the disparity in transistor and wire speedand increased power dissipation, leading to a decrease inthe area of the chip which can be utilized with a singleclock cycle [3][4]. Another dominant factor is the abilityto design the system in an acceptable timeline known astime-to-market. Also, system level designers have toconstantly look for ways to support a set of Quality ofService (QoS) parameters and performance metrics thathave become more demanding, as expectations havesoared.ABSTRACTMultiprocessor system on chip (MPSoC) platform is aninnovative trend of System on Chip (SoC) that enhancessystem performance. Demanding quality of serviceparameters and performance metrics, especially in mobileapplications, are leading to the exploration of even moreinnovative architectures for SoC. These will have toincorporate highly scalable, reusable, predictable, costand energy efficient architectures. Network on Chip(NOC) is a key example of this trend. NOC separatescomputing and communication concerns in an elegantmanner. We propose here a seven layered architecture fordesigning NOC-based systems.Such a platform canseparate domain specific issues in separate layers, whichwill allow for more effective modeling of concurrencyand synchronization issues, in an attempt to develop anoptimized system. For such a layered architecture, modelsof computation (MOC) will provide a framework tomodel various algorithms and activities, while accountingfor and exploiting concurrency and synchronizationaspects. These MOCs may differ from one to anotherNOC region. Further, a combination of these MOCs maybe needed to truly represent a given NOC region. Wehave analyzed various models of computation (MOC)suitable for NOC. MLDesigner provides a system levelmodeling platform which allows one to integrate suchMOCs together. We present our efforts and experiencesso far.Technology scaling has also had unwanted side effectswhich include cross coupling, noise, and transient errors[5]. This has resulted in reuse of design blocks,sometimes referred as components, which have beencarefully designed by expert designers. However it cannever be guaranteed that those sub-micron effects will notpop-up again when such reusable components areintegrated into larger designs, such as a sub-system or asystem. Thus it can be concluded that components or thesub-systems which perform as expected when isolated,might not perform in the same way after systemintegration [6]. This has led to a new domain of researchwork for system level integration and verification viz, theNOC architecture [2, 6, 7].ITRS (International Technology Roadmap forSemiconductors) [8] provides a plot that depicts thechange in engineering design cost over the time span of1990 to 2005. One might expect this to have increasedsubstantially, since the chips and systems got morecomplex during that period. However, the exact oppositewas the case.KEY WORDSNetwork on Chip, Modeling and Simulation, Quality ofService, System Level Design1. IntroductionMany EDA (engineering design automation) innovationskept the engineering design cost fairly flat, that is, theengineering design productivity actually increased about70 fold. This brought down the cost of productdevelopment which led to an affordable price for thecustomers, while providing more functionality. However,this trend may be at an end [8] unless innovativearchitectures and methodologies for system design are notdeveloped. ITRS predicted in 2001 that the engineeringdesign cost would increase to an unaffordable amount ofone billion dollars by 2010 [8]. Much innovation hascome since then. It is expected that the future systems willThe System Level Design era where creativity, innovativeideas, ingenuity and inspiration are expected to come tothe fore, has arrived. System complexity, driven by bothincreasing transistor count and customer appetite for moresavvy applications, has increased so dramatically thatsystem design and integration can no longer be an afterthought. Moore’s law predicts that a chip in 2010 willcount more than four billion transistors operating in multiGHz range [1] [2]. This is mainly due to the exponentialdecrease in the transistor size enabling faster transistorswitching times and more densely integrated circuits.466-132659
with resources with different types of interfaces and datarequirements. Substantial research has been conducted topropose the right data formats needed for various layers inthe protocol stack. A reusable switch is used foreffectively routing the packet through the entire NOC;they buffer packets at both input and output [20].have increasing roles of design automation, reusabilityand componentization, thus increasing the role of theEDA Industry. For such scenario, a system-levelmodeling environment should be developed thatessentially supports the middle-out design philosophy toexploit reuse to the maximum in order to reduce thedesign effort [9] [10]. The high volume of reuse shouldcut down the overall system design cycle [11] [12]. In thispaper we present one such unified framework for thearchitectural design and simulation for the NOCenvironment.Once the design of the basic NOC architecture becameestablished, new techniques evolved to address advancedissues such as dynamic load balancing on to a node of theNOC architecture, the shortest/fastest path for the dataflow through NOC, and energy efficient NOC architecturedesign. Most researchers have focused on thecommunication architecture of NOC; few have focusedon exploiting the computing capability of NOC.Computer architects have come up with many innovativeideas over the past decade to enhance systemperformance; however not all of them are viable in NOC.One innovation that is useful for NOC is to divide thesystem into smaller, locally decoupled synchronousregions and then composing a few of them to yield alocalized subsystem. These synchronous regions andsubsystems would be easier to integrate into a globalsolution and verify. At the same time there will be anasynchronous way in which all the local synchronousregions will communicate at the system level. Thus thesedifferent synchronous regions need not have to besynchronized to a single global clock. This approachwould reduce the requirement for chip-wide clock trees;the designers could focus on local synchronous regionsonly which would be far less complex than the completesystem. Also, since one has the flexibility to reduce theclock speed of a given synchronous region (or node)independent of other such regions, the amount of powerconsumption in a system can be managed better andreduced.2. Background workIntegration of a system comprising of hundreds andthousands of cores with adequate memory andcommunication backbone on a single silicon die isfeasible but highly complex [13]. Designing such systemson a chip (SOC) is a challenging process, and is currentlyapproached with few principles of organization [14].Researchers have contributed in various dimensions tothis activity to make such an effort plausible. One suchdesign discipline is platform based design [15] [16].Essential elements of platform-based design are thefunctional behavior of each core and separateconsideration of the interaction among the cores. Thisseparation of concerns is essential to the success of areuse strategy [15]. The future SOCs, in order to beeconomical, will have to aim at designing highly scalableand configurable systems so that it can be adapted todifferent workload needs, applications and products,while maintaining the generality of the applicationdevelopment methods and practices.As emphasized in the International Technology Roadmapfor Semiconductor (ITRS) 2001 document [8], it is veryimportant, especially at system level, to separate thecomputation from communication aspects to enhancedesign productivity [15]. From the communicationperspective, several researchers have suggested a 2-Dmesh architecture for NOC [13] [17] that connects(computational) resources at various nodes via networkelements. The network elements are switches, channelsand resource-network interfaces (RNI). A (computational)resource in an NOC can be any general purpose processorcore, memory, specified controller, FPGA, ASIC etc. Thisinfrastructure will be ideal where QoS and performanceparameters will be traded off based on the userrequirements. New algorithms have been proposed in thisdomain to reduce power consumption while securing costoptimization [18]. It has been a well established fact thatsuch NOC architectures will be based on packet switchednetworks. This has led to new and efficient principles fordesign of routers for the NOC architecture [19]. Theserouters will be responsible for routing the entire trafficacross and have to be interfaced with switches andresources in the NOC architecture. The RNI should behighly scalable and re-usable in order to be integrated3. A NovelArchitectureApproachfortheNOCThe key challenge for the system level design withintegration of thousands of cores is the modeling ofconcurrency and synchronization issues. This requiresrepresentation of various activities and algorithms withappropriate Models of Computation (MOC). This definesour two goals for the system level designers: (1) To modelthe system functionality well in advance of building theactual computing system in order to provide a level offlexibility in system design. (2) To be able to manipulatean abstract set of design elements simultaneously togenerate different sets of QoS parameters andperformance metrics and fine tune the system model. Fordesigning such a system we first define the concept [21]of a layered NOC architecture and then try to integratedifferent MOCs onto this layered architecture.660
dynamic load balancing can also be addressed as a part ofthis layer. This model will influence the protocol stackdesign.3.1 Layered architecture for NOC designLayered architecture is an effective way of dividing andconquering a problem. We have seen it working in aneffective way in the of open system interconnection (OSI)model. It provides a way to separate the concerns of eachdifferent domain thus providing an effective solution to adomain specific problem. It can also be argued that thisapproach will provide us with a scalable solution inaddressing inter-domain specific issues. We define belowthe seven-layer NOC architecture:3.1.6 Communication Backbone: This layer below thecommunication protocol layer will model the actualrouters, switches, and resource network interface, alongwith buffers, busses, queues, and FIFO. This is the layerwhere actual transfer of data among the differentresources takes place.3.1.7 VLSI: This will be model the final systemimplementation at the transistor level. The VLSI relatedissues will be abstracted to this layer.3.1.1. Application: This will be the top functional level ofthe NOC system where different applications arerepresented in an abstract manner. This layer will modelthe application software. Since a NOC system shouldsupport a wide range of the applications, there is need forapplication libraries. These software applications shouldbe portable in nature so that we can use them in differentapplication domains. This will enhance reuse by systemlevel designers. Thus these applications should be welldesigned to have proper interfaces with the system.3.2 Model of Computation (MOC)A MOC is a mathematical formalism that captures allowsus to reason about a computational system or conceptindependent of its implementation details. DifferentMOCs have evolved to represent the reasoning indifferent areas of focus. A synchronous local region of anNOC might require one ore more such MOCs to co-existand interact. Further, to reduce simulation time and tointegrate the subsystems into an integrated system model,other MOCs may be needed. Thus, several MOCs areneeded for modeling an integrated system. In such asystem each component or the subsystem of the systemshould be able to use any allowed MOC and moreimportantly should retain its behavior after integration ofthe system. Consider also the case in which a subsystemuses two or more local regions (or islands) of the NOC.These are connected by a switch in an NOC. For exampleconsider a digital camera as a component or a subsystemof a much larger system, such as a wireless handhelddevice (system). It is possible that its design would not fitinto one local region. Under such a scenario we shouldalso be able to address the concurrency andsynchronization issues because of shared resources (bothlocal and global).3.1.2 Algorithm: This will be the next lower level layerwhere the real-time control and multimedia algorithms, aswell as the optimization algorithms, will run. Thesealgorithms will be application and performance specific.3.1.3 RTOS (Real-Time Operating System): The nextlower layer will comprise of RTOS. This layer will beresponsible for effective scheduling of the NOC resourcesto run application and algorithmic software. RTOS willschedule applications based on a priority scheme whichin turn will be defined by specified QoS parameters andperformance metrics. The other main functionality of thislayer will be the management of concurrency andsynchronization issues.3.1.4 Architecture: Architectural exploration is done atthis layer. It will comprise of architectural building blockssuch as a processor, cache, bus, and memory, andparameters that capture their pertinent properties.Hardware and software are traded off depending uponperformance metrics such as utilization, latency, andtransactions. Different combinations of these buildingblocks are simulated to run certain target applications.Based on such simulation runs, a set of optimalarchitectures will be selected. However, do note that forcomplete and valid results, the lower layers will also haveto be simulated.We propose to integrate appropriate models ofcomputation to model our layered NOC architecture (See[21] for similar work for more general cases).Weaddress below the various MOCs needed to model NOC:3.2.1 NOC at System Level (Global Region): At thesystem (top) level, the NOC model, in order to be usefulfor what-if type analysis, should be at a high level ofabstraction. Lower level (RTL code, VLSI, and Sourcecode) issues, while appropriate for the design level, wouldslow down the trade-off analysis. Assume that a digitalcamera’s processing is implemented on an NOC; then thesystem level issues to be addressed would be resolution,image size, power dissipation and cost, which we wouldrefer to as parameters. We should be able to adjust one ofthese parameters to fine tune system performance andyield different combinations of cost-performance-QoSpower dissipation. One may wish to do this on a dynamic3.1.5 Communication Protocol: Packet switching hasbeen proven to be the right way to implement this layer.This will define the size of the packet, the queuingdiscipline, routing strategies, and the issues related to thetraffic density. For a real time application this layer willforward the traffic on to a dedicated channel so that thetimely response can be guaranteed in order to generate therequired level of service. The algorithms related to661
scalable to be mapped into the higher domains, viz., thesubsystems and the systems. This component level wouldcomprise of software components, and a computation partwhich in turn could be represented by electricalcomponents and computer architecture components. Forelectrical components to be specified in such domain, wecan use mathematical equations to represent properties ofthe model giving continuous time (CT) MOC as a feasiblesolution. Hierarchical FSM can contribute tosynchronization among the software elements and thehardware components at component level where eachstate can be programmable in itself. Such a state machineis often referred as a state chart, where each state hastrigger, action and guard conditions. At the same time wemay also utilize SDF MOC to model the architecturalissues.basis for better power management of the system in thefield. Thus we can argue that at system level we wouldneed some a kind of manager to dynamically optimize thesystem level design parameters.At the same time such a control (manager) should havesome level of concurrency in time domain. This is due tothe fact that control (manager) might have to optimizetwo or more different local regions at the same time. Thisrequirement rules out a finite state machine (FSM) modelto sit at the top as a manager. At the system level thismanager should be able to observe and control only thosesignals which are changing their state or behavior ratherthan monitoring all the signals at every clock event. Adiscrete event simulation at the system level would suitesuch a requirement.Another possible MOC to model global communicationand management in NOC, with asynchronousmechanisms, is the process network (PN). This MOC wasdescribed by Kahn and McQueen [20]. Two importantproperties of the PN domain which make suchcomputation plausible are that processes communicateasynchronously and that the memory used in tion of PN cannot support an infinite memoryrequirement; therefore we specify upper bound formemory requirements whenever possible. The PN domainhas the capability to model a system as a network ofprocesses that communicate with each other by -outchannels.We need a platform to support and integrate differentmodels of computation to exploit the computation andcapability of the future generation systems. Such aplatform should be able to model software and hardwarealong with communication and scheduler components, toaccount for resource sharing and consequent limitations.Such a platform would not distinguish between hardwareand software components but rather integrate both into thesystem in almost the same way.We discuss such system below.4. Mapping Various Models of Computationinto a Single System3.2.2 NOC at Subsystem Level (Local Region): The localregion for NOC is again divided into two differentdomains as NOC at subsystem level and NOC atcomponent level. At sub-system level we will have toaddress local issues (as relating to a particular subsystem)rather than the global issues. Such a sub-system willusually be some DSP sub-system, IP-core, fieldprogrammable gate arrays (FPGA), or application specificintegrated circuit (ASIC). This subsystem in conjunctionwith the packet switching network would be required toconsume some fixed amount of data (tokens) at the inputand to produce some fixed amount of data (tokens) atoutput that will be routed over the network. Synchronousdata flow (SDF) is one such MOC which has appropriateproperties. At subsystem level, there is also some need fora smaller control element. This control element would berequired to address the synchronization issue at thatsubsystem level only making FSM as another plausiblesolution to MOC at the subsystem level.Electronic Design Automation (EDA) tools are able toplay a vital role in optimizing the entire productdevelopment life cycle for the system level designs.Powerful EDA tools and interface software ensure moreefficient use of resources leading to high quality designs.EDA software product development teams constantlystrive to increase the intelligence and functionality of theEDA tools by incorporating more and more sophisticatedalgorithms in the tool to aid the system designer.We have analyzed one such design automation tool“MLDesigner” [22], which is a system level solution thatintegrates multiple level designs. This provides a platformon which we can implement our layered architecture forNOC. We will be able to integrate different MOCs at thesame time allowing us to separate the concerns and limitthem to a particular layer rather than addressing all theissues at the same time. This will allow us to build eachlayer separately and to integrate them subsequently toobtain a fully modeled system.3.2.3 NOC at Component Level (Local Region): This isanother essential part of the local region. Thesecomponents together would constitute the highersubsystem level. At this level designer will not have toworry about addressing the system wide concurrency andsynchronization issues and the design should be highlyreusable to be able to be utilized in other products andWe have included two examples to demonstrate theeffectiveness and the feasibility of the proposed designmethodology [23]. The first example demonstrates theidea of a layered approach for the design, while the662
second example will bring forth the concept of integrationof different MOCs in a single system [23].The simulation model abstracts computer cycles as costsand offers a flexible approach for studying the interactionof hardware and software. At the system level, the modelconsists of hardware and software blocks that are virtuallyconnected via the shared memory as shown in Figure 2.4.1 Modeling a Multi-processor Architecture usingMLDesigner: A Layered Approach for theArchitecture Design [23]The hardware module has the following blocks –Dispatcher, CPU, cache, bus, memory, etc. as shown inFigure 3. The dispatcher works as a scheduler: it receivesan instruction from the software model, assigns it to thefirst available idle CPU. If none of the CPUs is idle thenthe dispatch queues that instruction for future execution.The CPU block decides if the instruction requires accessof the cache to satisfy the request. If the requested data isnot available in the cache, it is obtained from the sharedmemory using the shared bus.The multi-processor computing system under studyconsists of four CPUs, a shared bus, shared memory, andvarious controllers. Each CPU has its own cache memory.MLDesigner is used to model the computer architectureas shown in Figure 1. This system design has beenpartitioned into layers of software and hardware. Thesoftware layer is the application layer which is separatefrom and above the hardware layer. A concept of theOperating system layer has been introduced via a modelof a Dispatcher block at the hardware layer. For thecommunication backbone the basic bus based model hasbeen used. This model represents another layer. (For theNOC architecture this layer will be described with twodifferent layers: the communication protocol and thecommunication backbone layers.) This design platformprovides an interactive environment for simulation-basedanalysis and design of a broad range of complexembedded systems including NOC.Figure 3: Hardware ModuleThe parameters for the simulation are shown as shown inFigure 4.Processor Speed Per Time-unit: 1000000Mean Memory Accesses per Instruction: 1.4Cache Hit Rate: 0.89Cache Hit Time: 5.0-9Memory Access Time: 4.0E-8Number of Bus Cycles: 2Bus Cycle Time: 5.0E-9Number of Instructions: 50000; 100000; 150000Number of Active Processors: 1; 2; 3; 4Global Seed: 1234567890Run Length: 1Figure 1: Multi Processor Computer ArchitectureThe model uses sophisticated Discrete Event (DE)modeling and abstraction techniques such as datastructures, quantity resources, and shared memory.Figure 4: Parameters for SimulationThe software model generates one processor request perprocessor and drives the hardware model.Thissimulation iterates on two parameters: Number ofInstructions and Number of Active Processors. In thissimulation, the first set of results show what happens tothe mean time per instruction when the number of CPUsis increased.Figure 2: System (Hardware-Software) Model663
The second set of results looks at bus activity with fouractive processors.adding additional components or adding additional detailto components.Mean Eecution Delay Per InstructionMean Eecution Delay Per Instruction1.02421.0241Delay (micro-secs)Delay 41.023941.02391.02381.02371.023681.02362341Number of Active Processors234Number of Active ProcessorsFigure 5: Single Instruction Delay versus Number ofProcessors (for 50,000 Instructions)Figure 7: Single Instruction Delay versus Number ofProcessors (for 150,000 Instructions)Figures 5, 6, and 7 show the mean execution delay perinstruction with increase in number of active CPUs andwith 50000, 100000, and 150000 instructions perprocessor request. The simulation results show that, theaverage time for the execution of an instruction increaseswith the increase of active processors in the system. Asmore CPUs become active in the system, more cachemisses occur and each CPU makes more demands on thebus to access main memory.Mean Eecution Delay Per InstructionDelay (micro-secs)1.02421.024141.0241Figure 8: Bus activity for 50,000 Number ofInstructions and 4 CPUs1.024041.0241.023911.02391.02381.02374.2 Water-pump Controller Model using MLDesigner[23]1.023671.0236123This system model demonstrates the integration ofvarious MOCs together. In particular this exampleintegrates MOCs for Finite State Machine (FSM),Synchronous Data Flow (SDF), and Discrete Event (DE).4Number of Active ProcessorsFigure 6: Single Instruction Delay versus Number ofProcessors (for 100,000 Instructions)This causes the requests to get queued inside the bus andresults in bus contention. This will reduce the effectivespeed up below the theoretical limit of n, where n is thenumber if processors. Figure 8 shows the bus activity inthe system to provide more detail on bus contention. Inthe plot the processor IDs are represented from 0 to 3.The plot shows the bus activity due to requests from 4different processors. The designs of both hardware andsoftware components are modularized and parameterizedso the model can be quickly modified to address a varietyof design issues and use cases. Modification could includeFigure 9: High Level System Model664
switches on the pumps to raise the level to a preset level.The pumps stop, the water level drops, and the cycle startsagain.The model also shows the use of dynamic control andanimation components. The simulated system consists ofa water tank equipped with a drain to remove water fromthe tank, two pumps to refill the tank, and a controller thatmonitors the level in the tank and controls the operationof the two pumps. The high level model is shown inFigure 9. The system model consists of a clock, a waterdrain, the controller, two identical pump modules, thevisualization components, and a block to update the tankwater level reduction.Figure 12: Controller Module FSM-1This simulation demonstrates the feasibility of integratingvarious MOCs.Figure 10: Water Pump ModuleThe water drain block models the operation of the tankdrain and associated tank levels. Shared memories (blocksRead WaterReduction and Write WaterReduction) trackthe water level and the water level reduction. Twoidentical pumps are used to refill the tank. A water pumpmodel is shown in Figure 10. The controllers are differentin functions (Figure-11).Figure 13: Full Tank5. ConclusionSystem complexity is increasing due both to continuedminiaturization and increase in demanding applications.NOC (Network on Chip) elegantly separates the concernsof computing and communication, and is expected to beideally suited to address this increased system complexity.We propose a layered architecture so the designcomplexity can be well managed and design issues can beaddressed at different levels in the layered architecture. Asystem for modeling of such systems, using our layeredapproach, will require support for components andinteraction among these components, using variousMOCs (models of computation). We show the use ofMLDesigner for this. The simulation results show thatMLDesigner can be one such effective environment tomodel our layered NOC architecture. Such a model canbe used to trade off different system parameters to yieldappropriate quality of service and performance metrics.Figure 11: Controller ModuleFSM-1 handles the two water pumps. It consists of 3states (s0, s1, and s2) as shown in Figure 12. FSM-2controls their equal distribution. FSM-2 consists of 2states (s0 and s1). When the model starts, the draincontrol and tank animation (Figures 13) appear and thetank fills. The drain is initially closed. When the drain isopened, it triggers the sensors and the water flows out.The controller detects the change in level and starts thepumps when necessary. When the tank reaches a set level,the controller shuts off the pumps. While the drain is openthe model cycles constantly. Water flows out, the tanklevel drops, sensors detect the lowered level, andcontroller gets the information from the sensors and665
AcknowledgementsWe would like to acknowledge the help of a PhD studentAbu Asaduzzaman and Mr. Colin Mick, MLDesigner, forproviding the [8][9][10][11]L. Benini and G. De Micheli. Networks on chip: anew SOC paradigm, IEEE Computer, 35(1),January 2002, 70-78.Xu, Jiang, W. Wolf, J. Hankel, S. Charkdhar, AMethodology for design, modeling and analysis fornetworks-on-Chip, IEEE International Symposiumon Circuits and Systems, May 2005, 1778-1781Hemani, Axel Jantsch, Shashi Kumar AdamPostula, Johnny Öberg, Mikael Millberg, DanLindqvist, Network on Chip: an architecture forbillion transistor era, Proc. of IEEE NorChipConference, November 2000, 8-12.Paul Wielage, Kees Goossens. Network on silicon:blessing or nightmare? In Euromicro Symposiumon Digital System Design, Dortmund, Genmany,September 2003. Keynote Speech.Tejasvi Das, Clyde Washburn, P. R. Mukund,Steve Howard, Ken Paradis, Jung-Geau Jang, JanKolnik, Effects of technology and dimensionalscaling on input loss prediction of RF MOSFETs,International Conference on VLSI Design heldjo
Once the design of the basic NOC architecture became established, new techniques evolved to address advanced issues such as dynamic load balancing on to a node of the NOC architecture, the shortest/fastest path for the data flow through NOC, and energy efficient NOC architecture design. Most researchers have focused on the
May 2020 NOC April 2020 NOC March 2020 Modification of Section IV Table 11C.1 (New provision symbols: 30B#6.21N_1, 30B#6.21N_2) February 2020 NOC January 2020 Modification of Section II Chapter 1 and Chapter 2 with new Special Sections: AP30/P and AP/30A/P. December 2019 NOC November 2019 NOC October 2019 NOC September 2019
Bruksanvisning för bilstereo . Bruksanvisning for bilstereo . Instrukcja obsługi samochodowego odtwarzacza stereo . Operating Instructions for Car Stereo . 610-104 . SV . Bruksanvisning i original
complex system chip design, especially for NoC-based SoC, which has been increasingly applied to complex system design. This paper proposes a collaborative verification and testing platform for NoC-based SoC. Based on VMM verification methodology, a hierarchical NoC validation platform is constructed and assigned to the function verification of NoC
Our NOC obtains both area and en-ergy benefits without compromising either performance or QOS guarantees. In a notional 256mm2 high-end chip, the proposed NOC consumes under 7% of the overall area and 23.5W of power at a sustained network load of 10%, a mod-est fraction of the overall power budget. Table 1: Scalability of NOC topologies. k .
To overcome these limitations, we propose an NoC-enabled PIM-based architecture that amalgamates: (a) multiple logic layers in conventional PIM, (b) M3D-based vertical integration, and (c) efficient 3D-NoC design for high-performance k-mer counting, while remaining within 85ᵒC temperature. To take advantage of and aid NoC design, we also
10 tips och tricks för att lyckas med ert sap-projekt 20 SAPSANYTT 2/2015 De flesta projektledare känner säkert till Cobb’s paradox. Martin Cobb verkade som CIO för sekretariatet för Treasury Board of Canada 1995 då han ställde frågan
service i Norge och Finland drivs inom ramen för ett enskilt företag (NRK. 1 och Yleisradio), fin ns det i Sverige tre: Ett för tv (Sveriges Television , SVT ), ett för radio (Sveriges Radio , SR ) och ett för utbildnings program (Sveriges Utbildningsradio, UR, vilket till följd av sin begränsade storlek inte återfinns bland de 25 största
learning teams, guided inquiry activities, critical and analytical thinking, problem solving, reporting, metacognition, and individual responsibility. Strategies for the successful use of learning teams are discussed, the roles of the instructor in this learning environment are described, and implementation hints
