|
Prev: how we can prove that really the AES 256 is used to crypt the Bitstream in virtex 5
Next: Problem writing quadrature decoder
From: chrisdekoh on 20 Apr 2008 22:01 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 20 Apr 2008 23:20 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 21 Apr 2008 00:40 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 21 Apr 2008 03:56 <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 21 Apr 2008 05:34
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 |