Prev: Multiple builds with different top-level generic
Next: Best clock output pin in Spartan-3
From: Gabor on 10 Aug 2010 10:07
On Aug 10, 8:38 am, Benjamin Krill <b...(a)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.

Regards,
Gabor
From: Fredxx on 10 Aug 2010 12:00
Gabor wrote:
> On Aug 10, 8:38 am, Benjamin Krill <b...(a)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.


From: Chris Maryan on 11 Aug 2010 14:24
On Aug 10, 12:00 pm, "Fredxx" <fre...(a)spam.com> wrote:
> Gabor wrote:
> > On Aug 10, 8:38 am, Benjamin Krill <b...(a)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 athttp://www.xilinx.com/support.- Hide quoted 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
First  |  Prev  | 
Pages: 1 2
Prev: Multiple builds with different top-level generic
Next: Best clock output pin in Spartan-3