Scribd
Upload
257 views5 pages

Lab0 Xcelium

This document presents how to use Xcelium for logic design and verification. It explains the typical front-end development flow and how to structure projects. Students will learn to use text-based and GUI-based verification in Xcelium to debug designs using sample files provided.

Uploaded by

Khánh Nguyễn
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
257 views5 pages

Lab0 Xcelium

This document presents how to use Xcelium for logic design and verification. It explains the typical front-end development flow and how to structure projects. Students will learn to use text-based and GUI-based verification in Xcelium to debug designs using sample files provided.

Uploaded by

Khánh Nguyễn
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Lab 0: Logic Design with XCELIUM

Hai Cao X.

March 13, 2024

Abstract

This document presents the basic usage of Xcelium, Cadence, for logic design and verification. It first
explains the typical flow of Front-End development and then how to manage projects appropriately. With
two ways of verifying a design, students will learn to use both, depending on which phases they’re in
while designing, and also how to use this commercial tool in the SERVER203. In case you meet an error
or have any improvement in this document, please email the TA: [email protected] with the
subject “[COMPARCH203 FEEDBACK]”

1 Objectives
• Understand the design flow of Front-End, both logic design and design verification

• Understand the important of making a directory structure for a design project

• Know how to run Xcelium command using batch files

• Know how to use SimVision to debug designs

1
2 Design Flow for Front-End Development

Figure 1: Design flow of logic design and design verification

2
3 Project Management
To have a neat and organized project, students need to structure their project directory efficiently. The below
tree directory is an example that students must follow.

1 [hai.cao@mars project00]$ tree


2 .
3 |-- 00_src
4 | |-- counter.sv
5 | |-- fadder_4bit.sv
6 | |-- fadder.sv
7 | `-- hadder.sv
8 |-- 01_tb
9 | |-- counter_tb.sv
10 | |-- fadder_4bit_tb.sv
11 | |-- fadder_tb.sv
12 | `-- hadder_tb.sv
13 |-- 10_sim
14 | |-- checksyntax.submit
15 | |-- counter.f
16 | |-- counter.submit
17 | |-- fadder_4bit.f
18 | |-- fadder_4bit.submit
19 | |-- fadder.f
20 | |-- fadder.submit
21 | |-- hadder.f
22 | `-- hadder.submit
23 |-- 20_syn
24 `-- 99_doc

1. All source code must be put into 00_src

2. Each testbench for each source code file must have the same name with suffix _tb

3. All testbench files must be placed in 01_tb

4. All simulation-related files, such as filelist and submit files, are in 10_sim

5. In 10_sim, students will run all their simulation tasks to avoid polluting source code and testbench
files

6. Directory 20_syn is to contain all synthesis-related files

7. All documentation of the projects must be placed into 99_doc

There is a sample project called sample-proj in /earth/class/comp/common. Copy that directory to


Documents, go into that and investigate the structure, coding style, and especially how to use Xcelium.

1 cp -rf ~/../common/sample-proj ~/Documents


2 cd ~/Documents/sample-proj

3
4 Text-based Verification
4.1 Half adder
First, investigate the source file hadder.sv and identify two bugs: a functional bug and a syntax bug.

After finishing coding, students need to run a command to check syntax (or lint for both syntax checks and
structural checks) before going to simulation phase. Going to 10_sim and that command is in line 14 of
checksyntax.submit. However, students need to provide a lot of lines before that so they can submit this
command to the server.

1 #!/bin/bash --login
2 #SBATCH --job-name=checksyntax
3 #SBATCH --account=hai.cao
4 #SBATCH --ntasks=1
5 #SBATCH --nodes=1
6 #SBATCH --cpus-per-task=1
7 #SBATCH --time=00:10:00
8 #SBATCH --mem-per-cpu=1G
9 #SBATCH --partition=phobos
10 #SBATCH --out=checksyntax.out
11

12 module load xcelium


13

14 xrun -hal -sv ../00_src/hadder.sv

job-name the name of this file, students should name it after the task they want to do

account the username

time the expected time this job will finish. Remember, your job will be prioritized to be executed if it uses less
time than others.

mem-per-cpu the RAM/memory this job needs. You will know how much to use after several run.

partition the compute to be used for running this job

out the output file

But, students need to invoke or load the tool first, so add module load xcelium before the main
command.

The last command is for lint checking the SystemVerilog file ../00_src/hadder.sv. Remember that
you’re in 10_sim

To submit this job to the server, run “sbatch checksyntax.submit”

Investigate the output file in the same directory and fix the syntax bug. Then, open the file hadder_tb.sv
to learn how to write testbench and compare what are the differences between checksyntax.submit and
hadder.sv.

Hint: -f hadder.f will take all files in hadder.f, so you don’t need to list a lot files in a single command.

Now that submit hadder.submit and enjoy the functional bug that causes the simulation failed. There are
some useful command to track jobs: sacct and squeue. Please try these two and discover yourselves.

4
The functional bug is really simple. Go back to hadder.sv, fix that bug and re-run the job until it shows
“TEST PASSED”.

4.2 Full adder and more


Still, other source code and sample files are easy to do reserve-engineering, feel free to read, submit, and
modify to learn.

5 GUI-based Verification
Xcelium provides a tool called SimVision that helps users debug with wide-range of features: wavefore,
source browser, etc. As in the last section, students learn how to submit jobs to get text-based results. Even
though that is fast, but occasionally, they still require a more visual result to debug.

First, unlike the above example that students list all parameters in a file to ask the server doing their jobs,
they now will access to the compute node and only run Xcelium command (xrun). To access the compute
node, say phobos, run:

1 salloc --x11 --partition=phobos --mem-per-cpu=1G --time=0-1:00:00


2 srun --pty bash

time the expected time this job will finish. Remember, your job will be prioritized to be executed if it uses less
time than others.

mem-per-cpu the RAM/memory this job needs. You will know how much to use after several run.

partition the compute to be used for running this job

The first one is to ask the server allocating a slot with those familiar parameters like the submit file
above

The second command is to access to the compute node. Notice the host name after @ change when you
run this command.

When in the compute node, students need to load the tool first:

1 module load xcelium

And then, if run the command in the directory 10_sim

1 xrun -sv ../01_tb/hadder_tb.sv -f hadder.sv

This, however, just prints the text result like in the previous section. In order to invoke the SimVision, use
this command instead:

1 xrun -gui -access +rwc -sv ../01_tb/hadder_tb.sv -f hadder.sv

Now, when the SimVision windows are all open, feel free to explore this tool yourselves using the sample
files.

You might also like