Prev: I'd rather switch than fight!
Next: Problems with data2mem
From: Fredxx on 9 Apr 2010 10:17
I seem to be stuck on this one.

I have 2 DCMS creating a 100MHz clock and a 125MHz clock derived from a
common 25MHz clock.

Signals cross clock domains using grey-code and suitable multiple latches
where appropriate. I am aware of metastable states etc and their
consequences..

However when I specify a 40ns timing criteria for the 25MHz clock I get a
mapping failure. I increase the timing criteria to 80ns and the timing
analysis is expecting clock transitions at 16 and 20ns, for signals crossing
clock domains which of course it fails. How can I turn off timing analysis
for signals crossing clock domains? I note that the "TIG" can't be used for
"from" "to" statements.


From: austin on 9 Apr 2010 10:53
f,

This is your lucky day:

Go read my new blog post:

http://forums.xilinx.com/t5/PLD-Blog/Timing-Constraints-Part-4-of-5/ba-p/66696

where TIG is discussed, and an example given how it can be used in a
FROM-TO.

Since this design is completely synchronous to the 25 MHz clock, if
properly constrained (and designed) there will be metastability issues
at all.

Your Gray code and synchronizers may not be necessary at all.
However, if you don't have the time (or knowledge) to do this
properly, then having a two clocks that are almost (but not quite)
synchronous can be a nightmare, and no amount of Gary coded counters,
nor synchronizers will save you: you will be "almost always at the
wrong point" so frequently that you have created the perfect storm for
looking at metastable events.

The built in BRAM FIFO in V5 and V6 is the obvious solution to cross
boundaries, or the use of a FIFO from the core generator, is
suggested: do not try to spin your own solution unless you are an
expert in clock domain crossing -- this is not for "newbies" to try
(unless they are trying to develop the skills to do it right).

You would be better off using the 125 MHz clock domain everywhere, and
creating a clock enable that disables one 125 clock out of every five
125 clocks (for the 100 MHz domain processing). Then you will have no
need to cross any clock boundaries, the design is simpler, more
robust, and will likely just work.

If you then need to transfer data out at 100 MHz, that is where the
FIFO is best used: once, at this boundary. The same is not true for
transferring 100 MHz data into the 125 MHz domain, that is
accomplished by just sampling at the right time (the four clocks not
dropped every 5).

Austin
From: Fredxx on 9 Apr 2010 11:45

"austin" <austin(a)xilinx.com> wrote in message
news:fc92c4bb-3a00-4990-b2f5-3767c15c41c9(a)x20g2000yqb.googlegroups.com...
> f,
>
> This is your lucky day:
>
> Go read my new blog post:
>
> http://forums.xilinx.com/t5/PLD-Blog/Timing-Constraints-Part-4-of-5/ba-p/66696
>
> where TIG is discussed, and an example given how it can be used in a
> FROM-TO.
>
> Since this design is completely synchronous to the 25 MHz clock, if
> properly constrained (and designed) there will be metastability issues
> at all.
>
> Your Gray code and synchronizers may not be necessary at all.
> However, if you don't have the time (or knowledge) to do this
> properly, then having a two clocks that are almost (but not quite)
> synchronous can be a nightmare, and no amount of Gary coded counters,
> nor synchronizers will save you: you will be "almost always at the
> wrong point" so frequently that you have created the perfect storm for
> looking at metastable events.
>
> The built in BRAM FIFO in V5 and V6 is the obvious solution to cross
> boundaries, or the use of a FIFO from the core generator, is
> suggested: do not try to spin your own solution unless you are an
> expert in clock domain crossing -- this is not for "newbies" to try
> (unless they are trying to develop the skills to do it right).
>
> You would be better off using the 125 MHz clock domain everywhere, and
> creating a clock enable that disables one 125 clock out of every five
> 125 clocks (for the 100 MHz domain processing). Then you will have no
> need to cross any clock boundaries, the design is simpler, more
> robust, and will likely just work.
>
> If you then need to transfer data out at 100 MHz, that is where the
> FIFO is best used: once, at this boundary. The same is not true for
> transferring 100 MHz data into the 125 MHz domain, that is
> accomplished by just sampling at the right time (the four clocks not
> dropped every 5).
>
> Austin

Many thanks, I had made a syntax error where I wrote

TIMESPEC "my_fromto" = FROM "my_from_grp" TO "my_to_grp" TIG;

and when changed ito

TIMESPEC TS_my_fromto = FROM "my_from_grp" TO "my_to_grp" TIG;

it all worked.

I'm sure in my past designs I haven't had this problem, but I guess using
clocks which have a common sourse means that the timing analyser has founf
something to analyse!

I take your point about the sourcing of clocks. For various reasons I want
the design to be flexible as possible, and willing to accept the
consequences. Also missing a clock every 5 will require a tighter design in
terms of timing.


From: Gabor on 9 Apr 2010 14:06
On Apr 9, 11:45 am, "Fredxx" <fre...(a)spam.com> wrote:
> "austin" <aus...(a)xilinx.com> wrote in message
>
> news:fc92c4bb-3a00-4990-b2f5-3767c15c41c9(a)x20g2000yqb.googlegroups.com...
>
>
>
> > f,
>
> > This is your lucky day:
>
> > Go read my new blog post:
>
> >http://forums.xilinx.com/t5/PLD-Blog/Timing-Constraints-Part-4-of-5/b...
>
> > where TIG is discussed, and an example given how it can be used in a
> > FROM-TO.
>
> > Since this design is completely synchronous to the 25 MHz clock, if
> > properly constrained (and designed) there will be metastability issues
> > at all.
>
> > Your Gray code and synchronizers may not be necessary at all.
> > However, if you don't have the time (or knowledge) to do this
> > properly, then having a two clocks that are almost (but not quite)
> > synchronous can be a nightmare, and no amount of Gary coded counters,
> > nor synchronizers will save you:  you will be "almost always at the
> > wrong point" so frequently that you have created the perfect storm for
> > looking at metastable events.
>
> > The built in BRAM FIFO in V5 and V6 is the obvious solution to cross
> > boundaries, or the use of a FIFO from the core generator, is
> > suggested:  do not try to spin your own solution unless you are an
> > expert in clock domain crossing -- this is not for "newbies" to try
> > (unless they are trying to develop the skills to do it right).
>
> > You would be better off using the 125 MHz clock domain everywhere, and
> > creating a clock enable that disables one 125 clock out of every five
> > 125 clocks (for the 100 MHz domain processing).  Then you will have no
> > need to cross any clock boundaries, the design is simpler, more
> > robust, and will likely just work.
>
> > If you then need to transfer data out at 100 MHz, that is where the
> > FIFO is best used:  once, at this boundary.  The same is not true for
> > transferring 100 MHz data into the 125 MHz domain, that is
> > accomplished by just sampling at the right time (the four clocks not
> > dropped every 5).
>
> > Austin
>
> Many thanks, I had made a syntax error where I wrote
>
> TIMESPEC "my_fromto" = FROM "my_from_grp" TO "my_to_grp" TIG;
>
> and when changed ito
>
> TIMESPEC TS_my_fromto = FROM "my_from_grp" TO "my_to_grp" TIG;
>
> it all worked.
>
> I'm sure in my past designs I haven't had this problem, but I guess using
> clocks which have a common sourse means that the timing analyser has founf
> something to analyse!
>
> I take your point about the sourcing of clocks.  For various reasons I want
> the design to be flexible as possible, and willing to accept the
> consequences.  Also missing a clock every 5 will require a tighter design in
> terms of timing.

It always bothered me that time specs needed to start with "TS". This
is the syntax problem in the first version, not the quotes.

From: Fredxx on 11 Apr 2010 04:47
Gabor wrote:
> On Apr 9, 11:45 am, "Fredxx" <fre...(a)spam.com> wrote:
>> "austin" <aus...(a)xilinx.com> wrote in message
>>
>> news:fc92c4bb-3a00-4990-b2f5-3767c15c41c9(a)x20g2000yqb.googlegroups.com...
>>
>>
>>
>>> f,
>>
>>> This is your lucky day:
>>
>>> Go read my new blog post:
>>
>>> http://forums.xilinx.com/t5/PLD-Blog/Timing-Constraints-Part-4-of-5/b...
>>
>>> where TIG is discussed, and an example given how it can be used in a
>>> FROM-TO.
>>
>>> Since this design is completely synchronous to the 25 MHz clock, if
>>> properly constrained (and designed) there will be metastability
>>> issues at all.
>>
>>> Your Gray code and synchronizers may not be necessary at all.
>>> However, if you don't have the time (or knowledge) to do this
>>> properly, then having a two clocks that are almost (but not quite)
>>> synchronous can be a nightmare, and no amount of Gary coded
>>> counters, nor synchronizers will save you: you will be "almost
>>> always at the wrong point" so frequently that you have created the
>>> perfect storm for looking at metastable events.
>>
>>> The built in BRAM FIFO in V5 and V6 is the obvious solution to cross
>>> boundaries, or the use of a FIFO from the core generator, is
>>> suggested: do not try to spin your own solution unless you are an
>>> expert in clock domain crossing -- this is not for "newbies" to try
>>> (unless they are trying to develop the skills to do it right).
>>
>>> You would be better off using the 125 MHz clock domain everywhere,
>>> and creating a clock enable that disables one 125 clock out of
>>> every five 125 clocks (for the 100 MHz domain processing). Then you
>>> will have no need to cross any clock boundaries, the design is
>>> simpler, more robust, and will likely just work.
>>
>>> If you then need to transfer data out at 100 MHz, that is where the
>>> FIFO is best used: once, at this boundary. The same is not true for
>>> transferring 100 MHz data into the 125 MHz domain, that is
>>> accomplished by just sampling at the right time (the four clocks not
>>> dropped every 5).
>>
>>> Austin
>>
>> Many thanks, I had made a syntax error where I wrote
>>
>> TIMESPEC "my_fromto" = FROM "my_from_grp" TO "my_to_grp" TIG;
>>
>> and when changed ito
>>
>> TIMESPEC TS_my_fromto = FROM "my_from_grp" TO "my_to_grp" TIG;
>>
>> it all worked.
>>
>> I'm sure in my past designs I haven't had this problem, but I guess
>> using clocks which have a common sourse means that the timing
>> analyser has founf something to analyse!
>>
>> I take your point about the sourcing of clocks. For various reasons
>> I want the design to be flexible as possible, and willing to accept
>> the consequences. Also missing a clock every 5 will require a
>> tighter design in terms of timing.
>
> It always bothered me that time specs needed to start with "TS". This
> is the syntax problem in the first version, not the quotes.

Thanks for pointing that out. To be honest I don't dislike being forced to
use a meaningful prefix, but I would have liked ISE to have warned me where
I hadn't conformed.


 | 
Pages: 1
Prev: I'd rather switch than fight!
Next: Problems with data2mem