From: chrisdekoh on
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
From: Peter Alfke on
On Apr 20, 7:01 pm, chrisde...(a)gmail.com wrote:
> 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

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
From: chrisdekoh on
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
From: HT-Lab on

<chrisdekoh(a)gmail.com> wrote in message
news:6ee86d42-4111-4a7c-8a85-30011b78a244(a)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
>



From: Lars on
On 21 Apr, 06:40, chrisde...(a)gmail.com wrote:
> 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

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