You copied the Doc URL to your clipboard.

Getting started with Cortex-M0, Cortex-M0+, Cortex-M3 and Cortex-M4 full licensee bundles

Article ID: 238818831

Published date: 21 Sep 2018

Last updated: -

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

Problem/Question

How do I get started with Cortex-M0, Cortex-M0+, Cortex-M3 and Cortex-M4 full licensee bundles?

Scenario

This knowledge article is for chip designers who have licensed the full Cortex-M processor RTL bundle of the earlier Cortex-M processors for inclusion in their chip design. It does not focus on the Cortex-M0 and Cortex-M3 DesignStart Eval or DesignStart Pro deliverables.

Some of the earlier members of the Cortex-M processor family have been mature for several years. Additionally, they have had no errata which would have required a re-release of the processor RTL. As a result, the tool and platform versions on which these products were developed have become outdated. The original tool versions are listed in the release note with each product.

Each processor is delivered together with an Integration Kit (IK). The IK consists of a simple example MCU design and a few test programs, together with a script for compiling and running the tests. Running the tests as an Out of Box (OoB) test allows you to become familiar with the product and check that it is correctly installed. The supported simulators are Synopsys VCS, Cadence NC-Verilog or Cadence NCsim, and Mentor ModelSim or Mentor QuestaSim. Some of these tests might not run smoothly on modern platforms and tool versions, and might require small adjustments of the scripts because of their age.

This knowledge article is dated July 2018, and refers to current processor versions at the time of writing:

- Cortex-M0 AT510 r0p0-03rel2 26 April 2010

- Cortex-M0+ AT590 r0p1-01rel0 15 April 2016

- Cortex-M3 AT420 r2p1-00rel1 25 September 2017

AT425 r2p1-00rel0 28 July 2010

- Cortex-M4 AT520 r0p1-03rel1 25 September 2017

AT521 r0p1-03rel0 02 December 2013

The platform that was used to check these results was Red Hat Enterprise Linux 6.6.

Answer

The version of Synopsys VCS used in development of all of these products is 2008.09. This version is not compatible with contemporary server OS versions such as RHEL 6.6 because of an unrecognized switch passed into the C compiler.

     g++: error: unrecognized command line option '-melf_i386'

Versions of Synopsys VCS starting from 2014.03 run correctly on RHEL 6.6 on Arm’s compute cluster.

Cadence Incisive / IUS versions 9.20.023 and lower are not supported on Arm’s 64-bit RHEL 6.6 servers. Version 9.20.033 is the lowest version that simulates the example designs correctly on Arm’s compute cluster.

Cortex-M3:

The Cortex-M3 full RTL bundle can be licensed as either of:

  • AT420, Cortex-M3.

  • AT425, Cortex-M3 with ETM.

Cortex-M3 predates the standardized IK and RunIK command used in the later Cortex-M processors. Instead, it provides a simple example system that uses a run_example script to invoke the tests, and a behavioral component to drive debug test sequences into the debug slave port using JTAG or Serial Wire Debug (SWD) Port protocol. The generator for the JTAG sequences uses a model manager dynamically-linked object called 'armBST.'

The armBST binary object is provided in both 32-bit and 64-bit forms, but the run_example script used to invoke the tests provided with the example system defaults to the 32-bit setup.

The default invocation of Cadence NC-Verilog in run_example correctly calls the 32-bit tools and the 32-bit armBST, resulting in a correct simulation.

The default invocation of Mentor ModelSim (QuestaSim) in versions 6.5c to 6.5e calls the 64-bit simulator, but links to the 32-bit armBST, resulting in an error:

     # ** Error: (vsim-3197) Load of "<your path>/example/coresight/logical/armBST/ModelManager/Linux/MM/mti_modelsim_verilog/libmgmm.so" failed: <your path>/example/coresight/logical/armBST/ModelManager/Linux/MM/mti_modelsim_verilog/libmgmm.so: wrong ELF class: ELFCLASS32.
     # ** Error: (vsim-PLI-3002) Failed to load PLI object file "<your path>/example/coresight/logical/armBST/ModelManager/Linux/MM/mti_modelsim_verilog/libmgmm.so".

This can be resolved by appending '_64' to two definitions in the run_example file, like this:

    $the_os   = "Linux_64";
    $rtl_os   = "RH_Linux_x86_64";

From version 6.6 upwards, the default invocation reverts to 32-bit, and runs correctly out of the box. Alternatively, these versions of vsim support command line options of '-32' or '-64', so the 64-bit executable can be called by adjusting the setup_mti section of run_example script to add '-64':

        $SimOptions  = "-64 -pli \${MG_LIB}/$mg_sim/libmgmm.so";

The default invocation of Synopsys VCS is out of date when used with versions of VCS that run on Arm’s RHEL 6.6 compute cluster, resulting in an error:

     Error-[UCLI-121] Runtime Argument Error.
       Argument -s is not supported anymore in this release, kindly move to UCLI.

This can be fixed by modifying '-s' to '-ucli' in the run_vcs section of run_example:

    RunSimulation("echo 'quit' | $SimTool -ucli -i $SimCmdsFile $SimOptions");

However, running this version of the command results in the following error message:

     Error-[UCLI-117] UCLI command without '-debug'
       The design was not compiled with any of the '-debug_pp/-debug/-debug_all'

The cause of this error occurs 10 lines earlier, where SIMCMDS is populated with ‘.’ Instead of 'run.' This can be resolved by changing '.\n' to 'run\n':

    print SIMCMDS "run\n"; # run

If 32-bit binaries of your chosen simulator are not available on your system, or if you prefer to run the 64-bit executable, any of the supported simulators can be run in 64-bit mode by including the '_64' modifications to the 'os' variables above, by adding explicit command line switches to invoke VCS and NC-Verilog, and depending on the version number, ModelSim/QuestaSim, in 64-bit mode. These would be:

  • For VCS, '-full64' in the setup_vcs and run_vcs sections of run_example:

        vcs     +vcs+lic+wait -full64
       RunSimulation("echo 'quit' | $SimTool -ucli -full64 -i $SimCmdsFile $SimOptions");
  • For NC-Verilog, '-64BIT' in the setup_nc section of run_example:

    push @BuildCommands, "ncvlog -64BIT -f ncvlog.args";
    push @BuildCommands, "ncelab -64BIT -mess -f ncelab.args -ACCESS rwc -loadpli1 \${MG_LIB}/cadence_nc_verilog/mm_nc_dynamic.so:mgboot_nc";
    $SimOptions .= " -nbasync -64BIT";
  • For ModelSim / QuestaSim, '-64' in the setup_mti section of run_example, as discussed earlier.

Note:

If you use the part number AT420 (Cortex-M3), instead of AT425 (Cortex-M3 with Embedded Trace Macrocell (ETM)), the example design by default configures the Cortex-M3 to expect the ETM to be present, and consequently the RTL compilation step fails because the CM3ETM module is absent. The example system is the same deliverable for both part numbers, and therefore, needs to be adjusted before use for the AT420 part.

The Trace support section in the Cortex-M3 Integration and Implementation Manual (IIM) indicates you can only include the ETM if you have licensed it. For part number AT420, which does not include the ETM, the `define ARM_CM3_ETM_LICENSE in file ./logical/cm3_lic_defs/Verilog/cm3_lic_defs.v is already commented out. The presence or absence of this `define affects the instance of Cortex-M3 in your own chip design.

Note:

The Key CORTEXM3INTEGRATION integration tasks section of the Cortex-M3 Integration and Implementation Manual incorrectly suggests that "`define ARM_ETM_LICENSE" (sic) is located in a file called CortexM3Integration.v, which is an outdated reference to older versions of Cortex-M3 and does not apply to the current version. However, the example system has an additional copy of the real `define, not mentioned in the IIM, in file ./example/tbench/CM3ExampleConfig.vh that also needs to be commented out so that the example system does not try to include a reference to the ETM.

With this modification, the AT420 version of the example system runs cleanly on all three simulators, with the same version requirements as listed above for AT425. However, the two trace tests CM3_J_CM3Trace1 and CM3_S_CM3Trace1 do not work due to the absence of the Embedded Trace Macrocell.

The Cortex-M3 release also includes a validation environment, described in the RTL Validation chapter of the Cortex-M3 Integration and Implementation Manual. Licensees are typically obliged to run the validation tests and generate a validation report to confirm correct installation and configuration of the RTL. Again, you will likely need to use a newer version of your chosen simulator than was used during development of the product.

After linking to the Verilog directory and extracting the golden binaries tarball as described in the IIM, you need to compile the RTL testbench design for your chosen simulator. As described in Chapter 8 of the Cortex-M3 IIM, a typical sequence would be:

    source dotcshrc
    validation -build -<simulator>     # to compile the RTL design, where <simulator> is mti, nc, or vcs
    validation -gbin -v -<simulator> sc_hellow       # to run the “hello world” test as a sanity check
    val_report cortex-m3.list <switches>     # to set up or run the full validation

Note:

For Mentor ModelSim/QuestaSim, you might need to edit validation.cfg to comment out the two lines where '-novopt' is added to $BuildOpts and $SimOptions. The trailing comments on the relevant lines refer to older versions of ModelSim, but the same requirement applies to newer versions of QuestaSim.

The val_report utility is intended to be able to set up and run simulations of all of the validation tests provided, under a number of different operating environment configurations, and can submit these simulations as batch jobs under the platform LSF workload management environment. However, the use of the '-sub' switch to submit the generated jobs provokes a perl error, because the val_report utility uses a feature of perl that is deprecated, to test for the existence of particular entries in hash structures:

    defined(%hash) is deprecated at /…./validation/tools/bin/linux/val_report line 1775.
            (Maybe you should just omit the defined()?) 

A simple workaround is to generate the batch job scripts by use of the '-s' switch, then to manually submit the scripts to your workload management environment. You can either modify the val_report.cfg file to match the commands and resource requirements needed for you to submit jobs to your own compute environment, or edit this file to change '$UseLsf' to ‘0’, and then submit the job files by separately bsubbing them. With $UseLsf set to 1, the job files will contain full bsub commands for each simulation, whereas with $UseLsf set to 0, the job files will contain just the simulation commands alone.

Editing the file, and assuming you create a suitable alias for bsub with the required resources to run your Cortex-M3 validation simulations (bsub_m3 in the example below), you can submit the jobs as follows:

    val_report cortex-m3.list -s -<simulator>
    foreach i ( jobs/*job )
    bsub_m3 $i &
    end

The val_report command reports that none of the simulations have been run yet, but because of the '-s' switch, it will generate a set of job files in ./jobs/.

The bsub command in the foreach loop batch submits all of these jobs. You can use the bjobs command to track progress of the submitted jobs. Once all of the jobs have completed, you can test the results by running a val_report in the foreground:

    val_report cortex-m3.list

Cortex-M0, Cortex-M0+ and Cortex-M4:

Cortex-M0, Cortex-M0+ and Cortex-M4 use a standardized IK and RunIK command instead of the example system and validation environment provided with Cortex-M3.

For QuestaSim versions 10.7 and higher, the '-novopt' switch is deprecated and causes RunIK to fail. For simple runs of the tests, the '-novopt' can simply be removed from the VSIM invocation in RunIK, although for detailed debug using more than tarmac logging, it may be necessary to consult the QuestaSim User’s Manual for details on how to preserve visibility of the design with vopt.

For Cortex-M4, as referenced in the Configuration options section in the Cortex-M4 Integration and Implementation Manual:

If you are using AT520 (Cortex-M4) instead of AT521 (Cortex-M4 with FPU), that is, you have not licensed the Floating Point Unit (FPU) for Cortex-M4, you must edit the file ./logical/cm4_lic_defs/verilog/cm4_lic_defs.v to comment out the `define of ARM_CM4_FPU_LICENSE. If you do not do this, the RTL compilation step fails because it tries to include FPU header files, irrespective of whether your configuration includes the FPU.

Note:

  • If you have licensed the FPU and included it in your RTL configuration, remember to edit the file integration_kit/validation/tests/Makefile to set COMPILE_FPU = 1 to allow the Arm compiler to use floating-point instructions.

  • If you have not licensed and installed TM925 (CoreSight ETM-M4), that is, you have not licensed the ETM for Cortex-M4, you must edit the file ./logical/cm4_lic_defs/verilog/cm4_lic_defs.v to comment out the `define of ARM_CM4_ETM_LICENSE. If you do not do this, the RTL compilation step will fail as it will try to include the ETM module.

  • If you have not licensed and installed the ETM, you must also adjust the IK so that it does not expect the ETM to be present. You must edit the file integration_kit/logical/cm4ikmcu/verilog/cm4ik_sys.v to change the default value for TRACE_LVL to less than 2, and you must edit the file integration_kit/validation/tests/IKConfig.h to change EXPECTED_TRACE_LVL to match your chosen value of TRACE_LVL.

Workaround

N/A

Example

N/A

Related Information

N/A

Was this page helpful? Yes No