'A la Carte' SoCs require innovative IO management

by David Murray,  Michael Phelan, Duolog Technologies
Ireland

Abstract :

As the cost of mask production increases more designs use Application Specific Standard Product or Platform based SoCs.  Leading edge chip manufacturers are resolving Multiple-Application requirements into single chip solutions and are literally giving their customers a menu of interfaces to chose from. Increasing gate density allows more functionality to be implemented in these devices and system architects are finding themselves becoming heavily pin-limited.

To overcome this limitation the chip IO has to be highly configurable. The configuration scheme has to be balanced to ensure that the selection of one interface can co-exist with several others and this leads to some interfaces having sets of IO Pins in different configurations. This many-to-many IO mapping leads to IO pins having several system functions and several test functions.   The complexity is increased when IO functions have to take into account pull-up/down control, analog cells or specialised buffers.   Architects can struggle with tracking all the constraints of SoC core signals which are mapped to several pins making the IO function high-risk.

From a validation perspective it’s the same nightmare. The chip has to be validated for multiple scenarios and this requires a highly complex testbench. Any bugs that are contained in the IO layer can even slow the validation process down as highly validated SoC Core interfaces are not routed correctly through the IO layer delaying the validation phase.

This paper describes an automated SoC IO Management technology called Spinner that was applied to a leading edge multimedia SoC platform.  Spinner allows an effective IO specification mechanism to capture all requirements and generates the complete IO layer.  These  requirements include IO multiplexing (functional and Test) , BSR insertion, Power isolation cell insertion. From the validation side Spinner automates system-level testbench generation and generates a self checking testbench and coherency check for the complete IO layer.  Configuration scenarios can be specified which produce C code that allows chip configuration.

IO Evolution

One simple evolution that’s happening in the electronic design industry today is that SoCs are being designed to handle multiple applications/ products. There are many reasons for this trend – cost and time to market being the main ones.  If a large amount of engineering effort is invested in a chip that can be  included in several products then the mask costs of this chip can be spread across a range of products and the life of the chip may even be prolonged.  ‘Platform’ based SoC s suit this type of methodology. A central platform forming the core of the SoC onto which a which a wide range of peripherals can be attached.

Increasing gate density means that more and more can be added to these platforms to ensure that they fit with yesterday’s, today’s and tomorrow’s system environments.   A ‘hard-wired’ reconfigurability and functional redundancy is part of these SoC architectures going forward with specific applications using specific peripheral sets and other peripheral choices are discarded (turned off).  In effect the evolution is toward  ‘A la Carte’ SoCs.

Companies are currently developing platforms for many applications including  wireless multimedia platforms, personal area network communicators, storage platforms and security platforms to mention a few. Typical platforms include the TI OMAP (Open Multimedia Application Platform), Palmchip’s AcurX platform, Toshiba SoCMosaic platform.

After intensive planning for cost, usability and flexibility a SoC architecture can be proposed which could contain at it’s interface boundary pin counts exceeding 2-3 times that of a proposed package.  This is not necessarily bad news as there is redundancy here which means that we can multiplex different interfaces depending on the requirements.  It does however increase the complexity  of the IO Layer which causes problems for the SoC life cycle.

 
Figure 1 : Multiplexing Scenarios

Figure 1.  shows some typical multiplexing requirements for an ‘A la Carte’ SoC where the constraint is that the are more Core signals than pins but we require some redundancy on these pins to ensure that the multiplexing possibilities are not limited. This requires a many-to-many type of multiplexing function. A single pin may have to support multiple core outputs, inputs or bi-directional signals as well as pull-up/pull-down logic and test signals.  This type of complexity requires focused planning and an innovative approach to ensure that the SoC development lifecycle runs smoothly.

IO Process

The IO layer is a major and critical deliverable in the SoC lifecycle. With the emergence of these ‘A la Carte’ type SoCs there is more emphasis on this layer than ever before.


Figure 2 : IO Layer

 Some typical requirements of the IO Layer are as follows:

• Well balanced Functional Multiplexing
• DFT Requirements such as test multiplexing, BSR logic,  test override logic for e.g. IDDQ test
• Timing requirements
• Package Requirements
• Power requirements such as Power Plane definition and power insertion of power isolation logic
• IO Cell requirements, particularly complex IOs.
• Validation requirements.
• System testbench requirements.

Typically these requirements are distributed throughout several different teams with no single central view of the process.  This makes this layer of logic harder to manage from a requirements perspective, especially with increasing complexity of the multiplexing functionality.  

Requirements tracking for a large number of multiplexed IO Pins can be very difficult.  A many-to-many relationship between core signals and pins means that constraints on a single core signal may have to be traced to several IO cell types, and several BGA Balls and vice versa. 
This typically tends to be a manual process (other than perhaps BSR generation which boasts some toolsets ) open to many risks.   A manual and fragmented process requires implementation from several specifications. These specifications  can be unstable and difficult to maintain and as such,  the inherent knowledge of  the IO layer functionality ends up in somebody’s head.

Once the design is implemented how is the quality ensured?  If the design process is as manual as detailed then the only persons capable of validating the IO layer , could be the same person that designed it?  From standard verification methodologies this would unfortunately not be the right person to do the verification as objectivity, a main requirement for effective validation, would not be achieved.  Putting a testplan and testsuite in place would add significant overhead to the process. 

Even after an IO layer is implemented and fully validated, there is a further problem – Maintenance.  If a single core signal is changed  then the following may require maintenance

• IO Specification
• IO RTL Code
• BGA Diagrams
• Software Configuration Libraries
• Self-Checking Test Code
• System Level Testbench code.

Something as simple as swapping the multiplexing of one interface with another on a set of pins could cause a substantial change of a few days.

Another consideration of this process lies in the fact that a chip may require repackaging and incremental changes downstream.  This could be practically a redesign of the IO Layer and with a manual process, this is a repeat of the same problem within an even more aggressive timeframe.

IO Risks

So, the IO Layer is emerging to be a complex, fragmented and traditionally manual process that is becoming increasingly higher risk. What effects does this have on the overall SoC lifecycle?

There are two main effects.
1.    The IO Layer is difficult to implement and is delayed.
2.    The IO Layer is difficult to implement and is incorrect.

How do these effect the overall SoC lifecycle? 

A SoC Lifecycle typically has the following phases that run closely with each other.

• Module/Sub-System Development + validation. (This could be anything from a uart peripheral to a processor sub-system)
• System Level Integration (Connectivity of Sub Modules)
• IO Integration (Implementation of IO Layer)
• System Level Validation

The following diagram shows an example of the SOC lifecycle. Please note that this only focuses on specific IO related tasks.



Figure 3 : IO Integration in SOC Lifecycle

Depending on the maturity and organization of the SOC lifecycle, a complex IO Layer can introduce a lag in the system level validation, which is already a critical process.  Unfortunately for the IO Layer, it is dependent on many levels of the design. Instability in the module level and system architecture can be reflected in the IO Layer.  If module/subsystem level validation is mature then this validation expertise may have to wait until the IO layer is complete before being able to move to a system-level validation focus.

IO Layer bugs are critical in that they may cripple an entire interface or the entire chip.

If an IO Layer bug is found – Great! The validation process is working. However, finding IO bugs during system simulation is usually very unproductive.  Typically system-level simulation is very slow and the validation of an interface at system level requires reset sequences, embedded processor cycles and in general, large amounts of simulation time.  Sometimes it takes days between finding a bug and understanding a bug, and also days before a bug is fixed and system-level  simulations can be progressed.

An unstable IO Layer can leave the majority of a system validation team literally tunneling through the chip to get to their required level of validation.
 
An Innovative Approach
For most platform based SoCs a new approach to IO management needs to be defined.  A wish list for such a layer would be :

1.    Centralized Requirements Specification
This would allow a centralized view and management of IO requirements and data.  Users should be able to view data from different perspectives, Functional, DFT, Package.

2.    Intuitive Visualisation
The ability to trace requirements or signal/pin properties throughout the pinout specification process is essential to robust IO level design.

3.    Fully Automated RTL Code Generation
A key part to an innovative approach would be to automate the centralized specification in a push-button manner and generate 100% of the RTL code.

4.    Automated Validation
This capability would ensure that the RTL code if functionally validated within a simulation environment. This is the key requirement and again would be automated from the central specification.

5.    Testbench Automation
The generation of a testbench wrapper for the SOC would be necessary to streamline System-Level validation.

Spinner Technology
Spinner is a tool that Duolog Technologies have developed to aid IO Management. This technology includes automation libraries for the generation of RTL code, TCL Code, HTML documentation and BGA package visualization.

Automated specification, visualisation and RTL generation tools simplify the I/O design and verification task. Spinner’s GUI based specification  mechanism gives the user an intuitive and efficient environment to enter in IO Layer Data.


Figure 4 : Spinner Visualisation

Spinner supports ‘Many-to-Many’ signal and control multiplexing. A single CORE signal can be assigned to multiple pins and a single pin can also be assigned to multiple signals. This allows full multiplexing possibilities. The multiplex function can resolve all I/O multiplexing requirements for both I/O signals and their respective control (e.g. Output Enable, Pull-Up/Down etc.) .

This multiplexing logic can be overridden using specific logic functions to allow test requirements to be implemented e.g. for IDDQ tests.
Input pins can tied to default values if not selected. These default values can in fact be constants, internal signals or even pins. Input values can also be overridden.

Dialogs are provided to aid pin multiplexing and to provide essential information in an easy to use format. Information can be entered in either sequential table or BGA type formats.  SoC interfaces are colour coded to enhance usability and resulting configurations can be seen fully in the BGA diagrams. Navigation features allow the user to trace signals through the hierarchy.

Coherency Checking

In order to ensure a robust process Spinner provides both Database Coherency and Functional Coherency checks.

Database coherency checks that all data input into Spinner is of good quality and includes checks such as signal naming, BGA references, correctly specified override functions etc.

Functional coherency ensures that there is a robust link between the CORE level and the PIN Level of the specification. For example, Spinner checks to ensure that if a pin has multiplexed inputs only, it should then have an ‘input only’ I/O Cell.

Full RTL Logic Generation

Spinner will generate fully synthesizable RTL Code for complete I/O Control, Top-level Chip and Testbench code.  Code generated is fully commented and formatted for ease of navigation.  Figure 5 shows  the generated hierarchy.


Figure 5 : Spinner Hierarchy

Spinner also allows the user to include custom logic to handle complex IOs. This is used for a minority of pins.

System Testbench Generation
Multiplexed I/O can usually add complications to an already complex  validation environment especially when trying to hook it into an external environment.
Spinner can generate a de-multiplexing layer that reconnects the chip to a core level type interface. This layer can then be automatically instantiated into a system level testbench.

Self-Checking Testbench
Spinner generates a self-checking test-bench that provides 100% functional cover-age. The self-checking testbench can either be a TCL based testbench for use with the most popular simulators or a HVL type testbench
(e.g. Specman). The structure of this testbench is such that it can be extended to hook into the SoC CORE and even generate I/O Configuration routines. In this way there is minimum effort in porting from module level to system level validation, while maintaining 100% coverage.

Case Study -  Multimedia based SOC Platform

Spinner has been used to manage the IO Layer of a highly complex Multimedia platform based SOC. The following characteristics apply:

Number of Pins	> 300
Number of Core ‘Pins’	> 500
Functional Muxing Layers	8
Test Muxing Layers	30

  
 With over 600 core pins, there were greater than 1500 signals coming from the SOC Core including configuration registers, control signals, IO Control signals (e.g. Output enable), IO signals.  Many of the pins had 5 to 6 possible connections to the Core.

Spinner successfully generated full RTL code for the IO layer and testbench as follows:

Generated Language	VHDL RTL
IO Layer RTL Code	86,000 Lines
System Level Testbench Code	20,000 Lines
Self-Check Testsuite	40,000 Lines
Manual code in IO Layer	300 Lines

Table 1 : Lines of Code

What is of particular importance is that only 300 lines were created manually while over 100,000 lines were generated automatically.

Table 2 presents statistics on the build time.

IO Layer RTL Code build time	45 seconds
System Level Testbench build time	1 Minute
Self Checking TB build Time	2 Minutes
Self Checking TB Simulation time	15 Minutes
IO Layer turnaround time	~30 Minutes

  
Table 2 : Build /Turnaround Time

Another item of interest here is the turnaround time.  A specification change can be automatically generated the IO Layer RTL code in less than 2 minutes and to do a full IO Layer validation regression test on this for 100% coverage will take less than 30 minutes.

Conclusion

I/O Pin Management is currently at the core of highly configurable SoC design process issues.  SoC IO requirements has advanced and traditional Pin Management methods are not keeping pace.  By using Spinner,  Pinout development time is greatly reduced, the documentation process is improved and the probability of first time right silicon is greatly improved. The structured approach is the best way to manage the complex Pinout requirements of all your future ASSP platforms.

About the authors
David Murray leads the verification and automation group of Duolog Technologies and has presented papers at IP99, IP2002 and been published several times in EETIMES and ISD Magazine on a range of topics such ‘Algorithmic IP’ and ‘Advanced Verification Reusability’. He can be reached at [david DOT murray AT duolog DOT com]

Michael Phelan leads Duolog’s Sales and Marketing department. Michael holds an MSc in Digital Signal Processing and an MBA. He can be contacted at [Michael DOT Phelan AT duolog DOT com]