That Dangerous Asynchronous Reset!

[chapman]

Anyone who knows me will tell you that I hate global asynchronous resets with a passion! If you don’t know me that well, then please take a while to read white papers WP272 and WP275 and, hopefully, you will understand why. If, like so many other people, you do have a coding style that results in global asynchronous resets, then I totally understand that you won’t immediately welcome my suggestions, and I can appreciate why. Let’s face it, there is an abundance of coding examples out there that include this nasty habit and we all copy something to begin with. 

http://www.xilinx.com/support/documentation/white_papers/wp272.pdf

http://www.xilinx.com/support/documentation/white_papers/wp275.pdf

This time, I’m going to focus on just how dangerous asynchronous resets can be. Maybe after this repeated horror story, you will be thinking twice about your coding style in the future.

Unreliable Sporadic Behaviour!

Three times now I have had Spartan users come to me saying that their designs are behaving “erratically” (well, that’s the polite way of saying it!). Ken asking them if they have a global asynchronous reset was not exactly what they wanted to hear back, but it did become the start of their investigation. In each case, there was indeed a large, if not truly global, asynchronous reset sourced by a pin on the device. The following picture is a simplification of their situation. Not surprisingly, the reset signal was also quite a big network on their PCB’s as well.

[see image (1) below]

The problem with such a big trace on a PCB is that it can also be a rather good antenna waiting to pick up signals. In fact, let’s not rule out that it may also reach out across multiple boards, or even pass through wiring looms, to reach a big black reset button somewhere! In the three cases that came my way, this was exactly the situation, and as the red trace on the PCB illustrates, there was indeed an opportunity for some inductive coupling to take place between the traces and induce a very narrow pulse into the FPGA causing at least a partial reset of the logic. As the pulse propagates through the programmable interconnect of the FPGA, it tends to ‘decay’ and hence effects only some of the flip-flops to which the reset signal connects.

Looking in the Spartan-3A data sheet, you can see that the minimum pulse width to reset a CLB flip-flop is TRPW_CLB and is stated to be 1.61 ns in the -4 speed grade. The key thing is that this is the minimum pulse width to guarantee that the flip-flop is reset under worst case conditions (low voltage, high temperature and slowest device we might ever manufacture). In practice, devices are nearly always faster under normal conditions and often significantly so. This means that induced pulses less than 1 ns can easily be enough to cause problems, which is nasty because very often you don’t have an oscilloscope fast enough to see them. It’s also one of those annoying situations where simply attaching the scope probe often introduces enough capacitance to suppress the pulse adequately to stop the issue when you try to observe it.

The Quick Fix!

Of course, I’m going to say that it is time to remove the asynchronous reset from your design. Certainly, that should be true at the start of your next design, but these things tend to happen when you have little time to fix them. Likewise, this is unlikely to be the time to consider better layout of traces on the PCB to prevent signals coupling. So if you find yourself in this situation, the quick fix is to add a filter to the reset signal as it enters the FPGA. Note that PROG_B could be considered to be the ultimate global asynchronous reset for the FPGA, and because of that we include a filter which prevents any pulses less than 100 ns or so from triggering reconfiguration; we need to mimic that filter using look-up tables as shown below.

[see image (2) below]

One or more buffers implemented in separate LUTs combined with their associated interconnect provide a delay to the incoming signal such that only a pulse longer than that delay will provide a High level to the AND gate when the directly routed input signal is still High. This will eliminate those spurious unintentional pulses for now, but in the future don’t even allow this to be a potential problem for your designs.

Message Edited by kcmman on 06-16-2008 09:35 AM

[brouhaha]

I've never understood why anyone uses an asynchronous reset in a system that is otherwise fully synchronous to a free-running clock, since it's blatantly obvious that it is a source of non-deterministic behavior.

[chapman]

Well obviously I agree with you in the practical sense and can rest easy that your designs do not suffer from such problems described in this Blog. However, I can at least understand why other people do it. In the many classes I have taught over the years the most frequent reasons given for having a ‘global’ asynchronous reset have been as follows.

“I need one to initialise my simulation”.
“You need one to be able to test devices”.
“It’s in our company coding standards”.

The second two really relate to the implementation of ASICs where even the most fundamentals testing of silicon you at least have to know that the device starts in a known state at the beginning of each test. Indeed our FPGA devices also need this so we can test them before we ship them to you and everyone can use that themselves because it is called the PROG_B pin. Any design that is subsequently configured into the device is then in a known state so there is just no need for another reset in the design either synchronous or asynchronous.

However it is the issue of simulation that really dominates most users of FPGAs. The problem with simulation is that it is a SIMULATION. Simply getting everything to work in the simulator is only an indication that the design will work under one specific set of conditions. In practice the device the speed of the device will be different in different places, but more specifically, just how will that asynchronous reset release relative to your clock? By having a global asynchronous reset just so a simulation looks ‘tidy’ at the beginning then users are throwing away a huge amount of valuable information. It really is a case of ‘head buried in the sand’ to think that everything it alright because a simulation looks nice. In truth, a simulation that starts up full of ‘unknowns’ can be perfectly alright, but where it is not alright to have ‘unknowns’ it is telling you that your HDL code is lacking an initial state declarations.

Here is a link to the white paper covering this subject in more detail.

http://www.xilinx.com/support/documentation/white_papers/wp272.pdf



Regards,

Ken

[dpollum238]

My board designs use CPLDs (9500 & 9500XL) and micros. I use a reset chip such as the TI TLC7705 or MAX-811. The reset chips feeds a 2 FF synchronizer in the CPLD, which in turn resets the CPLD's FFs that use the same clock (as per WP272). In other words, reset assertion is asynchronous, but reset de-assertion is synchronous.  I also have an external RESET push button switch, which may be on a long cable, so I don't connect it directly to the reset chip. Instead I connect the switch to the ground and cathode input of an opto-isolator. The isolator's output is then connected to the reset chip's reset switch input.  This keeps noise on the reset switch cable from accidentally resetting the CPLD and micro.
Dave Pollum

Message Edited by dpollum238 on 09-08-2008 09:44 AM

[randy@06]

Hi Ken,

I used to use async resets to initialize flops to specific states in my designs (e.g. states of FSMs, values of counters, etc), but now I use initialized signals, like in the following VHDL:

signal MYCOUNTER : integer range 0 to 7 := 3; --initialize counter to 3

signal MYSTATE : MYSTATETYPE := sINIT; --initialize fsm to state "sINIT"

signal MYVEC : std_logic_vector(15 downto 0) := X"BEEF"; --initialize 16 bit register to 0xBEEF

This works for me in XST synthesis AND simulation.  Chip powers up, and simulation starts, with these values.

I read about this once in Xilinx docs, and switched to this method.  Is this still a/the preferred way?

Thanks, 

Randall

[Anonymous]

Ken, The primary reason I have seen the global async reset used is It also allows the user to reset the part without having to reprogram the whole part, and to get the simulation to work as you noted.

There are many problems you pointed out that can arrise, but if you address each of them then can't the asynchronous reset be far more efficient than coding a synchronous reset?

If you coded the design such that the async reset uses the global reset resource, and synchronize the global reset to your primary clock, then is your primary clock safe? If the secondary DCMs are reset by the same asynch reset, and also the lock signal from the first DCM, and then if you gate these clocks with thier own lock signals, are they not also safe?

[chapman]

Synchronising the switching of an asynchronous reset to the clock is effectively a way to make the global reset synchronous even when using asynchronous reset inputs to flip-flops. However, to do so requires that everything is clocked by the same clock source (again something I advocate but just isn’t possible in all cases and why we have to provide multiple DCMs and clock buffers in our devices).

It also requires that the synchronised reset signal can be distributed globally within a single clock period to meet set up and hold times at all the loads. This is possible when the clock rate is slow enough but it rarely is! The DLL (the heart of a DCM and similar to a PLL) was introduced into Xilinx FPGA’s many years ago simply because it was not possible to distribute a clock globally fast enough. So the same applies to any global signal. The issue is that a reset signal is not repetitive like a clock and therefore can not be predicted in the same way that a DLL exploits.

Ultimately, you are correct but only if you are using a single slow clock. Since a Xilinx flip-flop can be synchronously or asynchronously reset there is no real saving (the transistors are there already).

[jnm]

I have a design (xc3s1600e-4fg320) with an async reset that is IP which has been implemented successfully by several people.  In my implementation the design is operating properly and passes board-level diagnostics.  However, the default value for several status registers does not match the value designed.  Sometimes following reset a value is correct, other times it is not.  It appears this is a problem addressed by WP272.  I've implemented the circuit that synchronizes the reset to the clock - see below - and now the design fails board-level diagnostics.  All timing constraints were met.  What could cause this problem?

A 20MHz clock (ref_clk) from an external oscillator is brought into a DCM and multiplied to 40MHz (cpu_clk).

rst_async_n is the external async reset.  It will pulse low for 300ms, then 300ms will pass before access to the part begins.

DCM cpu_clk_dcm (
  .CLKIN(ref_clk), // 20 MHz
  .CLKFB(), // use CLK0 or CLK2X
  .DSSEN(1'b0),
  .PSINCDEC(1'b0), // unused - no phase shift
  .PSEN(1'b0), // disable phase shift enable
  .PSCLK(1'b0), // no phase shift clock
  .RST(!rst_async_n), //
  .CLK0(), // freq = clkin, can drive clkfb for DLL ops
  .CLK90(), // freq = clkin, phase shifted 90
  .CLK180(), // freq = clkin, phase shifted 180
  .CLK270(), // freq = clkin, phase shifted 270
  .CLK2X(), // can drive clkfb for DLL ops
  .CLK2X180(), // freq = clk2x, phase shifted 180
  .CLKDV(), // clkin/clkdv_divide
  .CLKFX(cpu_clk), // clkin*clkfx_multiply/clkfx_divide, 40_MHz - set in ucf
  .CLKFX180(),
  .PSDONE(), // unused - no phase shift
  .STATUS(),
  .LOCKED(cpu_clk_locked)
);

always @(posedge cpu_clk or negedge rst_async_n) begin
  if (!rst_async_n) begin
    cpu_rst_n <= 1'b0;
    cpu_pre_rst_n <= 1'b0;
  end else begin
    cpu_rst_n <= cpu_pre_rst_n;
    cpu_pre_rst_n <= 1'b0; //cpu_clk_locked;
  end 
end

Also, it is clear that the sync'd reset must be distributed faster than a clock period of the clock,

so a MAXDELAY constraint is needed.  The best I can tell this delay must be PERIOD - JITTER_BUDGET - CLK_TO_OUT_DELAY - FF_SETUP.  If this is a common technique necessary for building reliable designs, why isn't there a Xilinx document that describes the necessary implementation details (i.e. MAXDELAY).

[jnm]

I've been told by FAEs that including in the UCF

ENABLE = reg_sr_q;

ENABLE = reg_sr_r;

ENABLE = reg_sr_o;

will not only report violations of async reset use,

but will be used by ISE for timing driven placement and routing.

I've been told this has solved this problem for other customer.

Is this true?

Does ISE actually figure out the clock period and ensure that all FFs are reset in the same clock period without having to actually synchronize the reset to the clock?

[jnm]

The STARTUP_SPARTAN3E primitive appears to allows the global reset to be synchonized to a clock.

If a design uses a single clock, then this primitive can be used to sync the global reset to that clock.

My FAE tells me Xilinx told them that this is an acceptable way to address the problem in WP272.

Do you agree?

I also understand that if you have control over the clock, then it would be acceptable to stop/gate the clock,

assert the async reset, then start/ungate the clock.  Can you comment on this approach?

Could I use the DCM CLKFX in combination with a BUFG_MUX primitive to implement such an approach for each clock in my design?

[chapman]

Dear jnm,

Sorry to hear of your problems but I’m afraid they are not unsurprising to me. As long as people continue to design using these ‘global asynchronous reset’ signals these problems will be there to bite just when you don’t want them too. Clearly it is better top avoid them by design rather than look for ways to patch them afterwards and I’m sure you will now be motivated to do that in your future designs.

The suggestions made sound reasonable but probably still will not provide a solution in most real designs. All the suggestions are really a way to enforce a synchronous operation onto an otherwise asynchronous design. In each case they are ways to make sure that the reset signal (when going active or inactive) has been distributed to all loads meeting set-up time before the next clock edge then it will be safe and work. The key point about these paths is that simply reaching a flip-flop reset pin is not enough; the path from that flip-flop that gets asynchronously reset to its load(s) is also part of the path that must meet timing. The net effect being that the clock frequency needs to be rather slow (like in the good old days when most designs were less than 20MHz) so if your clock is faster then your design just won’t meet timing. Using a global signal to distribute the reset sounds good but again this global signal will not be that fast and still you have the path from the flip-flops as well as to them to consider. Once again the net effect is a rather slow design. Finally the idea of stopping the clock is valid providing it is possible to stop the clock. DCM, DLL and PLL are all about locking to free running clocks. If your design doesn’t use these clocking components then you would be able to stop your clock but that again means that your application has relatively slow communication requirements on the I/O pins.

In summary, if a design is low frequency like most were in the olds days then you can probably get away with using global asynchronous resets. In a modern design you almost certainly need to apply modern design techniques. It is just a pity that ther are so many old examples of coding out there that continue to see the younger engineers learning bad habits today.

Good luck getting your design to work reliably and for sharing your misfortune with others. I really hope it helps to motivate more readers to take this fundamental issue seriously and change their ways.

Regards,

Ken

[nju044]

Hi, kcmman:

About the image 2, I have something don't understand.

Since the "delay" and "input" connect to input pins of AND, I think "filtered" should fall to zero when "input" falls to zero. According to the image, it's not the case.

Is there anywhere I misunderstand? Thanks in advance!

[chapman]

The timing diagram is also representing the propagation delay through the LUT which is implementing the AND gate. So 'filtered' is going Low due to 'input' going Low but there is a small delay.

[nju044]

Hi, kcmman:

I read your white paper about synchronous design. But I am a little confused about in which condition should I apply this principle to my design.

For example:

I read xapp283. All of its verilog source files do not comply with synchronous reset rules.

I read xapp199. Some of its verilog files comply with these rules while the other files not.

Can you help me with this obsession? I'm sorry that I can't find the file attachment feature......

[chapman]

Yes, I am obsessed about this!

I’m also obsessed about people that drive whilst holding and talking on the their mobile phones whilst driving. Lots of people do that even though it illegal in some countries. Lots claim that they can still drive in perfect safety whilst doing it and statistically most people do get away with it. But every now and again it contributes to a crash and for those involved it becomes a serious matter. Now may be on a long drive down a big road with light traffic on a clear day you could even argue that it is safe to talk on your mobile phone whilst driving and may be I’d even agree with the suggestion that talking helps to keep you awake on that long journey. But the danger is when you believe it is still ok to use your mobile whilst negotiation a busy road junction next to a school when all the children are coming out onto the street.

So to be realistic about the application of resets I can see that I will never win the battle against such a deep entrenched HDL coding style. A coding style that often makes life easy for simulation and of course people want to copy and reuse old code without changing it. In a great deal of cases the use of an asynchronous reset will make no difference at all such as in the pipe line stages of a data path. Indeed, my point is that the majority of a circuit doesn’t need a reset at all and one way or another it is an overhead but people do like there simulation to look clean so they keep it and apparently accept the cost of including it. Let me say that I have lost count of the number of designs that I have been able to speed up enough to achieve the desired timing simply by removing the resets from the elements that never needed in the first place. This has nothing to do with asynchronous being dangerous, but emphasizes that there is a cost associated with a ‘global reset’ and you can ignore that until it matters if you like! When it does matter then often people can’t see that it is the cause.

However, there are resets that really do count such as the one to a state machine. Most of the time you will get away with it but a good engineer will recognize when it is necessary to stop doing the ‘normal’ thing and focus on doing it 100% right. I have a set top box at home that I have to unplug a couple of times a year when it unexpectedly locks up; annoying but the worst that happens is that I fail to record a TV program. I don’t expect the pilot of an airliner to be unplugging the flight control system on final approach to land. Economic pressure to get a design out quickly may encourage a degree of risk but when the risk must be kept to a minimum then it is only right to focus more and review coding styles. If someone doesn’t design correctly when it matters and then things occasionally go wrong they often turn to the manufacturer of the device for an explanation. Their expectation is that there is a fault with the device and that is when things can become very emotional!

The reason so much code contains a ‘global asynchronous reset’ stems from when an ASIC needed to be tested during production. To begin any test it really helps if everything can be placed in a known state and a global asynchronous reset does that the cheapest way. As a result it became common for design reviews to include the review item; “are all flip-flops connected to the reset input?”.  Well old habits die hard and so we still see that coding style and we still find that requirement in company design reviews. But there are two important observations. Firstly that was a reset used for test purposes and not during general operation. Secondly we are using a Xilinx FPGAs and not building an ASIC. All Xilinx FPGAs come to you fully tested and have the built-in initialisation mechanism.  If you drive PROG_B Low then it acts as the most comprehensive global rest you could ever wish for; even the block memories are reset and reloaded by the next configuration. If you are designing for an FPGA then why write code for an ASIC? Why have design review items that enforce ASIC design rules onto an FPGA design when it adds unnecessary cost?

In conclusion, I’m really not saying all usage of asynchronous reset is dangerous. It is ‘acceptable’ for a lot of code to continue carrying this style albeit less than desirable in an FPGA design. But what I really ask is that a design review should check for what is being reset and ensure that correct synchronous techniques are used where it really matters. Any circuit that relies on feedback being the most obvious target. Then, based on the subject of this blog, I would also highly recommend that the integrity of any signal used as an asynchronous reset is thoroughly reviewed.

[nju044]

Hi, kcmman:

Thank you very much for your comprehensive explanation and this does solve many phenomena I encountered. For many times, changing my code to synchronous reset doesn't affect the hardware verification.

I am always confused about the term "global reset", and read http://forums.xilinx.com/t5/DSP-Tools/About-reset-for-system-generator/m-p/74222#M2770. I know GSR is a kind of global reset, although it's not recommend because of large-skew.

I am guessing what is connected to the top module's RESET pin is a global reset while what connects to submodule's RESET pin is a local reset. Is this cognition right?

[chapman]

Try to think in terms of ‘global’ simply meaning ‘everything’ or ‘all’ regardless of scale. If I develop a macro that contains 100 flip-flops and every one of them is connected to a reset signal then we can say that the macro contains a global reset. If I then instantiate that macro in a design 20 times and I connect all the reset inputs back to one reset input pin there will be 2,000 flip-flops all connected to the same global reset even though at the top level it only looks like there are 20 loads. So it isn’t how it looks depending at what level you view it but the fact that you have just blindly connected every reset together at any level that you look at it. The danger is that what seems small at any one level all adds up to be something big and that large fan-out will result in larger delays and skew both of which contribute to the nasty stuff we are trying to avoid.

In contrast, a local reset is where only those flip-flops that need to be reset in a particular way are treated in isolation. For example, I may have recognized that of the 100 flip-flops in my macro, 4 were used to form a state machine critical to reliable operation so I provided them with a carefully controlled synchronous reset generated locally (probably a signal generated as a consequence of the release of the ‘global’ asynchronous reset).  May be I left the other 96 flip-flops connected to the ‘global’ reset just for a clean simulation (or to satisfy that unnecessary design review item!). Back in the big design I would then have 1,920 flip-flops connected to the ‘global’ reset but providing as long as the input reset signal is clean that would be fine. However  the complete design also contains 20 carefully controlled local resets which do matter.

Now there may be cases in which the  local reset needs to connect to tens or even hundreds of flip-flops so you shouldn’t take fan-out as a measure of what is local or global. The key difference is that in any localized reset you maintain precise control over what happens because you care about it. In practice, it just gets very difficult to maintain that control if the fan-out is too high. If it were easy to have precise control over all flip-flops in the device then we wouldn’t be having this discussion.

To make it really simple….. Local means you care and global means you don’t.

[nju044]

Hi, kcmman:

This is more specific than the other threads I searched in the forum and really helps me. Thank you very much!

[fraveydank]

Ken,

Thanks for this series of articles and the resulting thread.  It's caused me to reevaluate how I think about reset logic, and that can't be a bad thing.

However, your preference for synchronous resets causes some portability problems for me, since our company does an equal amount of work with Altera FPGAs.  Altera's architecture has the synchronous load/clear logic between the LUT and the flip-flop, meaning that the clock enable must still be asserted for the flip-flop to clear (the resulting synthesis tends to require that the clock enable take precedence over the synchronous load/clear, otherwise it generates extra glue logic).  This is at odds with the typical synchronous reset coding, where the synchronous set/reset takes priority over the clock enable.

For this reason, I still tend to use global async resets (synchronized and debounced internally to a local clock) because the priority inversion tends to inhibit portability between architectures.  Do you have any suggestions (other than the obvious "don't use other architectures" :-)?

[fraveydank]

(above edited, but it won't let me delete this comment)

[chapman]

Putting to one side the weaknesses of devices offered by another vendor, I think the aspect you may still not be fully grasping is the advantages of thinking  local rather than global. Great that you are in some way synchronising your reset to your local clocks before they get applied to your circuits but I still see no point in a global distribution.

Quite literally everyone wins if you don’t reset something unless it really needs to be reset. In other words, probably less than 10% of your design needs the flops to be reset (properly) and the rest don’t need to be reset at all.  So see how much of your source code can have the reset removed and then it won’t ever be a problem in any architecture.

[jonas812]

> The reason so much code contains a ‘global asynchronous reset’ stems from when an ASIC needed to be

> tested during production. To begin any test it really helps if everything can be placed in a known state and

> a global asynchronous reset does that the cheapest way.

In case a design is first tested on a FPGA before being implemented on an ASIC, why not write processes so ?  :

process (Reset_i, Clk_i) is
begin
    if Reset_Style = ASIC And Reset_i = '1' then
        <...>
    elsif Rising_Edge (Clk_i) then
        <...>
    end if;
end process;

Like showed by the code below, Reset_Style is a global enum constant that is to be set to FPGA at the time the design is tested on a FPGA and will be set to ASIC when the design will be implemented on an ASIC :

type Reset_Style_Type is (FPGA, ASIC);

constant Reset_Style : Reset_Style_Type := ASIC;

Greetings

Jonas

[peterfrey]

@kcmman:

I find it interesting that the STARC VHDL linting ruleset doesn't agree with you.  See rule 3.3.1.4:

http://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_stylgd_vhdl_eng.html#1023818

Care to comment?

Thanks,

[chapman]

Having looked at the reference you have provided and seen that it refers to a ‘ruleset’ called ‘S_3_3_TEST_FACILITATION_DESIGN’, then I think it is safe to assume that this item relates to a design practice for testability of a device. In which case, it appears that you have yet to read the very opening words in WP272 (link provided at the beginning of this Blog). Those words are as follows...

One of the commandments of digital design states, "Thou shalt have a master reset for all flip-flops so that the test engineer will love you, and your simulations will not remain undefined for time eternal."

So, some may be surprised to learn that applying a global reset to your FPGA designs is not a very good idea and should be avoided. Clearly, this is a controversial issue, so let's take a look at the reasons why such a design policy should be considered.

Then included in WP275 are the following words....

When adding controls to their designs, designers often include a global reset. This reset is especially liked for simulation. However, because a Xilinx FPGA already starts up in a known state following configuration, the global reset is really not necessary.

In other words, it comes back to the fundamental difference between an ASIC and an FPGA. It is wrong and inappropriate to apply ASIC coding styles and design rules to an FPGA design. I’m not here to stop you or anyone else designing to ASIC rules if you feel compelled to do so. However, I am saying that to apply such inappropriate rules will impact design performance, increase power consumption, increase costs (engineering time and device cost) and, worst of all, have the potential of being dangerous as this Blog has described.

[arroxo2]

Hi,

big reason to use a asynchronous reset:

- CDC:

when you use several clock domains, sreset delays can be very different in each clock domain, then How to ensure a reset in all the whole design at the same time? - your design could have portions of design that could be unbehaviour (some portions reseted while others not) - and the same reason when the reset is de-asserted

To apply areset in a right way you should ensure no glitches (combinational logic at input to filter it) and reset de-assertion synchronization (please google it!)

- Xilinx recommends sreset, but that's due to the tool does not able to calculate the removal/recovery time. Xilinx likes to analyze the reset as another synchronous signal, not more...

- Altera analyzes that timing very well

sreset and areset are two valid methods but they must be planned and designed carefully:

- sreset: safe when no techniques are applied

- areset: unsafe when you do not take care of it (remember!: you need to use an synchronous reset de-assertion filtering)

best choice (in my opinion): areset! (FPGA)

[arroxo2]

and another comment:

"However, because a Xilinx FPGA already starts up in a known state following configuration, the global reset is really not necessary" => Xilinx does not recommend it in its coding style guides!!! why? the answer is PORTABILITY!!!

known state at start-up depends on the device and the sinthesis tool, besides RTL and gate-level netlist could differ in this start-up state (RTL and gate-level comparison can not be performed!!!), and design could not be portabled to another device or manufacturer.

How many problem have you when you try to move your design to another ISE version? (me: a lot!!!)