FPGA Central

Hello all,

I helping a colleague debug a timing issue on his SX-A design. I
don't have any experience with Actel devices or tools, only Xilinx and
Altera, so setting timing constraints with these devices is new to
me. I'm hoping someone might be able to help.

The design has two clock domains with a handful of control signals
crossing the domains: 48 MHz and 24 MHz generated on the board by a
12MHz oscillator through a zero delay buffer. The FPGA is a bridge
between two different bus types. The problem we're seeing is the
device fails when cold, but not after it has warmed up.

Apparently for the SX-A family, the only timing constraint functions
available are create_clock, set_min_delay and set_max_delay. Here's
what he currently has:

create_clock -name {clk_48M_p} -period 20.000 -waveform {0.000 10.000}
{clk_48M_p}
create_clock -name {clk_24M_p} -period 40.000 -waveform {0.000 20.000}
{clk_24M_p}

set_max_delay 20.000 -from [all_inputs] -to [get_clocks{ * }]
set_max_delay 15.000 -from [get_clocks{ * }] -to [all_outputs]
set_max_delay 20.000 -from [all_inputs] -to [all_outputs]

I'm looking at that and thinking we might have an issue since it's
constraining the max delay from all inputs to both clocks as 20.000
ns. Shouldn't we constrain the inputs/outputs in each clock domain
only to that clock? I'm thinking the tools are going to spend
unnecessary effort to constrain the signals in the 24MHz domain when
we could somehow partition the constraints between the two clock
domains and allow the tools to put more effort on the 48MHz signals.
Does that sound right?

Is there a good, clean way of partitioning the constraints for the two
clock domains short of listing all of the different signals in each
domain? Anybody have any other ideas?

kkoorndyk wrote:

> Is there a good, clean way of partitioning the constraints for the two
> clock domains short of listing all of the different signals in each
> domain? Anybody have any other ideas?

Consider running everything on 48 MHz and using
the 24 MHz as an input.

-- Mike Treseler

"kkoorndyk" <[email protected]> wrote in message
news:[email protected]...
> I'm looking at that and thinking we might have an issue since it's
> constraining the max delay from all inputs to both clocks as 20.000
> ns. Shouldn't we constrain the inputs/outputs in each clock domain
> only to that clock? I'm thinking the tools are going to spend
> unnecessary effort to constrain the signals in the 24MHz domain when
> we could somehow partition the constraints between the two clock
> domains and allow the tools to put more effort on the 48MHz signals.
> Does that sound right?
>
> Is there a good, clean way of partitioning the constraints for the two
> clock domains short of listing all of the different signals in each
> domain? Anybody have any other ideas?
>
>

If the place and route is achieving timing closure then it doesn't matter
that it might be over-constrained, and this won't be causing the failure. It
is more likely you have a design problem with the retiming of signals
crossing between the clock domains. Although the two clocks come from a
common source, it's not wise to assume they are synchronized. Presumably the
PLL in the clock buffer is multiplying the 12MHz up to 48MHz and dividing it
down to generate the 24MHz. I would be surprised if it guarantees phase
alignment between the two when operating at different frequencies.

On Mar 21, 2:35 pm, "David Spencer" <davidmspen...@verizon.net> wrote:
> "kkoorndyk" <kris.koorn...@gmail.com> wrote in message
>
> news:[email protected]...
>
>
> If the place and route is achieving timing closure then it doesn't matter
> that it might be over-constrained, and this won't be causing the failure. It
> is more likely you have a design problem with the retiming of signals
> crossing between the clock domains. Although the two clocks come from a
> common source, it's not wise to assume they are synchronized. Presumably the
> PLL in the clock buffer is multiplying the 12MHz up to 48MHz and dividing it
> down to generate the 24MHz. I would be surprised if it guarantees phase
> alignment between the two when operating at different frequencies.

That's probably it. I just took at look at the code and noticed a
couple of control signals crossing the clock domains without
appropriate synchronization. Thanks for the input!

On 21 Mrz., 19:02, kkoorndyk <kris.koorn...@gmail.com> wrote:

> create_clock -name {clk_48M_p} -period 20.000 -waveform {0.000 10.000}
[..]
> set_max_delay 20.000 -from [all_inputs] -to [all_outputs]

I think these are synthesis constraints. Did you use them for layout,
too?

> Is there a good, clean way of partitioning the constraints for the two
> clock domains short of listing all of the different signals in each
> domain? Anybody have any other ideas?

I wouldn't use timing constraints for clock domain crossing, but
ensure a proper handling in the code.
Even if your clocks are alligned on input, you might have a big skew
caused by using different routing sources for the clock (Especially
when mixing hclk, clk and qclk in SX-A).

bye Thomas