Sign in

username:

password:



Not a member?

Search Comp.Arch.FPGA



Search tips

fpga by Keywords

Altera | ASIC | CPLD | Cyclone | DCM | DDR | DSP | Ethernet | ISE | JTAG | Linux | LVDS | Microblaze | ML310 | Modelsim | NIOS | OPB | PCI | Quartus | RocketIO | SDRAM | Spartan | Spartan3 | SRAM | Stratix | Verilog | VHDL | Virtex | Virtex-4 | Virtex-II | Xilinx | XST

Ads

See Also

DSPEmbedded SystemsElectronics

Comp.Arch.FPGA | Instantiating non-global clock buffers (Xilinx ISE)

There are 8 messages in this thread.

You are currently looking at messages 0 to 8.

Instantiating non-global clock buffers (Xilinx ISE) - Fredxx - 2010-08-10 08:15:00

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?


______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.



Re: Instantiating non-global clock buffers (Xilinx ISE) - Benjamin Krill - 2010-08-10 08:22:00

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



Re: Instantiating non-global clock buffers (Xilinx ISE) - Fredxx - 2010-08-10 08:34:00

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!


______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.

Re: Instantiating non-global clock buffers (Xilinx ISE) - Benjamin Krill - 2010-08-10 08:38:00

> 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.


______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.

Re: Instantiating non-global clock buffers (Xilinx ISE) - Chris Maryan - 2010-08-10 10:03:00

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

Re: Instantiating non-global clock buffers (Xilinx ISE) - Gabor - 2010-08-10 10:07:00

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

Re: Instantiating non-global clock buffers (Xilinx ISE) - Fredxx - 2010-08-10 12:00:00

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. 


______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.

Re: Instantiating non-global clock buffers (Xilinx ISE) - Chris Maryan - 2010-08-11 14:24:00

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