Actel SX-A Timing Constraints Issues

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?

Reply to
kkoorndyk
Loading thread data ...

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

-- Mike Treseler

Reply to
Mike Treseler

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.

Reply to
David Spencer

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!

Reply to
kkoorndyk

[..]

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

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

Reply to
Thomas Stanka

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.