Xilinx V4SX35 ISE 8.2.03 Modelsim I got CLKI(300MHz), CLKI_DIV(150MHz) generated through a counter(just a flip_flop) clocked by CLKI, both clocks connect to BUFG. Then I use CLKI to sample data generated byCLKI_DIV(width=160bit), simulation result in some warnings which said setuptime is not enough during sampling. How can I constraint PAR to get enough setuptime? Because of funtion request, I can not use DCM and OSERDES. The minimum delay between risingedge of CLKI_DIV and CLKI is much more than the period of CLKI. I have to make sure all simultaneous data sampled by CLKI simultaneously. But actually, there always some bits sampled a period(CLKI) later or earlier. I can constraint the max delay from the last 150MHz flip-flop to the first 300MHz flip-flop, but how can I constraint the minimum delay? Thank you!!
sampling error between 2 clocks
Started by ●December 16, 2007
Reply by ●December 17, 20072007-12-17
<wxy0624@gmail.com> wrote in message news:58990fd1-be0d-410e-85ad-37765935953b@e6g2000prf.googlegroups.com...> Xilinx V4SX35 > ISE 8.2.03 > Modelsim > > > I got CLKI(300MHz), CLKI_DIV(150MHz) generated through a counter(just > a flip_flop) clocked by CLKI, both clocks connect to BUFG. Then I use > CLKI to sample data generated byCLKI_DIV(width=160bit), simulation > result in some warnings which said setuptime is not enough during > sampling. How can I constraint PAR to get enough setuptime? > > Because of funtion request, I can not use DCM and OSERDES. The minimum > delay between risingedge of CLKI_DIV and CLKI is much more than the > period of CLKI. I have to make sure all simultaneous data sampled by > CLKI simultaneously. But actually, there always some bits sampled a > period(CLKI) later or earlier. I can constraint the max delay from the > last 150MHz flip-flop to the first 300MHz flip-flop, but how can I > constraint the minimum delay? > > > Thank you!!Dear Whoever, Use CLKI to clock _all_ the synchronous elements. Use CLKI_DIV as the clock enable for all the synchronous elements you were going to clock with CLKI_DIV. HTH., Syms.
Reply by ●December 17, 20072007-12-17
On 12=D4=C217=C8=D5, =CF=C2=CE=E76=CA=B113=B7=D6, "Symon" <symon_bre...@hotm= ail.com> wrote:> <wxy0...@gmail.com> wrote in message > > news:58990fd1-be0d-410e-85ad-37765935953b@e6g2000prf.googlegroups.com... > > > > > > > Xilinx V4SX35 > > ISE 8.2.03 > > Modelsim > > > I got CLKI(300MHz), CLKI_DIV(150MHz) generated through a counter(just > > a flip_flop) clocked by CLKI, both clocks connect to BUFG. Then I use > > CLKI to sample data generated byCLKI_DIV(width=3D160bit), simulation > > result in some warnings which said setuptime is not enough during > > sampling. How can I constraint PAR to get enough setuptime? > > > Because of funtion request, I can not use DCM and OSERDES. The minimum > > delay between risingedge of CLKI_DIV and CLKI is much more than the > > period of CLKI. I have to make sure all simultaneous data sampled by > > CLKI simultaneously. But actually, there always some bits sampled a > > period(CLKI) later or earlier. I can constraint the max delay from the > > last 150MHz flip-flop to the first 300MHz flip-flop, but how can I > > constraint the minimum delay? > > > Thank you!! > > Dear Whoever, > Use CLKI to clock _all_ the synchronous elements. Use CLKI_DIV as the cloc=k> enable for all the synchronous elements you were going to clock with > CLKI_DIV. > HTH., Syms.- =D2=FE=B2=D8=B1=BB=D2=FD=D3=C3=CE=C4=D7=D6 - > > - =CF=D4=CA=BE=D2=FD=D3=C3=B5=C4=CE=C4=D7=D6 -Thanks! That is exactly what I am doing now, and the FPGA is working properly under lab condition. It just a warning during simulation. I just worry about when the environment, for example, the voltage changes, the temperature changes, or something like that. I move the flipflop which generate CLKI_DIV to change the phase relationship between the two clocks, but it's time consuming and not effective. Is there some other methods to achieve the setup time? Some kind of constraints in the UCF file?
Reply by ●December 18, 20072007-12-18
wxy0624@gmail.com wrote:> That is exactly what I am doing now, and the FPGA is working properly > under lab condition. > It just a warning during simulation. > I just worry about when the environment, for example, the voltage > changes, the temperature changes, > or something like that.Usually, the timing analysis that is done by the tools uses a worst case scenario, like 85 ��C temperature and a very low VCCINT. When you look at the logfile "par" produces (it's a text file with the ending .par in your project directory), there are lines like this at the beginning: "Initializing temperature to 85.000 Celsius. (default - Range: -40.000 to 100.000 Celsius) Initializing voltage to 1.140 Volts. (default - Range: 1.140 to 1.260 Volts)" You can even put the setting in you UCF: TEMPERATURE = 75 C; sets the temperature to 75 ��C (pure magic!). I assume there's a similar setting for the core voltage. So unless your real-life environment isn't worse than that, you should be safe. HTH, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...
Reply by ●December 18, 20072007-12-18
<wxy0624@gmail.com> wrote in message news:e43ec1f2-8d3b-47c2-b9a2-1a6fc17c7d8c@b1g2000pra.googlegroups.com... On 12��17��, ����6ʱ13��, "Symon" <symon_bre...@hotmail.com> wrote:> <wxy0...@gmail.com> wrote in message > > news:58990fd1-be0d-410e-85ad-37765935953b@e6g2000prf.googlegroups.com... > > > > > > > Xilinx V4SX35 > > ISE 8.2.03 > > Modelsim > > > I got CLKI(300MHz), CLKI_DIV(150MHz) generated through a counter(just > > a flip_flop) clocked by CLKI, both clocks connect to BUFG. Then I use > > CLKI to sample data generated byCLKI_DIV(width=160bit), simulation > > result in some warnings which said setuptime is not enough during > > sampling. How can I constraint PAR to get enough setuptime? > > > Dear Whoever, > Use CLKI to clock _all_ the synchronous elements. Use CLKI_DIV as the > clock > enable for all the synchronous elements you were going to clock with > CLKI_DIV. > HTH., Syms.- ���ر��������� - > > - ��ʾ���õ����� -> Thanks! > > That is exactly what I am doing now, and the FPGA is working properly > under lab condition.Read Symon's suggestion again....what you've described is NOT what he suggested.> It just a warning during simulation.And that 'warning' will turn into an intermittent functional failure for you eventually.> I just worry about when the environment, for example, the voltage > changes, the temperature changes, > or something like that.Temp will do it. Try cold spraying or heat gunning your 'working properly under lab condition' FPGA and is likely that it will fail.> I move the flipflop which generate CLKI_DIV to change the phase > relationship between the two clocks, > but it's time consuming and not effective.That's because the correct approach is to have one clock in your design and have your the divided down clock be used as a clock enable. Example: process(CLKI) begin if rising_edge(CLKI) then if (CLKI_DIV = '0') then -- Whatever you have that is currently clocked -- by 'CLKI_DIV' goes here. end if; end if; end process;> Is there some other methods to achieve the setup time?Yes, see above and get rid of all of your processes that are clocked by 'CLKI_DIV'> Some kind of constraints in the UCF file?Only if you want to have a flaky design Kevin Jennings
Reply by ●December 18, 20072007-12-18
> Yes, see above and get rid of all of your processes that are clocked by > 'CLKI_DIV'Thanks! But do you mean to let all logic clocked by CLKI, meanwhile use CLKI_DIV as a clk_enable? That would make all the logic run at 300MHz. I want to use concurrent logic to achieve lower clock frequency, that is why I am using CLKI_DIV. Even if V4SX55 can run at 300MHz, I don't think it's a good idea. And I still have to worry about the skew of CLKI_DIV, and the phase relationship beteen the 2 clocks, which is the main problem. You know, if use BUFG to drive CLKI_DIV, the phase relationship is hard to control, If not, the skew will be a huge problem. These 2 problems are all I got right now, and they are still there! I really wanna know your solution in detail.
Reply by ●December 19, 20072007-12-19
Reply by ●December 19, 20072007-12-19
On Dec 18, 9:46 pm, wxy0...@gmail.com wrote:> > Yes, see above and get rid of all of your processes that are clocked by > > 'CLKI_DIV' > > Thanks! > > But do you mean to let all logic clocked by CLKI, > meanwhile use CLKI_DIV as a clk_enable?Yes.> > That would make all the logic run at 300MHz.That's correct.> I want to use concurrent logic to achieve lower clock frequency, > that is why I am using CLKI_DIV.Some questions you should ponder then.... What is the point of the 300 MHz then? How low of a clock frequency are you trying to achieve? What is the reason for needing this lower clock frequency? The only real correct answer to all of the above is that you have some chunk of logic that needs to run at 300, and some other chunks that just can't because they fail timing. If that is not the situation, then use CLKI_DIV as a clock enable and be done with it. IF that is your situation, you should first consider breaking up the chunk-o-logic that doesn't run at 300 into smaller pipelined chunks that can. Finally, if you really do need the two clocks, then any communication between the CLKI and CLKI_DIV should be treated as if they are totally asynchronous clocks which generally means inserting fifos to move the data across the clock domains.> > Even if V4SX55 can run at 300MHz, > I don't think it's a good idea. >1. Explain why you don't think it's a good idea. 2. Then explain why your design is attempting to run at least part of it at 300 MHz. 3. Then explain why your answer to #2 is not in violation of your answer to #1.> And I still have to worry about the skew of CLKI_DIV, > and the phase relationship beteen the 2 clocks, > which is the main problem.CLKI_DIV would no longer be a clock, you would not need to worry about the skew of CLKI_DIV and the phase relationship. Anyplace you previously were looking for a rising edge of CLKI_DIV (as a clock) you would replace with "if CLKI_DIV = '0'" as a clock enable as I demonstrated. If you had any code that was looking for falling edges of CLKI_DIV you would replace it with "if CLKI_DIV = '1'" (as a clock enable).> You know, if use BUFG to drive CLKI_DIV, > the phase relationship is hard to control, > If not, the skew will be a huge problem. > These 2 problems are all I got right now, > and they are still there!And the root cause of the problem is that you're using CLKI to generate CLKI_DIV which will inherently generate skew between these two signals. Even in simulation, they do not happen simultaneously, CLKI_DIV will happen on the next simulation delta. When they are both used as clocks you'll have the problems that you're seeing, if you use CLKI_DIV as a clock enable as Symon and I have pointed out you won't. If you want to beat your head against the wall trying to solve this go ahead but all you'll get is a headache and a flaky design that will mysteriously work (or not) when you first power it on, then will not work (or work) once it has been powered up for some period of time....which you'll attribute to some mysterious temperature sensitivity....but the reason for the 'sensitivity' is improper design and failing timing analysis which is what your timing report is telling you right now.> > I really wanna know your solution in detail.What detail do you think was not disclosed previously? Kevin Jennings
Reply by ●December 19, 20072007-12-19
On Tue, 18 Dec 2007 18:46:38 -0800 (PST), wxy0624@gmail.com wrote:>> Yes, see above and get rid of all of your processes that are clocked by >> 'CLKI_DIV' > > >Thanks! > >But do you mean to let all logic clocked by CLKI, >meanwhile use CLKI_DIV as a clk_enable? > >That would make all the logic run at 300MHz.Exactly.>I want to use concurrent logic to achieve lower clock frequency, >that is why I am using CLKI_DIV.But why?> And I still have to worry about the skew of CLKI_DIV, > and the phase relationship beteen the 2 clocks, >which is the main problem.No - you let the tools worry about them. If the tools can achieve timings WITHOUT issuing warnings, there is no worrying to be done. This approach lets the timing constraints necessary on the 150MHz clock to be correctly inferred by the tools. And there are no clock domain crossings to worry about. - Brian
Reply by ●December 19, 20072007-12-19
On Dec 19, 7:20 am, Brian Drummond <brian_drumm...@btconnect.com> wrote:> On Tue, 18 Dec 2007 18:46:38 -0800 (PST), wxy0...@gmail.com wrote: > >> Yes, see above and get rid of all of your processes that are clocked by > >> 'CLKI_DIV' > > >Thanks! > > >But do you mean to let all logic clocked by CLKI, > >meanwhile use CLKI_DIV as a clk_enable? > > >That would make all the logic run at 300MHz. > > Exactly. > > >I want to use concurrent logic to achieve lower clock frequency, > >that is why I am using CLKI_DIV. > > But why? > > > And I still have to worry about the skew of CLKI_DIV, > > and the phase relationship beteen the 2 clocks, > >which is the main problem. > > No - you let the tools worry about them. If the tools can > achieve timings WITHOUT issuing warnings, there is no worrying to be > done. > > This approach lets the timing constraints necessary on the 150MHz clock > to be correctly inferred by the tools. And there are no clock domain > crossings to worry about. > > - BrianAnother approach might be to generate the 150 MHz clock with a BUFGE, enabled by clki_div (keep in mind that such a clock may not be 50% duty cycle). Or use a DCM. Otherwise, you have been given the best advice, and only if you really need the rest of your design to run at 150 (for power savings, etc?) should you actually generate a slower clock signal, and then there are good ways to do it (what I suggested above) and bad ways (what you were doing). If your logic that you want to run at 150 MHz is too complex to run at 300, then you can use a 150 MHz clock enable as suggested previously, with multi-cycle path constraints to relax timing on those paths that have two 300 MHz cycles to complete. However, this is generally more error prone, since incorrectly specified multi-cycle paths can usually only be found by a simulation that exercises the incorrectly specified path. As to the difference between lab operation and simulation warnings, even if you were to test with your voltage at the lowest possible value, and raise the temperature to the highest, consider that your lab experiment works on a sample of one FPGA, from one production lot. If you plan on producing more than just the board you have in the lab, you need to solve the problems indicated by the simulator and/or timing analysis tool. "Works in the lab" is necessary, but not sufficient for "works in production". Andy
