ISE de Xilinx (GSR): El bloque inicial añade un retraso de 100 unidades de tiempo a la simulación

Question

Estoy trabajando en un trabajo de laboratorio en el que se supone que debo simular un circuito lógico secuencial (un dispositivo ROM). Estoy usando el ISE de xilinx como IDE.

Mi implementación funciona bien y la lógica y los datos son correctos (estoy 100% seguro porque las salidas en la simulación son correctas) el problema es que cuando se simula hay un retraso de 90 unidades de tiempo antes de que las salidas empiecen a cambiar.

El siguiente es mi banco de pruebas:

`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

Sé a ciencia cierta que el problema no está en la lógica porque cuando la secuencia se repite a 350ns los 90ns que aparecían al principio no se repiten como se puede ver en la imagen lo que me hace creer que es el bloque inicial.

Simulación:

HAWK_ROM.V:

Módulo HAWK:

`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 [5:0] address;
  reg [8:0] data;

  always @* begin

    address[0]=YP;
    address[1]=NS;
    address[5:2]=PXS;

    case({address})
      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:

---

---ACTUALIZACIÓN---

Me he dado cuenta de que junto a mi banco de pruebas se crea automáticamente una instanciación de otro módulo llamado "glbl", que contiene el siguiente código:

// $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

Ahora me he dado cuenta de que están configurando y utilizando el GSR interno y creo que eso es lo que está causando ese comportamiento. (el IDE no me deja editar ese archivo pero supongo que puedo encontrarlo en el directorio de mi proyecto)

Answer 1

Creo que lo que ves es el resultado de la caída de la señal interna de GSR a t=100ns. Esta señal evita que los flip flops cambien de estado mientras está afirmada. Es una especie de reset interno. No estoy seguro si puedes cambiar el comportamiento de GSR en modelsim. Pero lo que puedes hacer es simplemente añadir un retardo de 100 ns antes de iniciar la señal de reloj para evitar el efecto de la señal GSR.

Answer 2

Así que, gracias a la perspicacia de @alex.forencich, pude reducir mi investigación y, de hecho, lo que explicó era completamente correcto. en el siguiente documento (página 131-132) hay una explicación de por qué sucede esto: Síntesis y simulación Guía de diseño

Ahora, para solucionarlo simplemente he añadido un par de líneas a mi banco de pruebas:

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

y establecer "GSR = 0;" dentro de mi bloque inicial, el código final se ve así:

`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

No sé (y no creo que sea recomendable pero parece que funciona bien)

Los resultados parecen coherentes: