WP_Term Object
(
    [term_id] => 8
    [name] => ClioSoft
    [slug] => cliosoft
    [term_group] => 0
    [term_taxonomy_id] => 8
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 95
    [filter] => raw
    [cat_ID] => 8
    [category_count] => 95
    [category_description] => 
    [cat_name] => ClioSoft
    [category_nicename] => cliosoft
    [category_parent] => 157
    [is_post] => 1
)

HCM Is More Than Data Management

HCM Is More Than Data Management
by Alex Tan on 04-12-2018 at 12:00 pm

21468-fig1.jpgWhile tracking Moore’s Law has become a more expensive and difficult endeavor in the HPC design, the mobile SOC design space is also increasingly heterogeneous and complex. Strict safety guidelines such as the ISO-26262 being imposed in the automotive applications further exacerbate the situation.

Looking closer into the design ecosystem, we could view the segregated landscape as being occupied by four key players, namely foundry, EDA, IP and design service providers. For example, the first ADAS computer vision SOC tapeout in February last year is as a result of a collaboration among three IP companies (Dreamchip, ARM, Arteris), an EDA (Cadence), a design service (INVECAS) and a foundry (Global Foundries). It is intuitively clear that collaboration should serve as a common denominator, in order to ascertain a seamless design implementation and successful product rollout.

Design realization involves taking its formulation into different level of abstractions, which then get optimized, verified, analyzed and aligned with foundry requirements. All of these imply frequent and occasionally massive data generation, in binary and ASCII alike. Key to a proper handshake among these ecosystem players is a formal process or policy for data and version control management. Last month, the use of Hardware Configuration Management (HCM) from ClioSoft, SOS7, as embedded agent in various underlying point-tools or flow interface had been discussed in this blog. In this article, we will expand its usage scenarios within the ecosystem.

21468-fig1.jpgFoundry Files
When a new or derivative process node is introduced, it is normally accompanied by foundry’s Process Design Kit (PDK). A PDK is a collection of foundry-specific data files and script files used with EDA tools in a chip design flow. PDK main components are models, symbols, technology files, parameterized cells (PCells), and rule files. Any process related fine-tuning and control variations could result in an incremental release of PDK. On the other hand, timing models and its related parameters are captured and released as SPICE model as illustrated in Figure 2.

21468-fig1.jpgOnce the PDK is passed to the foundry customers, the chain reaction starts. The design and IP teams should make a call as to which part of the design step(s) in the flow that need a respin. PDK changes usually impact changes to routing vias and metal stacks, parasitics parameters or extraction setup; although they may or may not be relevant to the integrity of the standard cells library. SPICE model updates, however, would trigger a library recharacterization and a timing respin. With ClioSoft’s HCM SOS7, such PDK update can be captured as separate reference projects, allowing ease of retrievals for correlating with prior versions and tracking trade-off of chosen design metrics. It is usually normal to expect between 4 – 6 iterations for a new process. For example, annually TSMC releases between 500 – 700 techfiles and 50-70 PDK updates for all supported processes.

Aside from PDK, there is usually a validated reference flow accompanying each foundry process node rollout. A reference flow is adopted by foundry and open-source IP provider such as ARM to address critical design challenges associated with the new process technologies and pipe-clean the flow to be ready for performance, power and area optimization.

Packaging
Other variations which might require creating different design implementation scenarios, are presented from the IP and packaging selections. Depending on the market segments (automotive, IoT or mobile), the form factor, power or thermal requirements may drive the package selection. Figure 5 shows various package technologies vs market segments. With stringent requirements such as ISO-26262
21468-fig1.jpgand the availability of advanced packaging analysis, it is becoming common to analyze the impact of project targeted packaging on the system’s silicon. For example, FOWLP (Fan-Out Wafer Level Packaging) is known for its low cost and high performance and selected in low-power, high performance mobile applications. A thermal-stress analysis can be performed to assess its reliability. Another example is the System-in-Package (SiP) which is targeted for the IoT wearable, RF and automotive. Each of these packaging analysis such as 3D-Electro-Magnetic simulation, thermal and stress analysis need to be aligned and synchronized with upstream system silicon. Since SOS7 platform is methodology agnostic, data management from this downstream analysis can be folded into the ecosystem.

IP Reuse and Management
We often discuss about design reuse as it applies to both internal and third party IPs. The steps in generating, maintaining and propagating design changes as well as user experiences as manifested in scripts, documents, or other file formats, are daunting–especially with increasingly shortened deliverable schedules to meet time to market. ClioSoft SOS7 addresses most of these requirements. It helps the design team to streamline the IP development and management, ensuring efficient collaboration while dealing with many design collaterals.

ClioSoft’s SOS7 platform can be easily integrated with different applications. The development environment is separated from the release environment. Normal procedural access steps (such as checkout, modify, checkin) are enforced with either a corresponding locking mechanism or concurrent checkout (with merging capability), similar to Software Configuration Management (SCM) features. Several other ClioSoft’s SOS7 neat features include:

  • Customizable triggers as a condition, e.g., no check-in prior to a clean code linting.
  • The use of symbolic labels/tags on revisions to communicate a revision status.
  • Customizable composite object, treating multiple files as single object.
  • Sandbox for local workspace, while SOS7 monitors and send project level periodical updates.
  • Rewind or snapshot features add flexibility to move along progress or debug timelines.
  • Simplified IP release through a script, copying collaterals from development to the release environment.
  • Tool level ‘diff’-ing of two revisions.

Unlike Software Configuration Management (SCM) which may be confined into a distinct set of files and formats, Hardware Configuration Management (HCM) involves handling many design parts and formats. ClioSoft SOS7 offers an integrated development and management platform for not only design data but also design knowledge.

For more info on ClioSoft HCM SOS7 please check HERE