synchronous reset problems on FPGA
in [FPGA]
|
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: KJ on 21 Apr 2008 07:51 On Apr 20, 10:58 am, chrisde...(a)gmail.com wrote: > 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. > Mike mentioned this in his first post but you seemed to have missed the point with the diversion down clock enable lane. The reset to the block that you're trying to control should not be the same signal as the reset to the DCM. Instead... 1. Take the reset input to the DCM or it together with the DCM not locked output to create a new signal that is used to asynchronously preset a shift register. 2. Clock the shift register with the DCM output clock (i.e. the clock / 4). 3. Use the output of the shift register as the reset to the block that you're trying to control. The shift register output will now be properly synchronized to the 'clock / 4' clock domain and will be nominally active for as many clock cycles as you make the shift register. Add one extra flop to the shift register to account for not knowing precisely when the reset input to the shift register will go away (i.e. to get a minimum 1 clock cycle wide reset, make the shift register 2 flops long). Kevin Jennings
From: Nial Stewart on 22 Apr 2008 07:40 > "Peter Alfke" <alfke(a)sbcglobal.net> wrote in message > news:6864a277-1433-452a-9918-c60c6b2c9463(a)u36g2000prf.googlegroups.com... > 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. Peter, from what Chris has said I don't think there are CE's into the core he's using. Nial
From: Andy Peters on 22 Apr 2008 12:55
On Apr 21, 2:34 am, Lars <noreply.lar...(a)gmail.com> wrote: > 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). Yep, the DCM locked output does the trick! -a |