Verilator使用指南：从安装到高级功能

fpga

需积分: 10 143 浏览量更新于2024-07-09 收藏 640KB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

"Verilator_doc.pdf 是一份关于FPGA工具Verilator的文档，由Wilson Snyder在2021年4月26日发布。文档涵盖了从入门到高级使用的多个方面，包括Verilator的安装、使用方法、连接Verilated模型以及模拟Verilated模型时的性能优化和调试工具等。" Verilator是一款开源的硬件描述语言(HDL)仿真器，它能够将Verilog代码转换为C++或SystemC代码，以便在软件环境中快速进行FPGA设计的验证和模拟。以下是文档中的主要知识点： 1. 概述：Verilator提供了一个高效的方法来验证Verilog模块，使得开发者可以在软件环境中模拟硬件行为，而无需专门的硬件仿真器。 2. 例子：文档提供了不同类型的示例，包括C++执行示例和SystemC执行示例，帮助用户理解如何与Verilated模型交互。 3. 安装：提供了通过包管理器快速安装、使用Git安装以及详细的构建指令，还包括了使用Docker容器进行安装的步骤，便于在隔离的环境中运行Verilator。 4. Verilating：这部分讲解了如何使用Verilator生成C++或SystemC代码，支持层次化验证、跨平台编译、多线程以及与GNUMake和CMake的集成。 5. 连接到Verilated模型：介绍了如何用C++和SystemC与Verilated模型接口，以及直接编程接口（DPI）和Veriﬁcation Procedural Interface (VPI)的使用，VPI允许与外部程序库进行交互。 6. 模拟（Verilated-Model Runtime）：讨论了在模拟过程中如何进行基准测试、优化、覆盖率分析、代码 profiling 和线程 profiling。同时，还提到了保存/恢复状态的功能，方便中断和恢复模拟。 7. 贡献和报告错误：文档鼓励用户参与Verilator的开发和改进，并提供了公告和错误报告的途径。 Verilator的这些特性使其成为FPGA设计验证的重要工具，它简化了硬件验证过程，提高了开发效率，同时也为开发者提供了丰富的调试和分析手段。

资源详情

资源推荐

CHAPTER

FOUR

VERILATING

Verilator may be used in ﬁve major ways:

• With the --cc or --sc options, Verilator will translate the design into C++ or SystemC code respectively. See

C++ and SystemC Generation.

• With the --lint-only option, Verilator will lint the design to check for warnings but will not typically create

any output ﬁles.

• With the --xml-only option, Verilator will create XML output that may be used to feed into other user-

designed tools. See docs/xml.rst in the distribution.

• With the -E option, Verilator will preprocess the code according to IEEE preprocessing rules, and write the

output to standard out. This is useful to feed other tools, and to debug how “

deﬁne” statements are expanded.

4.1 C++ and SystemC Generation

Verilator will translate a SystemVerilog design into C++ with the --cc option, or into SystemC with the --sc option.

When using these options:

1. Verilator reads the input Verilog code, determines all “top modules” that is modules or programs that are not

used as instances under other cells. If --top-module is used, then that determines the top module and all

other top modules are removed, otherwise a MULTITOP warning is given.

2. Verilator writes the C++/SystemC code to output ﬁles into the --Mdir option-speciﬁed directory, or defaults

to “obj_dir”. The preﬁx is set with --prefix, or defaults to the name of the top module.

3. If --exe is used, Verilator creates makeﬁles to generate a simulation executable, otherwise it creates makeﬁles

to generate an archive (.a) containing the objects.

4. If --build option was used, it calls GNU Make or CMake to build the model.

Once a model is built it is then typically run, see Simulating (Verilated-Model Runtime).

Verilator, Release 4.202

4.2 Hierarchical Verilation

Large designs may take long (e.g. 10+ minutes) and huge memory (e.g. 100+ GB) to Verilate. In hierarchical mode,

the user manually selects some large lower-level hierarchy blocks to separate from the larger design. For example a

core may be the hierarchy block, and separated out of a multi-core SoC.

Verilator is run in hierarchical mode on the whole SoC. Verilator will make two models, one for the CPU hierarchy

block, and one for the SoC. The Verialted code for the SoC will automatically call the CPU Verilated model.

The current hierarchical Verilation is based on protect-lib. Each hierarchy block is Verilated to a protect-lib. User

modules of the hierarchy blocks will see a tiny wrapper generated by protect-lib instead of the actual design.

4.2.1 Usage

Users need to mark one or more moderate size module as hierarchy block(s). There are two ways to mark a module:

• Write /

verilator&32;hier_block

/ metacomment in HDL code.

• Add a hier_block line in a the Conﬁguration Files.

Then pass the --hierarchical option to Verilator

Compilation is the same as when not using hierarchical mode.

make -C obj_dir -f Vtop_module_name.mk

4.2.2 Limitations

Hierarchy blocks have some limitations including:

• The hierarchy block cannot be accessed using dot (.) from upper module(s) or other hierarchy blocks.

• Signals in the block cannot be traced.

• Modport cannot be used at the hierarchical block boundary.

• The simulation speed is likely to not be as fast as ﬂat Verilation, in which all modules are globally scheduled.

• Generated clocks may not work correctly if they are generated in the hierarchical model and pass up into another

hierarchical model or the top module.

But, the following usage is supported:

• Nested hierarchy blocks. A hierarchy block may instantiate other hierarchy blocks.

• Parameterized hierarchy block. Parameters of a hierarchy block can be overridden using #(.

param_name(value)) construct.

4.2. Hierarchical Verilation 14

Verilator, Release 4.202

4.2.3 Overlapping Verilation and Compilation

Verilator needs to run 2 + N times in hierarchical Verilation, where N is the number of hierarchy blocks. One of the

two is for the top module which refers wrappers of all other hierarchy blocks. The second one of the two is the initial

run that searches modules marked with /

verilator&32;hier_block

/ metacomment and creates a plan and

write in prefix_hier.mk. This initial run internally invokes other N + 1 runs, so you don’t have to care about

these N + 1 times of run. The additional N is the Verilator run for each hierarchical block.

If :-j {jobs} option is speciﬁed, Verilation for hierarchy blocks runs in parallel.

If --build option is speciﬁed, C++ compilation also runs as soon as a hierarchy block is Verilated. C++ compilation

and Verilation for other hierarchy blocks run simultaneously.

4.3 Cross Compilation

Verilator supports cross-compiling Verilated code. This is generally used to run Verilator on a Linux system and

produce C++ code that is then compiled on Windows.

Cross compilation involves up to three different OSes. The build system is where you conﬁgured and compiled

Verilator, the host system where you run Verilator, and the target system where you compile the Verilated code and

run the simulation.

Currently, Verilator requires the build and host system type to be the same, though the target system type may be

different. To support this, ./configure and make Verilator on the build system. Then, run Verilator on the host

system. Finally, the output of Verilator may be compiled on the different target system.

To support this, none of the ﬁles that Verilator produces will reference any conﬁgure generated build-system speciﬁc

ﬁles, such as config.h (which is renamed in Verilator to config_build.h to reduce confusion.) The disad-

vantage of this approach is that include/verilatedos.h must self-detect the requirements of the target system,

rather than using conﬁgure.

The target system may also require edits to the Makeﬁles, the simple Makeﬁles produced by Verilator presume the

target system is the same type as the build system.

4.4 Multithreading

Verilator supports multithreaded simulation models.

With --no-threads, the default, the model is not thread safe, and any use of more than one thread calling into

one or even different Verilated models may result in unpredictable behavior. This gives the highest single thread

performance.

With --threads 1, the generated model is single threaded, however the support libraries are multithread safe. This

allows different instantiations of model(s) to potentially each be run under a different thread. All threading is the

responsibility of the user’s C++ testbench.

With --threads {N}, where N is at least 2, the generated model will be designed to run in parallel on N threads.

The thread calling eval() provides one of those threads, and the generated model will create and manage the other N-1

threads. It’s the client’s responsibility not to oversubscribe the available CPU cores. Under CPU oversubscription, the

Verilated model should not livelock nor deadlock, however, you can expect performance to be far worse than it would

be with proper ratio of threads and CPU cores.

The remainder of this section describe behavior with --threads 1 or --threads {N} (not --no-threads).

VL_THREADED is deﬁned in the C++ code when compiling a threaded Verilated module, causing the Verilated support

classes become threadsafe.

4.3. Cross Compilation 15

Verilator, Release 4.202

The thread used for constructing a model must be the same thread that calls eval() into the model, this is called

the “eval thread”. The thread used to perform certain global operations such as saving and tracing must be done by a

“main thread”. In most cases the eval thread and main thread are the same thread (i.e. the user’s top C++ testbench

runs on a single thread), but this is not required.

The --trace-threads options can be used to produce trace dumps using multiple threads. If

--trace-threads is set without --threads, then --trace-threads will imply --threads 1, i.e.: the

support libraries will be thread safe.

With --trace-threads 0, trace dumps are produced on the main thread. This again gives the highest single

thread performance.

With --trace-threads {N}, where N is at least 1, N additional threads will be created and managed by the trace

ﬁles (e.g.: VerilatedVcdC or VerilatedFstC), to generate the trace dump. The main thread will be released to proceed

with execution as soon as possible, though some blocking of the main thread is still necessary while capturing the

trace. Different trace formats can utilize a various number of threads. See the --trace-threads option.

When running a multithreaded model, the default Linux task scheduler often works against the model, by assuming

threads are short lived, and thus often schedules threads using multiple hyperthreads within the same physical core.

For best performance use the numactl program to (when the threading count ﬁts) select unique physical cores on the

same socket. The same applies for --trace-threads as well.

As an example, if a model was Verilated with --threads 4, we consult:

egrep 'processor|physical id|core id' /proc/cpuinfo

To select cores 0, 1, 2, and 3 that are all located on the same socket (0) but different physical cores. (Also useful is

numactl --hardware, or lscpu but those doesn’t show Hyperthreading cores.) Then we execute:

numactl -m 0 -C 0,1,2,3 -- verilated_executable_name

This will limit memory to socket 0, and threads to cores 0, 1, 2, 3, (presumably on socket 0) optimizing performance.

Of course this must be adjusted if you want another simulator using e.g. socket 1, or if you Verilated with a different

number of threads. To see what CPUs are actually used, use --prof-threads.

4.4.1 Multithreaded Verilog and Library Support

$display/$stop/$ﬁnish are delayed until the end of an eval() call in order to maintain ordering between threads. This

may result in additional tasks completing after the $stop or $ﬁnish.

If using --coverage, the coverage routines are fully thread safe.

If using the DPI, Verilator assumes pure DPI imports are thread safe, balancing performance versus safety. See

--threads-dpi.

If using --savable, the save/restore classes are not multithreaded and must be called only by the eval thread.

If using --sc, the SystemC kernel is not thread safe, therefore the eval thread and main thread must be the same.

If using --trace, the tracing classes must be constructed and called from the main thread.

If using --vpi, since SystemVerilog VPI was not architected by IEEE to be multithreaded, Verilator requires all VPI

calls are only made from the main thread.

4.4. Multithreading 16

剩余183页未读，继续阅读

haitaox

粉丝: 7
资源: 14

Verilator使用指南：从安装到高级功能

verilator-doc.pdf 关于verilator的使用文档，全English

ethercat_doc.zh-CN_纯中文.pdf

aes_doc.pdf

asio_doc.pdf

109759944_Prepare.NetControls_DOC_en.pdf

FastAPI_EN_DOC.pdf

109748892_OPC_UA_ClientLibrary_DOC_V10_en.pdf

P_DOC_RIOM_006E_V01_STRATON.pdf

中学寒假期间计划_0.doc.pdf

氧气同步测考试题_0.doc.pdf

专题12.2有机合成材料带解析_0.doc.pdf

八年级语文考试题含答案_0.doc.pdf

学生会副主席的竞选稿_1.doc.pdf

学生会副主席的竞选稿_2.doc.pdf

七年级语文考试卷含答案_0.doc.pdf

初中化学哈尔滨市初中升学考试_1.doc.pdf

初中化学级化学考试题及答案_1.doc.pdf

初中化学沙洋县上学期期末考试_0.doc.pdf

主题二物质构成的奥秘及答案_0.doc.pdf

最新资源