cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Anonymous
Not applicable
6,917 Views

Modelsim FATAL in protected context when loading secureip.B_GTPA1_DUAL

Jump to solution

Hello Community,

 

I am currently trying to simulate a design using the Spartan 6 GTP Transceiver (Xilinxcorelib (Release 13.2) model) using Modelsim 10.0a DE. The toplevel is a systemverilog module, while the design itself is VHDL.

 

Now, after compiling the design and mapping all libraries, I can do 

vsim -t 10fs secureip.B_GTPA1_DUAL

 and the sim model loads just fine. Also, when I load the DUT top module, everything's good.

 

However, when I try to load the SV TB top, I get a Fatal Error which is not helping me much, since it occurs in a protected context:

vsim -t 10fs top
# vsim -t 10fs top 
# Loading sv_std.std

*snip* Loading other design components...

# Loading work.s6_gtp(rtl)
# Loading work.pkg_gige_fe(body)
# Loading work.s6_gtp_tile(rtl)
# Loading ieee.vital_timing(body)
# Loading ieee.vital_primitives(body)
# Loading unisim.vpkg(body)
# Loading unisim.gtpa1_dual(gtpa1_dual_v)
# Loading secureip.GTPA1_DUAL_WRAP
# Loading secureip.B_GTPA1_DUAL
# ** Fatal: Error occurred in protected context.
#    Time: 0 fs  Iteration: 0  Protected: /top/dut/gtp_gen_l01/gtp_101/PHY/tile0_s6_gtp_i/gtpa1_dual_i/GTPA1_DUAL_WRAP_INST/<protected>/<protected> File: nofile
# FATAL ERROR while loading design
# Error loading design

 What could be wrong here? Note that I am just in the process of coding up the 'top' TB module, maybe there's something wrong with the connection/instantiation of the DUT? ('top.sv' compiles fine though).

 

Regards,

Florian

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Anonymous
Not applicable
8,725 Views

Solved. The following minimum toplevel now works:

 

`timescale 1ns / 1ps
module mintop();
   reg clk = 0;
    B_GTPA1_DUAL dummy ();
    always #4 clk <= ~clk;     
endmodule // top

 with vsim -t 10fs -L secureip mintop

 

The key, as expected, is the timescale directive; omitting it leads to the 'protected' fatal. While experimenting with the clock in another module, I once got

 ** Error: (vsim-3009) [TSCALE] - Module 'miniclk' does not have a timeunit/timeprecision specification in effect, but other modules do.
#         Region: /miniclk

 which might also make sense as the FATAL error message from the module, if we were allowed to see it.

 

Also note that putting the timescale directive INSIDE the module code does not work, it must be specified before the module declaration.

 

I found the timescale line in demo_tb.v from the GTP Wizard and thought I'd give it a try, and yes, that was the problem.

 

View solution in original post

0 Kudos
2 Replies
Highlighted
Anonymous
Not applicable
6,891 Views

Okay, I've isolated, but not solved the problem (yet).

 

It seems that the clock generation is causing the issue, or to be more specific, the delay instruction.

In the toplevel, if I have the line 

always #4 clk = ~clk;

 the error behaviour occurs.

 

If I change that to

always clk = ~clk;

 vsim loads OK (but of course that's not a clock anymore).

 

So, the B_GTPA1_DUAL module seems to have problems with me having delay instructions in the top level (some timescale issue?)

As I'm new to verilog, can a clock stimulus be written without using the '#' delays (that would possibly be a workaround), or is there a 'real' solution to this?

 

Regards,

Florian

0 Kudos
Highlighted
Anonymous
Not applicable
8,726 Views

Solved. The following minimum toplevel now works:

 

`timescale 1ns / 1ps
module mintop();
   reg clk = 0;
    B_GTPA1_DUAL dummy ();
    always #4 clk <= ~clk;     
endmodule // top

 with vsim -t 10fs -L secureip mintop

 

The key, as expected, is the timescale directive; omitting it leads to the 'protected' fatal. While experimenting with the clock in another module, I once got

 ** Error: (vsim-3009) [TSCALE] - Module 'miniclk' does not have a timeunit/timeprecision specification in effect, but other modules do.
#         Region: /miniclk

 which might also make sense as the FATAL error message from the module, if we were allowed to see it.

 

Also note that putting the timescale directive INSIDE the module code does not work, it must be specified before the module declaration.

 

I found the timescale line in demo_tb.v from the GTP Wizard and thought I'd give it a try, and yes, that was the problem.

 

View solution in original post

0 Kudos