Intel hls

Intel hls DEFAULT

High-level synthesis

creation of hardware designs from software code

High-level synthesis (HLS), sometimes referred to as C synthesis, electronic system-level (ESL) synthesis, algorithmic synthesis, or behavioral synthesis, is an automated design process that takes an abstract behavioral specification of a digital system and find a register-transfer level structure that realizes the given behavior.[1][2]

Synthesis begins with a high-level specification of the problem, where behavior is generally decoupled from low-level circuit mechanics such as clock-level timing. Early HLS explored a variety of input specification languages,[3] although recent research and commercial applications generally accept synthesizable subsets of ANSI C/C++/SystemC/MATLAB. The code is analyzed, architecturally constrained, and scheduled to transcompile into a register-transfer level (RTL) design in a hardware description language (HDL), which is in turn commonly synthesized to the gate level by the use of a logic synthesis tool.

The goal of HLS is to let hardware designers efficiently build and verify hardware, by giving them better control over optimization of their design architecture, and through the nature of allowing the designer to describe the design at a higher level of abstraction while the tool does the RTL implementation. Verification of the RTL is an important part of the process.[4]

Hardware can be designed at varying levels of abstraction. The commonly used levels of abstraction are gate level, register-transfer level (RTL), and algorithmic level.

While logic synthesis uses an RTL description of the design, high-level synthesis works at a higher level of abstraction, starting with an algorithmic description in a high-level language such as SystemC and ANSI C/C++. The designer typically develops the module functionality and the interconnect protocol. The high-level synthesis tools handle the micro-architecture and transform untimed or partially timed functional code into fully timed RTL implementations, automatically creating cycle-by-cycle detail for hardware implementation.[5] The (RTL) implementations are then used directly in a conventional logic synthesis flow to create a gate-level implementation.

History[edit]

Early academic work extracted scheduling, allocation, and binding as the basic steps for high-level-synthesis. Scheduling partitions the algorithm in control steps that are used to define the states in the finite-state machine. Each control step contains one small section of the algorithm that can be performed in a single clock cycle in the hardware. Allocation and binding maps the instructions and variables to the hardware components, multiplexers, registers and wires of the data path.

First generation behavioral synthesis was introduced by Synopsys in 1994 as Behavioral Compiler[6] and used Verilog or VHDL as input languages. The abstraction level used was partially timed (clocked) processes. Tools based on behavioral Verilog or VHDL were not widely adopted in part because neither languages nor the partially timed abstraction were well suited to modeling behavior at a high level. 10 years later, in early 2004, Synopsys end-of-lifed Behavioral Compiler.[7]

In 1998, Forte Design Systems introduced its Cynthesizer tool which used SystemC as an entry language instead of Verilog or VHDL. Cynthesizer was adopted by many Japanese companies in 2000 as Japan had a very mature SystemC user community. The first high-level synthesis tapeout was achieved in 2001 by Sony using Cynthesizer. Adoption in the United States started in earnest in 2008.[8]

Source input[edit]

The most common source inputs for high-level synthesis are based on standard languages such as ANSI C/C++, SystemC and MATLAB.

High-level synthesis typically also includes a bit-accurate executable specification as input, since to derive an efficient hardware implementation, additional information is needed on what is an acceptable Mean-Square Error or Bit-Error Rate etc. For example, if the designer starts with an FIR filter written using the "double" floating type, before he or she can derive an efficient hardware implementation, they need to perform numerical refinement to arrive at a fixed-point implementation. The refinement requires additional information on the level of quantization noise that can be tolerated, the valid input ranges etc. This bit-accurate specification makes the high level synthesis source specification functionally complete.[9] Normally the tools infer from the high level code a Finite State Machine and a Datapath that implement arithmetic operations.

Process stages[edit]

The high-level synthesis process consists of a number of activities. Various high-level synthesis tools perform these activities in different orders using different algorithms. Some high-level synthesis tools combine some of these activities or perform them iteratively to converge on the desired solution.[10]

  • Lexical processing
  • Algorithm optimization
  • Control/Dataflow analysis
  • Library processing
  • Resource allocation
  • Scheduling
  • Functional unit binding
  • Register binding
  • Output processing
  • Input Rebundling

Functionality[edit]

In general, an algorithm can be performed over many clock cycles with few hardware resources, or over fewer clock cycles using a larger number of ALUs, registers and memories. Correspondingly, from one algorithmic description, a variety of hardware microarchitectures can be generated by an HLS compiler according to the directives given to the tool. This is the same trade off of execution speed for hardware complexity as seen when a given program is run on conventional processors of differing performance, yet all running at roughly the same clock frequency.

Architectural constraints[edit]

Synthesis constraints for the architecture can automatically be applied based on the design analysis.[4] These constraints can be broken into

  • Hierarchy
  • Interface
  • Memory
  • Loop
  • Low-level timing constraints
  • Iteration

Interface synthesis[edit]

Interface Synthesis refers to the ability to accept pure C/C++ description as its input, then use automated interface synthesis technology to control the timing and communications protocol on the design interface. This enables interface analysis and exploration of a full range of hardware interface options such as streaming, single- or dual-port RAM plus various handshaking mechanisms. With interface synthesis the designer does not embed interface protocols in the source description. Examples might be: direct connection, one line, 2 line handshake, FIFO.[11]

Vendors[edit]

Data reported on recent Survey[12]

Status Compiler Owner License Input Output Year Domain Test
Bench
FP FixP
In Use Stratus HLS Cadence Design SystemsCommercial C/C++ SystemC RTL 2015 All Yes Yes Yes
AUGHTIMA Lab. Academic C subset VHDL 2012 All Yes No No
eXCiteY Explorations Commercial C VHDL/Verilog 2001 All Yes No Yes
BambuPoliMi Academic C VHDL/Verilog 2012 All Yes Yes No
BluespecBlueSpec Inc. Commercial BSV SystemVerilog 2007 All No No No
QCCCacheQ Systems, Inc.Commercial C/C++/Fortan Host Executable + FPGA Bit file (SystemVerilog is intermediate) 2018 All - multi-core and heterogeneous compute Yes (C++) Yes Yes
CHC Altium Commercial C subset VHDL/Verilog 2008 All No Yes Yes
CoDeveloper Impulse Accelerated Commercial Impulse-C VHDL 2003 Image
Streaming
Yes Yes No
HDL CoderMathWorks Commercial MATLAB, Simulink, Stateflow, Simscape VHDL / Verilog 2003 Control Systems, Signal Processing, Wireless, Radar, Communications, Image and Computer Vision Yes Yes Yes
CyberWorkbench NEC Commercial BDL, SystemC VHDL/Verilog 2011 All Cycle/
Formal
Yes Yes
CatapultMentor
(Siemens business)
Commercial C, C++, SystemC VHDL/Verilog 2004 All Yes Yes Yes
DWARV TU. Delft Academic C subset VHDL 2012 All Yes Yes Yes
GAUTU. Bretagne Academic C/C++ VHDL 2010 DSP Yes No Yes
HastlayerLombiq Technologies Commercial C#/C++/F#...
(.NET)
VHDL 2015 .NET Yes Yes Yes
Instant SoCFPGA Cores Commercial C/C++ VHDL/Verilog 2019 All Yes No No
Intel High Level Synthesis CompilerIntel FPGA (Formerly Altera) Commercial C/C++ Verilog 2017 All Yes Yes Yes
LegUp HLSLegUp Computing Commercial C/C++ Verilog 2015 All Yes Yes Yes
LegUpU. Toronto Academic C Verilog 2010 All Yes Yes No
MaxCompiler Maxeler Commercial MaxJ RTL 2010 DataFlow No Yes No
ROCCCJacquard Comp. Commercial C subset VHDL 2010 Streaming No Yes No
Symphony C Synopsys Commercial C/C++ VHDL/Verilog/
SystemC
2010 All Yes No Yes
VivadoHLS
(formerly AutoPilot
from AutoESL[13])
Xilinx Commercial C/C++/SystemC VHDL/Verilog/
SystemC
2013 All Yes Yes Yes
KiwiU. Cambridge Academic C# Verilog 2008 .NET No Yes Yes
CHiMPS U. Washington Academic C VHDL 2008 All No No No
gcc2verilog U. Korea Academic C Verilog 2011 All No No No
HercuLeSAjax Compilers Commercial C/NAC VHDL 2012 All Yes Yes Yes
ShangU. Illinois Academic C Verilog 2013 All Yes ? ?
Trident Los Alamos NL Academic C subset VHDL 2007 Scientific No Yes No
Aban-
doned
AccelDSP Xilinx Commercial MATLAB VHDL/Verilog 2006 DSP Yes Yes Yes
C2H Altera Commercial C VHDL/Verilog 2006 All No No No
CtoVerilog U. Haifa Academic C Verilog 2008 All No No No
DEFACTO U. South Cailf. Academic C RTL 1999 DSE No No No
Garp U. Berkeley Academic C subset bitstream 2000 Loop No No No
MATCH U. Northwest Academic MATLAB VHDL 2000 Image No No No
Napa-C Sarnoff Corp. Academic C subset VHDL/Verilog 1998 Loop No No No
PipeRench U.Carnegie M. Academic DIL bistream 2000 Stream No No No
SA-C U. Colorado Academic SA-C VHDL 2003 Image No No No
SeaCucumber U. Brigham Y. Academic Java EDIF 2002 All No Yes Yes
SPARK U. Cal. Irvine Academic C VHDL 2003 Control No No No

See also[edit]

References[edit]

  1. ^Coussy, Philippe; Morawiec, Adam, eds. (2008). High-Level Synthesis - Springer. doi:10.1007/978-1-4020-8588-8. ISBN .
  2. ^McFarland, M.C.; Parker, A.C.; Camposano, R. (February 1990). "The high-level synthesis of digital systems". Proceedings of the IEEE. 78 (2): 301–318. doi:10.1109/5.52214. ISSN 1558-2256.
  3. ^IEEE Xplore High-Level Synthesis: Past, Present, and Future DOI 10.1109/MDT.2009.83
  4. ^ ab"The 'why' and 'what' of algorithmic synthesis". EE Times. Retrieved 2016-10-03.
  5. ^"C-Based Rapid Prototyping for Digital Signal Processing"(PDF). UBS University, France. Retrieved 2016-10-03.
  6. ^"Publications and Presentations". Bdti.com. Archived from the original on 2008-04-26. Retrieved 2016-10-03.
  7. ^"Behavioral synthesis crossroad". EE Times. Retrieved 2016-10-03.
  8. ^[1]
  9. ^Multiple Word-Length High-Level Synthesis EURASIP Journal on Embedded Systems
  10. ^"A look inside behavioral synthesis". EE Times. Retrieved 2016-10-03.
  11. ^[2]
  12. ^Nane, R.; Sima, V. M.; Pilato, C.; Choi, J.; Fort, B.; Canis, A.; Chen, Y. T.; Hsiao, H.; Brown, S. (2016). "A Survey and Evaluation of FPGA High-Level Synthesis Tools"(PDF). IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems. 35 (10): 1591–1604. doi:10.1109/TCAD.2015.2513673. hdl:11311/998432. ISSN 0278-0070. S2CID 8749577.
  13. ^"Xilinx buys high-level synthesis EDA vendor". EE Times. 2011-02-05. Archived from the original on 2011-10-17. Retrieved 2016-10-03.
  14. ^"MathWorks – Makers of MATLAB and Simulink". Mathworks.com. Retrieved 2016-10-03.
  15. ^"SystemC based ESL methodologies - SystemC based ESL methodologies". Circuitsutra.com. Retrieved 2016-10-03.
  16. ^John M. at a major ERP & DBMS Corporation (2016-08-29). "QuickPlay: Bringing FPGA Computing to the Masses". Quickplay.io. Retrieved 2016-10-03.
  17. ^[3]
  18. ^"CyberWorkBench: Products". NEC. Retrieved 2016-10-03.
  19. ^[4]
  20. ^[5]
  21. ^"Nikolaos Kavvadias - HercuLeS high-level synthesis tool". Nkavvadias.com. Retrieved 2016-10-03.
  22. ^"Synopsys buys Synfora assets". EE Times. Archived from the original on 2011-04-07. Retrieved 2016-10-03.
  23. ^"The xPilot System". Cadlab.cs.ucla.edu. Retrieved 2016-10-03.
  24. ^"vSyn.ru". vSyn.ru. 2016-06-16. Archived from the original on 2016-06-30. Retrieved 2016-10-03.
  25. ^"Hardware design for all". Synflow. Retrieved 2016-10-03.

Further reading[edit]

  • Michael Fingeroff (2010). High-Level Synthesis Blue Book. Xlibris[self-published source] Corporation. ISBN .
  • Coussy, P.; Gajski, D. D.; Meredith, M.; Takach, A. (2009). "An Introduction to High-Level Synthesis". IEEE Design & Test of Computers. 26 (4): 8–17. doi:10.1109/MDT.2009.69. S2CID 52870966.
  • Ewout S. J. Martens; Georges Gielen (2008). High-level modeling and synthesis of analog integrated systems. Springer. ISBN .
  • Saraju Mohanty; N. Ranganathan; E. Kougianos & P. Patra (2008). Low-Power High-Level Synthesis for Nanoscale CMOS Circuits. Springer. ISBN .
  • Alice C. Parker; Yosef Tirat-Gefen; Suhrid A. Wadekar (2007). "System-Level Design". In Wai-Kai Chen (ed.). The VLSI handbook (2nd ed.). CRC Press. ISBN . chapter 76.
  • Shahrzad Mirkhani; Zainalabedin Navabi (2007). "System Level Design Languages". In Wai-Kai Chen (ed.). The VLSI handbook (2nd ed.). CRC Press. ISBN . chapter 86. covers the use of C/C++, SystemC, TML and even UML
  • Liming Xiu (2007). VLSI circuit design methodology demystified: a conceptual taxonomy. Wiley-IEEE. ISBN .
  • John P. Elliott (1999). Understanding behavioral synthesis: a practical guide to high-level design. Springer. ISBN .
  • Nane, Razvan; Sima, Vlad-Mihai; Pilato, Christian; Choi, Jongsok; Fort, Blair; Canis, Andrew; Chen, Yu Ting; Hsiao, Hsuan; Brown, Stephen; Ferrandi, Fabrizio; Anderson, Jason; Bertels, Koen (2016). "A Survey and Evaluation of FPGA High-Level Synthesis Tools". IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems. 35 (10): 1591–1604. doi:10.1109/TCAD.2015.2513673. hdl:11311/998432. S2CID 8749577.
  • Gupta, Rajesh; Brewer, Forrest (2008). "High-Level Synthesis: A Retrospective". "High-level Synthesis: A Retrospective". Springer. pp. 13–28. doi:10.1007/978-1-4020-8588-8_2. ISBN .

External links[edit]

Sours: https://en.wikipedia.org/wiki/High-level_synthesis

Gidel Announces Developer Tools for Intel HLS

Gidel has announced an application support package for Intel’s HLS compiler. HLS is designed to take “untimed C++ as input and generate production-quality register transfer level (RTL) code that is optimized for Intel Field Programmable Gate Arrays (FPGAs).” The new developer tools, which Gidel says are the first to market for this kind of HLS support, “… produce speed increases of up to 5X over prior FPGA development options.”

According to the press announcement, “Standard HLS does not provide system middleware and board support, but simply accelerates FPGA code development; HLS is intended for traditional FPGA designers. Gidel’s development tools grant software developers easy access to the same level of OpenCL design for FPGA by tailoring the ASP(s), using C++ as the programing language. Developers of all types can now work faster and more efficiently, with the freedom to mix between C++ and HDL as most appropriate to the application.”

Sours: https://www.admin-magazine.com/HPC/News/Gidel-Announces-Developer-Tools-for-Intel-HLS
  1. Imbues synonyms
  2. Supercharged c4 corvette
  3. Fnaf new song
  4. Rgb fan pack
  5. Heroquest tiles

Intel-HLS / BIGstack Public

Intel® Select Solutions for Genomics Analytics is an end-to-end, optimized hardware and software solution for analyzing genomic data. It provides a way to run pre-packaged, optimized workflows, including the Genome Analysis Toolkit* (GATK*) Best Practices workflows from the Broad Institute.

This repo contains a simple smoketest benchmark for HPC clusters ("20k Throughput Run"). The test ensures your HPC system is configured correctly to run whole genome and whole exome samples.

For an overview on how to set up an HPC cluster for running GATK, see the Broad documentation here. An overview of the Intel Solution, including a HW reference design, can be found here.

For detailed, line-by-line instructions on how to configure an HPC system for running genomics workflows, please contact your Intel representative.

Sours: https://github.com/Intel-HLS/BIGstack
Siap utk PS5, Dirancang Tahan Lama: Review Sony BRAVIA XR-55X90J

Genomics Kernel Library (GKL)

Build StatusMaven Central

This repository contains optimized versions of compute kernels used in genomics applications like GATK and HTSJDK. These kernels are optimized to run on Intel Architecture (AVX, AVX2, AVX-512, and multicore) under 64-bit Linux and Mac OSX.

Kernels included:

  • PairHMM
    • AVX and AVX-512 optimized versions of PairHMM used in GATK HaplotypeCaller and MuTect2.
    • OpenMP support for multicore processors.
  • Smith-Waterman
    • AVX2 and AVX-512 optimized versions of Smith-Waterman used in GATK HaplotypeCaller and MuTect2.
  • DEFLATE Compression/Decompression:
    • Performance optimized Level 1 and 2 compression and decompression from Intel's ISA-L library.
    • Performance optimized Level 3 through 9 compression from Intel's Open Source Technology Centerzlib library.

GKL release binaries are built on CentOS 7, to enable running on most Linux distributions (see holy-build-box for a good discription of portability issues).

Requirements

  • Java JDK 8
  • Git >= 2.5
  • CMake >= 2.8.12.2
  • GCC g++ >= 5.3.1
  • GNU patch >= 2.6
  • GNU libtool >= 2.2.6
  • GNU automake >= 1.11.1
  • Yasm >= 1.2.0
  • zlib-devel >= 1.2.7

Setup

Run these commands to setup the build environment on CentOS:

Build and Test

After build requirements are met, clone, and build :

For more details check

All code is licensed under the MIT License, except:

Sours: https://github.com/Intel-HLS/GKL

Hls intel

Intel High Level Synthesis Compiler Pro Edition: Reference Manual

Updated for:
Intel® Quartus® Prime Design Suite 21.3

The Intel® HLS Compiler Pro Edition Reference Manual provides reference information about the features supported by the Intel® HLS Compiler Pro Edition. The Intel® HLS Compiler is sometimes referred to as the i++ compiler, reflecting the name of the compiler command.

In this publication, refers to the location where you installed Intel® Quartus® Prime Design Suite.

The default Intel® Quartus® Prime Design Suite installation location depends on your operating system:
Windows
C:\intelFPGA_pro\21.3
Linux
/home//intelFPGA_pro/21.3

About the Intel® HLS Compiler Pro Edition Documentation Library

Documentation for the Intel® HLS Compiler Pro Edition is split across a few publications. Use the following table to find the publication that contains the Intel® HLS Compiler Pro Edition information that you are looking for:
Title and Description
Release Notes

Provide late-breaking information about the Intel® HLS Compiler.

Link
Getting Started Guide

Get up and running with the Intel® HLS Compiler by learning how to initialize your compiler environment and reviewing the various design examples and tutorials provided with the Intel® HLS Compiler.

Link
User Guide

Provides instructions on synthesizing, verifying, and simulating intellectual property (IP) that you design for Intel FPGA products. Go through the entire development flow of your component from creating your component and testbench up to integrating your component IP into a larger system with the Intel Quartus Prime software.

Link
Reference Manual

Provides reference information about the features supported by the Intel HLS Compiler. Find details on Intel® HLS Compiler command options, header files, pragmas, attributes, macros, declarations, arguments, and template libraries.

Link
Best Practices Guide

Provides techniques and practices that you can apply to improve the FPGA area utilization and performance of your HLS component. Typically, you apply these best practices after you verify the functional correctness of your component.

Link
Quick Reference

Provides a brief summary of Intel HLS Compiler declarations and attributes on a single two-sided page.

Link
Use the Intel® HLS Compiler Pro Edition command options to customize how the compiler performs general functions, customize file linking, or customize compilation.
Command OptionDescription
-h or --helpInstructs the compiler to list all the command options and their descriptions on screen.
-oInstructs the compiler to place its output into the executable and the .prj directory.

If you do not specify the -ooption, the compiler outputs an a.out file for Linux and an a.exe file for Windows. Use the -o command option to specify the name of the compiler output.

Example command:

Invoking this example command creates an hlsoutput executable for Linux and an hlsoutput.exe for Windows in your working directory.

--debug-logInstructs the compiler to generate a log file that contains diagnostic information.

The debug.log file is in the .prj subdirectory within your current working directory.

If your compilation fails, the debug.log file is generated whether you set this option or not.

-vVerbose mode that instructs the compiler to display messages describing the progress of the compilation.

Example command: , where multiplier.cpp is the input file.

--versionInstructs the compiler to display its version information on screen.

Command:

OptionDescription
-cInstructs the compiler to preprocess, parse, and generate object files (.o/.obj) in the current working directory. The linking stage is omitted.

Example command:

Invoking this example command creates a multiplier.o file and sets the name of the .prj directory to multiplier.prj.

When you later link the .o file, the -o option affects only the name of the executable file. The name of the .prj directory remains unchanged from when the directory name was set by i++ -c command invocation.

--componentAllows you to specify a comma-separated list of function names that you want to the compiler to synthesize to RTL.

Example command:

To use this option, your component must be configured with C-linkage using the specification. For example:extern "C" int myComponent(int a, int b)

Using the function attribute is preferred over using the --component command option to indicate functions that you want the compile to RTL.

-D[=]Allows you to pass a macro definition () and its value () to the compiler.

If you do not a specify a value for , its default value will be 1.

-gGenerate debug information (default).
-g0Do not generate debug information.
--gcc-toolchain=

Specifies the path to a GCC installation that you want to use for compilation. This path should be the absolute path to the directory that contains the GCC lib, bin, and include folders.

You should not need to use this if you configured your system as described in the Getting Started Guide.

--hyper-optimized-handshaking=[auto|off]

This option applies to Intel® Agilex™ and Intel® Stratix® 10 devices only.

Use this option to modify the handshaking protocol used in certain areas of your design.

By default, the option is set to .

When you enable this optimization, the compiler adds pipeline registers to the handshaking paths of the stallable nodes. This optimization results in a higher fMAX at the cost of increased area and latency due to the added registers.

Disabling this optimization typically decreases area and latency at the cost of lower fMAX.

Restriction: This option applies only to designs targeting Intel® Agilex™ and Intel® Stratix® 10 devices. If you use this option when you target devices other than Intel® Agilex™ and Intel® Stratix® 10 devices, the compiler exits with an error.
-IAdds a directory () to the end of the include path list.
-march=Instructs the compiler to compile the component to the specified architecture or FPGA family.
The -march compiler option can take one of the following values:
Instructs the compiler to compile the code for an emulator flow.
Instructs the compiler to compile the code for a target FPGA device family.
The value can be any of the following device families:
  • or
  • 1
  • or
  • or
Quotation marks are required only if you specify a FPGA family name specifier that contains spaces
Instructs the compiler to compile the code for a target device. The compiler determines the FPGA device family from the FPGA part number that you specify here.

If you do not specify this option, -march=x86-64 is assumed.

If the parameter value that you specify contains spaces, surround the parameter value in quotation marks.

--quartus-compileCompiles your design with the Intel® Quartus® Prime compiler.

Example command:

When you specify this option, the Intel® Quartus® Prime compiler is run after the RTL is generated. The compiled Intel® Quartus® Prime project is put in the .prj/quartus directory and a summary of the FPGA resource consumption and maximum clock frequency is added to the high level design reports in the .prj/reports directory.

This compilation is intended to estimate the best achievable fMAX for your component. Your component is not expected to cleanly close timing in the reports.

--quartus-seedSpecifies the seed numeric value that is used by Intel® Quartus® Prime project located in the .prj/quartus directory.

This seed value is used by the Intel® Quartus® Prime Fitter for initial placement configuration when optimizing design placement to meet timing requirements (fMAX).

For more information about the Fitter seed, refer to Fitter Initial Placement Seed in the "Fitter Settings Reference" section of Intel® Quartus® Prime Pro Edition User Guide: Design Compilation.

--simulator Specifies the simulator you are using to perform verification.
This command option can take the following values for :
  • modelsim

    Use Siemens* EDA ModelSim* or Questa* for component verification.

  • none

    Disable verification. That is, generate RTL for components without the test bench.

If you do not specify this option, --simulator modelsim is assumed.

Important: The --simulator command option only works in conjunction with the -march command option.

The --simulator none option instructs the HLS compiler to skip the verification flow and generate RTL for the components without generating the corresponding test bench. If you use this option, the high-level design report (report.html) is generated more quickly but you cannot simulate your design. Without data from simulation, the report must omit verification statistics such as component latency.

Example command:

-ffp-contract=fast

Remove intermediate rounding and conversion when possible, except for code blocks fenced by .

To learn more, review the following tutorial: /hls/examples/tutorials/best_practices/floating_point_ops

-ffp-reassoc

Deprecated: This command option is deprecated and will be removed in a later release of the Intel® HLS Compiler. Use the -ffp-reassociate command option instead.
Relax the order of floating point arithmetic operations, except for code blocks fenced by

To learn more, review the following tutorial: /hls/examples/tutorials/best_practices/floating_point_ops

-ffp-reassociateRelax the order of floating point arithmetic operations, except for code blocks fenced by

To learn more, review the following tutorial: /hls/examples/tutorials/best_practices/floating_point_ops

--dazFor data types only, disable subnormal support in native IEEE-754 double-precision floating-point computations.

To learn more, review the following tutorial: /hls/examples/tutorials/best_practices/submnormal_and_rounding

--rounding=

For data types only, control rounding scheme for native IEEE-754 double-precision adders, multipliers, and dividers.

If you do not specify this option, adders and multipliers use IEEE-754 round to nearest, ties to even (RNE) rounding (0.5 ULP) and dividers use faithful rounding (1 ULP).

The --rounding option can take one of the following values:
All adders, multipliers, and dividers use IEEE-754 RNE rounding.

IEEE-754 RNE rounding rounds results to the nearest value. If the number falls midway, it is rounded to the nearest value with an even least-significant digit. This is the default rounding mode defined by IEEE 754-2008 standard.

IEEE-754 RNE rounding has a accuracy of 0.5 ULP.

All adders, multipliers, and dividers use faithful rounding.

Faithful rounding rounds results to either the upper or lower nearest single-precision numbers. Therefore, faithful rounding produces one of two possible values. The choice between the two is not defined.

Faithful rounding has a maximum error of one ULP. Errors are not guaranteed to be evenly distributed.

Faithful rounding mode is not defined by the IEEE-754 standard.

To learn more, review the following tutorial: /hls/examples/tutorials/best_practices/submnormal_and_rounding

--clockOptimizes the RTL for the specified clock frequency or period.

The value must include a unit.

For example: i++ -march="Arria 10" test.cpp --clock 100MHzi++ -march="Arria 10" test.cpp --clock 10ns
--dsp_mode=For supported data types and math operations, controls the hardware implementation of math functions on a global scope.
The compiler tries to implement supported math operations with DSPs.
The compiler tries to implement supported math operations with soft logic using ALMs.
The compiler implements supported math operations based on data type and operation.

This value is the default.

For details about the implementation of math functions in hardware, refer to Math Function Hardware Implementation Summary.

To learn more, refer to the following tutorial: /hls/examples/tutorials/best_practices/control_of_dsp_usage

OptionDescription
-ghdl[=]

Logs signals when running the verification executable to help you debug the generated RTL. After running the executable, the simulator logs waveforms to the a.prj/verification/vsim.wlf file.

Use the optional attribute to specify how many levels of hierarchy are logged. If you do not specify a value for the attribute, all signals are logged.

Use to log only the top-level signals.

For details about the ModelSim* waveform, see Debugging during Verification in Intel® High Level Synthesis Compiler Pro Edition User Guide.

-L

-L

(Linux only) Adds a directory () to the end of the search path for the library files.
-l(Linux only) Specifies the library file (.a) name when linking the object file to the binary.

On Windows, you can list library files (.lib) on the command line without specifying any command options or flags.

--x86-onlyCreates only the testbench executable.

The compiler outputs a file for Linux or a .exe file for Windows. The .prj directory and its contents are not created.

--fpga-onlyCreates only the .prj directory and its contents.

The testbench executable file (/.exe) is not created.

Before you can simulate your hardware from a compilation output that uses this option, you must compile your testbench with the --x86-only option (or as part of a full compilation).

Use libraries to reuse functions created by you or others without needing to know the function implementation details.

To use the functions in a library, you must have the C/C++ header files (.h or .hpp) for the library available. For object libraries, you must also have the object library archive file (.a on Linux systems or .lib on Windows systems) available.

Any object libraries that you use in your component must be built and used by the same version number Intel FPGA high-level design tool. For example, to compile your component with the Intel HLS Compiler Version 21.3, the libraries included in your component must have been created with a version 21.3 Intel FPGA high-level design tool. If you use a library with a different version, you get a version mismatch error when you compile your component.

To include a library in your component:

  1. Review the header files corresponding to the library that you want to include in your component.

    The header file shows you the functions available to call in the library and how to call the functions.

  2. Include the header files in your component code.

    For example,

  3. Compile your component with the Intel® HLS Compiler as follows::
    • For source code (that is, header-only) libraries, there is no additional library file name to specify.

      For example, i++ -march=arria10 MyComponent.cpp

    • For object libraries, ensure that you add the object library archive file name to the i++ command.

      For example, i++ -march=arria10 MyComponent.cpp libprim.a (Linux) or (Windows).

You can compile your testbench code with GCC or Microsoft Visual Studio, but generating RTL and simulation support for your component always requires the Intel® HLS Compiler.
The following table shows which parts of your design you can compile with each compiler:
 GCC/MSVCi++
TestbenchXX
Component (emulation)XX
Component (RTL) X
Restriction: You cannot use GCC and Microsoft Visual Studio to compile code that uses any Intel® HLS Compiler provided header files other than HLS/hls.h. For some arbitrary precision data types, the Intel® HLS Compiler provides reference headers that can be compiled GCC and Microsoft Visual Studio along with the FPGA-optimized headers. For details, see Arbitrary Precision Math Support.

To see what versions of GCC and Microsoft Visual Studio the Intel® HLS Compiler supports, see " Intel® High Level Synthesis Compiler Prerequisites" in Intel® High Level Synthesis Compiler Getting Started Guide.

To use a native compiler (GCC or Microsoft Visual Studio) to compile your Intel® HLS Compiler code, you must run your native compiler from a terminal session where you initialized the environment for the Intel® HLS Compiler. The initialization script chooses the correct native compiler for you system.

GCC

To compile your Intel® HLS Compiler code with GCC:
  1. Initialize your environment with the Intel® HLS Compiler initialization script:/hls/init_hls.sh
  2. Add the path to the Intel® HLS Compiler header files to the g++ command include path with the -l command option.

    The header files are in the /hls/include directory.

  3. Add the path to the HLS emulation library to the linker search path with the -L command option.

    The emulation library is in the /hls/host/linux64/lib directory.

  4. Add the hls_emul library to the linker command (that is, specify as a command option).
  5. Ensure that you specify the -std=c++17 option of the g++ command.
  6. If you want to generate debug symbols, specify the option of the g++ command.
  7. If you are using HLS tasks in a system of tasks ( and ), specify the option of the g++ command.
  8. If you are using arbitrary precision datatypes, include the reference version in your source code instead of the FPGA-optimized version provided with the Intel® HLS Compiler. You can use the macro to control which variant is included. For example, if you are using arbitrary precision integers, you can use the following macro code#ifdef __INTELFPGA_COMPILER__ #include "HLS/ac_int.h" #else #include "ref/ac_int.h" #endif
If you implement these steps, your g++ command resembles the following example command:g++ myFile.cpp -g -I"$(HLS_INSTALL_DIR)/include" -L"$(HLS_INSTALL_DIR)/host/linux64/lib" -lhls_emul -pthread -std=c++17

Microsoft Visual C++

The following instructions were tested with Microsoft Visual Studio 2017 Professional.

To compile your Intel® HLS Compiler code with Microsoft Visual C++:

  1. Initialize your environment with the Intel® HLS Compiler initialization script:/hls/init_hls.bat
  2. Add the Intel® HLS Compiler header files to the compiler command include path with the /l command option.

    The header files are in the \hls\include directory.

  3. Add the option to generate debug symbols when compiling.
  4. Add the option to suppress warnings because MSVC does not recognize the Intel® HLS Compiler pragmas.
  5. Add the HLS emulation library to the linker search path with the /libpath command option.

    The emulation library is in the \hls\host\windows64\lib directory.

  6. Add the hls_emul library to the linker command.
  7. If you are using arbitrary precision datatypes, include the reference version instead of the FPGA-optimized version provided with the Intel® HLS Compiler. You can use the macro to control which version is included:#ifdef __INTELFPGA_COMPILER__ #include "HLS/ac_int.h" #else #include "ref/ac_int.h" #endif
Your Microsoft Visual C++ compiler command should resemble the following example command:cl myFile.cpp /I "%HLS_INSTALL_DIR%\include" /nologo /EHsc /wd4068 /MD /std:c++17 /Zi /link "/libpath:%HLS_INSTALL_DIR%\host\windows64\lib" hls_emul.lib

In some cases, you might want to decouple your testbench development from your component development. For example, you might want to change your testbench code without recompiling your HLS component.

You can compile your testbench and component separately in one of the following ways:
  • Compile your testbench with the Intel® HLS Compiler and then compile your component code with the Intel® HLS Compiler.
  • Compile your testbench with GCC or Microsoft Visual Studio, and then compile your component code with the Intel® HLS Compiler.
In either case, the build flow is similar:
  1. Use the i++ -c command to compile your component code to an object file.

    For example, i++ -c component.cpp -o component.o -march=

  2. Use any compiler supported by the Intel® HLS Compiler to compile your testbench to an object file (or files):
    • Intel® HLS Compiler: i++ -c
    • GCC: g++ -c
    • MSVC: cl /c

    For example, g++ -c testbench.cpp -o testbench.o

  3. Link the component and testbench object files with the i++.

    For example, i++ testbench.o component.o -o prog -march=.

For an example of compiling your testbench and component separately, review the following tutorial:/hls/examples/tutorials/usability/compiler_interoperability

The Intel® HLS Compiler attempts to pipeline functions as much as possible. Different stages of the pipeline might have multiple operations performed in parallel.

The following figure shows an example of the pipeline architecture generated by the Intel® HLS Compiler. The numbered operations on the right side represent the pipeline implementation of the C++ code on the left side of the figure. Each box in the right side of the figure is an operation in the pipeline.

Figure 1. Example of Pipeline Architecture

With a pipelined approach, multiple invocations of the component can be simultaneously active. For example, the earlier figure shows that the first invocation of the component can be returning a result at the same time the fourth invocation of the component is called.

One invocation of a component advances to the its next stage in the pipeline only after all of the operations of its current stage are complete.

Some operations can stall the pipeline. A common example of operations that can stall a pipeline is a variable latency operation like a memory load or store operation. To support pipeline stalls, the Intel® HLS Compiler propagates and signals through the pipeline to all operations that have a variable latency.

For operations that have a fixed latency, the Intel® HLS Compiler can statically schedule the interaction between the operations and signals are not needed between the stages with fixed latency operations. In these cases, the compiler optimizes the pipeline to statically schedule the operations, which significantly reduces the logic required to implement the pipeline.

Some common software patterns cannot be physically realized in FPGA digital logic, which results in limitations in the coding style that the Intel® HLS Compiler can support.
The compiler cannot generate RTL for the following C++ constructs:
  • Dynamic memory allocation.
  • Virtual functions.
  • Function pointers
  • C++ or C library functions, except the supported math functions explicitly mentioned in Supported Math Functions.
  • Non-static class functions.
  • Template functions without an explicit specialization.
In general, the compiler can generate RTL for functions that can be statically linked such as static class methods and "regular" functions. HLS component functions can include classes, structs, functions, templates, and pointers.

In addition, a component or task function cannot contain an irreducible loop. That is, loops in component and task functions must have only one entry point into the loop.

Important: These synthesis limitations do not apply to testbench code.
The Intel® High Level Synthesis (HLS) Compiler provides a number of header files to provide FPGA implementations of certain C and C++ functions.
HLS Header FileDescription
Required for component identification and component parameter interfaces.
Includes FPGA-specific definitions for the math functions from the for your operating system.
Includes additional FPGA-specific definitions of math functions not in .
Provides FPGA-optimized arbitrary width integer support.

Provides FPGA-optimized arbitrary precision fixed point support.

Provides FPGA-optimized arbitrary precision fixed point math functions.

HLS/ac_complex.hProvides FPGA-optimized complex number support.
HLS/hls_float.hProvides FPGA-optimized arbitrary-precision IEEE-754 compliant floating-point number support.
HLS/hls_float_math.hProvides FPGA-optimized floating-point math functions.
HLS/math_dsp_control.hProvides the function to control the hardware implementation for supported data types and math functions at a local-scope.
Provides support for components so that statements work in x86 emulations, but are disabled in component when compiling to an FPGA architecture.
To use and in your component, guard the statements with the macro.

math.h

To access functions in math.h from your component function, include the "HLS/math.h" file in your source code. The header ensures that the components call the hardware versions of the math functions.

For more information about supported math.h functions, see Supported Math Functions.

stdio.h

Synthesized component functions generally do not support C and C++ standard library functions such as FILE objects.

A component can call by including the header file HLS/stdio.h. This header changes the behavior of depending on the compilation target:

  • For compilation that targets the x86-64 architecture (that is, ), the call behaves as normal.
  • For compilation that targets the FPGA architecture (that is, ), the compiler removes the call.

If you use in a component function without first including the line in your code, you get an error message similar to the following error when you compile hardware to the FPGA architecture:

$ i++ -march="" --component dut test.cppError: HLS gen_qsys FAILED.See ./a.prj/dut.log for details.

You can use C and C++ standard library functions such as and as normal in all testbench functions.

iostream

The C++ standard output streams ( or ) output streams are not supported in RTL, but you can use them to debug your component in emulation. However, you must guard any or statements with the macro.

This macro ensures that statements in a component work in x86 emulations (that is, ), but are disabled in the component when compiling it to an FPGA architecture (that is, ). For example:#include "HLS/hls.h"#include <iostream>component int debug_component (int a){#ifndef HLS_SYNTHESIS std::cout << "input value: " << a << std::endl;#endif return a;}

If you attempt to use or in a component function without guarding the line in your code with the macro , you get an error message similar to the following error when you compile hardware to the FPGA architecture:

$ i++ -march="" run.cpp run.cpp:5: Compiler Error: Cannot synthesize std::cout used inside of a component.HLS Main Optimizer FAILED.
You can use templating and overloading to create generalized function interfaces for your HLS components and HLS tasks. HLS components can be both templated and overloaded. HLS tasks can only be templated. You cannot overload an HLS task function.
Using a templated function as an HLS component differs from using the templated function as an HLS task.

Templated Functions as an HLS Component

When you create a template function, you must declare the instantiation of the function to synthesize into hardware.

For example, a templated function might be useful in a system.template <typename T, int MULT>T multadd (T a, T b) { return MULT * (a + b);}
To synthesize a version of this function into a component, you must declare the instantiation that you want to synthesize:template component int multadd<int, 5>(int a, int b);

This declaration combined with the earlier template definition marks the variant with =5 of the function to be generated into a component. This component can now be invoked from the testbench.

Templated Functions as an HLS Task

If you want to use the function as a task in a system of tasks, use the and calls as shown in the following example:

component void foo () { int a, b; ihc::launch<multadd<int, 5>> (a, b); int res = ihc::collect<multadd<int, 5>>();}
HLS component functions can be overloaded, but HLS task functions cannot because the and calls cannot distinguish between overloaded variants of a task function.

To overload a component function, define multiple variants of the function.

For example:component int mult (int a, int b) { return a * b;}component float mult (float a, float b) { return a * b;}
The Intel® HLS Compiler always generates unique function names to avoid name collisions that might occur for overloaded and templated functions.

A mapping of the full function declaration to the synthesized function name is provided in the summary page of the High-Level Design Reports (report.html). The synthesized function name is used for all the other reports such as the loops report and area analysis.

The following example shows an example of this table in the report:

The Intel® HLS Compiler Pro Edition has built-in macros that you can use to customize your code to create flow-dependent behaviors.
Tool Invocation__INTELFPGA_COMPILER__
or Undefined
Tool InvocationHLS_SYNTHESIS
Testbench CodeHLS Component Code
or UndefinedUndefined
UndefinedUndefined
UndefinedDefined
The Intel® HLS Compiler generates a component interface for integrating your RTL component into a larger system. A component has two basic interface types: the component invocation interface and the parameter interface.

The component invocation interface is common to all HLS components and contains the return data (for non- functions) and handshake signals for invoking the component, and for receiving results back when the component finishes executing.

Use the parameter interface to transfer data in and out of your component function. The parameter interface for your component is based on the parameters that you define in your component function signature and global variables (including global streams) that your component accesses.

For each function that you label as a component, the Intel® HLS Compiler creates a corresponding RTL module. This RTL module must have top-level ports, or interfaces, that allow your overall system to interact with your HLS component.
By default, the RTL module for an HLS component includes the following interfaces and data:
  • A call interface that consists of and signals. The call interface is sometimes referred to as the .
  • A return interface that consists of and signals. The return interface is sometimes referred to as the .
  • Return data if the component function has a return type that is not
The following diagram shows a component with the default call and return interfaces:

Alternatively, by declaring your component as an component, your component can have signals registered in the component agent memory map instead. In an component, the , , and signals appear in the component control and status registers (CSR) instead of as conduits outside of the component.

For a comparison of the invocation interfaces, see Interface Definition Example: Component Invocation Interface Control Attributes.

For an example of a component interface with scalar and pointer arguments, see Figure 2.

Interfaces and Generated RTL

Your component function parameters generate different RTL depending on their type. For details see the following sections:
You can also explicitly declare Avalon Streaming interfaces (using and classes) and Avalon Memory-Mapped Host (using classes) interfaces on component interfaces. For details see the following sections:

Component Invocation Interface Control Attributes

You can indicate the control signals that correspond to the actions of calling your component by using one of the component invocation interface attributes.

Unless a component parameter is marked stable (with the attribute), the component parameter inputs are synchronized according to this component invocation protocol.

Control AttributeDescription

This is the default component invocation interface.

The component uses , , , and signals for handshaking.

The , , and (if applicable) signals appear in the component CSR instead of as conduits outside of the signal.
The signal is tied to internally in the component. There is no signal output.
The signal is removed by internally setting it to .

Use this control attribute only if the downstream component never stalls.

Each scalar parameter in your component results in an input conduit that is synchronized with the component and signals.

The inputs are read into the component when the external system pulls the signal high and the component keeps the signal low.

If your component has a return value, an output conduit that is synchronized to your component signal is generated.

For an example of how to specify a scalar parameter and how it is read in by a component, see the argument in Figure 2 and Figure 3.

Each pointer or reference parameter of a component results in an input conduit for the address. The input conduit is synchronized with the component and signals. In addition to this input conduit, all pointers share a single Avalon® Memory-Mapped (MM) host interface that the component uses to access system memory.

You can customize these pointer interfaces using the class.

Note: Explicitly-declared Avalon® Memory-Mapped Host interfaces and Avalon Streaming interfaces are passed by reference.

For details about Avalon® (MM) Host interfaces, see Avalon Memory-Mapped Host Interfaces.

This example compares two simple components. One component is implemented with simple conduits as its signal interface, while the other component is implemented as an .

Consider the following code example for a simple component:component float myComponent(float a, float b) { return a+b;}

This code example results in a component with the following signals:


You can also implement this component as an component with the control signals residing in a register map:hls_avalon_agent_componentcomponent float myComponent(hls_avalon_agent_register_arg float a, hls_avalon_agent_register_arg float b) { return a+b;}
This code results in a component with the following signals:

The following design example illustrates the interactions between a component's interfaces and signals, and the waveform of the corresponding RTL module.
component int dut(int a, int* b, int i) { return a*b[i];}
Figure 2. Block Diagram of the Interfaces and Signals for the Component dut
Figure 3. Waveform Diagram of the Signals for the Component dutThis diagram shows that the Avalon-MM read signal reads from a memory interface that has a read latency of one cycle and is non-blocking.

If the component raises the signal, the caller needs to keep the signal high and continue asserting the input arguments. Similarly, if the component downstream of raises the signal, then holds the signal high until the signal is de-asserted.

A component can have input and output streams that conform to the Avalon Streaming (ST) interface specifications. These input and output streams are represented by passing references to and objects as function arguments to the component.

When you use an Avalon ST interface, you can serialize the data over several clock cycles. That is, one component invocation can read from a stream multiple times.

You cannot derive new classes from the stream classes or encapsulate them in other formats such as structs or arrays. However, you may use references to instances of these classes as references inside other classes, meaning that you can create a class that has a reference to a stream object as a data member.

A component can have multiple read sites for a stream. Similarly, a component can have multiple write sites for a stream. However, for best component performance try to restrict each input stream in your design to a single read site and each output stream to a single write site.

Note: Within the component, there is no guarantee on the order of execution of different streams unless a data dependency exists between streams.
For more information about streaming interfaces, refer to "Avalon Streaming Interfaces" in Avalon Interface Specifications.
Restriction: The Intel® HLS Compiler does not support the Avalon ST or signals.

Streaming Input Interfaces

Template Object or ParameterDescription
Streaming input interface to the component.
Specifies the capacity (in words) of the FIFO buffer on the input data that associates with the stream.
Specifies the number of cycles between when the signal is deasserted and when the input stream can no longer accept new inputs.
Describes how the data is broken into symbols on the data bus.
Specifies whether the data symbols in the stream are in big endian order.
Exposes the and sideband signals on the stream interface.

Exposes the out-of-band signal on the stream interface.

Controls whether a signal is present on the stream interface.
Function APIDescription
Blocking read call to be used from within the component

Available only if is set.

Blocking read with out-of-band and signals.
Available only if and are set.

Blocking read with out-of-band , , and signals.

Non-blocking read call to be used from within the component. The bool is set to true if the read was valid. That is, the Avalon®-ST signal was high when the component tried to read from the stream.

The emulation model of is not cycle-accurate, so the behavior of might differ between emulation and simulation.

Available only if is set.

Non-blocking read with out-of-band and signals.
Available only if and are set.

Non-blocking read with out-of-band , , and signals.

Blocking write call to be used from the testbench to populate the FIFO to be sent to the component.

Available only if is set.

Blocking write call with out-of-band and signals.
Available only if and are set.

Blocking write call with out-of-band , , and signals.

Streaming Output Interfaces

Template Object or ParameterDescription
Streaming output interface from the component.
Specifies the number of cycles between when the signal is deasserted and when the input stream can no longer accept new inputs.
Describes how the data is broken into symbols on the data bus.
Specifies whether the data symbols in the stream are in big endian order.
Exposes the and sideband signals on the stream interface.

Exposes the out-of-band signal on the stream interface.

Controls whether a ready signal is present.
Function APIDescription
Blocking write call from the component

Available only if is set.

Blocking write with out-of-band and signals.
Available only if and are set.

Blocking write with out-of-band , , and signals.

Non-blocking write call from the component. The return value represents whether the write was successful.

Available only if is set.

Non-blocking write with out-of-band and signals.

The return value represents whether the write was successful. That is, the downstream interface was pulling the signal high while the HLS component tried to write to the stream.

Available only if and are set.

Non-blocking write with out-of-band , , and signals. The return value represents whether the write was successful.

Blocking read call to be used from the testbench to read back the data from the component

Available only if is set.

Blocking read call to be used from the testbench to read back the data from the component with out-of-band and signals.
Available only if and are set.

Blocking read call to be used from the testbench to read back the data from the component with out-of-band , , and signals.

Using external memory to move data in and out of static-object libraries or task functions can constrain the performance of your design. Pipes provide a mechanism for passing data with high efficiency and low latency by using on-device FIFO buffers to communicate.

Pipes are similar to streams, but are simpler. You can use pipes in a component or to allow tasks to communicate with each other, but pipes support only / and signals, while streams support additional sideband signals such as and .

Unlike streams, you can declare an array of pipes and you can iterate over the array to write or read many pipes in a design.

Data written to a pipe remains in the pipe until it is read or until the component is reset.

The memory model of pipes allows you to use them to send and receive data from task functions in running functions in a static-object library or a running task function.

Pipe Properties

Pipes have the following key properties:
FIFO ordering
Data is accessible (readable) only in FIFO order. There is no concept of a memory address or pointer in a pipe, which means random data access is not possible with pipes.
Capacity
Pipes have a capacity. That is, a fixed amount of data can be written to an initially empty pipe before needing to read anything from it to make room for more data.

A full pipe applies back pressure to the write site.

Pipe Accessors

Data is written to a pipe through an API that commits a single word of the pipe data type, and that word is later returned by an API that reads data from the pipe.

The API accessing the pipe can be a blocking or a nonblocking type:
Blocking API calls
Blocking write API calls wait until the pipe has enough capacity to commit data.

Blocking read API calls wait until the pipe contains data to be read.

Nonblocking API calls
Nonblocking API calls execute immediately and return a status that indicates whether the operation was successful.

You can mix blocking and nonblocking accesses to the same pipe. For example you can write data to a pipe with a blocking pipe call and read it from the other end using a non-blocking call, and vice versa.

Data Persistence in Pipes

Data written to a pipe by a component remains in the pipe until it is read or until the component is reset.

Data written to a pipe by a task remains in the pipe until another task reads from the pipe or the component containing the tasks is reset.

The sequence of data in a pipe always follows FIFO ordering.

Data in pipes does not persist across FPGA device resets or reprogramming.

Restrictions on using Pipes

Using pipes comes with the following restrictions:
Multiple pipe call sites
A component or task function can read from the same pipe multiple times, but multiple component or task functions cannot read from the same pipe. Similarly, a component or task function can write to the same pipe multiple times, but multiple component or task functions cannot write to the same pipe.
Feedback and feed-forward pipes
A component or task function should use separate pipes for pipe reads and pipe writes. Writing to and reading from the same pipe within the same function can lead to poor performance.
Pipe accesses in loops
Do not use nonblocking pipes if you use a loop structure that waits for data from the pipe. That is, avoid the following code pattern for nonblocking pipe accesses:bool success = false;while (!success) { my_pipe::write(rd_src_buf[i], success); // can also be a nonblocking read}Use a blocking access with this code pattern instead because a blocking access in this code pattern is more efficient in hardware than a nonblocking access in this code pattern.

The class exposes static methods for writing a data word to a pipe and reading a data word from a pipe. The reads and writes can be blocking or nonblocking, with the form chosen based on the overload resolution.

The API is equivalent to the following class declaration:template <class name, class dataT, size_t min_capacity = 0>class pipe {public: // Blocking static dataT read(); static void write(dataT data); // Non-blocking static dataT read(bool &success); static void write(dataT data, bool &success);}
Where the template parameters are defined as follows:
ParameterDescription
The type that is used to create a unique identifier for the pipe.

It is typically a user-defined class, in a user namespace. Forward declaration of the type is enough, and the type need not be defined.

The data type of the packet contained within a pipe.

This is the data type that is read during a successful pipe operation, or written during a successful pipe operation.

The type must have a standard layout and be trivially copyable.

Sours: https://www.intel.com/content/www/us/en/programmable/documentation/ewa1462824960255.html
HLS Walkthrough Part 2: Integrating with Quartus

Even under the peach-colored lipstick, it was clear that her lips were as pale as ever. He walked up to her from behind and stroked her long wavy hair. He bent over and tried to smell her body.

You will also be interested:

Shoe. Some kind of village girl on top of it, covering me with lush hips the view on it. She began to do something with her hands. It seems that she unbuttoned her jeans and lowered them a little. She leaned towards her, apparently kissing.



216 217 218 219 220