Xilinx Best Source for Reset

>>> synchronizing the reset to your local cock(s)
>
> nooooo, you really don't want to do that at all.  Jolly painful.

Jonathan, I hope you're not being rude ;-)

> See the recent thread "Bulletproofing CPLD Design" on comp.lang.vhdl
> for further suggestions from me and others on this issue.

To recap, Jonathan suggests.....
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
- Datapaths, configuration registers etc have simple asynch reset.
- Sequence-control state machines have asynch reset, but also have
  synchronous reset signal that holds them in their idle state.
- Arrange one small dedicated piece of logic that is reset by
  asynch reset, and holds the synch reset signal active for
  two clocks after asynch reset has been released.

Now, your sequence controllers will remain in their idle state
for two clocks after the end of asynch reset.  While they are
in the idle state, no other activity will run in the other parts
of the design.  Consequently, it doesn't matter what happens
to the other flip-flops immediately after the end of asynch reset.
But the synchronous reset is applied only to a small part of the
design (the sequence control FSMs) so it consumes very little
extra logic.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Which is similar to the approach I take, except often the synchronous
reset can also be triggered by an SBC/CPU or whatever to get the FPGA
to a known state.


The question still remains...

"If you drive flip-flop asynchronous reset inputs from a synchronous source,
are the tools intelligent enough to include these paths and the flip-flop
reset mechanism in the timing analysis"?

If so then the extra synchronous reset logic could also be dispensed with.

Anybody from Altera/Xilinx want to comment?


Nial.

Hmm.  I have to admit that I didn't think of this.  So you can register
your reset at the IO pin and then have that synced output drive the
internal global reset? Is that right?

>> Actually this is a false compromise. There is a perfectly safe way of
>> synchronizing the reset to your local cock(s) so that there is no
>> chance of metastability regardless of the reset release time. This way
>> you can continue to use async resets.

Brad Smallridge wrote:

> Wow, that's an interesting use of procedures to automatically
> restructure a program.

I like to play with templates.
For production code, I just pick one and use it.

> I brought the question of async vs. sync reset to the group awhile ago,
> and someone told me (they should harp in here to get credit), that with
> an async reset you may have metastable issues when your reset goes
> inactive, which sort of defeats the purpose of having a reset.

Unless the inactive edge is synchronized.

> So this
> sold me on sync resets, end of story.

That will work fine.

> 
> When does a CPU know when to reset the FPGA?

In our system, the cpu runs the show.
The FPGA is just one of many chips
that is initialized during boot up.


        -- Mike Treseler

On Thu, 4 Aug 2005 11:57:51 +0100, "Nial Stewart"
<nial@nialstewartdevelopments.co.uk> wrote:

>>>I brought the question of async vs. sync reset to the group awhile ago,
>>>and someone told me (they should harp in here to get credit), that with
>>>an async reset you may have metastable issues when your reset goes
>>>inactive, which sort of defeats the purpose of having a reset.  So this
>>>sold me on sync resets, end of story.
>>
>> Actually this is a false compromise. There is a perfectly safe way of
>> synchronizing the reset to your local cock(s) so that there is no
>> chance of metastability regardless of the reset release time. This way
>> you can continue to use async resets.
>
>
>If you generate a synchronous reset signal then connect that to the asynch
>reset input of the registers in your design, can you be sure that the tools
>include this path in the timing analysis?
>
>It be a reasonable assumption of those designing the timing analysis tools
>that anything going to an asynchronous input doesn't need to be included.

The Reset to Clock path of a flop is very similar to Input to Clock
path and in all libraries I have used it is a timing check which is
included in the flop description. The release time of the reset is
checked against the clock pulse. By supplying a registered reset, you
are allowing to STA tool to do a better job because now it has an
availabitlity number for reset with respect to clock which can be
checked. 
Of course this assumes that your cell library has the reset to clock
timing checks.

On Thu, 4 Aug 2005 10:45:04 -0700, "Brad Smallridge"
<bradsmallridge@dslextreme.com> wrote:

>Hmm.  I have to admit that I didn't think of this.  So you can register
>your reset at the IO pin and then have that synced output drive the
>internal global reset? Is that right?
>
>>> Actually this is a false compromise. There is a perfectly safe way of
>>> synchronizing the reset to your local cock(s) so that there is no
>>> chance of metastability regardless of the reset release time. This way
>>> you can continue to use async resets.
>

In a way yes and it's safe to do. You don't register the reset signal
though. Assume you have an active low reset. You connect input of a
flop to 1 and connect its async reset input to the reset io pin, a
second flop takes the output of the first as input and it's also async
reset by the io pin. These are clock by your local clock (of course
you have to make sure that for every clock domain in your design, you
repeat this process). 

So now when reset io is on, both flops are reset which also resets
your design. When reset io goes high, the first flop can get upset if
it's close to the clock edge but the second flop is perfectly happy as
its input doesn't change at the same clock. On the next clock it sees
the high value on its input (as the first flop is not being reset
anymore) and propagates it to its output (as it's not being reset
either).

This works very nicely if the library has the reset to clk path
characterized and timed.

> In a way yes and it's safe to do. You don't register the reset signal
> though. Assume you have an active low reset. You connect input of a
> flop to 1 and connect its async reset input to the reset io pin, a
> second flop takes the output of the first as input and it's also async
> reset by the io pin. These are clock by your local clock (of course
> you have to make sure that for every clock domain in your design, you
> repeat this process).

OK.  Are you doing this with Unisim components?  Or can the
XST infer all this through VHDL?  And then does the synched
reset from the second flop then connect to some global reset?
And then how do you check that the synthesizer is correctly
inferring to use the synched reset signal?

Brad

"Brad Smallridge" wrote:

>> In a way yes and it's safe to do. You don't register the reset signal
>> though. Assume you have an active low reset. You connect input of a
>> flop to 1 and connect its async reset input to the reset io pin, a
>> second flop takes the output of the first as input and it's also async
>> reset by the io pin. These are clock by your local clock (of course
>> you have to make sure that for every clock domain in your design, you
>> repeat this process).
>
>OK.  Are you doing this with Unisim components?  Or can the
>XST infer all this through VHDL?  And then does the synched
>reset from the second flop then connect to some global reset?

Try something like this:

Process(clk,resetin)
begin
  if resetin = '1' then
    reset1 <= '1';
    reset2 <= '1';
  elsif rising_edge(clk)
    reset1 <= not dll_lock;
    reset2 <= reset1;
  end if;
end process;

-- one of many processes
Rest_of_logic: process(clk)
begin
  if rising_edge(clk) then
    if reset = '1' then
      -- set reset conditions where needed
    else
      -- normal operation
    end if;
  end if;
end process;

Output_needing_forced_off_during_reset: process(regular_oe, reset, d)
begin
  if regular_oe = '0' or reset = '1' then
    OUTPIN <= 'Z';
  else
    OUTPIN <= d;
  end if;
end process;

>And then how do you check that the synthesizer is correctly
>inferring to use the synched reset signal?

FPGA_editor.


--
Phil Hays
Phil-hays at comcast.moc (remove moc and add net) should work for
email