NCSIM ddr2_controller post synthesis simulation - setup time warnings

[Mahesh Shinde]

I am running ddr2_controller post synthesis simulation using 45nm technology. I am getting setup time violation for one register, but I am not getting same timing violation for other registers. In same always block, I have assigned values to these registers. What could be the problem.

here is the screenshot of the warning


And here is the code,

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
always @(posedge fStrobe)
     case (count)
       0: r0 <= din;   
       1: r2 <= din;
       2: r4 <= din;
       3: r6 <= din;
     endcase // case(counter)
   always @(negedge fStrobe)
     case (count)
       0: r1 <= din;   
       1: r3 <= din;
       2: r5 <= din;
       3: r7 <= din;
     endcase // case(counter)
 
 
// Read data
// ---------
   always @ (r0 or r1 or r2 or r3 or r4 or r5 or r6 or r7  or readPtr)
     begin
        case (readPtr) 
          3'b000: dout <= r0;
          3'b001: dout <= r1;
          3'b010: dout <= r2;
          3'b011: dout <= r3;
          3'b100: dout <= r4;
          3'b101: dout <= r5;
          3'b110: dout <= r6;
          3'b111: dout <= r7;
          default: dout <= r0;
        endcase // case (readPtr)
     end

---

 

[sharath666]

It is very much possible to get a violation only on r1 and not on others. The fanout at DIN seems to be high. Can you try replicating DIN?

 

[Mahesh Shinde]

It is very much possible to get a violation only on r1 and not on others. The fanout at DIN seems to be high. Can you try replicating DIN?

I tried replication, but still I am getting 'XX' result in r1 and r3 registers, rest of them are working properly. Till now I tried changing counter, even used gray counter, tried different logic using case statements, but still facing the problem. Dont know how to solve the r1, r3 register prob

 

[sharath666]

Because of setup violations, r1 and r3 need not settle at X. It will be restored to a stable value. That is the way I suppose simulation tools handle this. I think there is some other issue here like multiple drive.You can run at a lower frequency to avoid these violations and check whether you are getting the same error.