Skip to content

Commit 2b101ef

Browse files
committed
[doc] fix grammatical issues
1 parent 70836c5 commit 2b101ef

File tree

5 files changed

+43
-37
lines changed

5 files changed

+43
-37
lines changed

doc/src/VIB.rst

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22

33
VIB Architecture
44
============
5-
The VIB architecture adds modeling support for double-level MUX topology and bent wires. In past, switch blocks have only one level of routing MUXes, whose inputs are driven by outputs of programmable blocks and routing tracks. Now outputs of programmable blocks can shape the first level of routing MUXes, while the inputs of second level involves the outputs of first level and other routing tracks. This can reduce the number and input sizes of routing MUXes.
5+
The Versatile Interconnect Block (VIB) architecture adds modeling support for double-level MUX topology and bent wires. In the past, switch blocks had only one level of routing MUXes, whose inputs were driven by outputs of programmable blocks and routing tracks. Now outputs of programmable blocks can shape the first level of routing MUXes, while the inputs of second level involves the outputs of first level and other routing tracks. This can reduce the number and input sizes of routing MUXes.
66

77
Figure 1 shows the proposed VIB architecture which is tile-based. Each tile is composed of a CLB and a VIB. Each CLB can interact with the corresponding VIB which contains all the routing programmable switches in one tile. Figure 2 shows an example of the detailed interconnect architecture in VIB. The CLB input muxes and the driving muxes of wire segments can share the same fanins. A routing path of a net with two sinks is presented red in the Figure.
88

@@ -26,7 +26,7 @@ Figure 3 shows the modeling for bent wires. A bent L-length wire is modeled as t
2626

2727
FPGA Architecture File Modification (.xml)
2828
--------------------------
29-
For original tags of FPGA architecture file see :ref:`fpga_architecture_description`.
29+
For the original tags available for the standard FPGA architecture file see :ref:`fpga_architecture_description`.
3030

3131
Modification for ``<segmentlist>`` Tag
3232
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -115,7 +115,7 @@ For example:
115115
.. arch:tag:: <multistage_muxs>content</multistage_muxs>
116116
117117
:req_param content:
118-
The detaild information for first and second MUXes.
118+
The detailed information for first and second MUXes.
119119

120120
The ``content`` of ``<multistage_muxs>`` tag consists of a ``<first_stage>`` tag and a ``<secong_stage>`` tag.
121121

@@ -248,7 +248,7 @@ For example:
248248
</fixed_layout>
249249
</vib_layout>
250250
251-
In this VIB grid layout, ``perimeter``, ``fill``, ``col`` and so on are tags in original ``<layout>`` tag to describe positions of each type of VIB block. The attibute ``type`` should correspond to the ``name`` of a ``<vib>`` tag in ``<vib_arch>``.
251+
In this VIB grid layout, ``perimeter``, ``fill``, ``col`` and so on are tags in original ``<layout>`` tag to describe positions of each type of VIB block. The attribute ``type`` should correspond to the ``name`` of a ``<vib>`` tag in ``<vib_arch>``.
252252
Besides, the ``pbtype_name`` of corresponding ``<vib>`` must be the same as the physical block type at this position.
253253

254254
In this example, IO blocks are located on the perimeter of the layout. Memory blocks are on column 5 and CLBs are on the rest positions. The ``vib_io``, ``vib_clb`` and ``vib_memory`` are different types of vib blocks corresponding to IO, CLB and memory blocks respectively.

doc/src/arch/reference.rst

Lines changed: 28 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -2695,13 +2695,13 @@ Layout
26952695
26962696
.. option:: tileable="<bool>"
26972697
2698-
Turn ``on``/``off`` tileable routing resource graph generator.
2698+
Turn ``on``/ ``off`` the tileable routing resource graph generator.
26992699

2700-
Tileable routing architecture can minimize the number of unique modules in FPGA fabric to be physically implemented.
2700+
The tileable routing architecture can minimize the number of unique modules in FPGA fabric to be physically implemented.
27012701

27022702
Technical details can be found in :cite:`XTang_FPT_2019`.
27032703

2704-
.. note:: It is strongly recommended to to enable the tileable routing architecture when you want to PnR large FPGA fabrics, which can effectively reduce the runtime.
2704+
.. note:: It is strongly recommended to enable the tileable routing architecture when you want to PnR large FPGA fabrics, which can effectively reduce the runtime.
27052705

27062706
.. option:: through_channel="<bool>"
27072707

@@ -2718,11 +2718,11 @@ Layout
27182718

27192719
.. warning:: Do NOT enable ``through_channel`` if you are not using the tileable routing resource graph generator!
27202720

2721-
.. warning:: You cannot use ``spread`` pin location for the ``height > 1`` or ``width >1`` tiles when using the tileable routing resource graph!!! Otherwise, it will cause undriven pins in your device!!!
2721+
.. warning:: You cannot use ``spread`` pin location for the ``height > 1`` or ``width >1`` tiles when using the tileable routing resource graph. Otherwise, it will cause undriven pins in your device!!!
27222722

27232723
.. option:: shrink_boundary="<bool>"
27242724

2725-
Remove all the routing wires in empty regions. This is mainly used in non-rectangle FPGAs to avoid redundant routing wires in blank area, as illustrated in :numref:`fig_shrink_boundary`.
2725+
Remove all the routing wires in empty regions. This is mainly used in non-rectangular FPGAs to avoid redundant routing wires in blank area, as illustrated in :numref:`fig_shrink_boundary`.
27262726
By default, it is ``false``.
27272727

27282728
.. _fig_shrink_boundary:
@@ -2737,10 +2737,11 @@ Layout
27372737

27382738
.. option:: perimeter_cb="<bool>"
27392739

2740-
Allow connection blocks to appear around the perimeter programmable block (mainly I/Os). This is designed to enhance routability of I/Os on perimeter. Also strongly recommended when programmable clock network is required to touch clock pins on I/Os. As illustrated in :numref:`fig_perimeter_cb`, routing tracks can access three sides of each I/O when perimeter connection blocks are created.
2741-
By default, it is ``false``.
2740+
Allow connection blocks to appear around the blocks on the perimeter of the device (mainly I/Os). This is designed to enhance routability of I/Os on perimeter. It is also strongly recommended when a programmable clock network is required to touch clock pins on I/Os. As illustrated in :numref:`fig_perimeter_cb`, routing tracks can access three sides of each I/O when perimeter connection blocks are created.
2741+
2742+
**Default:** ``false``
27422743

2743-
.. warning:: When enabled, please only place outputs at one side of I/Os. For example, outputs of an I/O on the top side can only occur on the bottom side of the I/O tile. Otherwise, routability loss may be expected, leading to some pins cannot be reachable. Enable the ``opin2all_sides`` to recover routability loss.
2744+
.. warning:: When enabled, please only place outputs at one side of I/Os. For example, outputs of an I/O on the top side can only occur on the bottom side of the I/O tile. Otherwise, routability loss may be expected, leading to some pins being unreachable. Enable the ``opin2all_sides`` to recover routability loss.
27442745

27452746
.. _fig_perimeter_cb:
27462747

@@ -2755,7 +2756,8 @@ Layout
27552756
.. option:: opin2all_sides="<bool>"
27562757

27572758
Allow each output pin of a programmable block to drive the routing tracks on all the sides of its adjacent switch block (see an illustrative example in :numref:`fig_opin2all_sides`). This can improve the routability of an FPGA fabric with an increase in the sizes of routing multiplexers in each switch block.
2758-
By default, it is ``false``.
2759+
2760+
**Default:** ``false``
27592761

27602762
.. _fig_opin2all_sides:
27612763

@@ -2770,7 +2772,8 @@ Layout
27702772
.. option:: concat_wire="<bool>"
27712773

27722774
In each switch block, allow each routing track which ends to drive another routing track on the opposite side, as such a wire can be continued in the same direction (see an illustrative example in :numref:`fig_concat_wire`). In other words, routing wires can be concatenated in the same direction across an FPGA fabric. This can improve the routability of an FPGA fabric with an increase in the sizes of routing multiplexers in each switch block.
2773-
By default, it is ``false``.
2775+
2776+
**Default:** ``false``
27742777

27752778
.. _fig_concat_wire:
27762779

@@ -2785,9 +2788,8 @@ Layout
27852788
.. option:: concat_pass_wire="<bool>"
27862789

27872790
In each switch block, allow each routing track which passes to drive another routing track on the opposite side, as such a pass wire can be continued in the same direction (see an illustrative example in :numref:`fig_concat_pass_wire`). This can improve the routability of an FPGA fabric with an increase in the sizes of routing multiplexers in each switch block.
2788-
By default, it is ``false``.
2789-
2790-
.. warning:: Please enable this option if you are looking for device support which is created by any release which is before v1.1.541!!!
2791+
2792+
**Default:** ``false``
27912793

27922794
.. _fig_concat_wire:
27932795

@@ -2813,14 +2815,14 @@ Switch Block
28132815

28142816
.. option:: sub_type="<string>"
28152817

2816-
Connecting type for pass tracks in each switch block
2817-
The supported connecting patterns are ``subset``, ``universal`` and ``wilton``, being the same as VPR capability
2818-
If not specified, the pass tracks will the same connecting patterns as start/end tracks, which are defined in ``type``
2818+
Connecting type for pass tracks in each switch block.
2819+
The supported connecting patterns are ``subset``, ``universal`` and ``wilton``, being the same as the capability of VPR.
2820+
If not specified, the pass tracks will have the same connecting patterns as start/end tracks, which are defined in ``type``
28192821

28202822
.. option:: sub_Fs="<int>"
28212823

28222824
Connectivity parameter for pass tracks in each switch block. Must be a multiple of 3.
2823-
If not specified, the pass tracks will the same connectivity as start/end tracks, which are defined in ``fs``
2825+
If not specified, the pass tracks will have the same connectivity as start/end tracks, which are defined in ``fs``.
28242826

28252827
A quick example which defines a switch block
28262828
- Starting/ending routing tracks are connected in the ``wilton`` pattern
@@ -2837,7 +2839,8 @@ A quick example which defines a switch block
28372839
Routing Segments
28382840
~~~~~~~~~~~~~~~~
28392841

2840-
OpenFPGA suggests users to give explicit names for each routing segement in ``<segmentlist>``
2842+
When using tileable architecture, it is strongly recommended to give explicit names
2843+
for each routing segment in ``<segmentlist>``.
28412844
This is used to link ``circuit_model`` to routing segments.
28422845

28432846
A quick example which defines a length-4 uni-directional routing segment called ``L4`` :
@@ -2848,7 +2851,7 @@ A quick example which defines a length-4 uni-directional routing segment called
28482851
<segment name="L4" freq="1" length="4" type="undir"/>
28492852
</segmentlist>
28502853
2851-
.. note:: Currently, OpenFPGA only supports uni-directional routing architectures
2854+
.. note:: Currently, tileable architecture only supports uni-directional routing architectures.
28522855

28532856
Direct Interconnect
28542857
~~~~~~~~~~~~~~~~~~~
@@ -2868,7 +2871,7 @@ The original direct connections in the directlist section are documented in :ref
28682871
28692872
.. note:: These options are required
28702873

2871-
In the OpenFPGA architecture file, you may define additional attributes for each VPR's direct connection:
2874+
In the tileable architecture file, you may define additional attributes for each VPR's direct connection:
28722875

28732876
.. code-block:: xml
28742877
@@ -2926,7 +2929,7 @@ In the OpenFPGA architecture file, you may define additional attributes for each
29262929
Enhanced Connection Block
29272930
~~~~~~~~~~~~~~~~~~~~~~~~~
29282931

2929-
The direct connection can also drive routing multiplexers of connection blocks. When such connection occures in a connection block, it is called enhanced connection block.
2932+
A direct connection can also drive routing multiplexers of connection blocks. When such connection occurs in a connection block, it is called an enhanced connection block.
29302933
:numref:`fig_ecb` illustrates the difference between a regular connection block and an enhanced connection block.
29312934

29322935
.. _fig_ecb:
@@ -2956,7 +2959,7 @@ Direct connections can be inside a tile or across two tiles. Currently, across m
29562959

29572960
Example of feedback connections inside a tile for enhanced connection block
29582961

2959-
For instance, VPR architecture defines feedback connections like:
2962+
For instance, a non-tileable VPR architecture defines:
29602963

29612964
.. code-block:: xml
29622965
@@ -2987,15 +2990,15 @@ Inter-tile Connections
29872990

29882991
For this example, we will study a scan-chain implementation. The description could be:
29892992

2990-
In VPR architecture:
2993+
In a non-tileable architecture:
29912994

29922995
.. code-block:: xml
29932996
29942997
<directlist>
29952998
<direct name="scff_chain" from_pin="clb.sc_out" to_pin="clb.sc_in" x_offset="0" y_offset="-1" z_offset="0"/>
29962999
</directlist>
29973000
2998-
In OpenFPGA architecture:
3001+
In a tileable architecture:
29993002

30003003
.. code-block:: xml
30013004
@@ -3014,7 +3017,7 @@ In OpenFPGA architecture:
30143017

30153018
In this figure, the red arrows represent the initial direct connection. The green arrows represent the point to point connection to connect all the columns of CLB.
30163019

3017-
A point to point connection can be applied in different ways than showed in the example section. To help the designer implement his point to point connection, a truth table with our new parameters id provided below.
3020+
A point to point connection can be applied in different ways than showed in the example section. To help the designer implement their point to point connection, a truth table with our new parameters is provided below.
30183021

30193022
:numref:`fig_p2p_trtable` provides all possible variable combination and the connection it will generate.
30203023

libs/libarchfpga/src/read_xml_arch_file_vib.h

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,5 @@
1+
#pragma once
2+
13
#include <vector>
24
#include "physical_types.h"
35

libs/librrgraph/src/base/rr_graph_view.h

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -462,9 +462,11 @@ class RRGraphView {
462462
return node_storage_.edge_sink_node(edge);
463463
}
464464

465-
/** @brief Get the source node for the iedge'th edge from specified RRNodeId.
466-
* This method should generally not be used, and instead first_edge and
467-
* last_edge should be used.*/
465+
/**
466+
* @brief Get the source node for the iedge'th edge from specified RRNodeId.
467+
* @note This method should generally not be used, and instead first_edge and
468+
* last_edge should be used.
469+
*/
468470
inline RRNodeId edge_source_node(RRNodeId id, t_edge_size iedge) const {
469471
return node_storage_.edge_source_node(id, iedge);
470472
}

vpr/src/base/setup_vib_grid.cpp

Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -302,11 +302,10 @@ static void set_vib_grid_block_type(int priority,
302302

303303
if (priority < max_priority_type_loc.priority) {
304304
//Lower priority, do not override
305-
#ifdef VERBOSE
306-
VTR_LOG("Not creating block '%s' at (%zu,%zu) since overlaps block '%s' at (%zu,%zu) with higher priority (%d > %d)\n",
307-
type->name.c_str(), x_root, y_root, max_priority_type_loc.type->name, max_priority_type_loc.x, max_priority_type_loc.y,
308-
max_priority_type_loc.priority, priority);
309-
#endif
305+
std::string msg = vtr::string_fmt("Not creating block '%s' at (%zu,%zu) since overlaps block '%s' at (%zu,%zu) with higher priority (%d > %d)\n",
306+
type->get_name().c_str(), x_root, y_root, max_priority_type_loc.type->get_name().c_str(), max_priority_type_loc.x, max_priority_type_loc.y,
307+
max_priority_type_loc.priority, priority);
308+
VTR_LOG_DEBUG(msg.c_str());
310309
return;
311310
}
312311

0 commit comments

Comments
 (0)