Targets

Let’s look at a slightly larger example project that illustrates some more of the Sigasi Project concepts:

{
  "name": "MyProject",
  "targets": {
    "rtl": {
      "environment": {
        "VARIABLE_A": "value",
        "VARIABLE_B": "${VARIABLE_A}"
      },
      "command": ["vcs -f ip/list.f", "vcs -f src/list.f"],
      "ignoreReturnCode": false
    },
    "tb": {
      "dependencies": ["rtl", { "UVM": "1.2" }],
      "libraryMapping": {
        "testbench/src": "testbench"
      },
      "ignore": ["**/sim/*"]
    }
  }
}

Again, the JSON contains the name of the project and targets. The targets are somewhat more complicated here, though. The first target is called rtl and describes how Sigasi should interpret the RTL code of the project. Instead of a library mapping, it configures two commands invoking a simulator: vcs -f ip/list.f and vcs -f src/list.f. In what are called Scripted targets, Sigasi figures out the structure of your project by reusing the existing project’s build system. This target also defines custom environment variables that might be used in the commands, and continues executing commands even if the return code isn’t 0.

The second target is called tb. You can find a manually defined library mapping in its definition, which makes it a Manual target. The files in the testbench/src folder and its subfolders are all assigned to the testbench library, except files with a path matching **/sim/*.

Note that the tb target does not stand on its own. It’s a UVM testbench for the RTL code in the project, so its source code depends on the rtl target and the UVM 1.2 library shipped with Sigasi. You can add Dependencies on other targets in the same project, targets in another project, and libraries from the Library Database.

To conclude:

• Use Scripted targets if you already have a build configuration that you can reuse

• Use Manual targets if you want full manual control or can reuse a lot of IP.