synchronous reset problems on FPGA

Hi,
   I am wondering if anyone of you have experienced this before. Here
goes the reset problem I am facing now. asynchronous reset in FPGAs
are usually a big NO-NO. from the articles I am reading, the async
reset, normally results in more logic being used to stitch up LUTs
together.
  However, the design I am currently working on requires only one of
the blocks to run at 1/4 that of the original clock speed. I am using
a DCM to clock divide the master clock, and the output goes into this
block. The problem happens when

- the reset signal which resets the DCM, is the same reset which goes
into this same block.
- This will result in a problem, as the clock-divide-by-4 as I call
it, will not emit a clock pulse in reset state, as the DCM has not
locked yet. the synchronous reset will thus not work for this block.

1) Any ideas of how to circumvent this problem? I would like to use
synchronous resets, but also use the divide by 4 clock for the block.
2) Are my concepts of synchronous resets correct? that synchronous
resets on FPGA are better than asynchronous resets?

thanks

Chris

chrisdekoh@gmail.com wrote:
> Hi,
>    I am wondering if anyone of you have experienced this before. Here
> goes the reset problem I am facing now. asynchronous reset in FPGAs
> are usually a big NO-NO. from the articles I am reading, the async
> reset, normally results in more logic being used to stitch up LUTs
> together.

I prefer an asynch assert for simulation of
the 'no clock running' case.

I generate an asynch assert and sync de-assert
reset strobe, something like this.

http://home.comcast.net/~mike_treseler/reset.vhd
http://home.comcast.net/~mike_treseler/reset.pdf

It's just a two flop shifter, reset_out is preset with reset_in.
A zero is clocked out to de-assert reset_out.

>   However, the design I am currently working on requires only one of
> the blocks to run at 1/4 that of the original clock speed. I am using
> a DCM to clock divide the master clock, and the output goes into this
> block.

I would clock all the flops at the original clock speed,
reset everything the same way, and use
clock enable strobes for the slower update rates.

  -- Mike Treseler

Hi Mike,

> >   However, the design I am currently working on requires only one of
> > the blocks to run at 1/4 that of the original clock speed. I am using
> > a DCM to clock divide the master clock, and the output goes into this
> > block.
>
> I would clock all the flops at the original clock speed,
> reset everything the same way, and use
> clock enable strobes for the slower update rates.
>
>   -- Mike Treseler

   thanks for your input. When you mean clock enable strobe, do you
mean... the following?

process (clk)
   if clk=1 and clk'event then
     if res = '1'

     else
         if clock_enable = '1'

         end if;
     end if;
   end if;

--then clock_enable will be in my case asserted one in every 4 clocks
to achieve a f/4 MHz kind of data rate...

    If my understanding is correct, then I have another question. The
maximum synthesizable frequency of a core used in the design cannot
run at clock speed and only at 1/4 clock speed. currently, I have thus
2 clock domains in this design

1) 1 clock runnning at f MHz
2) 1 clock running at f/4 frequency.

I have prevented potential clock domain crossing problems by piping
data already into an async FIFO (data entering the design written into
the FIFO at f MHz, data read out at f/4 MHz which goes into the core
also clocked at f/4 MHz).

Since you advised to use the strobe method as I understood above, then
how do i go about clocking the core that can run at only f/4 MHz max
and still not run into the reset problem stated above?

thanks again for your help.
Chris

On Apr 20, 6:30=A0pm, chrisde...@gmail.com wrote:
> Hi Mike,
>
> > > =A0 However, the design I am currently working on requires only one of=

> > > the blocks to run at 1/4 that of the original clock speed. I am using
> > > a DCM to clock divide the master clock, and the output goes into this
> > > block.
>
> > I would clock all the flops at the original clock speed,
> > reset everything the same way, and use
> > clock enable strobes for the slower update rates.
>
> > =A0 -- Mike Treseler
>
> =A0 =A0thanks for your input. When you mean clock enable strobe, do you
> mean... the following?
>
> process (clk)
> =A0 =A0if clk=3D1 and clk'event then
> =A0 =A0 =A0if res =3D '1'
>
> =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0if clock_enable =3D '1'
>
> =A0 =A0 =A0 =A0 =A0end if;
> =A0 =A0 =A0end if;
> =A0 =A0end if;
>
> --then clock_enable will be in my case asserted one in every 4 clocks
> to achieve a f/4 MHz kind of data rate...
>
> =A0 =A0 If my understanding is correct, then I have another question. The
> maximum synthesizable frequency of a core used in the design cannot
> run at clock speed and only at 1/4 clock speed. currently, I have thus
> 2 clock domains in this design
>
> 1) 1 clock runnning at f MHz
> 2) 1 clock running at f/4 frequency.
>
> I have prevented potential clock domain crossing problems by piping
> data already into an async FIFO (data entering the design written into
> the FIFO at f MHz, data read out at f/4 MHz which goes into the core
> also clocked at f/4 MHz).
>
> Since you advised to use the strobe method as I understood above, then
> how do i go about clocking the core that can run at only f/4 MHz max
> and still not run into the reset problem stated above?
>
> thanks again for your help.
> Chris

If you use a global clock to distribute the fast clock, but us CE to
disable each flip-flop for 3 out of 4 clock ticks, then that part of
your design really runs at the quarter clock speed. The flip-flops see
only every fourth clock tick, therefore your design will work as you
expect.
Peter Alfke

chrisdekoh@gmail.com wrote:

> Since you advised to use the strobe method as I understood above, then
> how do i go about clocking the core that can run at only f/4 MHz max
> and still not run into the reset problem stated above?

There is only one clock domain.
The reset circuit is separate.
See Peter's answer.
Post to comp.lang.vhd if you don't figure it out.

     -- Mike Treseler

Hi Peter,
   I do not have this luxury. The core which is running at f/4 clock
is a core originally written in Handel C and given to me as a ngc file
and not in VHDL. The maximum synthesizable speed of this core is only
at f/4 MHz. The core thus has to run at an f/4 clock.
   With this set of restrictions in mind, could there still be a
solution to the reset problem?

Chris

On Apr 20, 7:01=A0pm, chrisde...@gmail.com wrote:
> Hi Peter,
> =A0 =A0I do not have this luxury. The core which is running at f/4 clock
> is a core originally written in Handel C and given to me as a ngc file
> and not in VHDL. The maximum synthesizable speed of this core is only
> at f/4 MHz. The core thus has to run at an f/4 clock.
> =A0 =A0With this set of restrictions in mind, could there still be a
> solution to the reset problem?
>
> Chris

There must be a limited number of flip-flops in that part of the
design. Just clock each of them with the fast clock, and drive CE with
the slower clock. And forget all about asynchronous FIFOs.
Do you understand hardware, or are you just patching cores together ?
Peter Alfke

Hi Peter,
    I understand exactly what you are saying. Unfortunately I am just
patching cores together. As mentioned, what I get is an ngc file which
I do not have any control of the core.

Chris

<chrisdekoh@gmail.com> wrote in message
news:6ee86d42-4111-4a7c-8a85-30011b78a244@q27g2000prf.googlegroups.com...
> Hi,
>   I am wondering if anyone of you have experienced this before. Here
> goes the reset problem I am facing now. asynchronous reset in FPGAs
> are usually a big NO-NO. from the articles I am reading, the async
> reset, normally results in more logic being used to stitch up LUTs
> together.
>  However, the design I am currently working on requires only one of
> the blocks to run at 1/4 that of the original clock speed. I am using
> a DCM to clock divide the master clock, and the output goes into this
> block. The problem happens when
>
> - the reset signal which resets the DCM, is the same reset which goes
> into this same block.
> - This will result in a problem, as the clock-divide-by-4 as I call
> it, will not emit a clock pulse in reset state, as the DCM has not
> locked yet. the synchronous reset will thus not work for this block.
>
> 1) Any ideas of how to circumvent this problem? I would like to use
> synchronous resets, but also use the divide by 4 clock for the block.
> 2) Are my concepts of synchronous resets correct? that synchronous
> resets on FPGA are better than asynchronous resets?

I believe this only applies to Xilinx FPGA's and not to any other vendors.

From  http://www.xilinx.com/support/documentation/white_papers/wp248.pdf :

Use of Synchronous Sets/Resets
If a set or reset is necessary for the proper operation of the circuit, a
synchronous reset
should always be coded. Synchronous sets/resets not only have improved
timing
characteristics and stability but can also result in smaller, better
utilization within the
FPGA. Synchronous sets/resets can result in less logic (fewer LUTs), fewer
restrictions on packing, and, often, faster circuits.

Hans
www.ht-lab.com




>
> thanks
>
> Chris
>

On 21 Apr, 06:40, chrisde...@gmail.com wrote:
> Hi Peter,
> =A0 =A0 I understand exactly what you are saying. Unfortunately I am just
> patching cores together. As mentioned, what I get is an ngc file which
> I do not have any control of the core.
>
> Chris

There is an obvious answer that nobody seems to have mentioned: Use
the "LOCKED" signal from the DCM as reset to the logic that is clocked
by the clock from the DCM. I am not quite sure about the numbers, but
there ought to be at least one clock edge from the DCM before that
goes active. If you need more clock edges, delay the "LOCKED" signal
in a shift register (one SLR16 will give you 16 clock cycles delay
from just one LUT).

Hope this helps!

/Lars