cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
497 Views
Registered: ‎05-15-2014

Unexpected functional behaviour occuring while adding test registers

Hello

We are developing an FPGA design implemented on Xilinx 7 series 690.

Our development environment is Vivado 2017.4.1.

The previous version of our design had been operating properly.

When we add some simple test registers to the previous version of our design, unexpected functional errors occurred in the current version.

When we change the position of test registers in the state machine other unexpected functional errors occur.

The test registers that we add are not relevant to the functional behavior of the design, therefore, we do not expect any functional error because of the added registers.

We are sure that the constraints of the design are correct.

We do not have any idea why the current version and the previous version of the design behave differently.

Any suggestions?

 

 

 

 

 

 

0 Kudos
3 Replies
Highlighted
Adventurer
Adventurer
401 Views
Registered: ‎05-15-2014

Hello again

 

We want to share more information about the unexpected functional behavior occurring while adding test registers.

Let's call the implementation functioning correctly as impl_1 and

call the implementation of the same design with some test registers added but behaving not correctly as impl_2.

In both  impl_1 and impl_2, there is a module with the pseudo-code below.

_________________________________________________________________________________________________

 

output reg readEnable=0;

reg [7:0] state=0;

reg [2:0] dataPart=0;

reg [15:0] a=0;

reg [15:0] b=0;

reg [15:0] c=0;

reg [15:0] d=0;

reg [15:0] e=0;

always @(posedge clk)begin

     //code irrelevant to the errror

    //code irrelevant to the errror

    //code irrelevant to the errror

 

     else if(state==136)begin

          readEnable<=1;

          state<=state+1;

     end

     else if(state==137)begin

          readEnable<=0;

          if(dataReadValid)begin

                if(dataPart==0)begin

                     dataPart<=dataPart+1;

                     a[6:0]<=f[15:9];

                     state<=136;

                end

                else if(dataPart==1)begin

                     dataPart<=dataPart+1;

                     a[15:7]<=f[8:0];

                     b[6:0]<=f[15:9];

                     state<=136;

                end

                else if(dataPart==2)begin

                     dataPart<=dataPart+1;

                     c<=f;                    

                     state<=136;

                end

                else if(dataPart==3)begin                    

                     dataPart<=dataPart+1;

                      d<=f;

                      state<=136;

                end

                else if(dataPart==4)begin                    

                      dataPart<=0;

                      e<=f;

                      state<=140;

                end

     end

     

    //code irrelevant to the errror

    //code irrelevant to the errror

    //code irrelevant to the errror

end

_________________________________________________________________________________________________

 

When we explore the implementations of impl_1 and impl_2 and expand the cones of the register a[6:0]

In impl_1, we observe that dataPart registers drive some of the LUTs driving a [6:0] flip flops and

in impl_2, we observe that dataPart registers do not drive any of the LUTs driving a [6:0] flip flops.

 

Therefore in impl_2 a[6:0]<=f[15:9];

assignment is independent of dataPart register and the assignment occurs every clock when the state is 137 when dataReadValid is 1.

 

We have no idea why Vivado does not ignore dataPart check in impl_1 and does ignore dataPart check in impl_2.

I can share the original part of our design but the error is not relevant to the other parts.

I can add that register state is a register driving lots of other registers in the design so Vivado replicates it.

But we do not expect any errors regarding the replication.

 

Any help we appreciate

 

best regards

 

 

 

 

 

 

 

 

 

 

 

 

 

0 Kudos
Highlighted
Adventurer
Adventurer
334 Views
Registered: ‎05-15-2014

Hello again

We carried our design from Vivado 2017.4.1 to Vivado 2020.1 without changing any RTL code.

dataPart register is not ignored as it must be.

In 2020.1 we also added some test registers which must not change the functionality.

We observed that adding test registers does not change functionality.

We continue to develop our design with Vivado 2020.1 till we see any error.

 

But we must point out that most probably Vivado 2017.4.1 has a major and dangerous bug since the error is unexpected and it is not easy to detect.

We will give more feedback soon.

best regards.  

0 Kudos
Highlighted
Adventurer
Adventurer
155 Views
Registered: ‎05-15-2014

Hello again

 

It has been over 1 month since we started to use VIVADO 2020.1.

In our designs ,we used VIVADO 2020.1 intensely in this period.

I must point out that we did not observe any functional errors during this period.

Therefore we are sure that VIVADO 2017.4.1 has bug/bugs causing functional errors.

If Xilinx experts want to investigate this issue we can share project files in which

it can be possible to explore the bugs

 

best regards 

 

 

 

0 Kudos