@User @User I was going through post synthesis and post layout netlist simulation for final verification. I have checked in the simulation that my input register is not giving output, and it always gives outputs as XXXX … as shown in attached image.  Till now I have figured out that there is problem with the Verilog files provided with the pdk. I have found several mistakes in the file. E.g. on line number 30454 to 30494 there is definition for flip-flop bearing name sky130_fd_sc_hd__dfrtp.  

module sky130_fd_sc_hd__dfrtp (
  Q   ,
  CLK  ,
  D   ,
  RESET_B,
  VPWR ,
  VGND ,
  VPB  ,
  VNB
);
 
  // Module ports
  output Q   ;
  input CLK  ;
  input D   ;
  input RESET_B;
  input VPWR ;
  input VGND ;
  input VPB  ;
  input VNB  ;
 
  // Local signals
  wire buf_Q     ;
  wire RESET     ;
  reg notifier   ;
  wire D_delayed   ;
  wire RESET_B_delayed;
  wire CLK_delayed  ;
  wire awake     ;
  wire cond0     ;
  wire cond1     ;
 
  //                 Name Output Other arguments
  not                not0 (RESET , RESET_B_delayed                  );
  sky130_fd_sc_hd__udp_dff$PR_pp$PG$N dff0 (buf_Q , D_delayed, CLK_delayed, RESET, notifier, VPWR, VGND);
  assign awake = ( VPWR === 1'b1 );
  assign cond0 = ( awake && ( RESET_B_delayed === 1'b1 ) );
  assign cond1 = ( awake && ( RESET_B === 1'b1 ) );
  buf                buf0 (Q  , buf_Q                       );
 
endmodule

  Here local clock and d (defined as CLK_delayed, and D_delayed) are defined but not assigned any values. And there are 10’s of flipflop cells and every cell has the same problem. I have no idea who should be notified for these mistakes. So, I am posting here so it may be floated to relevant person.

Thanks, Muhammad. Adding @User and @User.

@User The complete code (at https://cs.opensource.google/skywater-pdk/sky130_fd_sc_hd/+/main:cells/dfrtp/sky130_fd_sc_hd__dfrtp.behavioral.pp.v) contains two important lines:

// Import user defined primitives.
`include "../../models/udp_dff_pr_pp_pg_n/sky130_fd_sc_hd__udp_dff_pr_pp_pg_n.v"

and

sky130_fd_sc_hd__udp_dff$PR_pp$PG$N dff0 (buf_Q , D_delayed, CLK_delayed, RESET, notifier, VPWR, VGND);

If you check this link (https://cs.opensource.google/skywater-pdk/sky130_fd_sc_hd/+/main:models/udp_dff_pr_pp_pg_n/sky130_fd_sc_hd__udp_dff_pr_pp_pg_n.v) to see the UDP, it has the functionality written. I don't think there are any errors in the pdk. Please correct me if I am wrong.

@User In the link you shared (https://cs.opensource.google/skywater-pdk/sky130_fd_sc_hd/+/main:cells/dfrtp/sky130_fd_sc_hd__dfrtp.behavioral.pp.v), you may see that the signals

D_delayed, CLK_delayed

declared as

wire

are input to the

sky130_fd_sc_hd__udp_dff$PR_pp$PG$N

module, where

D_delayed, CLK_delayed

have not assigned any value so they would be treated as

X

.

@User: The issue arises from the fact that the original SkyWater sources use

$setuphold

statements in the verilog. Because iverilog does not support these statements, they got scrubbed, but apparently the

$setuphold

statement defines actual connections, such as between

D

and

D_delayed

. I expect it will take a lot of work to generate a patch for it, given that the skywater-pdk repository is in error, and the correct source files are not available.

Ok, then is there any alternative to verify my netlist? in this case Conformal and Netlist simulation didn't worked?

Yes Muhammad, I noticed that the

Q

has been assigned to the local signal

buf_Q

but did not notice the issue with

CLK_delayed

and

D_delayed

.

@User I was having the same issue as you, with the flops not being connected. However, if you try to simulate the post-LVS netlist, which should end in

.lvs.powered.v

, that worked for me. I was trying to simulate the post yosys netlist, ending in

.synthesis.v

, and had been failing with the same error as you. You also need to define these macros in your top module: ``define UNIT_DELAY #1` ``define USE_POWER_PINS` ``define FUNCTIONAL` After making those changes icarus happily simulated the netlist for me. I'm not crystal clear on what the differences in those two netlists are, but at least it works now.

Yes, sorry for my delayed response, but yes, using the functional verilog by defining

FUNCTIONAL

is the easiest way to avoid the problem. The functional verilog does not have timing values, or a way to specify them, but it can be used for gate-level simulation. If you are trying to do simulation with timing, there is a commented-out line in the open_pdks Makefile that will add back the specify sections. I have not checked if that fixes the above issue, but it might. iverilog will not simulate with that syntax, but you can use the "cvc" simulator (commercial open source), which will.

Okay, thank you @User and @User I will try it.