When a synthesized module's interface has two methods whose schedule relationship is C (conflict), a parent compiled by bsc can never enable both in one cycle — the scheduler enforces the annotation. An instantiator written directly in Verilog/SystemVerilog has no such enforcement: if it asserts both enables in the same cycle, the module's internal logic (e.g. muxes whose arm exclusivity the scheduler derived from the conflict relationship) can silently misbehave, with no diagnostic anywhere.
bsc already injects dynamic checks for user scheduling assumptions: mutually_exclusive / conflict_free assumptions become $error calls inside translate_off, so every simulation validates them. The same idea could cover interface method conflicts at the generated-Verilog boundary:
// synopsys translate_off
always @(posedge CLK) begin
if (EN_methodA && EN_methodB)
$error("Methods methodA and methodB conflict and may not be enabled in the same clock cycle");
end
// synopsys translate_on
one check per C-related method pair of the synthesized module (SB/SBR pairs remain legal to co-enable and would not be checked). Mixed-language integrations could then validate the interface contract in simulation exactly the way rule-level ME assumptions are validated today.
If opt-in seems safer, a flag in the spirit of the existing assumption checks would work; default-on inside translate_off would match how the ME/CF assumption checks are emitted.
Happy to contribute a patch if the approach sounds acceptable — the natural implementation point looks to be alongside the existing assumption-injection machinery, extended to the module's method conflict matrix.
Drafted and filed by Claude (an AI assistant), on behalf of Ravi Nanavati.
When a synthesized module's interface has two methods whose schedule relationship is C (conflict), a parent compiled by bsc can never enable both in one cycle — the scheduler enforces the annotation. An instantiator written directly in Verilog/SystemVerilog has no such enforcement: if it asserts both enables in the same cycle, the module's internal logic (e.g. muxes whose arm exclusivity the scheduler derived from the conflict relationship) can silently misbehave, with no diagnostic anywhere.
bsc already injects dynamic checks for user scheduling assumptions:
mutually_exclusive/conflict_freeassumptions become$errorcalls insidetranslate_off, so every simulation validates them. The same idea could cover interface method conflicts at the generated-Verilog boundary:one check per C-related method pair of the synthesized module (SB/SBR pairs remain legal to co-enable and would not be checked). Mixed-language integrations could then validate the interface contract in simulation exactly the way rule-level ME assumptions are validated today.
If opt-in seems safer, a flag in the spirit of the existing assumption checks would work; default-on inside
translate_offwould match how the ME/CF assumption checks are emitted.Happy to contribute a patch if the approach sounds acceptable — the natural implementation point looks to be alongside the existing assumption-injection machinery, extended to the module's method conflict matrix.
Drafted and filed by Claude (an AI assistant), on behalf of Ravi Nanavati.