There are 8 messages in this thread.
You are currently looking at messages 0 to 8.
I have a design with too many global clocks which ISE automatically adds. Some of these clocks are slow and feed into relatively small areas of logic. Is there a way I can specify these clocks to be non-global?______________________________
Hi, try to use BUFR. cheers ben On Tue, 2010-08-10 at 13:15 +0100, Fredxx wrote:=20 > I have a design with too many global clocks which ISE automatically adds. >=20 > Some of these clocks are slow and feed into relatively small areas of log= ic. >=20 > Is there a way I can specify these clocks to be non-global? >=20 >=20
Benjamin Krill wrote: > On Tue, 2010-08-10 at 13:15 +0100, Fredxx wrote: >> I have a design with too many global clocks which ISE automatically >> adds. >> >> Some of these clocks are slow and feed into relatively small areas >> of logic. >> >> Is there a way I can specify these clocks to be non-global? > > Hi, > > try to use BUFR. > > cheers > ben > Many thanks. I thought all was going well until Translate. Unfortunately Spartan 3A's don't support the BUFR primitive!______________________________
> Many thanks. I thought all was going well until Translate. Unfortunatel= y=20 > Spartan 3A's don't support the BUFR primitive! Hm, to bad. Then you have to reduce your clocks and for example use clock enables for the slower logic parts.______________________________
On Aug 10, 8:38=A0am, Benjamin Krill <b...@codiert.org> wrote: > > Many thanks. =A0I thought all was going well until Translate. =A0Unfort= unately > > Spartan 3A's don't support the BUFR primitive! > > Hm, to bad. Then you have to reduce your clocks and for example use clock > enables for the slower logic parts. I'll second the clock enables. A common techinique is to use a single clock for most of your logic and (through various mechanisms) generate clock enables at the appropriate rate where necessary. This also makes timing analysis much easier since everythign is carried on a single clock. Chris
On Aug 10, 8:38=A0am, Benjamin Krill <b...@codiert.org> wrote: > > Many thanks. =A0I thought all was going well until Translate. =A0Unfort= unately > > Spartan 3A's don't support the BUFR primitive! > > Hm, to bad. Then you have to reduce your clocks and for example use clock > enables for the slower logic parts. Some spartan 3A parts have left or right half clock regions. If the buffer for these is not called a BUFR there should be some other way to use it. Also for small regions it is possible to attach a constraint to the clock net (BUFFER_TYPE =3D NONE if I remember correctly) to remove the BUFG. Then you should add a USELOWSKEWNETS (IIRC) attribute and make sure your timing analysis includes hold time. If your clock is very slow, you can also play games to avoid hold time errors like always going from rising edge to falling edge. Regards, Gabor
Gabor wrote: > On Aug 10, 8:38 am, Benjamin Krill <b...@codiert.org> wrote: >>> Many thanks. I thought all was going well until Translate. >>> Unfortunately Spartan 3A's don't support the BUFR primitive! >> >> Hm, to bad. Then you have to reduce your clocks and for example use >> clock enables for the slower logic parts. > > Some spartan 3A parts have left or right half clock regions. If the > buffer for these is not called a BUFR there should be some other > way to use it. > > Also for small regions it is possible to attach a constraint to > the clock net (BUFFER_TYPE = NONE if I remember correctly) > to remove the BUFG. Then you should add a USELOWSKEWNETS > (IIRC) attribute and make sure your timing analysis includes hold > time. If your clock is very slow, you can also play games to avoid > hold time errors like always going from rising edge to falling edge. > Many thanks. I used the attribute buffer_type = "none", but it seem to remove the offending clock altogether from the design. Not quite what I had intended. I then had a myraid more errors. In the end I resorted to removing the offending clocks and capture its edge with a high speed clock. All seemed well until Map when I got: FATAL_ERROR:3:xstphs.c:71:1.11.10.1 - Physical Synthesis Failed. Process will terminate. For technical support on this issue, please open a WebCase with this project attached at http://www.xilinx.com/support.______________________________
On Aug 10, 12:00=A0pm, "Fredxx" <fre...@spam.com> wrote: > Gabor wrote: > > On Aug 10, 8:38 am, Benjamin Krill <b...@codiert.org> wrote: > >>> Many thanks. I thought all was going well until Translate. > >>> Unfortunately Spartan 3A's don't support the BUFR primitive! > > >> Hm, to bad. Then you have to reduce your clocks and for example use > >> clock enables for the slower logic parts. > > > Some spartan 3A parts have left or right half clock regions. =A0If the > > buffer for these is not called a BUFR there should be some other > > way to use it. > > > Also for small regions it is possible to attach a constraint to > > the clock net (BUFFER_TYPE =3D NONE if I remember correctly) > > to remove the BUFG. =A0Then you should add a USELOWSKEWNETS > > (IIRC) attribute and make sure your timing analysis includes hold > > time. =A0If your clock is very slow, you can also play games to avoid > > hold time errors like always going from rising edge to falling edge. > > Many thanks. =A0I used the attribute buffer_type =3D "none", but it seem = to > remove the offending clock altogether from the design. =A0Not quite what = I had > intended. =A0I then had a myraid more errors. > > In the end I resorted to removing the offending clocks and capture its ed= ge > with a high speed clock. =A0All seemed well until Map when I got: > FATAL_ERROR:3:xstphs.c:71:1.11.10.1 - Physical Synthesis Failed. Process > will > =A0 =A0terminate. For technical support on this issue, please open a WebC= ase > with =A0 this project attached athttp://www.xilinx.com/support.- Hide quo= ted text - > > - Show quoted text - I can't comment on the error, but be careful with capturing clocks to create clock enables. Make sure your sampling clock is fast enough (Nyquist and then some at an absolute minimum, a couple times more if possible) - if necessary divide your to-be-sampled clock in a PLL and regenerate the higher rate once you sample the lower one. Make sure you run the to-be-sampled clock through a few FFs on the sampling clock for stability. And then make sure you do a good edge detect on the sampled clock. Chris