# Xilinx's ISE (GSR): The initial block adds a delay of 100 time units to simulation

I'm working on a lab assignment in which I'm supposed to simulate a sequential logic circuit (A ROM device). I'm using xilinx's ISE as IDE.

My implementation works fine and the logic and the data is correct (I'm 100% sure because the outputs in the simulation are correct) the problem is when simulating there's a 90 time units delay before the outputs start to change.

The following is my test bench:

timescale 1ns / 1ps

module HAWK_schematic_HAWK_schematic_sch_tb();

// Inputs
reg YP;
reg NS;
reg clk;

// Output
wire HDNW;
wire HW;
wire HRL;
wire HYL;
wire [3:0] NxtSt;
wire [3:0] PstSt;

// Bidirs

// Instantiate the UUT
HAWK_schematic UUT (
.HDNW(HDNW),
.HW(HW),
.HRL(HRL),
.HYL(HYL),
.YP(YP),
.NS(NS),
.clk(clk),
.NxtSt(NxtSt),
.PstSt(PstSt)
);
// Initialize Inputs
initial begin
YP = 1;
NS = 1;
clk = 0;
end

always #10
clk=~clk;

endmodule


I know for a fact that the problem is not in the logic because when the sequence repeats at 350ns the 90ns that appeared at the beginning doesn't repeat as you can see on the image which makes me believe its the initial block.

Simulation:

HAWK_ROM.V:

HAWK module:

timescale 1ns / 1ps

module HAWK_ROM(
input wire NS,
input wire YP,
input wire [3:0] PXS,
output reg HDNW,
output reg HW,
output reg HRL,
output reg HYL,
output reg [3:0] NXS
);

reg [8:0] data;

always @* begin

8'h00: data = 8'h00;   // 00
8'h01: data = 8'h10;   // 01
8'h02: data = 8'h00;   // 02
8'h03: data = 8'h10;   // 03
8'h04: data = 8'h29;   // 04
8'h05: data = 8'h29;   // 05
8'h06: data = 8'h29;   // 06
8'h07: data = 8'h29;   // 07
8'h08: data = 8'h38;   // 08
8'h09: data = 8'h38;   // 09
8'h0A: data = 8'h38;   // 0A
8'h0B: data = 8'h38;   // 0B
8'h0C: data = 8'h49;   // 0C
8'h0D: data = 8'h49;   // 0D
8'h0E: data = 8'h49;   // 0E
8'h0F: data = 8'h49;   // 0F

8'h10: data = 8'h58;   // 10
8'h11: data = 8'h58;   // 11
8'h12: data = 8'h58;   // 12
8'h13: data = 8'h58;   // 13
8'h14: data = 8'h69;   // 14
8'h15: data = 8'h69;   // 15
8'h16: data = 8'h69;   // 16
8'h17: data = 8'h69;   // 17
8'h18: data = 8'h79;   // 18
8'h19: data = 8'h79;   // 19
8'h1A: data = 8'h79;   // 1A
8'h1B: data = 8'h79;   // 1B
8'h1C: data = 8'h8A;   // 1C
8'h1D: data = 8'h8A;   // 1D
8'h1E: data = 8'h8A;   // 1E
8'h1F: data = 8'h8A;   // 1F

8'h20: data = 8'h86;   // 20
8'h21: data = 8'h86;   // 21
8'h22: data = 8'h96;   // 22
8'h23: data = 8'h96;   // 23
8'h24: data = 8'hA2;   // 24
8'h25: data = 8'hA2;   // 25
8'h26: data = 8'hA2;   // 26
8'h27: data = 8'hA2;   // 27
8'h28: data = 8'hB8;   // 28
8'h29: data = 8'hB8;   // 29
8'h2A: data = 8'hB8;   // 2A
8'h2B: data = 8'hB8;   // 2B
8'h2C: data = 8'hC2;   // 2C
8'h2D: data = 8'hC2;   // 2D
8'h2E: data = 8'hC2;   // 2E
8'h2F: data = 8'hC2;   // 2F

8'h30: data = 8'h08;   // 30
8'h31: data = 8'h08;   // 31
8'h32: data = 8'h08;   // 32
8'h33: data = 8'h08;   // 33
default:  data = 8'h00;  // Fail Safe case
endcase

HYL = data[0];
HRL = data[1];
HW = data[2];
HDNW = data[3];
NXS = data[7:4];
end

endmodule


HAWK_schematic:

---UPDATE---

I've noticed that alongside with my test-bench an instantiation of another module is automatically created called "glbl". this one contains the following code:

// $Header: /devl/xcs/repo/env/Databases/CAEInterfaces/verunilibs/data/glbl.v,v 1.15 2011/08/25 22:54:30 fphillip Exp$

timescale  1 ps / 1 ps

module glbl ();

parameter ROC_WIDTH = 100000;
parameter TOC_WIDTH = 0;

//--------   STARTUP Globals --------------
wire GSR;
wire GTS;
wire GWE;
wire PRLD;
tri1 p_up_tmp;
tri (weak1, strong0) PLL_LOCKG = p_up_tmp;

wire PROGB_GLBL;
wire CCLKO_GLBL;

reg GSR_int;
reg GTS_int;
reg PRLD_int;

//--------   JTAG Globals --------------
wire JTAG_TDO_GLBL;
wire JTAG_TCK_GLBL;
wire JTAG_TDI_GLBL;
wire JTAG_TMS_GLBL;
wire JTAG_TRST_GLBL;

reg JTAG_CAPTURE_GLBL;
reg JTAG_RESET_GLBL;
reg JTAG_SHIFT_GLBL;
reg JTAG_UPDATE_GLBL;
reg JTAG_RUNTEST_GLBL;

reg JTAG_SEL1_GLBL = 0;
reg JTAG_SEL2_GLBL = 0 ;
reg JTAG_SEL3_GLBL = 0;
reg JTAG_SEL4_GLBL = 0;

reg JTAG_USER_TDO1_GLBL = 1'bz;
reg JTAG_USER_TDO2_GLBL = 1'bz;
reg JTAG_USER_TDO3_GLBL = 1'bz;
reg JTAG_USER_TDO4_GLBL = 1'bz;

assign (weak1, weak0) GSR = GSR_int;
assign (weak1, weak0) GTS = GTS_int;
assign (weak1, weak0) PRLD = PRLD_int;

initial begin
GSR_int = 1'b1;
PRLD_int = 1'b1;
#(ROC_WIDTH)
GSR_int = 1'b0;
PRLD_int = 1'b0;
end

initial begin
GTS_int = 1'b1;
#(TOC_WIDTH)
GTS_int = 1'b0;
end

endmodule


Now I've noticed that they are setting and using the internal GSR and I think that is what is causing that behavior. (the IDE won't let me edit that file but I guess I can find it in my project's directory)

• It is probably an internal state in your DUT that needs a few clk cycles to be resolved. – HKOB Mar 27 at 6:39
• @HKOB any recommendation in how to solve it? or where to look for it? – Marco Castro Mar 27 at 7:00
• Obviously, you'd have to show us the code for HAWK_schematic as well. The testbench tells us nothing. – Dave Tweed Mar 27 at 11:37
• @DaveTweed So the HAWK_ROM is created from the HAWK_ROM module, which I have uploaded here, from there a symbol is created and a circuit is implemented (being HAWK_schematic) then the testbench is created based on that circuit diagram. (you may see some wires connected to nothing, those are actually connected to a bus) – Marco Castro Mar 27 at 15:10
• Although this is a little bit strange behavior (stuck for 6 cycles). My guess is that you should give FD4CE a CLR signal for 1 clock cycle (perhaps less) then you should be able to trust it and your DUT from the next cycle. – HKOB Mar 27 at 17:17

I think what you are seeing is the result of the internal GSR signal falling at t=100ns. This signal prevents the flip flops from changing state while it is asserted. It's sort of like an internal reset. I'm not sure if you can change the GSR behavior in modelsim. But what you can do is simply add a 100 ns delay before starting the clock signal so you avoid the effect of the GSR signal.

• I had forgotten about GSR. You're probably right. – Dave Tweed Mar 28 at 11:16
• Please refer to my update, I think you might be right and that it can be avoided by preventing something called "the fitter" to autocratically use global nets (which i think has to do with the fact that I'm using bus lines) Now I've found this little tutorial on how to do it but the options aren't available on my version of the software, maybe you might have an insight on how to accomplish that. goo.gl/ieFUL4 – Marco Castro Mar 30 at 4:37
• Sorry, I have not used ISE in a long time, I have never done any serious work with schematics in ISE, and I have not used modelsim in many years. – alex.forencich Mar 30 at 4:42

So, thanks yo @alex.forencich 's insight I was able to narrow my research and In fact what the explained whas completely right. on the following document (page 131-132) there's an explanation on why this happens: Synthesis and Simulation Design Guide

Now, to solve it I simply added a couple lines to my test-bench:

reg GSR;
assign glbl.GSR = GSR;
reg GTS;
assign glbl.GTS = GTS;


and set "GSR = 0;" within my initial block, final code looks like this:

timescale 1ns / 1ps

module HAWK_schematic_HAWK_schematic_sch_tb();

// Inputs
reg YP;
reg NS;
reg clk;

reg GSR;
assign glbl.GSR = GSR;
reg GTS;
assign glbl.GTS = GTS;

// Output
wire HDNW;
wire HW;
wire HRL;
wire HYL;
wire [3:0] NxtSt;
wire [3:0] PstSt;

// Bidirs

// Instantiate the UUT
HAWK_schematic UUT (
.HDNW(HDNW),
.HW(HW),
.HRL(HRL),
.HYL(HYL),
.YP(YP),
.NS(NS),
.NxtSt(NxtSt),
.PstSt(PstSt),
.clk(clk)
);
// Initialize Inputs
initial begin
GSR = 0;
GTS = 1;
YP = 1;
NS = 1;
clk = 0;
#100
GTS=0;

end

always #10
clk=~clk;
endmodule


I don't know (and I don't think this is recommended but it seems to be working fine)

Results look consistent: