@Mitch Bailey @Tim Edwards @donn It would be great to get your suggestions in this regard

@Md Omar Faruque Don’t know if this is relevant, but this is what ChatGPT say for the following prompts.

Synthesizing the following rtl verilog says that intr is undriven. Can you figure out why?

(paste

user_proj_example.v

)

The reason why the signal

intr

is reported as undriven during synthesis is that the signal

out_valid

, which is assigned to

intr

, is not driven in every possible scenario in your design. Specifically, it is driven only by the

maxFinder

module, and there may be situations where this module does not assert

out_valid

due to the conditions within your design. Here’s a summary of possible causes: 1. Conditional Assignment: The

out_valid

signal may not be assigned in every possible condition within the

maxFinder

module or other related logic. If

out_valid

remains unassigned under certain conditions, it will default to an unknown (X) or high-impedance (Z) state, causing the

intr

signal to also be undriven. 2. Reset Logic: It’s possible that the

maxFinder

or upstream logic does not initialize or assign

out_valid

under a reset condition or when specific input conditions are not met. Troubleshooting Steps: • Check the

maxFinder

Module: Inspect the

maxFinder

module to ensure that the

out_valid

signal is driven under all conditions, including reset and idle states. • Default Assignment: You can assign a default value to

out_valid

(e.g.,

out_valid = 0;

) before the main logic in the

maxFinder

or related modules. This ensures that

intr

will always have a valid value. • Ensure Continuous Assignment: Make sure

out_valid

is continuously assigned within an

always

block or combinatorial logic so that it’s not left floating. Implementing these steps should resolve the issue with

intr

being undriven.

Here’s the maxFinder module. Can you find a condition where out_valid is undriven?

(paste

maxFinder.v

)

The issue with the

maxFinder

module lies in the sequence of assignments within the

always

block. Specifically, the

o_data_valid

signal is being conditionally set to

1

when the

counter

equals

numInput

, but it is not explicitly assigned in all other cases. Here’s a step-by-step analysis: 1. Resetting

o_data_valid

: At the beginning of every clock cycle,

o_data_valid

is set to `0`: 2. verilog 3. 4. 5. o_data_valid <= 1'b0; 6. Condition when

i_valid

is high: ◦ The block sets

maxValue

,

counter

,

inDataBuffer

, and

o_data

. However, it does not set

o_data_valid

. ◦ Therefore,

o_data_valid

remains

0

in this condition. 7. Condition when

counter == numInput

: ◦ The block sets

o_data_valid

to

1

and resets

counter

to

0

. This is the only condition where

o_data_valid

is explicitly set to

1

. ◦ This condition seems to work as expected. 8. Condition when

counter != 0

: ◦ The block increments

counter

and checks if the current value in

inDataBuffer

is greater than

maxValue

. ◦ Here,

o_data_valid

is not explicitly assigned, so it remains

0

. Potential Issue: The signal

o_data_valid

is only set to

1

under the condition

counter == numInput

. In all other conditions, it defaults to

0

because of the initial assignment at the start of the

always

block. However, if the logic ever skips the

counter == numInput

condition or if

i_valid

is not asserted,

o_data_valid

could remain

0

, leading to the

intr

signal being undriven in the higher-level module. Solution: To ensure that

o_data_valid

is properly driven, even in edge cases, you might consider initializing

o_data_valid

appropriately or reordering the logic:

verilog


always @(posedge clk)
begin
    if(i_valid)
    begin
        maxValue <= i_data[inputWidth-1:0];
        counter <= 1;
        inDataBuffer <= i_data;
        o_data <= 0;
        o_data_valid <= 1'b0;  // Explicitly assign o_data_valid
    end
    else if(counter == numInput)
    begin
        counter <= 0;
        o_data_valid <= 1'b1;
    end
    else if(counter != 0)
    begin
        counter <= counter + 1;
        if(inDataBuffer[counter*inputWidth+:inputWidth] > maxValue)
        begin
            maxValue <= inDataBuffer[counter*inputWidth+:inputWidth];
            o_data <= counter;
        end
        o_data_valid <= 1'b0;  // Explicitly keep o_data_valid at 0
    end
end

This ensures that

o_data_valid

is always driven, either to

1

or

0

, depending on the condition.

I just noticed that although the open lane flow was complete, the synthesis error (the network is combinational) was there. There were another 2 issues. 1 antenna violation,2 slew violations. It looks like these violations are for the synthesis error Here is the new repo link https://github.com/MdOmarFaruque/HW_V3