• Like

SSM White Paper NOV-2010

  • 617 views
Uploaded on

SoC System Manager white paper delivered for the IP-SOC Conference in Grenoble, France (November 2010). …

SoC System Manager white paper delivered for the IP-SOC Conference in Grenoble, France (November 2010).

One of the key challenges associated with designing SoC system management schemes stems from the growing number of programmable devices on-chip. Programmable devices exponentially increase the number of combination's of software operations that drive hardware state changes in real time. This in turn complicates system level testing in order to achieve reasonable test coverage. Optimizing the SoC design for a single operating system provides little relief, because the diversity of applications running on the SoC continues to multiply the testing complexities at the system level.

This paper will discuss design considerations and compare and contrast three system management architectures. The first is an ad hoc system management, which is comprised of combination's of hardware and software elements that serve a dual purpose, one being normal operation, and one for system management. The second is including system management as part of the on-chip interconnects implementation. The third architecture introduces a control plane approach for system management which complements the data centric global interconnect.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
617
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
27
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Optimizing System Management in the Platform SoC EraHoward Pakosh, ChipStart and Phil Casini, AdvanceTech MarketingNovember 2010IntroductionConsumer focused SoCs have evolved system management, which is comprisedinto platform architectures that are now of combinations of hardware andbeing driven by requirements from software elements that serve a dualoperating systems such as Android, purpose, one being normal operation,iPhone. Linux, and Windows and the and one for system management. Thethousands of applications they support. second is including system managementOvertime more of the system is moving as part of the on-chip interconnectsinto silicon . As a result, system implementation. The third architecturemanagement functions have moved into introduces a control plane approach forthe SoC. Traditional feature based system management which complementsregression testing at the silicon level the data centric global interconnect.must now be increasingly complimentedwith complex system level testing in Finally the paper will discuss theorder to maintain a high level of system growing importance of integratedcoverage across SoC road maps. subsystem design and IP for SoCs and how system level partitioning will play aBalancing price-performance-power and growing role in achieving efficienthigh system level test coverage therefore system management.creates complex system managementdesign challenges that effect both System management designhardware and software operation. considerationsSystem management must now be One of the key challenges associatedconsidered as a central feature and with designing SoC system managementresponsibility of the SoC architecture, schemes stems from the growing numbernot just as a tactical design consideration of programmable devices on-chip.for the development of each individual Programmable devices exponentiallySoC. System management should increase the number of combinations ofprovide adequate synchronization of software operations that drive hardwarehardware state changes driven by state changes in real time. This in turnsoftware, maintain reasonable time to complicates system level testing in ordermarket and maximize system test to achieve reasonable test coverage.coverage and support. Optimizing the SoC design for a single operating system provides little relief ,The remainder of this paper will discuss because the diversity of applicationsdesign considerations and compare and running on the SoC continues tocontrast three system management multiply the testing complexities at thearchitectures. The first is an ad hoc system level.
  • 2. System level testing via traditional elements introduced into the SoCsilicon level functional and data path architecture.regressions must now be augmented bysystem functional test suites include the In fact, this trend has already begun. Theprogrammable elements and their impact growing use of decoupled globalon hardware state changes. Each interconnect structures, such as thoseprogrammable core can be isolated and that employ OCP or similar features,tested to achieve a high level of code provides a proven example of how tocoverage, and each execution path ease chip architecture design as itthrough the different cores combinations evolves from single to multicore orcan be tested., but the combinations of multi-layer. By “abstracting” the datahardware state changes they require as a plane, and allowing the associationsresult of application behavior makes it between the IP cores to become linkedalmost impossible to achieve adequate through the independent globalsystem level coverage solely from interconnect structure, systemtesting the cores and the buses in performance at the hardware levelisolation or even pseudo random becomes more predictable and tunablecombinations. (CPU to off chip memory for example). This predictability affords opportunitiesIt is at this point that compromises are to streamline the design process becauseoften made in the SoC design. How these loosely coupled associations aremuch risk is affordable when trading off less effected by specific design changes.the cost and time to build these complex This leads to more rapid timing closuresystem level regression suites with the even though the complexity of the dataactual test coverage achieved? As plane has grown significantly.volumes grow the answer is risk must bemitigated and therefore these tradeoffs Similar abstraction techniques can bebecome essential to minimize. applied to system management. The software and hardware layers, the system This paper challenges the increasing management, and the functional“tax” on the project costs to balance operation of the SoC can be decoupled,adequate system level test coverage, and making it easier to test each componentrisk, based on current system of the system level architecture whilemanagement architecture assumptions . considering the system level driven hardware state changes. This results in aSpecifically, instead of continuing to system level design which is more easilygrow regression suites and make risk understood and has better test coverage.choices based on the assumption that the This approach also abstracts the systemassociations between the levels of management operational complexitieshardware and system testing are tightly between hardware and software evencoupled, abstraction layers can be though the number of applicationsinserted into the architecture to decouple grows.the hardware, operating system, andapplications support functions. The next section of the paper willFurthermore, each of these components discuss three potential methods ofcan tested through independent
  • 3. abstraction that lead to varied degrees of However, the complexity growthoptimizing system management. associated with multicore SoC for consumer designs today have weakenedSystem Management Scheme the effectiveness of using this approachComparisons because as system tasks become distributed, that is more interdependentGiven that the objective is to reduce as more cores are added to the SoC, theoverall system management complexity visibility and control of any one corethere are three baseline characteristics over any of the others is reduced withthat system management schemes should each new element added. The visibilitybe benchmarked by: and control becomes more dependent on the global interconnect as well as the 1. How well does the approach cores, adding even more complexity to achieve independence between execute control functions. The addition the silicon-operating system- of the global interconnect as part of the and application layers? system testing is required in this case 2. How flexible is the approach to because it controls access to external adapt to each derivative design memory, a key element in system in a SoC road map? operations. 3. How much test coverage does the resultant system If the master CPU can no longer manage management scheme achieve and verify the hardware state changes of for the SoC architecture? the other core elements, the number of possible states increasing results inBy applying these benchmark criteria, unpredictable coverage and thethree methods can be evaluated. methodology no longer has value. Extending the scheme then to addMethod 1: Using a single operating system test does not return meaningfulsystem hosted on a “master” CPU. This dividends on the potentially massivehas been a popular approach to perform investment of developing the tests andsystem management because silicon verification infrastructure.elements already required for real timeoperation also execute system Applying the criteria then to this methodmanagement functions. for today’s platform SoCs Host IP CPU Core 1. This approach fundamentally breaks down for multicore SoCs because it will not adequately allow the economical IP Core I/O construction of operating system and application level system test layers.When SoC complexities are relatively 2. This criterion is consideredlow, this scheme is very efficient. No inconsequential given that theextra silicon, some extra software criteria failed the first test.development, but very containable.
  • 4. 3. This approach will yield approach feasible for some extremely low system test multicore SoCs. coverage and therefore its 2. However, the approach also has a usefulness is directly dependent ceiling of usefulness which is on the complexity of the SoC. normally reached when extra logic is required to manageMethod 2: Introducing global “special” cases for each of theinterconnect structures and additional derivatives in the SoC road maplogic to support pseudo-control plane as inefficiencies mount that aresystem management functions. This tolerated to minimize time toapproach is an extension of method 1 market. One area where thisbecause often the host CPU continues to occurs is when the systemact as the system management master. management master, usually theSide band signaling, either contained in host CPU, requests that anotherthe interconnect or designed separately core should power down.is used for the control functions. Inefficiencies sometimes occur when complex arbitration Host IP IP schemes and blocked requests CPU Core Core delay the actual action of powering down the core. These delays can often be measured in IP IP thousands of cycles, which is I/O power consumed for no useful Core Core system function, and is thereforeMixing data plane and control functions power wasted.introduces abstraction levels that aides in 3. As a result of the ceiling in theachieving higher system test coverage as benefits of the approach, overalllong as the SoC does not drive the coverage is directly dependent oninterconnect requirements to become so the complexity of the SoC and ascomplex that the control functions such is useful only within a rangebecome a small and lower priority in the of SOC complexity.overall mix of functions. When thisoccurs the control tasks are executed Method 3: Introducing a control planesub-optimally as delays occur from that compliments a data plane globalpriority choices between functional interconnect.operations and system management tasksbecause of complex arbitrationsequences and delayed communicationthrough blocked hierarchical buses.Applying the criteria then to this methodfor today’s SoCs 1. This approach introduces levels of abstraction which makes the
  • 5. This approach differs from the first two 2. This approach introduces highmethods because it does not extend the levels of flexibility as bothtraditional host CPU system master control and data plane functionsapproach. Rather, it introduces a can be tuned for each SoCseparate control plane and an derivative without changing theindependent system controller to base architecture.perform system management tasks. 3. This approach also maximizes the coverage achievable because any source can direct the system management and as such Media CPU DSP Engine operations (applications) can be System isolated and tested within theController Global Interconnect approach without compromising Low High overall coverage. DRAM Speed Speed Controller I/O I/O Control Plane Summary:An independent control plane essentially While method 3 introduces new controlabstracts the system management tasks plane functionality, it also enables SoCsfrom any one entity. As such, it can be of virtually any complexity to be testedcontrolled by any-or all SoC elements as and operated with maximum efficiencyrequired, and therefore offers multiple achieved using the same approach. Aslayers of abstraction. System testing can such it is best suited for roadmaps thatbe developed by software, hardware, contain a wide variety of complexity orverification, and system engineers and when extreme flexibility is required forapplied using a common framework with the SoC architecture. The ability toequal effectiveness. direct the system controller using any SoC core is especially noteworthyThis approach is also advantageous because it allows multiple applicationsbecause it separates targeted control to directly control the hardware states intasks ideally executed with low latency real time when needed and without thefrom longer more complex and often overhead of channeling its requestsperformance sensitive data plane tasks. through other entities, thus avoidingThis separation is often necessary when inter-function dependencies,complexity is high, because traditional complexities and delays.approaches reach the ceiling ofeffectiveness discussed during method 2. The Impact of SoC Subsystems on System Management.Applying the criteria then to this methodfor today’s SoCs The basic theme to achieving better system management is successful 1. This approach creates maximum partitioning in order to increase adequate levels of abstraction for system levels of system test coverage. This is management but introduces why method 3 was chosen as the most control plane functionality.
  • 6. effective for today’s system managementneeds.It stands to reason, then, that the impactof subsystem utilization further abstractsthe system management tasks. However,creating systems within systems alsointroduces hierarchies of complexity andas such, further pushes traditionalmethods of system management useless.The growing use of subsystems over thenext generations of SoC design willtherefore accelerate the adoption ofcontrol plane based system managementas the preferred method of architectureso that hierarchical levels of complexitycan be absorbed into the systemmanagement architecture whilemaintaining a common architecture thatprovides the flexibility and scalabilitywhile minimizing risks and costs ofexpensive architecture redesigns thatwill accelerate as system requirementscontinue to become more complex.