[Pack][Timing] Pre-Cluster Timing Analysis May Not Be Aware of Molecules

[AlexandreSinger]

The PreClusterDelayCalculator computes the max edge delay of a timing connection in the following function:

vtr-verilog-to-routing/vpr/src/timing/PreClusterDelayCalculator.h

Lines 30 to 46 in d6fe4b5

	tatum::Time max_edge_delay(const tatum::TimingGraph& tg, tatum::EdgeId edge_id) const override {
	tatum::NodeId src_node = tg.edge_src_node(edge_id);
	tatum::NodeId sink_node = tg.edge_sink_node(edge_id);
	auto edge_type = tg.edge_type(edge_id);
	if (edge_type == tatum::EdgeType::PRIMITIVE_COMBINATIONAL) {
	return prim_comb_delay(tg, src_node, sink_node);
	} else if (edge_type == tatum::EdgeType::PRIMITIVE_CLOCK_LAUNCH) {
	return prim_tcq_delay(tg, src_node, sink_node);
	} else {
	VTR_ASSERT(edge_type == tatum::EdgeType::INTERCONNECT);
	//External net delay
	return tatum::Time(inter_cluster_net_delay_);
	}
	}

All nets that connect atom blocks together are labelled as INTERCONNECT in the timing_graph_builder here:

vtr-verilog-to-routing/vpr/src/timing/timing_graph_builder.cpp

Lines 297 to 302 in d6fe4b5

	//Walk through the netlist nets adding the edges representing each net to
	//the timing graph. This connects the timing graph nodes of each netlist
	//block together.
	for (AtomNetId net : netlist_.nets()) {
	add_net_to_timing_graph(net);
	}

vtr-verilog-to-routing/vpr/src/timing/timing_graph_builder.cpp

Lines 670 to 690 in d6fe4b5

	void TimingGraphBuilder::add_net_to_timing_graph(const AtomNetId net) {
	//Create edges from the driver to sink tnodes
	AtomPinId driver_pin = netlist_.net_driver(net);
	if (!driver_pin) {
	//Undriven nets have no timing dependencies, and hence no edges
	VTR_LOG_WARN("Net %s has no driver and will be ignored for timing purposes\n", netlist_.net_name(net).c_str());
	return;
	}
	NodeId driver_tnode = netlist_lookup_.atom_pin_tnode(driver_pin);
	VTR_ASSERT(driver_tnode);
	for (AtomPinId sink_pin : netlist_.net_sinks(net)) {
	NodeId sink_tnode = netlist_lookup_.atom_pin_tnode(sink_pin);
	VTR_ASSERT(sink_tnode);
	tg_->add_edge(tatum::EdgeType::INTERCONNECT, driver_tnode, sink_tnode);
	}
	}

The timing graph is created before clustering. The prepacker then occurs after creating the timing graph, but before clustering. The prepacker will pre-cluster atoms together. These molecules will be observed by the packer (i.e. molecules will not get broken). Since the timing graph was created before the prepacker and it does not get updated after prepacking (as far as I am aware), this implies that the max edge delay computed by this calculator is not taking the prepacked molecules into account.

If a timing graph edge is between two atoms within the same molecule, the internal delay of that implemented molecule should be used instead of the inter_cluster_net_delay value.

Proposed next steps:

1. Verify that the assumptions above is true by adding an assertion within the max_edge_delay. The PreClusterDelayCalculator has access to the prepacker, it can check if two atoms are in the same molecule.
2. If we verify that this is correct, we should add a case to this method which will check if the edge is absorbed into a molecule and use a more accurate delay.
3. Verify the pre-clustering timing report to ensure that the molecule delays are being observed.

See #2965 (comment) for context

@vaughnbetz Let me know if I am missing anything here.

[vaughnbetz]

I like the plan. Thanks Alex.On Apr 11, 2025, at 6:09 PM, AlexandreSinger ***@***.***> wrote: The PreClusterDelayCalculator computes the max edge delay of a timing connection in the following function: https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/d6fe4b509ef5d3f24891e3b88da301d0e011e176/vpr/src/timing/PreClusterDelayCalculator.h#L30-L46 All nets that connect atom blocks together are labelled as INTERCONNECT in the timing_graph_builder here: https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/d6fe4b509ef5d3f24891e3b88da301d0e011e176/vpr/src/timing/timing_graph_builder.cpp#L297-L302 https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/d6fe4b509ef5d3f24891e3b88da301d0e011e176/vpr/src/timing/timing_graph_builder.cpp#L670-L690 The timing graph is created before clustering. The prepacker then occurs after creating the timing graph, but before clustering. The prepacker will pre-cluster atoms together. These molecules will be observed by the packer (i.e. molecules will not get broken). Since the timing graph was created before the prepacker and it does not get updated after prepacking (as far as I am aware), this implies that the max edge delay computed by this calculator is not taking the prepacked molecules into account. If a timing graph edge is between two atoms within the same molecule, the internal delay of that implemented molecule should be used instead of the inter_cluster_net_delay value. Proposed next steps: Verify that the assumptions above is true by adding an assertion within the max_edge_delay. The PreClusterDelayCalculator has access to the prepacker, it can check if two atoms are in the same molecule. If we verify that this is correct, we should add a case to this method which will check if the edge is absorbed into a molecule and use the more accurate gain in this case. Verify the pre-clustering timing report to ensure that the molecule delays are being observed. See #2965 (comment) for context @vaughnbetz Let me know if I am missing anything here.—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***> AlexandreSinger created an issue (verilog-to-routing/vtr-verilog-to-routing#2972) The PreClusterDelayCalculator computes the max edge delay of a timing connection in the following function: https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/d6fe4b509ef5d3f24891e3b88da301d0e011e176/vpr/src/timing/PreClusterDelayCalculator.h#L30-L46 All nets that connect atom blocks together are labelled as INTERCONNECT in the timing_graph_builder here: https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/d6fe4b509ef5d3f24891e3b88da301d0e011e176/vpr/src/timing/timing_graph_builder.cpp#L297-L302 https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/d6fe4b509ef5d3f24891e3b88da301d0e011e176/vpr/src/timing/timing_graph_builder.cpp#L670-L690 The timing graph is created before clustering. The prepacker then occurs after creating the timing graph, but before clustering. The prepacker will pre-cluster atoms together. These molecules will be observed by the packer (i.e. molecules will not get broken). Since the timing graph was created before the prepacker and it does not get updated after prepacking (as far as I am aware), this implies that the max edge delay computed by this calculator is not taking the prepacked molecules into account. If a timing graph edge is between two atoms within the same molecule, the internal delay of that implemented molecule should be used instead of the inter_cluster_net_delay value. Proposed next steps: Verify that the assumptions above is true by adding an assertion within the max_edge_delay. The PreClusterDelayCalculator has access to the prepacker, it can check if two atoms are in the same molecule. If we verify that this is correct, we should add a case to this method which will check if the edge is absorbed into a molecule and use the more accurate gain in this case. Verify the pre-clustering timing report to ensure that the molecule delays are being observed. See #2965 (comment) for context @vaughnbetz Let me know if I am missing anything here. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>