Skip to content

Commit 422fabe

Browse files
KA7EKA7E
committed
Merge remote-tracking branch 'origin/add_enable_pin_counting_filter_option_to_recluster_util' into add_enable_pin_counting_filter_option_to_recluster_util
2 parents aeab99c + d2cfec1 commit 422fabe

File tree

68 files changed

+2954
-1238
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

68 files changed

+2954
-1238
lines changed

‎.github/workflows/containers.yml

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,24 @@
11
name: Containers
22

33
on:
4+
# We want to run the CI when anything is pushed to master.
5+
# Since master is a protected branch this only happens when a PR is merged.
6+
# This is a double check in case the PR was stale and had some issues.
47
push:
8+
branches:
9+
- master
510
pull_request:
611
workflow_dispatch:
712
schedule:
813
- cron: '0 0 * * 0' # weekly
914

15+
# We want to cancel previous runs for a given PR or branch / ref if another CI
16+
# run is requested.
17+
# See: https://docs.github.com/en/actions/using-jobs/using-concurrency
18+
concurrency:
19+
group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
20+
cancel-in-progress: true
21+
1022
jobs:
1123

1224
Image:

‎.github/workflows/test.yml

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,24 @@
11
name: Test
22

33
on:
4+
# We want to run the CI when anything is pushed to master.
5+
# Since master is a protected branch this only happens when a PR is merged.
6+
# This is a double check in case the PR was stale and had some issues.
47
push:
8+
branches:
9+
- master
510
pull_request:
611
workflow_dispatch:
712
schedule:
813
- cron: '0 0 * * *' # daily
914

15+
# We want to cancel previous runs for a given PR or branch / ref if another CI
16+
# run is requested.
17+
# See: https://docs.github.com/en/actions/using-jobs/using-concurrency
18+
concurrency:
19+
group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
20+
cancel-in-progress: true
21+
1022
env:
1123
# default compiler for all non-compatibility tests
1224
MATRIX_EVAL: "CC=gcc-11 && CXX=g++-11"
@@ -74,6 +86,9 @@ jobs:
7486
NUM_CORES: ${{ matrix.cores }}
7587

7688
- name: Upload test results
89+
# We always want the test results to be uploaded, even when cancelled.
90+
# https://docs.github.com/en/actions/learn-github-actions/expressions#always
91+
if: ${{ always() }}
7792
# TODO: This runnner is running on a self-hosted CPU. In order to upgrade
7893
# to v4, need to upgrade the machine to support node20.
7994
uses: actions/upload-artifact@v3

‎.gitmodules

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,5 +3,4 @@
33
url = https://github.com/catchorg/Catch2.git
44
[submodule "libs/EXTERNAL/sockpp"]
55
path = libs/EXTERNAL/sockpp
6-
#url = [email protected]:fpagliughi/sockpp.git
7-
url = [email protected]:w0lek/sockpp.git # fork where in branch v1.0.0_no_complication_warnings there are compilation warnings fixes for upstream tag v1.0.0 of sockpp
6+
url = https://github.com/w0lek/sockpp.git # fork where in branch v1.0.0_no_complication_warnings there are compilation warnings fixes for upstream tag v1.0.0 of sockpp

‎dev/pylint_check.py

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -60,6 +60,7 @@
6060
repo_path / "doc/_exts/rrgraphdomain/__init__.py",
6161
repo_path / "doc/_exts/sdcdomain/__init__.py",
6262
repo_path / "doc/_exts/archdomain/__init__.py",
63+
repo_path / "doc/_exts/constraintsdomain/__init__.py",
6364
repo_path / "vpr/scripts/compare_timing_reports.py",
6465
repo_path / "vpr/scripts/profile/util.py",
6566
repo_path / "vpr/scripts/profile/parse_and_plot_detailed.py",

‎doc/_exts/constraintsdomain/__init__.py

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
from sphinxcontrib.domaintools import custom_domain
2+
from sphinx.util.docfields import *
3+
4+
5+
def setup(app):
6+
app.add_domain(
7+
custom_domain(
8+
"VPRConstraintsDomain",
9+
name="vpr_constraints",
10+
label="Place and Route Constraints",
11+
elements=dict(
12+
tag=dict(
13+
objname="Attribute",
14+
indextemplate="pair: %s; Tag Attribute",
15+
fields=[
16+
GroupedField(
17+
"required_parameter", label="Required Attributes", names=["req_param"]
18+
),
19+
GroupedField(
20+
"optional_parameter", label="Optional Attributes", names=["opt_param"]
21+
),
22+
Field("required", label="Tag Required", names=["required"]),
23+
],
24+
),
25+
),
26+
)
27+
)

‎doc/src/arch/reference.rst

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1955,7 +1955,7 @@ Wire Segments
19551955
The content within the ``<segmentlist>`` tag consists of a group of ``<segment>`` tags.
19561956
The ``<segment>`` tag and its contents are described below.
19571957
1958-
.. arch:tag:: <segment axis="{x|y}" name="unique_name" length="int" type="{bidir|unidir}" freq="float" Rmetal="float" Cmetal="float">content</segment>
1958+
.. arch:tag:: <segment axis="{x|y}" name="unique_name" length="int" type="{bidir|unidir}" res_type="{GCLK|GENERAL}" freq="float" Rmetal="float" Cmetal="float">content</segment>
19591959
19601960
19611961
:opt_param axis:
@@ -1975,6 +1975,10 @@ The ``<segment>`` tag and its contents are described below.
19751975
19761976
.. note:: ``longline`` is only supported on with ``bidir`` routing
19771977
1978+
:opt_param res_type:
1979+
Specifies whether the segment belongs to the general or a clock routing network. If this tag is not specified, the resource type for
1980+
the segment is considered to be GENERAL (i.e. regular routing).
1981+
19781982
:req_param freq:
19791983
The supply of routing tracks composed of this type of segment.
19801984
VPR automatically determines the percentage of tracks for each segment type by taking the frequency for the type specified and dividing with the sum of all frequencies.
@@ -2092,6 +2096,7 @@ Specifing a Clock Architecture
20922096

20932097
The element ``<clocknetworks>`` contains three sub-elements that collectively describe the clock architecture: the wiring parameters ``<metal_layers>``, the clock distribution ``<clock_network>``, and the clock connectivity ``<clock_routing>``.
20942098

2099+
.. note:: The clock network architecture defined in this structure is assigned the fixed default name ``"clock_network"``. When the user wants to specify a net to be routed through the defined clock architecture using a :ref:`global routing constraints file <global_routing_constraints>`, the network name attribute in the constraint tag must be set to ``"clock_network"``.
20952100

20962101
.. _clock_arch_example:
20972102

‎doc/src/conf.py

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -45,6 +45,7 @@
4545
"sphinx_markdown_tables",
4646
"sdcdomain",
4747
"archdomain",
48+
"constraintsdomain",
4849
"rrgraphdomain",
4950
"myst_parser",
5051
"sphinx.ext.autodoc",

‎doc/src/vpr/command_line_usage.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -360,11 +360,11 @@ Use the options below to override this default naming behaviour.
360360

361361
.. option:: --read_vpr_constraints <file>
362362

363-
Reads the :ref:`floorplanning constraints <vpr_constraints_file>` that packing and placement must respect from the specified XML file.
363+
Reads the :ref:`VPR constraints <vpr_constraints>` that the flow must respect from the specified XML file.
364364

365365
.. option:: --write_vpr_constraints <file>
366366

367-
Writes out new :ref:`floorplanning constraints <vpr_constraints_file>` based on current placement to the specified XML file.
367+
Writes out new :ref:`floorplanning constraints <placement_constraints>` based on the current placement to the specified XML file.
368368

369369
.. option:: --read_router_lookahead <file>
370370

‎doc/src/vpr/global_routing_constraints.rst

Lines changed: 108 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,108 @@
1+
Global Routing Constraints
2+
==========================
3+
.. _global_routing_constraints:
4+
5+
VPR allows users to designate specific nets in the input netlist as global and define the routing model for the global nets by utilizing a VPR constraints XML file. These routing constraints for global nets are specified inside the VPR constraints file in XML format, as described in the following section.
6+
7+
A Global Routing Constraints File Example
8+
------------------------------------------
9+
10+
.. code-block:: xml
11+
:caption: An example of a global routing constraints file in XML format.
12+
:linenos:
13+
14+
<vpr_constraints tool_name="vpr">
15+
<global_route_constraints>
16+
<set_global_signal name="clock*" route_model="dedicated_network" network_name="clock_network"/>
17+
</global_route_constraints>
18+
</vpr_constraints>
19+
20+
21+
Global Routing Constraints File Format
22+
---------------------------------------
23+
.. _global_routing_constraints_file_format:
24+
25+
.. vpr_constraints:tag:: <global_route_constraints>content</global_route_constraints>
26+
27+
Content inside this tag contains a group of ``<set_global_signal>`` tags that specify the global nets and their assigned routing methods.
28+
29+
.. vpr_constraints:tag:: <set_global_signal name="string" route_model="{ideal|route|dedicated_network}" network_name="string"/>
30+
31+
:req_param name: The name of the net to be assigned as global. Regular expressions are also accepted.
32+
:req_param route_model: The route model for the specified net.
33+
34+
* ``ideal``: The net is not routed. There would be no delay for the global net.
35+
36+
* ``route``: The net is routed similarly to other nets using generic routing resources.
37+
38+
* ``dedicated_network``: The net will be routed through a dedicated clock network.
39+
40+
:req_param network_name: The name of the clock network through which the net is routed. This parameter is required when ``route_model="dedicated_network"``.
41+
42+
43+
Dedicated Clock Networks
44+
--------------------------
45+
46+
Users can define a clock architecture in two ways. First, through the architecture description outlined in section :ref:`Clocks <clock_architecture>`. By using the ``<clocknetworks>`` tag, users can establish a single clock architecture with the fixed default name "clock_network". When routing a net through the dedicated network described with this tag, the network name must be set to ``"clock_network"``.
47+
48+
Alternatively, users can define a custom clock network architecture by inputting a custom resource routing graph. In this approach, users can specify various clock routing networks, such as a global clock network and multiple regional clock networks. There are three main considerations for defining a clock network through a custom RR graph definition, as described in the following sections.
49+
50+
Virtual Sinks Definition for Clock Networks
51+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
52+
For VPR to route global nets within defined clock networks, there needs to be a virtual sink node defined in the RR graph per each clock network. This virtual sink, which is of the type ``"SINK"``, must have incoming edges from all drive points of the clock network. The two-stage router used for global net routing will initially route to the virtual sink (which serves as the entry point of the clock network) in the first stage and then from the entry point to the actual sink of the net in the second stage.
53+
54+
To indicate that a node represents a clock network virtual sink, users can utilize the ``"clk_res_type"`` attribute on a node setting it to ``"VIRTUAL_SINK"``.
55+
56+
Distinguishing Between Clock Networks
57+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
58+
Given the support for multiple clock networks, VPR needs a way to distinguish between different virtual sinks belonging to various clock networks. This is achieved through the optional ``"name"`` attribute for the rr_node, accepting a string used as the clock network name. Therefore, when the ``"clk_res_type"`` is set to ``"VIRTUAL_SINK"``, the attribute ``"name"`` becomes a requried parameter to enable VPR to determine which clock network the virtual sink belongs to.
59+
60+
When specifying the network_name in a global routing constraints file for routing a global net through a desired clock network, as described in the :ref:`above <global_routing_constraints_file_format>` section, the name defined as an attribute in the virtual sink of the clock network should be used to reference that clock network.
61+
62+
Segment Definition for Clock Networks
63+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
64+
The node types ``"CHANX"`` and ``"CHANY"`` can construct the clock routing architecture, similar to a generic routing network. However, to identify nodes that are part of a clock network, one can define unique segments for clock networks. To indicate that a segment defined is a clock network resource, users can use the optional attribute ``res_type="GCLK"``. Therefore, nodes with a segment ID of this defined segment are considered to be part of a clock network.
65+
66+
While VPR currently does not leverage this distinction of clock network resources, it is recommended to use the ``res_type="GCLK"`` attribute, as this preparation ensures compatibility for future support.
67+
68+
69+
Example of RR Graph Definition for Clock Networks
70+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
71+
72+
Below are snapshots of a sample RR graph that illustrate how to define a clock network. This example demonstrates the definition of a virtual sink node, a clock network segment, and a CHANY node that is part of the clock network.
73+
74+
For the node with ``id="12746"``, the ``res_type="VIRTUAL_SINK"`` attribute marks it as the virtual sink node of a clock network named ``"global_network"``, as specified by the ``name`` attribute.
75+
76+
For the segment with ``id="1"``, the ``res_type="GCLK"`` attribute indicates that this segment is a clock network resource.
77+
78+
The ``"CHANY"`` node with the ``id="12746"`` has ``segment_id="1"``, which means this resource belongs to the clock network.
79+
80+
.. code-block:: xml
81+
:caption: Example snippets from an RR graph describing part of a clock network.
82+
:linenos:
83+
84+
<rr_nodes>
85+
<!-- Definition of a virtual sink node for a clock network named "global_network" -->
86+
<node capacity="1" clk_res_type="VIRTUAL_SINK" id="12746" name="global_network" type="SINK">
87+
<loc layer="0" ptc="72" xhigh="6" xlow="6" yhigh="6" ylow="6"/>
88+
<timing C="0" R="0"/>
89+
</node>
90+
91+
<!-- Definition of a CHANY node as part of the clock network -->
92+
<node capacity="1" direction="BI_DIR" id="12668" type="CHANY">
93+
<loc layer="0" ptc="20" xhigh="6" xlow="6" yhigh="6" ylow="6"/>
94+
<timing C="1.98240038e-13" R="50.4199982"/>
95+
<segment segment_id="1"/>
96+
</node>
97+
98+
<!-- ... other nodes ... -->
99+
</rr_nodes>
100+
101+
<segments>
102+
<!-- Definition of a clock network segment -->
103+
<segment id="1" name="spine1_drive" res_type="GCLK">
104+
<timing C_per_meter="2.06999995e-14" R_per_meter="50.4199982"/>
105+
</segment>
106+
107+
<!-- ... other segments ... -->
108+
</segments>

‎doc/src/vpr/index.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -55,7 +55,7 @@ The purpose of VPR is to make the packing, placement, and routing stages of the
5555
graphics
5656

5757
timing_constraints
58-
placement_constraints
58+
vpr_constraints
5959
sdc_commands
6060

6161
file_formats

‎doc/src/vpr/placement_constraints.rst

Lines changed: 23 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -1,39 +1,40 @@
11

2-
VPR Placement Constraints
3-
=========================
4-
.. _vpr_constraints_file:
2+
Placement Constraints
3+
======================
4+
.. _placement_constraints:
5+
56
VPR supports running flows with placement constraints. Placement constraints are set on primitives to lock them down to specified regions on the FPGA chip. For example, a user may use placement constraints to lock down pins to specific locations on the chip. Also, groups of primitives may be locked down to regions on the chip in CAD flows that use floorplanning or modular design, or to hand-place a timing critical piece.
67

78
The placement constraints should be specified by the user using an XML constraints file format, as described in the section below. When VPR is run with placement constraints, both the packing and placement flows are performed in such a way that the constraints are respected. The packing stage does not pack any primitives together that have conflicting floorplan constraints. The placement stage considers the floorplan constraints when choosing a location for each clustered block during initial placement, and does not move any block outside of its constraint boundaries during place moves.
89

9-
A Constraints File Example
10-
--------------------------
10+
A Placement Constraints File Example
11+
------------------------------------
1112

1213
.. code-block:: xml
1314
:caption: An example of a placement constraints file in XML format.
1415
:linenos:
1516
1617
<vpr_constraints tool_name="vpr">
17-
<partition_list>
18-
<partition name="Part0">
19-
<add_atom name_pattern="li354"/>
20-
<add_atom name_pattern="alu*"/> <!-- Regular expressions can be used to provide name patterns of the primitives to be added -->
21-
<add_atom name_pattern="n877"/>
22-
<add_region x_low="3" y_low="1" x_high="7" y_high="2"/> <!-- Two rectangular regions are specified, together describing an L-shaped region -->
23-
<add_region x_low="7" y_low="3" x_high="7" y_high="6"/>
24-
</partition>
25-
<partition name="Part1">
26-
<add_region x_low="3" y_low="3" x_high="7" y_high="7" subtile="0"/> <!-- One specific location is specified -->
27-
<add_atom name_pattern="n4917"/>
28-
<add_atom name_pattern="n6010"/>
29-
</partition>
30-
</partition_list>
18+
<partition_list>
19+
<partition name="Part0">
20+
<add_atom name_pattern="li354"/>
21+
<add_atom name_pattern="alu*"/> <!-- Regular expressions can be used to provide name patterns of the primitives to be added -->
22+
<add_atom name_pattern="n877"/>
23+
<add_region x_low="3" y_low="1" x_high="7" y_high="2"/> <!-- Two rectangular regions are specified, together describing an L-shaped region -->
24+
<add_region x_low="7" y_low="3" x_high="7" y_high="6"/>
25+
</partition>
26+
<partition name="Part1">
27+
<add_region x_low="3" y_low="3" x_high="7" y_high="7" subtile="0"/> <!-- One specific location is specified -->
28+
<add_atom name_pattern="n4917"/>
29+
<add_atom name_pattern="n6010"/>
30+
</partition>
31+
</partition_list>
3132
</vpr_constraints>
3233
3334
.. _end:
3435

35-
Constraints File Format
36-
-----------------------
36+
Placement Constraints File Format
37+
---------------------------------
3738

3839
VPR has a specific XML format which must be used when creating a placement constraints file. The purpose of this constraints file is to specify
3940

@@ -42,9 +43,7 @@ VPR has a specific XML format which must be used when creating a placement const
4243

4344
The file is passed as an input to VPR when running with placement constraints. When the file is read in, its information is used during the packing and placement stages of VPR. The hierarchy of the file is set up as follows.
4445

45-
.. note:: Use the VPR option :vpr:option:`--read_vpr_constraints` to specify the VPR placement constraints file that is to be loaded.
46-
47-
The top level tag is the ``<vpr_constraints>`` tag. This tag contains one ``<partition_list>`` tag. The ``<partition_list>`` tag can be made up of an unbounded number of ``<partition>`` tags. The ``<partition>`` tags contains all of the detailed information of the placement constraints, and is described in detail below.
46+
The top level tag is the ``<vpr_constraints>`` tag. This tag can contain one ``<partition_list>`` tag. The ``<partition_list>`` tag can be made up of an unbounded number of ``<partition>`` tags. The ``<partition>`` tags contains all of the detailed information of the placement constraints, and is described in detail below.
4847

4948
Partitions, Atoms, and Regions
5049
------------------------------

‎doc/src/vpr/vpr_constraints.rst

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
VPR Constraints
2+
=========================
3+
.. _vpr_constraints:
4+
5+
VPR allows users to run the flow with placement constraints that enable primitives to be locked down to a specific region on the chip and global routing constraints that facilitate the routing of global nets through clock networks.
6+
7+
Users can specify these constraints through a constraints file in XML format, as shown in the format below.
8+
9+
.. code-block:: xml
10+
:caption: The overall format of a VPR constraints file
11+
:linenos:
12+
13+
<vpr_constraints tool_name="vpr">
14+
<partition_list>
15+
<!-- Placement constraints are specified inside this tag -->
16+
</partition_list>
17+
<global_route_constraints>
18+
<!-- Global routing constraints are specified inside this tag -->
19+
</global_route_constraints>
20+
</vpr_constraints>
21+
22+
.. note:: Use the VPR option :option:`vpr --read_vpr_constraints` to specify the VPR constraints file that is to be loaded.
23+
24+
The top-level tag is the ``<vpr_constraints>`` tag. This tag can contain ``<partition_list>`` and ``<global_route_constraints>`` tags. The ``<partition_list>`` tag contains information related to placement constraints, while ``<global_route_constraints>`` contains information about global routing constraints. The details for each of these constraints are given in the respective sections :ref:`Placement Constraints <placement_constraints>` and :ref:`Global Route Constraints <global_routing_constraints>`.
25+
26+
.. toctree::
27+
:maxdepth: 2
28+
29+
placement_constraints
30+
global_routing_constraints
31+
32+

0 commit comments

Comments
 (0)