Aldec Riviera PRO 2014

Henderson, NV – July 12, 2016 – Aldec, Inc., today announced the latest release of its Advanced Verification Platform, Riviera-PRO™ 2016.06. Riviera-PRO is a tightly integrated solution for functional verification of complex System-on-Chip (SoC), ASIC and FPGA designs. The new release of Riviera-PRO offers enhanced support for Metric-Driven Verification, significant performance improvements in Constrained Random Verification (CRV), as well as new debugging features designed to increase verification productivity.“Metric-Driven Verification has become a significant methodology for increasing the overall verification coverage,” said Radek Nawrot, Riviera-PRO Product Manager. “It requires the right tools and features to enable a simple and transparent way to carry out the complicated process of verification. Riviera-PRO 2016.06 new features include Finite State Machine (FSM) Coverage, Design Units Viewer, Datasets Window and Covergroup Viewer.”Riviera-PRO 2016.06 offers up to 20% speed up in simulation of designs using XilinxCoreLib simulation libraries, SystemC testbench and SystemVerilog constrained random stimulus enabling users to run more regressions, therefore, improving the overall quality of verification.Along with introducing the official support for 4K resolution monitors, Riviera-PRO 2016.06 also introduces a new debugging tool, The Contributors, which allows users to easily list the signals that have an influence on the tested part of a design.AvailabilityThe 2016.06 release of Riviera-PRO also includes numerous new features, enhancements, and performance optimizations. For additional information, tutorials, free evaluation download and What’s New Presentation, visit AldecEstablished in 1984, Aldec is an industry leader in Electronic Design Verification and offers a patented technology suite including: RTL Design, RTL Simulators, Hardware-Assisted Verification, SoC and ASIC Prototyping, Design Rule Checking, CDC Verification, IP Cores, Requirements Lifecycle Management, DO-254 Functional Verification and Military/Aerospace solutions. www.aldec.comAldec is a registered trademark of Aldec, Inc. All other trademarks or registered trademarks are the property of their respective owners.Media Contact:Aldec, Inc. Christina Toole, Corporate Marketing Manager+ (702) 990-4400 [email protected]

We can mention:Amazon ECS, Amazon EKS, AWS Fargate AWS services for running docker containers used by GitLab to provide autoscaling features of runners.Amazon ECR A private container repository in the cloud. May be applied for storing images used by CI/CD pipelines.Azure Container Instances Fully managed container service in the Azure cloud.Google Kubernetes Engine (GKE) Cluster management and container orchestration in the Google Cloud.The next popular use case is experimenting with new technologies. Applications in docker imagesare delivered with all dependencies. A perfect example may be ourGitLab demodemonstrating fully functional CI/CD workflow for EDA projects on just two dockercontainers (GitLab instance and GitLab runner).Extending Riviera-PRO image with additional softwareRiviera-PRO Dockerfiles and docker images for selected Linux distributions can be requestedfrom the Aldec's support team.The distributed images usually do not contain any other software beside the one for which they were built.It is motivated by the need of reducing its size. Using such images in the CI/CD platform almost alwaysrequires to add additional software to them, often very common tools like perl or make.Extending the Riviera-PRO image will be shown on the example of adding the RISC-V GNU CompilerToolchain to it.Docker builds an image by reading and executing instructions from the file namedDockerfile.The following steps need to be executed to create Riviera-PRO image containing simplemodifications such as defining environment variable for the license server:Create a file named Dockerfile.Append the following code to it:FROM aldec/riviera-pro:latestENV [email protected] the following command inside the directory with Dockerfile:docker build -t aldec/riviera-pro:my_modified_image .The FROM instruction starts a new build stage and specifies the base docker image. TheENV instruction, in turn, sets a permanent environment variable in the image. It willpersist even restarting the container or changing the user. The docker build commandstarts the building process and the -t switch allows setting a tag for a newly createdimage. The

Example uses the Riviera-PRO image, mounts the current working directory (CWD) inthe Docker container, sets it as the current working directory inside the container and runsthe default image command (bash in this case). The container starts in an interactive modeand the user can execute the commands:The docker run command allows the user to override the default command and execute any program fromthe image. It is useful when the container is used in a makefile or shell script. Consider the situationwhen we want to run the run_tests.do macro from the host file system. The following command can be usedto achieve this:docker run \ -it \ --rm \ -u $(id -u):$(id -g) \ -w $PWD \ -v $PWD:$PWD \ aldec/rivierapro:latest \ vsimsa -do run_tests.doThere are additional arguments in comparison with the previous example:-u $(id -u):$(id -g)By default, Docker containers run as the root user. It may be problematic as all the filescreated by containers on the mounted host volumes (such as libraries, logs, coverage reports,etc.) will be owned by the root. Using this argument prevents this issue since the containerUID/GID are overridden by the values of the current host user.--rmAutomatically removes the container on exit. Useful when the docker run command isused in a shell script or makefile, as usually there is no need to keep the containersafter the script completion.vsimsa -do run_tests.doOverwrites the default container command. In this example it is an execution of the *.doscript in the Riviera-PRO CLI.Although running a GUI application from the docker container is not a recommended use case, it is possiblewith the following command:docker run --net=host \ -e DISPLAY \ -e [email protected] \ -v "$HOME/.Xauthority:/root/.Xauthority:rw" \ -w $PWD \ -v $PWD:$PWD \ aldec/rivierapro:latest \ rivierawhere:--net=hostConnects a container network to the host.-e DISPLAYSets the DISPLAY environment variable in the container. If there is no assignment then

Apt-get install -y --no-install-recommends \ make \ perl \ python3 \ && rm -rf /var/lib/apt/lists/*Then just copy the toolchain from the build image:COPY --from=toolchain-build $RISCV $RISCVThat's it. The final image will contain only the RISC-V toolchain without unnecessary source code,compilers, or build dependencies.The image build process can be started by executing the command below:docker build -t aldec/riviera-pro:demo .Note that the compilation toolchain from source code may take several hours. Using the same tag as in theimage from the GitLab demo project allows the user to re-run jobs and see how the toolchain is automatically used by the makefile:Creating and running docker containerBesides using containers in CI/CD platforms or in Kubernetes clusters, there is a possibilityto run them manually by the docker run command. Typical arguments to run the container fromthe image created in the previous section may look as follows:docker run -i -t \ -e [email protected] \ -w $PWD \ -v $PWD:$PWD \ aldec/riviera-pro:latestwhere:-i / --interactiveConnects the STDIN of the command to the STDIN of the container.-t / --ttyAllocates a pseudo-TTY. Together with the -i switch, allows the user to handle the Linux terminal in the proper way.-e / --envSets an environment variable, may occur multiple times. May be used, for example, to set up the license server address.-v / --volumeMounts a volume, creates an entity resembling a link between the location on the host file system andthe container. May be specified multiple times. The path before the colon is from the host and the valueafter the colon specifies the path in the container. In the above example, both paths are identical andpoint to the directory where the docker run command was executed.-w / --workdirSets the working directory inside the container.aldec/riviera-pro:latestA positional argument that specifies the name and tag of an image from which the container will be created.The above

Continuous Integration (CI) / Continuous Development (CD) tools such as GitLab provide post-processing features for code coverage results. For example, with the help of GitLab CI/CD, you can collect the test coverage information of your favorite testing or coverage-analysis tool and visualize them inside the file diff view of your merge requests (MRs). This will allow you to see which lines are covered by tests, and which lines still require coverage before the MR is merged. GitLab requires Cobertura format as input to be able to generate code coverage analysis reports.Cobertura report is an .xml file that contains information about the percentage of codes covered by test cases. It helps us find the parts of code that lacks the test coverage. This format was originally developed for Java, but most coverage analysis frameworks for other languages have plugins to add support for it, like:simplecov-cobertura (Ruby)gocover-cobertura (Golang)Other coverage analysis frameworks support the format out of the box, for example:Istanbul (JavaScript)Coverage.py (Python)Riviera-PRO generates the ACDB file which stands for "Aldec Code Coverage Data Base". So, Riviera-PRO users need to convert the ACDB report to Cobertura xml format to be able to utilize GitLab's visual coverage analysis feature. We have prepared a Python script to convert ACDB to Cobertura. This app note is prepared to provide more information on how to convert ACDB to Cobertura format.How to convert ACDB into Cobertura XMLTo run this app note, you will need to create a new project in GitLab followed by a gitlab.ci.yml file. We have covered how to create a project using GitLab and Riviera-PRO in another app note that can be found here. GitLab uses CI/CD's artifacts reports feature to collect the coverage information. You can specify one or more coverage report to collect, including wildcard paths. This change should be applied into the .yml file. For the coverage analysis to work, you have to provide a properly formatted Cobertura XML report to artifacts:reports:cobertura. Below you can find the the .yml file content for this project.stages: #List of stages for jobs, and their order of execution -buildbuild-job: # This job runs in the build stage, which runs first. stage: build tags: - ci artifacts: reports: cobertura: cobertura.xml script: - echo "Compiling the code..." - vsim -c -do sr c/runme_verilog.do - python3 ucdb2cobertura.py -i ucdb.xml -o cobertura.xml - echo "Compile complete."The "vsim" command is called using the host machine shell environment to run "runme_verilog.do" file.