04-12-2009 08:57 PM
I know I can assign zero to all the registers to initialize them(like the verilog test fixture generated by default) during the behavior simulation. But I want to use glbl.v to make the process of behavior simulation more alike to the real situation. I have writen the following code, but it doesn’t work and I don’t know why. I load the simulation by modelsim which starts directly form ISE.
// the start of the code
`timescale 1ns / 1ps
output reg[7:0] count;
always @ (posedge clk)
count <= 0;
count <= count + 1;
//the following is the testbench
`timescale 1ns / 1ps
parameter PERIOD = 100;
CLK = 1'b0;
#(PERIOD/2) CLK = 1'b1;
04-14-2009 07:08 AM
I'm not sure what you expect GSR to do. For a behavioral simulation there
is no connection between GSR and your inferred logic. GSR will reset
any instantiated library elements, however. You might want to try
post translate simulation to see what GSR can do...
04-15-2009 05:03 AM
Thank you for your attention to this post.
In the article "Understanding the Global Signals for Simulation"(which could be found at the link below), it is said that if a global set/reset is desired for behavioral simulation, it must be included in the behavioral code. So I want to try it to make it work. I know when I do the behavior simulation, I can just initialize all the registers to zero. But it is different from the real circuit which initialize all the registers by GSR after the configuration. However, the code which list above doesn't work and I want to know why.
But after reading your answer, I am a little confused. Do you mean I can only include the above code(which simulates GSR signal) for post place & route simulation? But in my view, GSR will be included by default when I do the post place & route simulation. I just need to compile glbl.v and don't need to include GSR signal in my testbench.
04-15-2009 06:22 AM
What I am saying is that the GSR signal itself is not the problem. In fact even for behavioral simulation
GSR is weakly driven active by default for 100 ns at the start of simulation and then weakly driven inactive.
The GSR signal is a global signal used by all of the library models including any CoreGen modules. However your
behavioral code (not the testbench, but the code you are putting in the FPGA) would need to model
the GSR behavior for this to reset the registers during behavioral simulation. After translation your
code is replaced by the library models for simulation. Then the GSR will reset the registers.
Most people don't try to make the behavioral code match the GSR behavior of the models. If you already
have a reset signal to your module, just drive that active at the start of simulation.
04-15-2009 09:53 PM
Thank you very much for your answer and especially, the patience.
Firstly, influenced by wp272, now generally, I don't use additional reset signal in my code and rely on GSR signal to reset all my registers in real circuit. So, in order to make the process of behavior simulation more like the real situation, I want to use GSR signal to reset all my registers too rather than initialize all the registers to zero.
However, at first, I think there is no need to change the code (not the testbench, but the code I am putting in the FPGA) even if I want to use GSR signal to reset the registers during behavior simulation. Now I know, in this way, I have to model the GSR behavior for this, which isn't what I expect. So, if it is true, maybe initializing all the registers is a more easy way. Am I right?
04-16-2009 05:31 AM
Initializing registers is the simplest way to make your simulation match the
post-translate behavior. If you are worried about using resources for
unnecessary resets, you could do this two ways:
1) In each module place an initial block that initializes the registers at the
start of simulation. Enclose the initial block with "translate_off ... translate_on"
// synthesis translate_off
reg1 = 0;
. . .
regN = 0;
// synthesis translate_on
This method will match the configuration reset if all the initial values are zero.
2) My preferred method is to give all registers an asynchronous reset in
the synthesizable code. Generally there is little or no such code in my top
level module, only in the lower-level modules instantiated at the top level.
If I don't really need the reset, I then tie the reset input low when I instantiate
the module. Testbenches for each module would drive the reset port
at time zero.
output reg[7:0] count;
always @ (posedge clk or posedge reset)
count <= 5; // Note that this doesn't need to be zero. GSR will match this value even if reset is tied low
count <= count + 1;
Then at the top level:
.reset (1'b0), // This does not change the power-on behavior of the module registers
In a testbench I would drive reset high for at least 100 ns. This is to avoid problems when
parts of the design use library elements held in "power-on reset" by GSR.
04-17-2009 12:38 AM - edited 04-17-2009 12:44 AM
Thank you very much for your answers and patience during this series of discussion about the GSR signal and the proper way to reset the registers. And your knowledge about FPGA has impressed me a lot.
I start to think about those things seriously when I encountered a problem during the behavioral simulation. In that case, since I don't initialize those registers to zero, the counter which used those registers cannot work correctly.
And especially after reading wp272, which discusses how to handle the reset signal more smartly and properly, I want to reset all the registers that way. Since all the registers will be reseted by GSR signal, I want to rely on that signal rather than other manual reset in order to use less logical resources. Although all the flip-flops have dedicated reset port, others resources, such as routing resources, really should be considered.
Afterwards, I want to use GSR signal even during my behavioral simulation to make the behavioral simulation match the post-Place & Route simulation. So I wrote the above code, which I find a little funny because during behavioral simuation how could those tools like modelsim know what is GSR signal. Now in my view, maybe initializing those relevant registers(for example, those which I will use to count and other registers don't need additonal initialization ) to zero is a more proper way especially considering that I don't want to add any additionaly signal in my code(not the testbench) for GSR signal during behavioral simulation. I want my code is exactly the same during behavioral simulation and post-Plance & Route simulation.
As for your two recommendation way to handle this problem, the first way is really proper and "synthesis translate_off" may not be added additionally. As for your second ways, I have implemented your code using ISE 10.1. If I assign zero to reset signal at the top level, the synthesis and implementation process will ingore this reset like it doesn't exist. And during behavioral simulation, you can drive reset signal high for 100ns to let it like GSR. But the last a little confused thing is that maybe you should write the code like the following:
count <= 0;
Otherwise, those registers will not be zero after the first 100ns during the behavioral simulation. I am really confused about your words"note that this doesn't need to be zero". How can GSR match this value during behavioral simulation because during it, there is no GSR. If you don't mean using this reset signal to stimulate GSR signal during behaviroal simulation and don't assign zero to reset signal at the top level, I think this vaule should be zero too. Only in the follwoing two situation can you assign any value to those registers:
(1) don't assign zero to reset signal at the top level and don't use this reset signal anytime. But those logical and routing resource will be wasted.
(2) assign zero to reset at the top level. Since the synthesis tool will ignore reset signal, in this case you could also assign any value to "count".
Do you mean those two situation?