Mentor HLS Bluebook v10.4a: September 2019 技术手册

需积分: 9 114 浏览量更新于2024-07-15 收藏 14.03MB PDF 举报

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

30元优惠券

"Mentor HLS Bluebook是Mentor Graphics公司的一款高级综合工具软件，版本为v10.4a，发布于2019年9月。此文档包含Mentor Graphics的专有信息，主要针对内部业务用途，要求复制者在保留所有版权通知的情况下才能复制部分或全部内容，并需尽力防止未经授权的使用和分布。文档中的信息仅供信息和教学目的，Mentor Graphics有权在不预先通知的情况下更改规格和其他出版物中的信息，读者应始终与Mentor Graphics联系以确认任何变更。 Mentor HLS（High-Level Synthesis）是一种用于硬件设计的工具，它允许工程师使用C、C++或SystemC等高级编程语言来描述硬件功能，然后自动将这些高级代码转换为低级的门级网表，简化了传统的硬件描述语言（如Verilog或VHDL）的设计流程。HLS工具提高了设计效率，使得设计者可以更专注于算法和功能实现，而非底层硬件细节。在v10.4a版本的Mentor HLS Bluebook中，可能涵盖了以下关键知识点： 1. **高级综合原理**：HLS工具如何将高级语言代码转化为硬件描述语言，包括优化策略如循环展开、并行化、流水线设计等。 2. **设计输入**：使用C、C++或SystemC进行设计输入的方法，包括特定的语法和注释，以便指导HLS工具进行硬件映射。 3. **性能估计**：工具如何提供早期的性能指标，如时钟周期、功耗和面积预估，帮助设计师进行设计决策。 4. **接口处理**：如何定义和处理外部接口，包括AXI、AHB、APB等总线协议，以及内存映射I/O。 5. **IP核生成**：HLS工具如何生成可重用的硬件IP核，包括生成的Verilog或VHDL代码结构和封装。 6. **约束管理**：在高级语言中设置时序、资源和功耗约束的方式，以及如何影响综合结果。 7. **验证**：使用仿真和形式验证方法确保HLS产生的硬件设计正确无误。 8. **调试和分析**：HLS工具提供的调试工具和报告，帮助用户理解综合过程和优化结果。 9. **IP复用和共享**：如何利用HLS进行模块复用，以提高设计效率和代码复用性。 10. **质量保证**：Mentor Graphics的产品销售和许可条款，包括对书面协议的依赖，以及对文档中声明的任何事实的解释不应视为保修或承担法律责任。请注意，实际的HLS Bluebook文档可能包含更多详细信息，如具体的操作步骤、案例研究和最佳实践，以帮助用户更好地理解和应用Mentor HLS工具进行硬件设计。为了获取最准确和最新的信息，建议直接参考Mentor Graphics提供的官方文档或联系其技术支持。"

资源详情

资源推荐

Header/Include Files

General C++ Style

which gives it access to the function prototype which is instantiated on line 4.

1 //Include user header file

2 #include "hello.h"

3 int main(){

4 hello();

5 }

PATH: $MGC_HOME/shared/examples/docs/bluebook/c_style/hello_tb.cpp

2.4. Test Benches

The user testbench is a C++ design that is used to test the device under test (DUT) for functional correctness.

In a HLS design environment the C++ testbench is typically used to test both the C++ and the RTL, so it is

important to follow good programming practices. Furthermore it is critical to leverage the C++ testbench to

prove that the DUT matches the original algorithm as code changes are made. There is nothing worse than

re-writing your C++ code to get good synthesis results only to find out that you have broken the

functionality. Be smart, be methodical, and verify your design at every step.

NOTE: If you don't have a C++ testbench, write one. Otherwise you're wasting valuable time.

2.5. Creating a Golden Reference Design

One of the first things a new HLS user discovers is that they have to make code changes to their original

floating or fixed point source code. These code changes are made to improve quality of results (QofR)

and/or pass synthesis. The biggest mistake that users can make is to take their algorithmic C++ code and

start modifying it for synthesis without having created a backup reference to compare the changes against. It

only takes a few code changes to completely break a design.

Consider the design shown in the following example:

1 #include "test.h"

2 void test_design (dType a[2],

3 dType b[2],

4 dType dout[2],

5 bool sel) {

7 if (sel) {

8 dout[0] = a[0] + b[0];

9 dout[1] = a[1] + b[1];

10 } else {

11 dout[0] = a[0] - b[0];

12 dout[1] = a[1] - b[1];

13 }

14 }

PATH: $MGC_HOME/shared/examples/docs/bluebook/c_style/test.cpp

Examination and/or synthesis of the "test" function reveals that the IO accesses on a, b, and dout creates a

performance bottleneck if the interfaces are memory interfaces (The reasons for this performance bottleneck

is discussed in later chapters). Rewriting the code allows for better performance, but rather than modifying

the original code, a new design is created which allows a comparison to the original algorithm.

Note: Always make a copy of the original algorithm to verify against any code changes when possible. It

may not be possible to do a bit-for-bit comparison for some algorithms.

HLS Bluebook v10.4a September 2019 9

Creating a Golden Reference Design

General C++ Style

• Lines 25 through 28 check to see if any errors occurred and return the test status.

Note: Each time a code change is made the testbench should be rerun to check the change against the

original design. Failure to do this may mean hours of debugging to figure out which change broke the

design.

2.5.1. Make Sure You're Fully Testing the DUT

One of the most common, and costly, mistakes users make when testing the DUT is failing to test all

possible conditional branches based on the control inputs into the DUT. This can often lead to discovering

functional differences between the DUT and the golden reference after having made significant changes

required for synthesis. This is illustrated by looking at the testbench and DUT shown in the next example.

The testbench only ever tests the DUT with "sel =1". "sel" is responsible for selecting one of two possible

conditional branches in the DUT. One of the primary reasons for making code changes is when the design

cannot be synthesized, or when timing, performance, or area must be improved. If any of these reasons

require the code to be rewritten, it is likely that it will force the user to modify all branches of any conditions

in the design. The user would be unaware if a functional mistake was introduced in the branch for "sel = 0"

after rewriting the code. The testbench should be rewritten as:

1 #include <iostream>

2 using namespace std;

3 #include "test.h"

4 #include "test_mod.h"

5 int main(){

6 dType a[2] = {10, 20};

7 dType b[2] = {10, 20};

8 dType dout[2];

9 dType dout_mod[2];

10 bool sel = true;

12 for(int j=0;j<2;j++){

13 sel = j;

14 //DUT original

15 test_design(a,b,dout,sel);

17 //DUT modified

18 test_mod(a,b,dout_mod,sel);

20 for(int i=0;i<2;i++){

21 if(dout_mod[i] != dout[i])

22 cout << "ERROR" << endl;

23 else

24 cout << dout[i] << endl;

25 }

26 }

27 }

PATH: $MGC_HOME/shared/examples/docs/bluebook/c_style/test_mod_cover_tb.cpp

Now the DUT is tested for both values of "sel" covering both conditional branches.

2.5.2. Uninitialized Variables

In general a variable should never be read before it is written. Uninitialized variables are treated differently

by different compilers and synthesis tools, often leading to unpredictable results. Many hours can be wasted

HLS Bluebook v10.4a September 2019 11

Bit Accurate Data Types

Chapter 3: Bit Accurate Data Types

Algorithm designers, system architects, and RTL engineers have been using bit-accurate data types for years

to model true hardware behavior. The need for bit-accuracy becomes especially obvious now that designers

are building hardware directly from C++, whose native types only come in widths of 1, 8, 16, 32, etc, bits.

Many existing bit accurate data types used today are “home grown” class libraries that evolved within

companies, and model bit accuracy using traditional shift and mask techniques. Although these "home

grown" types may be faster for simulation, they are typically very slow for synthesis, and can also give

much poorer quality of results than the industry standard bit-accurate data types.

To date there are two industry standard bit accurate data types, the SystemC

and Mentor Graphics

Algorithmic C data types. Although SystemC was developed first, the implementation of its bit-accurate data

types suffers from a number of issues, the biggest being long execution runtimes. Because of this, customer

demand drove Mentor to develop their own bit-accurate types, which have now become the most widely

used data types in high-level synthesis. The Algorithmic C data types not only simulate much faster than the

SystemC types, but give better quality of results for synthesis over "home grown" bit accurate types.

Algorithmic C data types are also consistent between C++ and RTL simulation. So whatever you build in C+

+ matches the true hardware behavior. In light of this, the focus of this chapter is on the use of the

Algorithmic C data types. Furthermore, this chapter only attempts to provide enough of an overview of the

Algorithmic C data types to begin designing in C++. A comprehensive manual is available at:

http://www.mentor.com/products/esl/high_level_synthesis/ac_datatypes

This section discusses the following topics:

• Compilation, Debug, and Simulation Speed

• Integer Data Types

• Fixed Point Data Types

• Operators

• Methods

• Helper/Utility Functions

• Complex Data Types

3.1. Compilation, Debug, and Simulation Speed

In order to compile and use the Algorithmic C data types the header file for either the integer data types,

ac_int, or fixed point data types, ac_fixed, must be included in the C++ source file(s).

#include <ac_int.h>

#include <ac_fixed.h>

It is also critical to achieving the fastest runtimes that the highest level of optimization is set (-O3 in gcc and

/Ox in MS Visual).

g++ -O3 -I <path to Algorithmic C data types> -o hello.exe hello.cpp

When debugging bit accurate code using gdb, ddd, or any of the MS Visual tools it is best to disable

optimizations and turn on verbose warnings. E.g.

HLS Bluebook v10.4a September 2019 13

剩余255页未读，继续阅读

kaoruzhu7

粉丝: 0
资源: 1

Mentor HLS Bluebook v10.4a: September 2019 技术手册

Xilinx HLS Bluebook 超清带书签PDF版

Xilinx_HLS官方手册集合压缩包

hls.js-0.8.7.zip_h5播放器_hls js_hls.js sample_hls.light.js_hls.min

_HLS_FPGA_Accelerator_for_CNN_using_Vivado_HLS_lenet5_hls.zip

RGB_To_HLS.rar_HLS_HLS色彩变换_RGB to H_rgb to hls_rgb转换hls公式

HLS_Matrix.rar

HLS_Keccak.zip_keccak

hls直播协议_rfc8216_hls.pdf

build_nginx_rtmp_hls_ffmpeg.tar

Fast_HLS_color_space_conversion.rar_HLS_conversion

Light_HLS_Top.7z

how_to_accelerate_opencv_applications_using_vivado_hls.pdf

xilinx_com_hls_sigmoid_1_0.zip

gate_test.zip_HLS VIVADO_vivado hls_应用HLS优化封装gate逻辑实现

rtmp_specification_1.0.pdf.7z

avplayer_pdf.pdf

Widevine_DRM_Architecture_Overview.pdf

The_Zynq_Book_Tutorials.pdf

最新资源