diff --git a/devel/objects.inv b/devel/objects.inv index b7b8ee7ca..81370c960 100644 Binary files a/devel/objects.inv and b/devel/objects.inv differ diff --git a/release/.buildinfo b/release/.buildinfo index 7274281f3..f85c30447 100644 --- a/release/.buildinfo +++ b/release/.buildinfo @@ -1,4 +1,4 @@ # Sphinx build info version 1 # This file records the configuration used when building these files. When it is not found, a full rebuild will be done. -config: db1c1339d69cc589c6f4db3cbf231b40 +config: d9ca9643927e9f96024273c65fe247d3 tags: 645f666f9bcd5a90fca523b33c5a78b7 diff --git a/release/_images/ndk_fpga_logo.png b/release/_images/ndk_fpga_logo.png new file mode 100644 index 000000000..a2838018c Binary files /dev/null and b/release/_images/ndk_fpga_logo.png differ diff --git a/release/_sources/base.rst.txt b/release/_sources/base.rst.txt index 17a3b4dcb..15f6b19af 100644 --- a/release/_sources/base.rst.txt +++ b/release/_sources/base.rst.txt @@ -2,7 +2,7 @@ Basic Tools =========== This chapter describes the basic components such as FIFOs, RAMs, multiplexers, encoders, decoders, etc. -The basic components are typically located in the ``comp/base/`` directory in the OFM repository. +The basic components are typically located in the ``comp/base/`` directory in the NDK-FPGA repository. .. toctree:: :maxdepth: 1 @@ -12,6 +12,5 @@ The basic components are typically located in the ``comp/base/`` directory in th memory fifo dsp - shift logic misc diff --git a/release/_sources/comp/base/mem/mem_clear/readme.rst.txt b/release/_sources/comp/base/mem/mem_clear/readme.rst.txt new file mode 100644 index 000000000..961169ed3 --- /dev/null +++ b/release/_sources/comp/base/mem/mem_clear/readme.rst.txt @@ -0,0 +1,33 @@ +.. _mem_clear: + +Memory clear +------------ + +Simple component that will generate addresses for memory clearing when RST is asserted. + +Component port and generics description +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. vhdl:autoentity:: MEM_CLEAR + :noautogenerics: + + +Instance template +^^^^^^^^^^^^^^^^^ + +.. code-block:: + + data_clear_i : entity work.MEM_CLEAR + generic map ( + DATA_WIDTH => BOX_WIDTH, + ITEMS => BOX_CNT, + CLEAR_EN => CLEAR_BY_RST + ) + port map ( + CLK => CLK, + RST => RST, + + CLEAR_DONE => RST_DONE, + CLEAR_WR => wr_clear, + CLEAR_ADDR => wr_addr_clear + ); diff --git a/release/_sources/comp/debug/data_logger/readme.rst.txt b/release/_sources/comp/debug/data_logger/readme.rst.txt index 41013525c..1454a13e2 100644 --- a/release/_sources/comp/debug/data_logger/readme.rst.txt +++ b/release/_sources/comp/debug/data_logger/readme.rst.txt @@ -171,22 +171,124 @@ Instance template (full usage) Control SW ^^^^^^^^^^ -Folder ``data_logger/sw/`` contains ``Python3`` package that provides: +Folder ``data_logger/sw/`` contains following ``Python3`` packages: -* Module for basic interaction with ``DATA_LOGGER`` -* Modules for ``DATA_LOGGER`` wraps like ``MEM_LOGGER`` -* Simple graph generator based on `matplotlib` library -* Simple PDF / Markdown report generator -* Common tools +* ``data_logger`` ... basic interaction with ``DATA_LOGGER`` +* ``mem_logger`` ... basic interaction with ``MEM_LOGGER`` +* ``logger_stats`` ... loading firmware statistics (multiple ``DATA_LOGGERS`` can be organized in tree hierarchy) +* ``graph_tools`` ... simple plot functions for statistics from ``logger_stats`` Package can be installed using this command: * You also need to install ``python nfb`` package .. code-block:: + python3 -m pip install --upgrade pip + # Install nfb: + cd swbase/pynfb + python3 -m pip install Cython + python3 -m pip install . + cd - + + # Install this package: cd data_logger/sw - python3 setup.py install --user + python3 -m pip install . + +Example usage of ``logger_stats`` (for more usage see `mem_logger/mem_logger.py`): + +.. code-block:: + + + import logger_stats as Stats + from data_logger.data_logger import DataLogger + + def create_stats(): + # Create DataLoggers + logger_0 = DataLogger(index=0, dev='/dev/nfb0') + logger_1 = DataLogger(index=1, dev='/dev/nfb0') + + # Create Stats hierarchy + stats = Stats.LoggerStats('Example stats') + stats_0 = Stats.LoggerStats('Logger 0 stats', logger=logger_0) + stats_1 = Stats.LoggerStats('Logger 1 stats', logger=logger_1) + stats.add_stat(stats_0) + stats.add_stat(stats_1) + + # Add basic statistics + stats_0.add_stat(Stats.Constant(index=7, name='X')) + stats_0.add_stat(Stats.Counter(index=7, name='Y')) + stats_0.add_stat(Stats.Value(index=7, name='Z')) + + # FSM state statistic + def fms_convert(v): + states = [ + 'IDLE', + ... + ] + if v >= len(states): + return "???" + else: + return states[int(v)] + + fsm_format = Stats.FormatDefaultValue(format=Stats.FormatNone) + stats_1.add_stat(Stats.Value(2, 'FSM states', convert=fms_convert, format=fsm_format)) + + # Latency statistic + FREQ = 200 * 10**6 + time_conv = Stats.ConvertTime(FREQ) + time_form = Stats.FormatDefaultValue(units='ns') + stats_1.add_stat(Stats.Value(9, 'Latency', convert=time_conv, format=time_form)) + + # Add value statistic which includes multiple commands + CMDS = [ + 'CMD_A', + ... + ] + stats_1.add_stat(Stats.ValueCMD(7, 'Latency of CMDs', cmd_width=2, cmds=CMDS, convert=time_conv, format=time_form)) + + # Add multiple counters + counters = [ + 'Counter A', + ... + ] + stats_1.add_stats( + name='Counters', + names=counters, + indexes=list(range(len(counters))), + constructor=lambda i, n: Stats.Counter(i, n) + ) + + return stats + + + stats = create_stats() + stats.load() + print(stats.to_str()) + stats.save('stats.npz') + + +Example usage of ``graph_tools``: + + from graph_tools.graph_tools import load_data, plot_counter, plot_value, plot_value_2d + + stats = load_data('stats.npz') + + node = pd.DataFrame.from_dict(stats['Stats A']['Counters']) + selected = ['Counter A', 'Counter B'] + + # Plot single counter + plot_counter(node['Counter X'], 'Time', 'Requests', 'Plot title') + + # Plot multiple counters + plot_counter(node[selected], 'Time', 'Requests', 'Plot title') + + # Plot histogram of the value interface + plot_value(node['Value A'], 'Time', 'Blocks', 'Title' log=True) + + # Plot 2D histogram of the value interface history + plot_value_2d(node['Value A'], 'Time', 'Blocks', 'Title' log=True) + MI address space diff --git a/release/_sources/comp/mfb_tools/edit/frame_appender/readme.rst.txt b/release/_sources/comp/mfb_tools/edit/frame_appender/readme.rst.txt new file mode 100644 index 000000000..e1be0cdf7 --- /dev/null +++ b/release/_sources/comp/mfb_tools/edit/frame_appender/readme.rst.txt @@ -0,0 +1,12 @@ +.. readme.rst: Documentation of a single component +.. Copyright (C) 2024 CESNET z. s. p. o. +.. Author(s): Daniel Kondys +.. +.. SPDX-License-Identifier: BSD-3-Clause + +.. _mfb_mvb_appender: + +MFB MVB Appender +---------------- + +.. vhdl:autoentity:: MFB_MVB_APPENDER diff --git a/release/_sources/comp/mvb_tools/flow/gate/readme.rst.txt b/release/_sources/comp/mvb_tools/flow/gate/readme.rst.txt new file mode 100644 index 000000000..35fedf5e0 --- /dev/null +++ b/release/_sources/comp/mvb_tools/flow/gate/readme.rst.txt @@ -0,0 +1,6 @@ +.. _mvb_gate: + +MVB Gate +-------- + +.. vhdl:autoentity:: MVB_GATE diff --git a/release/_sources/comp/mvb_tools/flow/item_collision_resolver/readme.rst.txt b/release/_sources/comp/mvb_tools/flow/item_collision_resolver/readme.rst.txt new file mode 100644 index 000000000..4323b1cf8 --- /dev/null +++ b/release/_sources/comp/mvb_tools/flow/item_collision_resolver/readme.rst.txt @@ -0,0 +1,6 @@ +.. _mvb_item_collision_resolver: + +MVB Item Collision Resolver +--------------------------- + +.. vhdl:autoentity:: MVB_ITEM_COLLISION_RESOLVER diff --git a/release/_sources/fifo.rst.txt b/release/_sources/fifo.rst.txt index 549fc5b86..8fab2e755 100644 --- a/release/_sources/fifo.rst.txt +++ b/release/_sources/fifo.rst.txt @@ -6,9 +6,17 @@ FIFO components Dual clock (asynchronous) FIFOs ------------------------------- -**ASFIFO** - Behavioral dual clock FIFO implementation based on LUTMEMs and optimized for Xilinx only. Include status signal. ``OBSOLETE, use ASFIFOX!`` +**ASFIFO** - Behavioral dual clock FIFO implementation, based on LUTMEMs and optimized for Xilinx only. Includes status signal. -**ASFIFO_BRAM** - Behavioral dual clock FIFO implementation based on BRAMs and optimized for Xilinx only. Include status signal. ``OBSOLETE, use ASFIFOX!`` +.. warning:: + .. deprecated:: 0.7.0 + This component is obsolete and is a candidate for removal, use **ASFIFOX** instead. + +**ASFIFO_BRAM** - Behavioral dual clock FIFO implementation, based on BRAMs and optimized for Xilinx only. Includes status signal. + +.. warning:: + .. deprecated:: 0.7.0 + This component is obsolete and is a candidate for removal, use **ASFIFOX** instead. **ASFIFO_BRAM_BLOCK** - Similar to ASFIFO_BRAM but with extra signal to mark end of input data block, output remains in empty state until such mark is received. Located in the same folder as ASFIFO_BRAM. @@ -34,13 +42,25 @@ Detailed :ref:`documentation can be found here`. Single clock FIFOs ------------------ -**FIFO** - Behavioral FIFO implementation based on LUTMEMs and optimized for Xilinx only. Include status signal. ``OBSOLETE, use FIFOX!`` +**FIFO** - Behavioral FIFO implementation, based on LUTMEMs and optimized for Xilinx only. Includes status signal. + +.. warning:: + .. deprecated:: 0.7.0 + This component is obsolete and is a candidate for removal, use **FIFOX** instead. -**FIFO_BRAM** - Behavioral FIFO implementation based on BRAMs and optimized for Xilinx only. Include status signal. ``OBSOLETE, use FIFOX!`` +**FIFO_BRAM** - Behavioral FIFO implementation, based on BRAMs and optimized for Xilinx only. Includes status signal. + +.. warning:: + .. deprecated:: 0.7.0 + This component is obsolete and is a candidate for removal, use **FIFOX** instead. **FIFO_BRAM_XILINX** - Structural implementation of FIFO based on Xilinx specific BRAM FIFO primitives (no extra logic). Include almost full and almost empty signal. -**FIFO_N1** - Behavioral implementation of FIFO with multiple write ports, it based on LUTMEMs and optimized for Xilinx only. ``OBSOLETE, use FIFOX_MULTI!`` +**FIFO_N1** - Behavioral implementation of FIFO with multiple write ports, it is based on LUTMEMs and optimized for Xilinx only. + +.. warning:: + .. deprecated:: 0.7.0 + This component is obsolete and is a candidate for removal, use **FIFOX** instead. **FIFOX** - Universal FIFO for Xilinx and Intel FPGAs. It support various memory implementation: LUTMEMs, BRAMs, URAMs (Xilinx only) and shift-registers in LUT slices (effective on Xilinx only). Include almost full, almost empty and status signal. Possible automatic selection of a suitable memory implementation. Detailed :ref:`documentation can be found here`. @@ -50,7 +70,11 @@ Include almost full, almost empty and status signal. Possible automatic selectio **MULTI_FIFO** - Behavioral implementation of FIFO for Xilinx and Intel FPGAs with multiple independent channels. It support various memory implementation: LUTMEMs, BRAMs, URAMs (Xilinx only). The memory type is selected automatically. -**SH_FIFO** - Behavioral FIFO implementation based on shift-registers in LUT slices and optimized for Xilinx only. ``OBSOLETE, use FIFOX!`` +**SH_FIFO** - Behavioral FIFO implementation, based on shift-registers in LUT slices and optimized for Xilinx only. + +.. warning:: + .. deprecated:: 0.7.0 + This component is obsolete and is a candidate for removal, use **FIFOX** instead. .. toctree:: :maxdepth: 1 diff --git a/release/_sources/index.rst.txt b/release/_sources/index.rst.txt index 7ed52d61e..ce3c1637a 100644 --- a/release/_sources/index.rst.txt +++ b/release/_sources/index.rst.txt @@ -1,26 +1,10 @@ -Documentation of Minimal NDK Application -**************************************** +.. currentmodule:: ndk_fpga -**Welcome to documentation of Minimal NDK Application!** +.. image:: img/ndk_fpga_logo.png + :width: 500px -The NDK-APP-Minimal is a reference application based on the Network Development Kit (NDK) for FPGAs. The NDK allows users to quickly and easily develop FPGA-accelerated network applications. The NDK is optimized for high throughput and scalability to support up to 400 Gigabit Ethernet. - -.. image:: img/liberouter_logo.svg - :align: center - :width: 50 % - -The NDK-based Minimal application is a simple example of how to build an FPGA application using the NDK. It can also be a starting point for your NDK-based application. The NDK-based Minimal application does not process network packets in any way; it only sends and receives them. If the DMA IP is enabled (see the :ref:`DMA Module chapter `), then it forwards the network packets to and from the computer memory. - -.. warning:: - - The DMA Medusa IP is not part of the open-source NDK. `You can get the NDK, including the DMA Medusa IP and professional support, through our partner BrnoLogic. `_ - -.. toctree:: - :maxdepth: 2 - :caption: Application: - :hidden: - - app-minimal +Overview +======== .. toctree:: :maxdepth: 2 @@ -36,10 +20,80 @@ The NDK-based Minimal application is a simple example of how to build an FPGA ap ndk_core/doc/devtree ndk_core/doc/faq +The **Network Development Kit (NDK) for FPGAs** is a comprehensive framework designed +for the rapid and efficient development of FPGA-accelerated network applications. Optimized +for scalability and high throughput, the NDK supports speeds up to **400 Gigabit Ethernet**. + +-------- + +The NDK provides a minimal example application. The **NDK Minimal Application** +demonstrates how to build an FPGA application using the NDK and serves as a starting point +for your own development. The minimal application doesn't process network packets; it simply +sends and receives them. If a DMA IP is enabled (see the :ref:`DMA Module `), +the packets are forwarded to and from the host's memory. Otherwise, DMA IP is replaced with +a loopback and packets may be forwarded from RX to TX ethernet interface. + +Other example applications will be added in the future, stay tuned! + .. toctree:: - :maxdepth: 2 - :caption: Supported cards: - :hidden: + :maxdepth: 1 + :caption: Applications + + app-minimal + +-------- + +In addition, the NDK provides a collection of reusable components, some of which are vendor and +vendor- and tool-independent, while others are optimized for specific FPGA vendors and architectures. +For transferring packets (frames) and auxiliary data at such high rates, the NDK uses its own set of what are called +"multibuses" that can transfer multiple frames and values, respectively, within a single clock cycle. +For details on these protocols, see the specifications for the :ref:`Multi Value Bus` and +:ref:`Multi Frame Bus`. + +To simplify module development, the NDK includes components for common operations on these buses, +multiplexers, FIFOs, BRAMs and lookup tables. To improve compatibility with other popular buses, +it also provides converters: + +* MFB to AXI stream, +* MFB to Avalon stream, +* MI to Avalon MM, +* MI to AXI4, +* MVB to MFB. + +.. toctree:: + :maxdepth: 1 + :caption: Reusable Modules Library + + base + ctrls + mi + mfb + mvb + nic + pcie + debug + ver + +-------- + +.. toctree :: + :maxdepth: 1 + :caption: Bus Specifications + + comp/mi_tools/readme + comp/mvb_tools/readme + comp/mfb_tools/readme + +-------- + +The NDK supports a wide range of FPGA cards, providing access to features such as DDR and HBM +memories, PCIe, and Ethernet in your applications. However, different applications may only +support a subset of these cards. A complete list of supported FPGA cards can be found below +(minimal app supports all of them). + +.. toctree:: + :caption: Supported Cards + :maxdepth: 1 ndk_cards/reflexces/agi-fh400g/readme ndk_cards/intel/dk-dev-1sdx-p/readme @@ -51,20 +105,27 @@ The NDK-based Minimal application is a simple example of how to build an FPGA ap ndk_cards/amd/alveo-u200/readme ndk_cards/amd/alveo-u55c/readme ndk_cards/amd/vcu118/readme - ndk_extra/nfb-200g2ql/readme + extra/nfb-200g2ql/readme ndk_cards/prodesign/pd-falcon/readme + ndk_cards/terasic/a2700/readme -.. toctree:: - :maxdepth: 2 - :caption: VHDL components: - :hidden: +-------- - base - ctrls - mi - mfb - mvb - nic - pcie - debug - ver +NDK provides two implementations of DMA IPs: + +* DMA Medusa +* DMA Calypte + +DMA Medusa is a state-of-the-art DMA module that supports up to 400Gbps of throughput to +host memory. DMA Calypte is an open-source low-latency DMA supporting throughput up +to tens of Gigabits per second. However, the DMA Calypte is still under development +and is not yet officially released (stay tuned). + +.. warning:: + + The DMA Medusa IP is not included in the open-source version of the NDK. `You can obtain the full NDK package, including DMA Medusa IP and professional support, from our partner BrnoLogic. `_ + + +.. image:: img/liberouter_logo.svg + :align: center + :width: 50 % diff --git a/release/_sources/logic.rst.txt b/release/_sources/logic.rst.txt index 41132ab03..620c19de8 100644 --- a/release/_sources/logic.rst.txt +++ b/release/_sources/logic.rst.txt @@ -80,8 +80,6 @@ Tries to use as simple adders as the set latency allows. It has a valid bit for **SHIFTER** - Behavioral implementation of left or right block-by-block shifter. -**SQUARER** - The unit is used for calculation square (n^2** of input vector). - **SR_SYNC_LATCH** - Synchronous SR latch whose forbidden state has been removed. Latches data of variable length. Detailed documentation can be found :ref:`here`. **SUM_ONE** - Behavioral implementation of generic counter of ones in input vector. diff --git a/release/_sources/memory.rst.txt b/release/_sources/memory.rst.txt index 4788b1d4d..25ddb1849 100644 --- a/release/_sources/memory.rst.txt +++ b/release/_sources/memory.rst.txt @@ -1,11 +1,17 @@ Memory modules ============== -**CAM** - Ternary content addressable memory implemented in memory LUTs, optimized for Xilinx only. Also there is **light variant** implemented using register array, simpler but less effective. +**DP_BMEM** - Behavioral implementation of dual clock BRAM memory with two read/write ports. -**DP_BMEM** - Behavioral implementation of dual clock BRAM memory with two read/write port. ``OBSOLETE, use DP_BRAM or DP_BRAM_XILINX!`` +.. warning:: + .. deprecated:: 0.7.0 + This component is obsolete and is a candidate for removal, use **DP_BRAM** or **DP_BRAM_XILINX** instead. -**DP_BMEM_V7** - Structural implementation of dual clock BRAM memory based on Virtex 7 specific primitives with two read/write ports. ``OBSOLETE, use DP_BRAM or DP_BRAM_XILINX!`` +**DP_BMEM_V7** - Structural implementation of dual clock BRAM memory based on Virtex 7 specific primitives with two read/write ports. + +.. warning:: + .. deprecated:: 0.7.0 + This component is obsolete and is a candidate for removal, use **DP_BRAM** or **DP_BRAM_XILINX** instead. **DP_BRAM** - Behavioral implementation of single clock BRAM memory with two read/write port. Optimized for Xilinx and Intel FPGAs. @@ -25,21 +31,28 @@ The read latency is 0 clock cycles. Optimized for same FPGAs as GEN_LUTRAM. **NP_LUTRAM_PRO** - An alternative version of NP_LUTRAM, which uses additional multiple frequency clock signal. Ports are registered and the read latency is 2 clock cycles. Expert knowledge is required to use this component! -**SDP_BMEM** - Behavioral implementation of dual clock BRAM memory with one read port and one write port. Located in the same folder as DP_BMEM. ``OBSOLETE, use DP_BRAM or DP_BRAM_XILINX!`` +**SDP_BMEM** - Behavioral implementation of dual clock BRAM memory with one read port and one write port. Located in the same folder as DP_BMEM. + +.. warning:: + .. deprecated:: 0.7.0 + This component is obsolete and is a candidate for removal, use **DP_BRAM** or **DP_BRAM_XILINX** instead. **SDP_BMEM_V7** - Structural implementation of dual clock BRAM memory based on Virtex 7 specific primitives with one read port and one write port. -Located in the same folder as DP_BMEM_V7. ``OBSOLETE, use SDP_BRAM or SDP_BRAM_XILINX!`` +Located in the same folder as DP_BMEM_V7. + +.. warning:: + .. deprecated:: 0.7.0 + This component is obsolete and is a candidate for removal, use **DP_BRAM** or **DP_BRAM_XILINX** instead. **SDP_BRAM** - Structural implementation of dual clock BRAM memory based on Xilinx and Intel specific primitives (xpm_memory_sdpram, altera_syncram) with one read port and one write port. It supports the byte enable feature! -**MP_BRAM** - Generic multiported single clock BRAM memory based on **SDP_BRAM**. Currently supports only 1 write port. Amount of read ports is not restricted. Also supports byte enable -feature. +**MP_BRAM** - Generic multi-port single-clock BRAM memory based on **SDP_BRAM**. -**LVT_MEM** - Multiported memory implemented suitable for shallow memories, supports generic amount of write/read ports and has customizable read during write behaviour. +**LVT_MEM** - Multi-port memory is suitable for shallow memories, supports a generic amount of write/read ports, and has customizable read during write behavior. **SDP_BRAM_BEHAV** - Another behavioral implementation of dual clock BRAM memory with one read port and one write port. -Located in the same folder as SDP_BRAM. ``OBSOLETE, use DP_BRAM or DP_BRAM_XILINX!`` +Located in the same folder as SDP_BRAM. **SDP_BRAM_XILINX** - Structural implementation of dual clock BRAM memory based on Xilinx specific primitives with one read port and one write port. Only for Xilinx FPGAs. @@ -48,7 +61,11 @@ Allows setting type of memory (LUT, BRAM, URAM) or automatic mode. Optimized for **SDP_URAM_XILINX** - Structural implementation of single clock URAM memory based on Xilinx specific primitives with one read port and one write port. Only for Xilinx UltraScale+ FPGAs. -**SP_BMEM** - Old behavioral implementation of single clock BRAM memory with one read/write port. ``OBSOLETE, use SP_BRAM or SP_BRAM_XILINX!`` +**SP_BMEM** - Old behavioral implementation of a single-clock BRAM memory with one read/write port. + +.. warning:: + .. deprecated:: 0.7.0 + This component is obsolete and is a candidate for removal, use **SP_BRAM** or **SP_BRAM_XILINX** instead. **SP_BRAM** - Behavioral implementation of single clock BRAM memory with one read/write port. Optimized for Xilinx and Intel FPGAs. @@ -56,6 +73,9 @@ Allows setting type of memory (LUT, BRAM, URAM) or automatic mode. Optimized for **SP_URAM_XILINX** - Structural implementation of single clock URAM memory based on Xilinx specific primitives with one read/write port. Only for Xilinx UltraScale+ FPGAs. +**_CLEAR** - Wrap around **** with additional clear logic. +Detailed :ref:`documentation can be found here`. + .. toctree:: :maxdepth: 1 :hidden: @@ -64,6 +84,7 @@ Allows setting type of memory (LUT, BRAM, URAM) or automatic mode. Optimized for comp/base/mem/sdp_bram/readme comp/base/mem/mp_bram/readme comp/base/mem/lvt_mem/readme + comp/base/mem/mem_clear/readme .. comp/base/mem/ References diff --git a/release/_sources/mfb.rst.txt b/release/_sources/mfb.rst.txt index e432cfc3a..cd527e19a 100644 --- a/release/_sources/mfb.rst.txt +++ b/release/_sources/mfb.rst.txt @@ -9,37 +9,37 @@ Components using the MFB bus are typically located in the ``comp/mfb_tools/`` di :maxdepth: 1 :caption: Content: - comp/mfb_tools/readme - comp/mfb_tools/flow/reconfigurator/readme + comp/mfb_tools/debug/gen_loop_switch/readme + comp/mfb_tools/debug/generator/readme + comp/mfb_tools/edit/frame_appender/readme + comp/mfb_tools/edit/frame_extender/readme + comp/mfb_tools/edit/frame_trimmer/readme + comp/mfb_tools/flow/crossbarx_stream2/readme + comp/mfb_tools/flow/cutter_simple/readme + comp/mfb_tools/flow/dropper/readme + comp/mfb_tools/flow/enabler/readme + comp/mfb_tools/flow/frame_masker/readme comp/mfb_tools/flow/frame_packer/readme comp/mfb_tools/flow/frame_unpacker/readme - comp/mfb_tools/flow/splitter_simple/readme + comp/mfb_tools/flow/loopback/readme + comp/mfb_tools/flow/merger/readme comp/mfb_tools/flow/merger_simple/readme - comp/mfb_tools/flow/cutter_simple/readme - comp/mfb_tools/flow/dropper/readme comp/mfb_tools/flow/metadata_insertor/readme - comp/mfb_tools/flow/transformer/readme + comp/mfb_tools/flow/packet_delayer/readme comp/mfb_tools/flow/pipe/readme - comp/mfb_tools/flow/merger/readme - comp/mfb_tools/flow/splitter/readme - comp/mfb_tools/flow/enabler/readme comp/mfb_tools/flow/rate_limiter/readme - comp/mfb_tools/flow/packet_delayer/readme + comp/mfb_tools/flow/reconfigurator/readme + comp/mfb_tools/flow/splitter/readme + comp/mfb_tools/flow/splitter_simple/readme comp/mfb_tools/flow/timestamp_limiter/readme - comp/mfb_tools/flow/loopback/readme - comp/mfb_tools/flow/crossbarx_stream2/readme - comp/mfb_tools/flow/frame_masker/readme - comp/mfb_tools/edit/frame_trimmer/readme - comp/mfb_tools/edit/frame_extender/readme - comp/mfb_tools/logic/crossbarx_stream/readme - comp/mfb_tools/logic/checksum_calculator/readme + comp/mfb_tools/flow/transformer/readme comp/mfb_tools/logic/auxiliary_signals/readme - comp/mfb_tools/storage/pd_asfifo/readme - comp/mfb_tools/storage/pd_asfifo_simple/readme + comp/mfb_tools/logic/checksum_calculator/readme + comp/mfb_tools/logic/crossbarx_stream/readme comp/mfb_tools/storage/asfifox/readme - comp/mfb_tools/storage/fifox/readme comp/mfb_tools/storage/crossbarx_output_buffer/readme - comp/mfb_tools/debug/gen_loop_switch/readme - comp/mfb_tools/debug/generator/readme + comp/mfb_tools/storage/fifox/readme + comp/mfb_tools/storage/pd_asfifo/readme + comp/mfb_tools/storage/pd_asfifo_simple/readme .. Add more references here... diff --git a/release/_sources/mi.rst.txt b/release/_sources/mi.rst.txt index 26eb15ee5..01d1d10c8 100644 --- a/release/_sources/mi.rst.txt +++ b/release/_sources/mi.rst.txt @@ -8,7 +8,6 @@ Components using the MI bus are typically located in the ``comp/mi_tools/`` dire :maxdepth: 1 :caption: Content: - comp/mi_tools/readme comp/mi_tools/async/readme comp/mi_tools/pipe/readme comp/mi_tools/indirect_access/readme diff --git a/release/_sources/misc.rst.txt b/release/_sources/misc.rst.txt index b6c3b7d8e..bcce26a96 100644 --- a/release/_sources/misc.rst.txt +++ b/release/_sources/misc.rst.txt @@ -3,8 +3,6 @@ Miscellaneous **ADC_SENSORS** - Controller of the Temperature and Voltage ADC IPs for Intel Stratix 10 FPGA. It is controlled via the MI bus. ``CANDIDATE FOR MOVE to CTRLs folder!`` -**CLK_GEN** - Old clock generator, is used in some simulation only. ``CANDIDATE FOR REMOVAL!`` - **CROSSBARX** - This unit performs data transfer between two buffers connected on SRC_BUF and DST_BUF interfaces based on Transactions passed on the TRANS interface. Detailed :ref:`documentation can be found here`. @@ -13,12 +11,8 @@ Detailed :ref:`documentation can be found here`. **EVENT_COUNTER** - The Event Counter is a debuging unit for receiving statistics of occurence frequency of a certain event. It is made accessible through MI interface using the Event Counter MI Wrapper. Detailed :ref:`documentation can be found here`. -**FIFO_PIPE** - Generic pipe implemented using registers and FIFO memory in almost full mode. ``UNUSED, CANDIDATE FOR REMOVAL!`` - **FIRST_ONE_DETECTOR** - Old behavioral implementation of first one detector in vector. ``CANDIDATE FOR REMOVAL! Use FIRST_ONE from base logic!`` -**HYPER_PIPE** - Generic hyper pipe implemented using registers, optimized for Intel Stratix 10 FPGA. ``UNUSED, CANDIDATE FOR REMOVAL!`` - **ID32** - Identification component, is a small component, which is used to detect design inside FPGA. Informations are stored inside registers which are accessible through dedicated 32 bit interface. **INTERRUPT_MANAGER** - Interrupt agregator module, TODO description. @@ -39,8 +33,6 @@ so that they are placed one after another with the needed inter-packet gaps and **TRANS_SORTER** - This unit converts out-of-order confirmations of transactions to the original order of the transactions. Detailed :ref:`documentation can be found here`. -**WATCHDOG** - Data flow watchdog module, which checks whether the monitored bus is not stuck. TODO - .. toctree:: :maxdepth: 1 :hidden: diff --git a/release/_sources/mvb.rst.txt b/release/_sources/mvb.rst.txt index f4d623c3d..3f0756bfb 100644 --- a/release/_sources/mvb.rst.txt +++ b/release/_sources/mvb.rst.txt @@ -1,5 +1,5 @@ -MVB Tools -========= +MVB Components +============== This chapter contains the specifications of the MVB bus and a description of the components that use MVB bus. The MVB bus was developed to support multiple items/values in one clock cycle. @@ -9,9 +9,9 @@ Components using the MFB bus are typically located in the ``comp/mvb_tools/`` di :maxdepth: 1 :caption: Content: - comp/mvb_tools/readme comp/mvb_tools/flow/channel_router/readme comp/mvb_tools/flow/discard/readme + comp/mvb_tools/flow/item_collision_resolver/readme comp/mvb_tools/flow/merge_items/readme comp/mvb_tools/flow/merge_streams/readme comp/mvb_tools/flow/demux/readme @@ -21,5 +21,6 @@ Components using the MFB bus are typically located in the ``comp/mvb_tools/`` di comp/mvb_tools/flow/operation/readme comp/mvb_tools/flow/merge_streams_ordered/readme comp/mvb_tools/flow/mvb2mfb/readme + comp/mvb_tools/flow/gate/readme comp/mvb_tools/storage/lookup_table/readme comp/mvb_tools/storage/fifox/readme diff --git a/release/_sources/ndk_build/readme.rst.txt b/release/_sources/ndk_build/readme.rst.txt index 3a3e25859..44cec39b1 100644 --- a/release/_sources/ndk_build/readme.rst.txt +++ b/release/_sources/ndk_build/readme.rst.txt @@ -83,6 +83,41 @@ Variables ``ENTITY``, ``ENTITY_BASE`` and ``ARCHGRP`` are predefined (provided) Prefer to use :tcl:`lappend MOD "myfile.vhd"` instead of :tcl:`set MOD "$MOD myfile.vhd"`, because the ``lappend`` better express the operation and is faster. +PLATFORM_TAGS +~~~~~~~~~~~~~ + +In the situation, when a platform (build tool: Quartus, Vivado, simulator: Questa Sim, etc.) supports various architectures / implementation schemes, +the PLATFORM_TAGS list variable can be used to distinguish, which source file should be included into project. + +List of available platforms: + +- **xilinx** - platform supports complete set of Xilinx component and products +- **altera** - platform supports complete set of Intel/Altera component and products + +.. - **empty** - platform, on which the empty architectures are enabled; this is used e.g. when user wants to check the code syntax even if the codebase for toplevel is not completed yet. + +.. If the component doesn't have common/universal platform implementation and the "empty" tag is not in PLATFORM_TAGS, the process should exit with error. + +Those tags are currently not available, but show the way of potential extension and usage: + +- **vivado:ge_2024.0** - Vivado version is equal or greater than 2024.0 (this doesn't means automatic comparison) +- **xilinx:usp** - Restrict for UltraScale+ platform. +- **xilinx:sim:gty** - Inculde simulation models from highspeed transceivers. + +Priority for PLATFORM_TAGS +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The PLATFORM_TAGS list can be potentially used also for specifying preference/priority (latter position in list means higher priority): +``set PLATFORM_TAGS "xilinx:bram:behav xilinx:bram:macro"`` +The priority can be easily overriden simply by appending item to the list. +(Also the ``lsearch`` can be easily used as returns -1 for non-existing item, which means lowest priority.) +In general, the highest priority tag from set of supported tags can be obtained by the ``proc nb_preference_filter {PLATFORM_TAGS SUPPORTED_TAGS}`` + + .. code-block:: tcl + + set SUPPORTED_PLATFORM_TAGS "xilinx altera" + set TARGET_TAG [nb_preference_filter $PLATFORM_TAGS $SUPPORTED_PLATFORM_TAGS] + .. _extra file properties: List of properties used in MOD variables @@ -350,3 +385,107 @@ The (incomplete) list of SYNTH_FLAGS array items - USE_XPM_LIBRARIES: includes XPM_CDC XPM_MEMORY XPM_FIFO in Vivado projects For other values and their purpose see the Vivado.inc.tcl or Quartus.inc.tcl file in the build directory. + +Device Tree nodes +----------------- + +For the software to find internal firmware components, a *Device Tree (DT)* is +used. This provides a tree of available parts (called nodes in the DT +terminology) of the design that can be accessed from the host without +restriction. A developer creates TCL procedures that generate nodes to *DT +string (DTS)* for the components he finds fit. Since the creation of the DTS can +be challenging, there are several TCL procedures provided that simplify the +process. These procedures are contained within the ``dts_templates.tcl`` file +with clarifying comments. The following examples provide an overview of their +usage. + +Example 1 +~~~~~~~~~ + +This presents a least viable code that creates a node +``dma_calypte_rx_perf_cntrs0`` with the base address *0x8000* +and the size *0x30*. It also contains a compatible string +``cesnet,dma_calypte_rx_perf_cntrs``. The string property is appended to ``dts`` +variable that contains a reference to the required Device Tree string (DTS). + +.. code-block:: tcl + + dts_create_node dts "dma_calypte_rx_perf_cntrs0" { + dts_appendprop_comp_node dts 0x8000 0x30 "cesnet,dma_calypte_rx_perf_cntrs" + } + +Example 2 +~~~~~~~~~ + +A second, more complex example demonstrates addition of multiple properties to a +node called ``dma_ctrl_calypte_$dir$id`` (string can be further adjusted through +parameters ``dir`` and ``id``). + +.. code-block:: tcl + + proc dts_dma_calypte_ctrl {DTS dir id base pcie} { + upvar 1 $DTS dts + + dts_create_node dts "dma_ctrl_calypte_$dir$id" { + # Adding compatible string "cesnet,dma_ctrl_calypte_$dir" and the + # reg property with base address $base and the size 0x80. + dts_appendprop_comp_node dts $base 0x80 "cesnet,dma_ctrl_calypte_$dir" + # Integer property called "version" with the value 0x10000 + dts_appendprop_int dts "version" 0x10000 + # Integer prperty "pcie" with the value of $pcie + dts_appendprop_int dts "pcie" $pcie + + # The addition of custom properties (customly named) can be done + # through a standard "append" macro. + if { $dir == "tx" } { + append dts "data_buff = <&dma_calypte_tx_data_buff$id>;" + append dts "hdr_buff = <&dma_calypte_tx_hdr_buff$id>;" + } + append dts "params = <&dma_params_$dir$pcie>;" + } + } + +Example 3 +~~~~~~~~~ + +This example shows how complex node with multiple subnodes is created. The parent +node is called ``dma_calypte_test_core0`` and contains subnodes +``mfb_loopback0``, ``dma_calypte_debug_core0``, ``dma_calypte_latency_meter0`` +and ``dma_calypte_reset_fsm0``. Further nesting of nodes is possible as can be +seen when adding the ``mfb_generator0`` node. Each of the called procedures +contain a reference to the same DTS from the ``dts`` variable. + +.. code-block:: tcl + + proc dts_calypte_test_core {DTS base_addr} { + # Populate reference from the calling environment + upvar 1 $DTS dts + + set LOOPBACK_BASE_ADDR [expr $base_addr + 0x0] + set TX_DBG_CORE_BASE_ADDR [expr $base_addr + 0x10000] + set LATENCY_METER_BASE_ADDR [expr $base_addr + 0x20000] + set RESET_FSM_BASE_ADDR [expr $base_addr + 0x30000] + + dts_create_node dts "dma_calypte_test_core0" { + + dts_create_node dts "mfb_loopback0" { + dts_appendprop_comp_node dts $LOOPBACK_BASE_ADDR 8 "cesnet,mfb_loopback" + } + + dts_create_node dts "dma_calypte_debug_core0" { + dts_appendprop_comp_node dts $TX_DBG_CORE_BASE_ADDR 0x1600 "cesnet,dma_calypte_debug_core" + + dts_create_node dts "mfb_generator0" { + dts_appendprop_comp_node dts [expr $TX_DBG_CORE_BASE_ADDR+0x8000] 0x40 "cesnet,mfb_generator" + } + } + + dts_create_node dts "dma_calypte_latency_meter0" { + dts_appendprop_comp_node dts $LATENCY_METER_BASE_ADDR 0x30 "cesnet,dma_calypte_latency_meter" + } + + dts_create_node dts "dma_calypte_reset_fsm0" { + dts_appendprop_comp_node dts $RESET_FSM_BASE_ADDR 0x4 "cesnet,dma_calypte_reset_fsm" + } + } + } diff --git a/release/_sources/ndk_cards/amd/alveo-u200/readme.rst.txt b/release/_sources/ndk_cards/amd/alveo-u200/readme.rst.txt index b77f1e7ca..b2636ea48 100644 --- a/release/_sources/ndk_cards/amd/alveo-u200/readme.rst.txt +++ b/release/_sources/ndk_cards/amd/alveo-u200/readme.rst.txt @@ -21,8 +21,8 @@ NDK firmware support - :ref:`CMAC in the Network Module ` - PCIe cores that are supported in the NDK firmware: - :ref:`USP in the PCIe Module ` - - See the ``/ndk/card/alveo-u200/config/card_conf.tcl`` file for supported PCIe configurations. -- Makefile targets for building the NDK firmware (valid for NDK-APP-Minimal, may vary for other apps): + - See the ``/card/amd/alveo-u200/config/card_conf.tcl`` file for supported PCIe configurations. +- Makefile targets for building the NDK firmware (valid for Minimal app, may vary for other apps): - Use ``make 100g2`` command for firmware with 2x100GbE (default). - Use ``make 100g0`` command for firmware with CMAC disabled but DMAs and Application core remaining (experimental feature). - Support for booting the NDK firmware using the nfb-boot tool: diff --git a/release/_sources/ndk_cards/amd/alveo-u55c/readme.rst.txt b/release/_sources/ndk_cards/amd/alveo-u55c/readme.rst.txt index 34f673562..eb21589b6 100644 --- a/release/_sources/ndk_cards/amd/alveo-u55c/readme.rst.txt +++ b/release/_sources/ndk_cards/amd/alveo-u55c/readme.rst.txt @@ -21,11 +21,12 @@ NDK firmware support - :ref:`CMAC in the Network Module ` - PCIe cores that are supported in the NDK firmware: - :ref:`USP in the PCIe Module ` - - See the ``/ndk/card/alveo-u55c/config/card_conf.tcl`` file for supported PCIe configurations. -- Makefile targets for building the NDK firmware (valid for NDK-APP-Minimal, may vary for other apps): + - See the ``/card/amd/alveo-u55c/config/card_conf.tcl`` file for supported PCIe configurations. +- Makefile targets for building the NDK firmware (valid for Minimal app, may vary for other apps): - Use ``make 100g2`` command for firmware with 2x100GbE (default). - Support for booting the NDK firmware using the nfb-boot tool: - - NO, use JTAG (see below). + - YES, starting with the nfb-framework version 6.24.0. + - OR use JTAG (see below). Programming the device ^^^^^^^^^^^^^^^^^^^^^^ diff --git a/release/_sources/ndk_cards/amd/vcu118/readme.rst.txt b/release/_sources/ndk_cards/amd/vcu118/readme.rst.txt index be5a08d1d..3e4038b30 100644 --- a/release/_sources/ndk_cards/amd/vcu118/readme.rst.txt +++ b/release/_sources/ndk_cards/amd/vcu118/readme.rst.txt @@ -21,8 +21,8 @@ NDK firmware support - :ref:`CMAC in the Network Module ` - PCIe cores that are supported in the NDK firmware: - :ref:`USP in the PCIe Module ` - - See the ``/ndk/card/vcu118/config/card_conf.tcl`` file for supported PCIe configurations. -- Makefile targets for building the NDK firmware (valid for NDK-APP-Minimal, may vary for other apps): + - See the ``/card/amd/vcu118/config/card_conf.tcl`` file for supported PCIe configurations. +- Makefile targets for building the NDK firmware (valid for Minimal app, may vary for other apps): - Use ``make 100g2`` command for firmware with 2x100GbE (default). - Use ``make 100g0`` command for firmware with CMAC disabled but DMAs and Application core remaining (experimental feature). - Support for booting the NDK firmware using the nfb-boot tool: diff --git a/release/_sources/ndk_cards/bittware/ia-420f/readme.rst.txt b/release/_sources/ndk_cards/bittware/ia-420f/readme.rst.txt index da5ee2d72..77f20c763 100644 --- a/release/_sources/ndk_cards/bittware/ia-420f/readme.rst.txt +++ b/release/_sources/ndk_cards/bittware/ia-420f/readme.rst.txt @@ -21,8 +21,8 @@ NDK firmware support - :ref:`E-Tile in the Network Module ` - PCIe cores that are supported in the NDK firmware: - :ref:`P-Tile in the PCIe Module ` - - See the ``/ndk/card/ia-420f/config/card_conf.tcl`` file for supported PCIe configurations. -- Makefile targets for building the NDK firmware (valid for NDK-APP-Minimal, may vary for other apps): + - See the ``/card/bittware/ia-420f/config/card_conf.tcl`` file for supported PCIe configurations. +- Makefile targets for building the NDK firmware (valid for Minimal app, may vary for other apps): - Use ``make 100g2`` command for firmware with 2x100GE (default). - Use ``make 25g8`` command for firmware with 8x25GE. - Use ``make 10g8`` command for firmware with 8x10GE. @@ -39,8 +39,8 @@ Boot instructions (initial) Before you can use the nfb-boot tool, you must write the initial NDK firmware to flash memory using a regular JTAG programmer. - After the NDK firmware build is complete, you will have a bitstream file called ``my_bitstream.sof``. -- Use the ``/ndk/cards/ia-420f/scripts/generate_jic.sh my_bitstream.sof my_bitstream.sof`` command to convert the two bitstream files to .jic format for flash memory. -- On the host PC where the card is connected, write the .jic bitstream to the flash memory with the command ``/ndk/cards/ia-420f/scripts/write_jic.sh my_bitstream.jic``. +- Use the ``/cards/bittware/ia-420f/scripts/generate_jic.sh my_bitstream.sof my_bitstream.sof`` command to convert the two bitstream files to .jic format for flash memory. +- On the host PC where the card is connected, write the .jic bitstream to the flash memory with the command ``/cards/bittware/ia-420f/scripts/write_jic.sh my_bitstream.jic``. - You must power off and on the PC to power cycle it completely. Only then is the new NDK firmware loaded into the FPGA. .. note:: diff --git a/release/_sources/ndk_cards/intel/dk-dev-1sdx-p/readme.rst.txt b/release/_sources/ndk_cards/intel/dk-dev-1sdx-p/readme.rst.txt index 4247df16c..d4fa2095e 100644 --- a/release/_sources/ndk_cards/intel/dk-dev-1sdx-p/readme.rst.txt +++ b/release/_sources/ndk_cards/intel/dk-dev-1sdx-p/readme.rst.txt @@ -23,8 +23,8 @@ NDK firmware support - :ref:`E-Tile in the Network Module ` - PCIe cores that are supported in the NDK firmware: - :ref:`P-Tile in the PCIe Module ` - - See the ``/ndk/card/dk-dev-1sdx-p/config/card_conf.tcl`` file for supported PCIe configurations. -- Makefile targets for building the NDK firmware (valid for NDK-APP-Minimal, may vary for other apps): + - See the ``/card/intel/dk-dev-1sdx-p/config/card_conf.tcl`` file for supported PCIe configurations. +- Makefile targets for building the NDK firmware (valid for Minimal app, may vary for other apps): - Use ``make 100g2`` command for firmware with 2x100GE (default). - Use ``make 25g8`` command for firmware with 8x25GE. - Use ``make 10g8`` command for firmware with 8x10GE. @@ -39,8 +39,8 @@ Boot instructions ^^^^^^^^^^^^^^^^^ - After the NDK firmware build is complete, you will have a bitstream file called ``my_bitstream.sof``. -- Use the ``/ndk/cards/dk-dev-1sdx-p/scripts/generate_pof.sh my_bitstream.sof`` command to convert the bitstream file to .pof format for flash memory. -- On the host PC where the card is connected, write the .pof bitstream to the flash memory with the command ``/ndk/cards/dk-dev-1sdx-p/scripts/write_pof.sh my_bitstream.pof``. +- Use the ``/cards/intel/dk-dev-1sdx-p/scripts/generate_pof.sh my_bitstream.sof`` command to convert the bitstream file to .pof format for flash memory. +- On the host PC where the card is connected, write the .pof bitstream to the flash memory with the command ``/cards/intel/dk-dev-1sdx-p/scripts/write_pof.sh my_bitstream.pof``. - You must power off and on the PC to power cycle it completely. Only then is the new NDK firmware loaded into the FPGA. .. note:: diff --git a/release/_sources/ndk_cards/intel/dk-dev-agi027res/readme.rst.txt b/release/_sources/ndk_cards/intel/dk-dev-agi027res/readme.rst.txt index 3ae46ae69..d33317726 100644 --- a/release/_sources/ndk_cards/intel/dk-dev-agi027res/readme.rst.txt +++ b/release/_sources/ndk_cards/intel/dk-dev-agi027res/readme.rst.txt @@ -23,8 +23,8 @@ NDK firmware support - :ref:`F-Tile in the Network Module ` - PCIe cores that are supported in the NDK firmware: - :ref:`R-Tile in the PCIe Module ` - - See the ``/ndk/card/dk-dev-agi027res/config/card_conf.tcl`` file for supported PCIe configurations. -- Makefile targets for building the NDK firmware (valid for NDK-APP-Minimal, may vary for other apps): + - See the ``/card/intel/dk-dev-agi027res/config/card_conf.tcl`` file for supported PCIe configurations. +- Makefile targets for building the NDK firmware (valid for Minimal app, may vary for other apps): - Use ``make 400g1`` command for firmware with 1x400GbE (default). - Use ``make 200g2`` command for firmware with 2x200GbE. - Use ``make 100g4`` command for firmware with 4x100GbE. @@ -43,8 +43,8 @@ Boot instructions ^^^^^^^^^^^^^^^^^ - After the NDK firmware build is complete, you will have a bitstream file called ``my_bitstream.sof``. -- Use the ``/ndk/cards/dk-dev-agi027res/scripts/generate_pof.sh my_bitstream.sof`` command to convert the bitstream file to .pof format for flash memory. -- On the host PC where the card is connected, write the .pof bitstream to the flash memory with the command ``/ndk/cards/dk-dev-1sdx-p/scripts/write_pof.sh my_bitstream.pof``. +- Use the ``/cards/intel/dk-dev-agi027res/scripts/generate_pof.sh my_bitstream.sof`` command to convert the bitstream file to .pof format for flash memory. +- On the host PC where the card is connected, write the .pof bitstream to the flash memory with the command ``/cards/intel/dk-dev-1sdx-p/scripts/write_pof.sh my_bitstream.pof``. - You must power off and on the PC to power cycle it completely. Only then is the new NDK firmware loaded into the FPGA. .. note:: diff --git a/release/_sources/ndk_cards/prodesign/pd-falcon/readme.rst.txt b/release/_sources/ndk_cards/prodesign/pd-falcon/readme.rst.txt index ae073296d..f39ca6f8d 100644 --- a/release/_sources/ndk_cards/prodesign/pd-falcon/readme.rst.txt +++ b/release/_sources/ndk_cards/prodesign/pd-falcon/readme.rst.txt @@ -21,8 +21,8 @@ NDK Firmware Support - :ref:`E-Tile in the Network Module ` - Supported PCIe Cores in the NDK Firmware: - H-Tile is supported. - - Refer to the ``/ndk/cards/prodesign/pd-falcon/config/card_conf.tcl`` file for supported PCIe configurations. -- Makefile Targets for Building NDK Firmware (for NDK-APP-Minimal, may vary for other applications): + - Refer to the ``/cards/prodesign/pd-falcon/config/card_conf.tcl`` file for supported PCIe configurations. +- Makefile Targets for Building NDK Firmware (for Minimal app, may vary for other applications): - Use the ``make 100g2`` command to build firmware with 2x100GE (default). - Support for Booting NDK Firmware Using the nfb-boot Tool: - Not supported. Refer to the card manual for booting instructions. @@ -35,7 +35,7 @@ Boot Instructions ^^^^^^^^^^^^^^^^^ - First, build the NDK firmware. Note that the first build will fail—this is expected. -- After the first failed implementation, run the ``/ndk/cards/prodesign/pd-falcon/src/ip/htile_pcie_fix.sh`` script to fix the generated H-Tile IP core. +- After the first failed implementation, run the ``/cards/prodesign/pd-falcon/src/ip/htile_pcie_fix.sh`` script to fix the generated H-Tile IP core. - The next build should complete successfully. - Once the NDK firmware build is complete, a bitstream file will be generated. - To load the firmware, attach the USB-Blaster II Download Cable via the Edge Debug Board to the card. diff --git a/release/_sources/ndk_cards/reflexces/agi-fh400g/readme.rst.txt b/release/_sources/ndk_cards/reflexces/agi-fh400g/readme.rst.txt index e54f5b250..23367ef1b 100644 --- a/release/_sources/ndk_cards/reflexces/agi-fh400g/readme.rst.txt +++ b/release/_sources/ndk_cards/reflexces/agi-fh400g/readme.rst.txt @@ -10,7 +10,7 @@ ReflexCES XpressSX AGI-FH400G - PCIe conectors: Edge connector + optional HSI connectors - `FPGA Card Website `_ - FPGA specification: - - FPGA part number: ``AGIB027R29A1E2VR0`` or ``AGIB027R29A1E2VR3`` + - FPGA part number: ``AGIB027R29A1E2V``, ``AGIB027R29A1E2VR3``, ``AGIB027R29A1E2VR0`` - Ethernet Hard IP: F-Tile (up to 400G Ethernet) - PCIe Hard IP: R-Tile (up to PCIe Gen5 x16) @@ -21,8 +21,8 @@ NDK firmware support - :ref:`F-Tile in the Network Module ` - PCIe cores that are supported in the NDK firmware: - :ref:`R-Tile in the PCIe Module ` - - See the ``/ndk/card/agi-fh400g/config/card_conf.tcl`` file for supported PCIe configurations. -- Makefile targets for building the NDK firmware (valid for NDK-APP-Minimal, may vary for other apps): + - See the ``/card/reflexces/agi-fh400g/config/card_conf.tcl`` file for supported PCIe configurations. +- Makefile targets for building the NDK firmware (valid for Minimal app, may vary for other apps): - Use ``make 400g1`` command for firmware with 1x400GbE (default). - Use ``make 200g2`` command for firmware with 2x200GbE. - Use ``make 100g4`` command for firmware with 4x100GbE. @@ -40,18 +40,19 @@ NDK firmware support Board Revision ^^^^^^^^^^^^^^ -This card exists in multiple revisions. The default revision for the firmware build is BOARD_REV=0. +This card exists in multiple revisions. The default revision for the firmware build is BOARD_REV=1. The correct revision for the firmware build can be selected using the Makefile parameter BOARD_REV, for example as follows: .. code:: - $ cd /build/agi-fh400g - $ make BOARD_REV=1 + $ cd /apps/minimal/build/agi-fh400g + $ make BOARD_REV=2 **Allowed values of BOARD_REV parameter** -- ``BOARD_REV=0`` - The first prototypes use FPGA part number ``AGIB027R29A1E2VR0``. +- ``BOARD_REV=2`` - The production revision uses FPGA part number ``AGIB027R29A1E2V``. - ``BOARD_REV=1`` - The second board revision uses FPGA part number ``AGIB027R29A1E2VR3``. +- ``BOARD_REV=0`` - The first prototypes use FPGA part number ``AGIB027R29A1E2VR0``. Board Test Scripts ^^^^^^^^^^^^^^^^^^ @@ -74,7 +75,7 @@ The test scripts themselves are written in `Python 3 `_ .. code:: bash - $ pytest --html=test_pcie.html --self-contained-html ndk/cards/agi-fh400g/bts/test_pcie.py + $ pytest --html=test_pcie.html --self-contained-html cards/reflexces/agi-fh400g/bts/test_pcie.py The whole test takes approximately 14 minutes. The test script displays test results and generates an HTML file containing a detailed description of the test results. diff --git a/release/_sources/ndk_cards/silicom/fb2cghh/readme.rst.txt b/release/_sources/ndk_cards/silicom/fb2cghh/readme.rst.txt index 22313aa82..23e377a9b 100644 --- a/release/_sources/ndk_cards/silicom/fb2cghh/readme.rst.txt +++ b/release/_sources/ndk_cards/silicom/fb2cghh/readme.rst.txt @@ -21,8 +21,8 @@ NDK firmware support - :ref:`CMAC in the Network Module ` - PCIe cores that are supported in the NDK firmware: - :ref:`USP in the PCIe Module ` - - See the ``/ndk/card/fb2cghh/config/card_conf.tcl`` file for supported PCIe configurations. -- Makefile targets for building the NDK firmware (valid for NDK-APP-Minimal, may vary for other apps): + - See the ``/card/silicom/fb2cghh/config/card_conf.tcl`` file for supported PCIe configurations. +- Makefile targets for building the NDK firmware (valid for Minimal app, may vary for other apps): - Use ``make 100g2`` command for firmware with 2x100GbE (default). - Support for booting the NDK firmware using the nfb-boot tool: - YES. diff --git a/release/_sources/ndk_cards/silicom/fb4cgg3/readme.rst.txt b/release/_sources/ndk_cards/silicom/fb4cgg3/readme.rst.txt index ed52ae07c..4963e3dde 100644 --- a/release/_sources/ndk_cards/silicom/fb4cgg3/readme.rst.txt +++ b/release/_sources/ndk_cards/silicom/fb4cgg3/readme.rst.txt @@ -21,8 +21,8 @@ NDK firmware support - :ref:`CMAC in the Network Module ` - PCIe cores that are supported in the NDK firmware: - :ref:`USP in the PCIe Module ` - - See the ``/ndk/card/fb4cgg3/config/card_conf.tcl`` file for supported PCIe configurations. -- Makefile targets for building the NDK firmware (valid for NDK-APP-Minimal, may vary for other apps): + - See the ``/card/silicom/fb4cgg3/config/card_conf.tcl`` file for supported PCIe configurations. +- Makefile targets for building the NDK firmware (valid for Minimal app, may vary for other apps): - Use ``make 100g2`` command for firmware with 2x100GbE for fb2CGg3 card only (default). - Use ``make 100g4`` command for firmware with 4x100GbE for fb4CGg3 card only. - Support for booting the NDK firmware using the nfb-boot tool: diff --git a/release/_sources/ndk_cards/silicom/n6010/readme.rst.txt b/release/_sources/ndk_cards/silicom/n6010/readme.rst.txt index 3a3c8a8fc..e46739cd6 100644 --- a/release/_sources/ndk_cards/silicom/n6010/readme.rst.txt +++ b/release/_sources/ndk_cards/silicom/n6010/readme.rst.txt @@ -21,7 +21,8 @@ NDK firmware support - :ref:`E-Tile in the Network Module ` - PCIe cores that are supported in the NDK firmware: - :ref:`P-Tile in the PCIe Module ` -- Makefile targets for building the NDK firmware (valid for NDK-APP-Minimal, may vary for other apps): + - See the ``/card/silicom/n6010/config/card_conf.tcl`` file for supported PCIe configurations. +- Makefile targets for building the NDK firmware (valid for Minimal app, may vary for other apps): - Use ``make 100g2`` command for firmware with 2x100GE (default). - Use ``make 25g8`` command for firmware with 8x25GE. - Use ``make 10g8`` command for firmware with 8x10GE. diff --git a/release/_sources/ndk_cards/terasic/a2700/readme.rst.txt b/release/_sources/ndk_cards/terasic/a2700/readme.rst.txt new file mode 100644 index 000000000..fd17db8b0 --- /dev/null +++ b/release/_sources/ndk_cards/terasic/a2700/readme.rst.txt @@ -0,0 +1,67 @@ +.. _card_terasic-a2700: + +Terasic A2700 +---------------- + +- Card information: + - Vendor: Terasic + - Name: Mercury A2700 Accelerator Card + - Ethernet ports: 2x QSFP-DD + - 400G + - up to 200G (200/100/40/25/10) - Unsupported + - PCIe conectors: Edge connector + - `FPGA Card Website `_ +- FPGA specification: + - FPGA part number: ``AGIB027R29A1E2VB`` + - Ethernet Hard IP: F-Tile (up to 400G Ethernet) + - PCIe Hard IP: R-Tile (up to PCIe Gen5 x16) + - Four DDR4 SO-DIMM Socket + - One shared with HPS + +NDK firmware support +^^^^^^^^^^^^^^^^^^^^ + +- Ethernet cores that are supported in the NDK firmware: + - :ref:`F-Tile in the Network Module ` +- PCIe cores that are supported in the NDK firmware: + - :ref:`R-Tile in the PCIe Module ` + - See the ``/card/terasic/a2700/config/card_conf.tcl`` file for supported PCIe configurations. +- Makefile targets for building the NDK firmware (valid for Minimal app, may vary for other apps): + - Use ``make 400g1`` command for firmware with 1x400GE (default). +- Support for booting the NDK firmware using the nfb-boot tool: + - YES, starting with the nfb-framework version 6.24.0. + +.. note:: + + To build the NDK firmware for this card, you must have the Intel Quartus Prime Pro installed, including a valid license. + Design requires enabled bifurcation (x8x8) on target machine + +Boot instructions (initial) +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Supported boot is handled by the Secure Device Manager (SDM), which has its own 1Gb flash to store Factory and User defined image. +To enable this method, it is necessary to set the switches on the board as follows: +- Ensure that the MSEL[2:0] switch on the board is set to 'Active Serial Normal' mode - MSEL[2:0] = 3'b011 + - Set SW4 to 2'b01 and SW5 to 2'b10. + - The SW4(1) set to 0 to load user image or to 1 to load factory image after power up. +- For more detailed description refer to `Mercury A2700 User Manual `_ + +Before you can use the nfb-boot tool, you must write the initial NDK firmware to flash memory using a regular JTAG programmer. +It is possible to use Micro-USB port marked as 'USB/UART' on the Terasic card for this purpose. + +- Build your application calling ``make`` in the build folder with 'Makefile'. +- After the NDK firmware build is complete, you will have a bitstream file called ``my_bitstream.sof``. +- Use the ``NDK-FPGA_root_directory/cards/terasic/a2700/scripts/generate_jic.sh my_bitstream.sof my_bitstream.sof`` command to convert the two bitstream files to .jic format for flash memory. + - This creates a flash image and sets address spaces in the flash to hold the factory and user images. +- On the host PC where the card is connected, write the .jic bitstream to the flash memory with the command ```_ and an `API for generating read/write memory requests `_. These are transferred via the :ref:`MI bus ` in the NDK firmware. This memory-oriented bus is wired throughout the NDK firmware, and each part, including the application, has its own allocated address space. You can find more about the MI and the available address space in the :ref:`MI bus interconnect ` chapter. -The description of the components with a specific address space is implemented in the NDK using a :ref:`DeviceTree `. Also, the Application must have its own DeviceTree description, which can further refer to the internal components and their address spaces. It is a good idea to take inspiration from the `NDK-APP-Minimal application DeviceTree file `_ when creating a DeviceTree file for your application. +The description of the components with a specific address space is implemented in the NDK using a :ref:`DeviceTree `. Also, the Application must have its own DeviceTree description, which can further refer to the internal components and their address spaces. It is a good idea to take inspiration from the `Minimal application DeviceTree file `_ when creating a DeviceTree file for your application. Ports and generics of the Application ************************************* diff --git a/release/_sources/ndk_core/doc/configuration.rst.txt b/release/_sources/ndk_core/doc/configuration.rst.txt index e1b579ab8..c2bedbe00 100644 --- a/release/_sources/ndk_core/doc/configuration.rst.txt +++ b/release/_sources/ndk_core/doc/configuration.rst.txt @@ -15,7 +15,7 @@ Build system files The following table provides an overview of files used for building a project/design. .. note:: - Path ``build/card`` reduced to build, ``ndk/core/intel`` reduced to ``core``, ``ndk/cards/vendor/dev`` reduced to card. + Path ``apps/minimal/card`` reduced to ``build``, ``cards/vendor/dev`` reduced to card. The placeholder {TOOL} refers to the tool-specific filename, for example: Vivado, Quartus. .. list-table:: Configuration files @@ -62,7 +62,7 @@ The following table provides an overview of files used for building a project/de * - core/config/core_func.tcl - Configuration - helper procedures used in _conf.tcl (e.g. ParsePcieConf) - * - core/Modules.tcl + * - core/top/Modules.tcl - Build - Top-level components and modules common for all designs (TSU, DMA, etc.) * - core/{TOOL}.inc.tcl @@ -77,14 +77,14 @@ The following table provides an overview of files used for building a project/de .. _ndk_core_configuration: -Parametrizing NDK-CORE design +Parametrizing NDK-FPGA design ============================= -The files in the ``/intel/config`` directory and the -``/intel/core.mk`` file contain CORE parameters. Some +The files in the ``/core/config`` directory and the +``/core/core.mk`` file contain CORE parameters. Some of these parameters are configurable (more info below). The sourcing of configuration parameter files has its own hierarchy, which is shown in the :ref:`fig_const_hierarchy`. This section describes the -configuration files used in the case of NDK-CORE design. For the description of +configuration files used in the case of NDK-FPGA design. For the description of the application and card-specific configuration, see following sections on this page. .. _fig_const_hierarchy: @@ -106,7 +106,7 @@ core_conf.tcl ^^^^^^^^^^^^^ This file provides a listing of all parameters that can be changed by the user. Each parameter contains a comment with allowed values and the meaning of -these values. Because the NDK-CORE design is independent of the underlying +these values. Because the NDK-FPGA design is independent of the underlying platform (e.g. card type) there are many allowed combinations of parameters. However, the user can find many combinations of parameters that are unsupported and may cause errors during the synthesis/implementation process. The user can add @@ -145,7 +145,7 @@ file. An example of a conditional assignment follows: The third purpose of this file is to implement statements that check compatible combinations of parameters. When an incompatible combination is detected, the TCL shell will raise an error and stop the compilation process. You should -implement these checks only for the parameters used in the NDK-CORE. +implement these checks only for the parameters used in the NDK-FPGA. .. _core_mk_include: @@ -184,9 +184,9 @@ provide an *ARCHGRP* list to pass specific constants across the source file hier Modules.tcl file obtains such a list from its parent Modules.tcl file. It allows further adjustments of the ARCHGRP list(s) of its descendant(s). -The parameters specified in the NDK-CORE repository are passed using the +The parameters specified in the NDK-FPGA repository are passed using the ``CORE_ARCHGRP`` associative array. The array is initialized in the -``/intel/common.inc.tcl`` file. Parameters are specified in +``/core/common.inc.tcl`` file. Parameters are specified in the ``core_conf.tcl`` and ``core_const.tcl`` files. This means that the configuration parameters of a chosen card are visible in this file and can be added to the array. The associative array was chosen for clarity purposes. Because the @@ -194,7 +194,7 @@ ARCHGRP is declared as a simple list, the associative array is converted to it and added to the ``FPGA`` entity. As the ARCHGRP list is passed through the hierarchy, it is converted back to the associative array when a specific array value is needed. An example is shown in the -``/intel/Modules.tcl`` file. +``/core/top/Modules.tcl`` file. .. _core_config_vhdl_pkg_const: @@ -237,7 +237,7 @@ The system provides mechanism to configure card specific parameters. File description ---------------- The file structure is similar to the one described in the configuration of the -`NDK-CORE` design. +`NDK-FPGA` design. card_conf.tcl ^^^^^^^^^^^^^ @@ -245,7 +245,7 @@ This file lists user-configurable parameters and their possible values in the comments. The file contains parameters relevant to a specific card. Those parameters are mostly tied to the underlying hardware, like the number of Ethernet ports or the PCIe generation of the used PCIe core. The purpose of this file is the -same as that of the ``core_conf.tcl`` file in the `NDK-CORE` repository. The only +same as that of the ``core_conf.tcl`` file in the `NDK-FPGA` repository. The only difference is that it has a higher priority. .. _card_conf_card_const_tcl: @@ -289,7 +289,7 @@ Further work with parameters application use. Passing the parameter values to other parts of the design or build system is -very similar to the case of `NDK-CORE`. +very similar to the case of `NDK-FPGA`. Passing through Modules.tcl ^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -307,7 +307,7 @@ Adding constants to the VHDL package ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It is recommended to add card-specific constants to the ``combo_user_const`` VHDL package in `card_const.tcl` file. The way of adding these constants was described in -the :ref:`core_config_vhdl_pkg_const` section in the documentation of NDK-CORE +the :ref:`core_config_vhdl_pkg_const` section in the documentation of NDK-FPGA configuration. .. _ndk_app_configuration: @@ -322,7 +322,7 @@ build process. Configuration files ------------------- -The configuration of the application is less constrained than `NDK-CORE` and +The configuration of the application is less constrained than `NDK-FPGA` and card configuration. The application repository provides three files in which the user application is or can be configured. @@ -385,11 +385,11 @@ This section contains specific recipes for achieving specific goals. I need to include specific component in CORE depending on a given parameter value --------------------------------------------------------------------------------- 1. First, you should write your parameter to the - ``core/intel/config/core_conf.tcl`` with a specific value (if the parameter - stays only in the ``core/intel/config/core_conf.tcl``) or with a default + ``core/config/core_conf.tcl`` with a specific value (if the parameter + stays only in the ``core/config/core_conf.tcl``) or with a default value (if the parameter will be set in other configuration files). 2. Then add this parameter to the *CORE_ARCHGRP* array in the - ``core/intel/common.inc.tcl`` file. + ``core/common.inc.tcl`` file. .. code-block:: tcl @@ -471,7 +471,7 @@ What can I do with the `core_const.tcl` file error "Unsupported value of MY_PARAM_1: $MY_PARAM_1!" } -* You can add a parameter value to the generated VHDL package, which is then icluded in +* You can add a parameter value to the generated VHDL package, which is then included in the `fpga.vhd` and `fpga_common.vhd` components: .. code-block:: tcl diff --git a/release/_sources/ndk_core/doc/eth.rst.txt b/release/_sources/ndk_core/doc/eth.rst.txt index 8ded3ed88..8d3dc5e28 100644 --- a/release/_sources/ndk_core/doc/eth.rst.txt +++ b/release/_sources/ndk_core/doc/eth.rst.txt @@ -43,7 +43,7 @@ There are two main blocks, the Network Module Core and the Network Module Logic. The number of their instances depends on the number of physical ports of the target card. The following sections describe each of the main blocks in more detail: :ref:`Network Module Core ` and :ref:`Network Module Logic `. Then there is the QSFP Control unit that enables the configuration of the QSFP transceivers of the NIC over the I2C bus. -The Network Module has three separate address spaces (see the `MI address space package `_). +The Network Module has three separate address spaces (see the `MI address space package `_). Each is represented by one of the three MI buses. Two (MI and MI PHY) are connected to MI Splitters, and one (MI PMD) is directly connected to QSFP Control. The MI PHY Splitter forwards requests to one or more instances of the Network Module Core. @@ -300,7 +300,7 @@ If there are multiple channels, the following two outputs are connected to the s MAC Lite pairs for the following channels are connected subsequently in the same way. The MAC Lites are offset by 0x200, and MAC Lites in different ports are additionally offset by 0x2000 (enough for 8 Ethernet channels per port). However, that is not the concern of the MI Splitter here but in the top-level of the :ref:`Network Module `. -To create a complete address of a MAC Lite register, add the address of the register, the channel offset, the port offset, and the offset of the Network Module Logic (MI_ADC_PORT_NETMOD in the `MI address space package `_). +To create a complete address of a MAC Lite register, add the address of the register, the channel offset, the port offset, and the offset of the Network Module Logic (MI_ADC_PORT_NETMOD in the `MI address space package `_). To show the connections of the MAC Lites, an example of the MAC Lite address spaces for a configuration with two 4x25 GE ports follows. Notation: TX_MAC_LITE(port_id)(channel_id), RX_MAC_LITE(port_id)(channel_id). diff --git a/release/_sources/ndk_core/doc/how_to_start.rst.txt b/release/_sources/ndk_core/doc/how_to_start.rst.txt index 0d30d3670..cfae359ec 100644 --- a/release/_sources/ndk_core/doc/how_to_start.rst.txt +++ b/release/_sources/ndk_core/doc/how_to_start.rst.txt @@ -11,12 +11,12 @@ What dependencies are needed to build an FPGA firmware - The NDK build system is for Linux operating systems only. We recommend using any RHEL-compatible OS, for example, Rocky Linux 8+. - The dtc/libfdt package is required. On RHEL-compatible OS, you can use the following command: ``sudo dnf install dtc``. - To build the FPGA firmware, you must have Intel Quartus Prime Pro or Xilinx Vivado (depending on the target card) installed, including a valid license. -- You can always find information about the required version of the synthesis tools (Quartus/Vivado) in the ``/README.md`` file. +- You can always find information about the required version of the synthesis tools (Quartus/Vivado) in the ``/README.md`` file. How to build an FPGA firmware with an NDK-based application =========================================================== -- Go to the ``/build//`` directory. +- Go to the ``/apps/minimal/build//`` directory. - Check or modify the ``app_conf.tcl`` file, where you can change the firmware configuration. - Build the FPGA firmware with Quartus/Vivado by the ``make`` command in the same folder. - If you do not have a DMA IP (it is not part of the open-source NDK), you must use the ``make DMA_TYPE=0`` command to disable the DMA and create a loopback instead. @@ -60,7 +60,7 @@ How to check the NDK firmware in the FPGA The NDK platform uses the `nfb-info tool `_ to read the basic information about the NDK firmware from the FPGA card. Using this tool, we can check that our NDK firmware has booted correctly. An example of the output of the nfb-info tool can be seen below: -.. code-block:: bash +.. code-block:: text $ nfb-info --------------------------------------- Board info ---- diff --git a/release/_sources/ndk_core/doc/mi.rst.txt b/release/_sources/ndk_core/doc/mi.rst.txt index 91f8bf477..0b1fc4125 100644 --- a/release/_sources/ndk_core/doc/mi.rst.txt +++ b/release/_sources/ndk_core/doc/mi.rst.txt @@ -13,9 +13,9 @@ The MI bus interconnection allows easy access to implemented Control/Status Regi The main allocation of the MI address space ******************************************* -An address range of 26 bits is available for the whole NDK firmware. It is divided between the individual parts of the design. The main allocation of the MI address space must be identically described in the VHDL package ``/ndk/core/intel/src/mi_addr_space_pkg.vhd`` and in the DeviceTree file of the NDK-CORE ``/ndk/core/intel/src/DevTree.tcl``. This allocation can also be found below: +An address range of 26 bits is available for the whole NDK firmware. It is divided between the individual parts of the design. The main allocation of the MI address space must be identically described in the VHDL package ``/core/top/mi_addr_space_pkg.vhd`` and in the DeviceTree file of the NDK-CORE ``/core/top/DevTree.tcl``. This allocation can also be found below: -.. code-block:: +.. code-block:: text 0x00000000-0x000000FF -- Test space (debug R/W registers) 0x00000100-0x00000FFF -- Reserved space diff --git a/release/_sources/ndk_core/doc/testing.rst.txt b/release/_sources/ndk_core/doc/testing.rst.txt index bec556a66..49d5e9ea5 100644 --- a/release/_sources/ndk_core/doc/testing.rst.txt +++ b/release/_sources/ndk_core/doc/testing.rst.txt @@ -3,6 +3,10 @@ NDK testing ----------- +.. warning:: + + Attention, this chapter may not be up to date, we are looking for a volunteer to update it. + This chapter describes how the NDK firmware and its HDL components can be tested: - Test R/W access to scratch registers in the NDK firmware (:ref:`see below `). @@ -38,9 +42,9 @@ GLS module tutorial The NDK firmware may include a GLS module that is instantiated in each DMA stream between the application core and the DMA controller. The GLS module is used for testing purposes and contains HW packet generators, speed meters, and datapath switches. Please refer to the :ref:`GLS module documentation ` for a more information. -The GLS module also comes with a Python script (``/ndk/ofm/comp/mfb_tools/debug/gen_loop_switch/sw/gls_mod.py``) that can be used to quickly perform several basic tests (modes). For example, you can measure the throughput of the NDK firmware. A list of tests can be obtained by running this script without parameters: +The GLS module also comes with a Python script (``/comp/mfb_tools/debug/gen_loop_switch/sw/gls_mod.py``) that can be used to quickly perform several basic tests (modes). For example, you can measure the throughput of the NDK firmware. A list of tests can be obtained by running this script without parameters: -.. code-block:: +.. code-block:: text $ python3 gls_mod.py gls_mod.py mode [port_list] @@ -68,7 +72,7 @@ Some tests require an available DMA controller; others require an external QSFP If an external QSFP loopback is connected, the transmitted packets are received back into the FPGA, where the script measures the receiving speed. In this test, packets pass through the application core so that the measured throughput corresponds with the throughput of the implemented application. The throughput calculation considers L2 packets from the destination MAC address to the end of the payload. Below is an example of the script output after running test 1: -.. code-block:: +.. code-block:: text $ python3 gls_mod.py 1 Test # 1 started... diff --git a/release/app-minimal.html b/release/app-minimal.html index 3869a1d0e..3481ef3fc 100644 --- a/release/app-minimal.html +++ b/release/app-minimal.html @@ -6,7 +6,7 @@ - Minimal NDK application — NDK-FPGA Docs documentation + Minimal NDK application — NDK-FPGA documentation @@ -19,8 +19,8 @@ - - + + @@ -32,7 +32,7 @@ - NDK-FPGA Docs + NDK-FPGA
@@ -42,15 +42,7 @@
@@ -94,7 +101,7 @@
@@ -266,8 +273,8 @@

The application MI offsets - - + +

diff --git a/release/async.html b/release/async.html index f45b59aff..f4b1acbb0 100644 --- a/release/async.html +++ b/release/async.html @@ -6,7 +6,7 @@ - Asynchronous modules — NDK-FPGA Docs documentation + Asynchronous modules — NDK-FPGA documentation @@ -32,7 +32,7 @@ - NDK-FPGA Docs + NDK-FPGA
@@ -42,11 +42,7 @@
@@ -102,7 +108,7 @@
diff --git a/release/base.html b/release/base.html index 25cfc1bcf..e9f499a1f 100644 --- a/release/base.html +++ b/release/base.html @@ -6,7 +6,7 @@ - Basic Tools — NDK-FPGA Docs documentation + Basic Tools — NDK-FPGA documentation @@ -20,7 +20,7 @@ - + @@ -32,7 +32,7 @@ - NDK-FPGA Docs + NDK-FPGA
@@ -42,11 +42,7 @@
@@ -99,7 +105,7 @@
@@ -120,7 +126,7 @@

Basic Tools

This chapter describes the basic components such as FIFOs, RAMs, multiplexers, encoders, decoders, etc. -The basic components are typically located in the comp/base/ directory in the OFM repository.

+The basic components are typically located in the comp/base/ directory in the NDK-FPGA repository.

Content:

@@ -139,7 +144,7 @@

Basic Tools - +

diff --git a/release/comp/base/dsp/dsp_comparator/readme.html b/release/comp/base/dsp/dsp_comparator/readme.html index cbe7af85a..3ef911d7a 100644 --- a/release/comp/base/dsp/dsp_comparator/readme.html +++ b/release/comp/base/dsp/dsp_comparator/readme.html @@ -6,7 +6,7 @@ - DSP Comparator — NDK-FPGA Docs documentation + DSP Comparator — NDK-FPGA documentation @@ -19,7 +19,7 @@ - + @@ -32,7 +32,7 @@ - NDK-FPGA Docs + NDK-FPGA
@@ -42,11 +42,7 @@
@@ -102,7 +108,7 @@
@@ -243,7 +249,7 @@