DCMAC block enablement not respected in `service_layer.tcl`
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 74/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Domain
- build-system
Research direction
Start in linker/slashkit/resources/templates/service_layer.tcl around lines 1117–1168, especially the DCMAC enable assignments and their use. Reproduce the network configuration with only eth_0 enabled and verify that the generated design instantiates qsfp_0_n_1 without qsfp_2_n_3 and avoids the reported Vivado clock error.
Written by the indexing model from the issue text.
Description
When vbin is built with a network config that enables only eth_0, both qsfp_0_n_1 and qsfp_2_n_3 blocks are instantiated, even though only qsfp_0_n_1 should be created. This results in a Vivado build error.
[network]
eth_0=1
eth_1=0
Expected Behavior:
Only qsfp_0_n_1 is instantiated. qsfp_2_n_3 should not be created, since only eth_0 is enabled.
Actual Behavior:
Both qsfp_0_n_1 and qsfp_2_n_3 blocks are created. Build fails with:
ERROR: [BD 41-758] The following clock pins are not connected to a valid clock source:
/qsfp_2_n_3/ap_clk
Root Cause:
In service_layer.tcl:
DCMAC0_ENABLEDandDCMAC1_ENABLEDare correctly set based on config at lines 1155–1156.- However, these values are not propagated when used at line 1161.
- Instead, they are unconditionally overridden at lines 1119–1120. As a result, whenever any network interface is enabled, both QSFP blocks are instantiated.
Impact:
Any build enabling only a single DCMAC/ethernet interface will fail.
- Dominant language
- Tcl
- Stars
- 46
- Forks
- 21
- Avg merge
- 1d 9m
- Merged PRs (30d)
- 9
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Xilinx/SLASH
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
The link is up and RX sees the packet, but the received packet is not counted as a good packet. Open
Difficulty 4/5 3-5 days Newbie friendliness 38/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Similar issues
-
type/automation type/tech-debt
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
priority: p3
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
googleapis/librarian#7636 ·
-
package-update
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
oSoWoSo/vOid_Community_repOsitory#147 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
agentic-workflows cascade-suspected
Difficulty 1/5 Under an hour Newbie friendliness 88/100