Global reset question?

I could be wrong, so maybe I should let the Xilinx people reply. But I am pretty sure that in the Xilinx parts, *all* CLB FFs are either set or reset by the async GRS. This is a hardware feature and does not depend on how you specify the async reset in your code. The code can only control whether it is set vs. reset. (I don't remember if the IOB FFs are cleared or have a controlled async set/reset).

The GRS always controls the starting state of the CLB FFs on configuration, but you don't have to use the GRS signal when you reset your design otherwise. In that case you can use your own input to globally reset your design and have that signal go to the FFs of your choice.

In either case, you need to be aware of the problems created anytime you use a global reset. The delays are typically pretty long and it is hard to assure that your reset trailing edge meets the setup and hold times on all the FFs. When it does not, it can create problems with FFs coming out of reset on different clock cycles and even FFs suffering from metastability problems, although I expect that would be exceedingly rare.

Typically an async reset needs to be combined with a mechanism to hold various parts of your design in reset until every FF has been released.

Although that begs the question of how is this latch set on the initial power up of the part? It will either power up randomly (differently) each time, or it will power up in a consistent state, but not defined. I guess whether this matters depends on how it is being used...

Actually, isn't the case that SRL16/LutAsRam data starts up at a known, DEFINED state based on the initial configuration of the LUT itself?

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

Denis,

There are a few solutions to this problem. First the SRL was mentioned but since you are targeting a Spartan-XL, you do not have an SRL but you do have LUT-RAM and it can serve this same purpose. You can use a RAM16X1S with all address lines tied to a known value (zeroes) and the write enable tied high. You would have more-or-less a FF not tied to global set/reset (GSR) at all. Another possibility to fix this problem is to use a regular FF and have the initial state specied to a one. It sounded like the problem was this the register going to zero and the default state can be made to a one if that solves the issue. In that case, and time GSR is used that register would be set to a one not a zero. Both of the above suggestions are assuming that you are using the STARTUP block to get access to the dedicated GSR net which will set or reset depending on the defined init state of the FF at configuration. If you have not instantiated a STARTUP block in your code, then you will be using local resets using standard routing and in that case anything that you do not connect to the reset will not be reset after power up. This will consume routing resources but the XCS05XL is a small device and as long as timing can be met, should be OK.

The warning message below looks to be issued by the synthesis tool and I am not exactly sure why it is being issued. I think it is trying to warn you that you may have made a mistake in accidentally not connecting one register to the reset but it sounds like you want this done. My suggestion would be to do a timing simulation and see if it works as you want it to. If so, then that can be ignored. If it does not act properly, then you can figure out why and maybe that can address this warning as well.

Hope this helps,

-- Brian

Denis Glees> Hello all

The LUT content is defined in the bitstream. That defines the original state of the latch. Same for SRL16. Peter Alfke

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

I'm not sure what that has to do with my statement, but you are correct, for VirtexII the SRL16 has a cascade out that is permanently connected to the last 'register' in the SRL16, which in effect is the same as forcing '1111' on the LUT inputs and looking at the normal output. The cascade output was a new feature for virtexII.

What Peter was say> According to the Virtex-II datasheet, if your SRL16 is configured as

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

VirtexII

'register' in

virtexII.

that

reconfiguration.

combinatorial

assigned to

directly

of the

latch and

than a

can be

held

of the

There is. SRL16, initialized to 0x0001, arbitrary delay lenght, with the input as a 0. The first cycle on startup it will be a 1, but every cycle thereafter, even after global reset, it will be a 0. If you want a longer "start high" you can make the initial chain of 1s be longer. Or use logic to drive a LUT-as-ram which you then set to 0 after enough startup time has passed.

Basically, you observe that LUT-as-RAM, SRL, BlockRAM contents are preserved across global reset, but start on initialization in a defined state.

What I wrote is not completely correct, but there is a work-around: use DONEbar to force a starting value into the latch. Also: the latch is just one LUT with its output used as one of the inputs. No need for 2 LUTs... We might also agree that the start-up after power-up is not so important. All external RAMs (but not the BlockRAMs) come up with unknown content. Anyhow, the SRL16 solution is the most elegant, and therefore the preferred solution. Peter Alfke

Hi Brian

Thanks for your answer, directed at my problem.

I should have said that at the end of all the warnings I received, was the following.

Warning: No Global(GSR) net could be used in the design because there is not a unique net that sets or resets all the sequential cells.

So I am assuming that the STARTUP block has been included, even though I didnt specifically stipulate that it should.

I am also assuming that my synthesis tool is trying to assign a signal assigned to a pin as a stimulus for this global net. As soon as one register is not cleared by this signal the GSR net is no more.

I ran a simulation to see what I would get. The simulation was done with the scenario described, i.e. one register is not cleared by the input "clear" pin and synthesis gives the warnings described.

I get one BUS signal at xxx? and another at 000?. Even though I am setting my external clear signal high. This is new and not what I normally get from this simulation. I normally get things cleared when the clear signal is high.

From this I assume that my efforts to clear a section of the FPGA leaving one register un cleared is not working.

Now this is really confusing me. I have a pin assigned to have an external signal(with the name clear). This signal is sent to all FFs and counters in the FPGA in my verilog code. Now because I have not complied with the requirements for a GSR signal, I effectivly have no clear?

Many thanks for your input.

Denis __________________________ From Concept to Production