You copied the Doc URL to your clipboard.

Using sdfremap with a Cortex-M DSM

Article ID: 241120290

Published date: 05 Sep 2018

Last updated: -

Applies to: Cortex-M0, Cortex-M0Plus, Cortex-M3, Cortex-M4

Problem/Question

How do I use sdfremap with my Cortex-M DSM?

Scenario

A Design Simulation Model (DSM) is a black-box model of a processor, suitable for chip-level simulations for engineers who do not have access to the processor RTL description. DSMs for the older Arm processors, mentioned above, use a model manager '$mm' call to an object file that implements the processor functionality.

This knowledge article is relevant to licensees of older Arm processors, who have a fully-implemented Arm processor macrocell in their chip design and who are trying to provide chip-level SDF to users who want to simulate the chip at gate level and using the processor DSM, with back-annotated delays.

'sdfremap' is needed to manipulate the chip-level SDF so that the IOPATH delays map onto appropriate annotation points on the DSM.

The DSM deliverables include some generic documentation, but this documentation does not explain specifically what is required for use with these Cortex-M DSMs.

Answer

The Design Simulation Model (DSM) is intended to be used in an EDA flow methodology in which the processor is implemented in isolation and then used as a design block in a chip-level design. This means that the chip-level design retains an identifiable boundary that is the processor instance. The processor layout is characterized for timing performance and this information is saved in .lib or .db format. The chip-level timing analysis can then use the characterized timing of the processor block to calculate the timing performance of each processor instance in the context of the full chip design, and produce timing arcs in the chip-level SDF file that refer to the top-level signal ports of the processor.

Note:

The alternative EDA methodology is to integrate the processor RTL description into the full chip RTL and then allow the synthesis tool to merge and optimize the logic across the processor boundary, and allow the layout tool to mix the logic gates and wires inside and outside the processor. This approach results in a chip design where there is no identifiable processor boundary within the chip, and this approach is therefore not compatible with using DSMs.

The DSM bundle delivered by Arm contains the binary object that implements the processor behavior, together with installation scripts and README file, documentation, a test harness to run an installation test with and without, SDF annotation, and SDF processing tools including sdfremap.

The docs directory in the DSM installation includes a PDF of the Design Simulation Model (DSM) User Guide (UG). This user guide gives a generic description of common problems with sdfremap, one of which is annotation at the wrong hierarchy level, and a reference to the pathtrails facility to fix this.

Note:

The docs directory in the DSM contains a man1 entry, so that if you add the docs path onto your MANPATH environment variable, you can use man sdfremap to get a much more detailed usage guide for sdfremap.

The structure of the DSM includes an RTL wrapper that presents the same top-level module name and signal ports as the processor RTL, and, through some further levels of hierarchy, makes a PLI call, '$mm' to the functional processor binary model. Each DSM contains two versions of the RTL wrapper: a simpler one that does not support delay annotation, for example, CORTEXM3.v, and a slightly more complex one that does support delay annotation, for example, timing_wrapper/CORTEXM3.v. The difference between these two wrappers is that the timing wrapper contains an extra level of hierarchy immediately below the top level, that instantiates a set of logical elements (such as pmos) that provide suitable annotation points for the SDF timing arcs. However, these annotation points are one level of hierarchy further down than the top-level signal ports referenced in the chip-level SDF. The sdfremap utility provides a method for adjusting the chip-level SDF file to correctly map the processor timing arcs onto the correct annotation points. This difference can be seen in the example SDF file where the CELLTYPE has '_timing' added, and the INSTANCE path has 'thetiming' added. sdfremap can be used to make these same adjustments to the chip-level SDF.

sdfremap needs an SDF template file, for example, CORTEXM3.sdft, and a timing defaults file, for example, CORTEXM3.tdef, for the processor, and these can be copied from the DSM installation into the directory where you want to run sdfremap.

To tell sdfremap that you want to qualify the CELLTYPE and INSTANCE to match those specified in the .sdft file, you need to supply a preferences file containing celleq and pathtrails directives. For example, for Cortex-M3, the file would need to contain the three lines:

<celleq>
"CORTEXM3"
<pathtrails>

The preferences file is selected by including the '-p' switch followed by the file name (without a space between them).

You might also like to add the '-v' switch to see a verbose listing of what is being remapped.

Workaround

N/A

Example

For one or more Cortex-M3 instances in a design SDF file, MyDesign.sdf, and with the CORTEXM3.sdft and CORTEXM3.tdef files copied into the current working directory, together with a preferences file, prefs, containing the three lines as described above, the sdfremap command might look like:

    sdfremap -v -pprefs -cell CORTEXM3 MyDesign.sdf Remapped.sdf

Related Information

The sdfremap executable supplied in the standard DSM bundle is a 32-bit executable, even in the 64-bit DSM bundles. This executable runs correctly on 32-bit and 64-bit platforms, but is subject to the file size limit of 2GB implicit in being a 32-bit executable.

The historical workaround for SDF file sizes greater than 2GB was to extract the section or sections of SDF referring to the processor DSM into a separate, smaller SDF file (for example, in a text editor), run sdfremap on the small file, then replace the original processor blocks in the full chip SDF with their remapped equivalents. However, this is an inefficient and a potentially error-prone approach, and users who need to handle SDF files greater than 2GB should look here:

Is there a 64-bit version of sdfremap? 

The sdfremap and DSM flow has a number of limitations, and users of this flow should familiarize themselves with the detailed descriptions of limitations in the Design Simulation Model (DSM) User Guide delivered with the DSM and available on https://developer.arm.com.

Was this page helpful? Yes No