docs/test_harness: Cosmetic changes

Signed-off-by: Istvan-Zsolt Szekely <[email protected]>

docs/library/utilities/test_harness/index.rst

@@ -18,7 +18,7 @@ environment.
 Structure
 -------------------------------------------------------------------------------
 
-The base environment design is built using the test_harness_system_bd.tcl
+The base environment design is built using the ``test_harness_system_bd.tcl``
 script when a project build is started. For the base environment, we're using 2
 AXI VIPs. One is used to simulate a Processing System, while the other one is
 used to simulate a DDR memory. The simulated PS is equivalent of a single core
@@ -29,25 +29,27 @@ other IPs. The DDR memory is connected to a different interconnect, that
 manages all IP accesses to the memory. The PS and the DDR memory are directly
 connected, which gives direct access from the PS to the DDR. 3 clocking VIPs
 are used to generate clock signals for these modules. These clocking VIPs
-provide the following frequencies: 100MHz, 200MHz and 400MHz. A reset VIP is
+provide the following frequencies: 100 MHz, 200 MHz and 400 MHz. A reset VIP is
 used to reset the whole system at the bring up phase. Each one of the clocking
 VIPs have an accompanying Processor System Reset IP, that is used for
 synchronizing the reset VIPs signal with each clock domain. The PS
-interconnect's base clock is set to use the 100MHz clock signal. The DDR memory
-interconnect's base clock is set to use the 400MHz clock. An AXI Interconnect
-IP from AMD is added to handle interrupt requests coming from different IPs.
-The interrupt handling function is not yet implemented in our base design.
+interconnect's base clock is set to use the 100 MHz clock signal. The DDR
+memory interconnect's base clock is set to use the 400 MHz clock. An AXI
+Interconnect IP from AMD is added to handle interrupt requests coming from
+different IPs. The interrupt handling function is not yet implemented in our
+base design.
 
 Additional notes
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * The structure used for the testbenches allows quick prototyping for our
   existing projects on a block design level.
-* The implemented interconnect IPs can be the older AXI Interconnect or the
-  newer Smart Connect, depending on the FPGA part used in the simulation. If
-  the FPGA part is a 7-series one, then the AXI Interconnect is used, otherwise
-  the Smart Connect. There is also a variable that can be set in the TCL script
-  to force the interconnect type by hand if needed.
+* The implemented interconnect IPs can be the older ``AXI Interconnect`` or the
+  newer ``Smart Connect``, depending on the FPGA part used in the simulation.
+  If the FPGA part is a 7-series one, then the ``AXI Interconnect`` is used,
+  otherwise the ``Smart Connect``. There is also a variable called
+  ``use_smartconnect`` that can be set in the TCL script to force the
+  interconnect type by hand if needed.
 * In our simulations, we have not pushed the DDR VIP to the limits in terms of
   storage. We advise to be careful with memory management considering the
   project size, as well as the test stimulus.
@@ -70,27 +72,27 @@ Additional notes
 Simulation environment
 -------------------------------------------------------------------------------
 
-The simulation environment is defined in test_harness_env.sv packaged in
-test_harness_env_pkg. The test_harness_env class is defined here, which has a
-basic set of instructions for environment bring up.
+The simulation environment is defined in ``test_harness_env.sv`` packaged in
+``test_harness_env_pkg``. The ``test_harness_env`` class is defined here, which
+has a basic set of instructions for environment bring up.
 
 Variables
 -------------------------------------------------------------------------------
 
 The base environment imports packages for the VIPs that are used in the base
 design using PKGIFY macro. Each VIP has a separate package created upon
 instantiation and this allows these to be imported by name. The
-test_harness_env class creates agents with the help of AGENT macro, similarly
-to how the packages are imported for the VIPs, since each agent has its own
-type definition. Parameterized sequencers are created with the intent of higher
-level of abstraction. Since we're practically simulating a PS, the functions
-available in the m_axi_sequencer class are specifically created for register
-reads and writes. Same thing goes for the DDR memory, which uses the
-s_axi_sequencer class. If the designer does not have the option to generate a
-specific transaction using these sequencers, the option is still there to
-access functions from the AXI VIP agent. Virtual interfaces for the clocking
-and reset VIPs are also instantiated, so these can be accessed later in the
-simulation.
+``test_harness_env`` class creates agents with the help of AGENT macro,
+similarly to how the packages are imported for the VIPs, since each agent has
+its own type definition. Parameterized sequencers are created with the intent
+of higher level of abstraction. Since we're practically simulating a PS, the
+functions available in the ``m_axi_sequencer`` class are specifically created
+for register reads and writes. Same thing goes for the DDR memory, which uses
+the ``s_axi_sequencer`` class. If the designer does not have the option to
+generate a specific transaction using these sequencers, the option is still
+there to access functions from the AXI VIP agent. Virtual interfaces for the
+clocking and reset VIPs are also instantiated, so these can be accessed later
+in the simulation.
 
 Functions
 -------------------------------------------------------------------------------