cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
csholikowski
Explorer
Explorer
14,577 Views
Registered: ‎06-13-2013

Help with Timing Constraints in 14.5

Good Afternoon,

 

As I am preparing for a grueling weekend of overtime, I need some help/guidance to help me debug my issues that are literally driving me and another engineer crazy.  (Hopefully I am still the more sane one :) )

 

Project:

 

XC3S700A -4ft256 i

 

Project Navigator 14.5  App version: p.58f

XST synthesis tool

VHDL and VHDL-93 standard

 

I have the attached UCF.

 

Symptoms of problem:

 

I have a design that i compile and timing score of '0' based on my constraints and create into a bit file.  I than turn the .bit into a .mcs file to store in my spi flash.  

 

With different additions to code and different placement of code the logic in the hardware either works or doesnt work.

 

Meaning  if Module 1,2, 3  work inside the hardware on our pcb.   I had Module 4 which takes Modules 3 output and uses it to do some calculations, and now Module 3 is not working properly.  I go back and add Half of module 4 to the project and Module 3 works.   I add 75% of module 4 and module 3 doesn't work.  So I am thinking hmmm must be that piece of code causing a bug.  So I go and add the other 25% of module 4 and module 3 doesn't work.  Now I am just confused.  

 

So I have Module 3 being watched by my external logic analyzer.  (MICTOR in my UCF)

 

I have simple code that does this:

 

if(rising_edge(clk)) then

   

    if(prev_sync ='0' and sync ='1') then

          addr <= addr + 1;

     end if;    

end if;

 

 

Addr in my logic analyzer  increments from  something like   150 to 210 instead of 151.   It skips 60 address and the output of my block rom skipps 60 steps.  (Sine Wave table)

 

Now I have looked through the code for Metastability and made sure to register a couple flip flops before all signals used in other clock domains but I still can't figure out how Module 4 can make a simple Addr + 1 mess up.

 

My clocks:

 

FPGA A has a 25 MHz SSO 0.5% down spread oscillator.

 

This 25  MHz SSO is driven directly into a DCM where I create a CLK0  and a CLK5X(125 Mhz).

I than use the CLK0 for 80% of my logic synchronous elements.

My CLK 125 is used for about 5% of my logic. 

 

I also have another DCM in which the 125 Mhz clock is fed into another DCM to create CLK2X and Clk2X180 (250 MHZ clocks).  This is used to run an ODDR (at a 500 Mhz Rate).  We have <1% of our logic running off the 250 Mhz. 

The last percentage is used from a 25 MHz SSO from FPGA B.  

 

So we have  CLK 25 MHZ A, CLK 25 MHZ B, CLK 125 MHz, CLK 250 MHZ, CLK 250(180 degree) MHz)

 

CLK 25 MHZ A and CLK 25 MHZ B are unrelated.  (In the UCF FPGA_BUS<4> is where the CLK 25 MHZ B is incoming into the system.)

 

I am inexperienced when it comes to timing constraints.  Does my UCF file seem sufficient?   I attached my .twx How do I analyze my problem better?  

 

I replaced my 25 MHz osc wit ha 20 MHz osc and the logic still fails.   

 

I am quite confused.

 

Any help would be greatly appreciated.

 

0 Kudos
9 Replies
driesd
Xilinx Employee
Xilinx Employee
14,575 Views
Registered: ‎11-28-2007

Hi Csholikowski,

 

I'm sorry to hear you will have to spend your weekend working while most of us can deserve a well deserved break with family and friends...

Let me see if I can try to avoid this and get this resolved as quickly as possible. (it's not the first time I get a phonecall late Friday afternoon with a desperate customer ;)

 

Your constraints look good.

When you constrain the input clock, the clock is propagated through the DCMs and PLLs and all generated clocks are automatically constrained and their clock relationship defined. As long as they are considered related, they are actually considered synchronous, so you even don't have to apply cross-clock-domain (CDC) techniques.

However, a good sanity check is to run timing analyzer or trce with the unconstrained paths option (trce -u) to see if you have any other clocks that are not constrained.

In your case, I seems like a pretty simple clock-setup so I'm pretty sure you won't find anything other than maybe inputs, outputs and full asynchronous paths. You should be able to safely ignore these...

 

I guess you have already simulated your design to verify that functionally everything is sound?

 

Have you considered inserting the Xilinx Integrated Logic Analyzer called Chipscope to monitor your design and narrow down on your issues?

 

Do you monitor the lock signal of the DCMs?

Cascading of DCMs is not recommended: http://www.xilinx.com/support/answers/52806.htm

Is the 2nd DCM reset signal tied to the lock signal of the 1st DCM? (you need to keep the 2nd DCM in reset until the clock input is stable)

Can you put some of the output clocks on a test-pin and monitor them using a scope?

 

I see that you target the highest speedgrade (-4), can you confirm this with the markings on the package? It might explain everything! Change the speedgrade in your project and regenerate a bitstream of -3, -2 and -1 and see what it gives.

Actually, you haven't specified a SYSTEM_JITTER constraint to add some margin for the SS-clock. Could you try with SYSTEM_JITTER set to 200ps (~0.5% of 25MHz) in the UCF?

Or even with 300, 400 or 500ps to add margin?

 

Are the power supplies of the FPGA clean? Have you provided the recommended amount of decoupling capacitors on VCCINT, VCCAUX and VCCO? (see UG331 for the recommended values)

It could also be a bad PCB design issue: can you measure the power supplies using an oscilloscope and see if they look nice and clean or noisy? (don't forget to do this during operation of the FPGA!)

 

Sorry for being direct, but I have to ask: what is the source of your FPGAs? Have you purchased them through an Authorized Xilinx Distributor? (Avnet, ...)

You can respond via a private message, but I'm asking but I have heard of cases where customers bought devices not through official channels and they turned out to be faulty devices due to improper storage or rebadged lower-speed devices.

 

 

Best regards,

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
0 Kudos
csholikowski
Explorer
Explorer
14,571 Views
Registered: ‎06-13-2013

To answer the question at the end quickly.

 

We purchase our Xilinx products from Avnet.

 

We are an Xilinx Alliance member, you probably can track down our parts.

 

I have an NDA with Xilinx, and Avnet.  So if set up in the right manor I could get my whole project to you.

 

I am definitely Cascading DCM's.   Here are the instantiations:

 

DCM_SP_inst : DCM_SP
generic map (
CLKDV_DIVIDE => 10.0, -- Divide by: 1.5,2.0,2.5,3.0,3.5,4.0,4.5,5.0,5.5,6.0,6.5
-- 7.0,7.5,8.0,9.0,10.0,11.0,12.0,13.0,14.0,15.0 or 16.0
CLKFX_DIVIDE => 1, -- Can be any interger from 1 to 32
CLKFX_MULTIPLY => 5, -- Can be any integer from 1 to 32
CLKIN_DIVIDE_BY_2 => FALSE, -- TRUE/FALSE to enable CLKIN divide by two feature
CLKIN_PERIOD => 40.0, -- Specify period of input clock
CLKOUT_PHASE_SHIFT => "NONE", -- Specify phase shift of "NONE", "FIXED" or "VARIABLE"
CLK_FEEDBACK => "1X", -- Specify clock feedback of "NONE", "1X" or "2X"
DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS", -- "SOURCE_SYNCHRONOUS", "SYSTEM_SYNCHRONOUS" or
-- an integer from 0 to 15
DLL_FREQUENCY_MODE => "LOW", -- "HIGH" or "LOW" frequency mode for DLL
DUTY_CYCLE_CORRECTION => TRUE, -- Duty cycle correction, TRUE or FALSE
PHASE_SHIFT => 0, -- Amount of fixed phase shift from -255 to 255
STARTUP_WAIT => TRUE) -- Delay configuration DONE until DCM_SP LOCK, TRUE/FALSE
port map (
CLK0 => clk_25Mhz, -- 0 degree DCM CLK ouptput
CLK180 => open, -- 180 degree DCM CLK output
CLK270 => open, -- 270 degree DCM CLK output
CLK2X => open, -- 2X DCM CLK output
CLK2X180 => open, -- 2X, 180 degree DCM CLK out
CLK90 => open, -- 90 degree DCM CLK output
CLKDV => open,--clkdiv_15, -- Divided DCM CLK out (CLKDV_DIVIDE)
CLKFX => clk125MHz, -- DCM CLK synthesis out (M/D)
CLKFX180 => open, -- 180 degree CLK synthesis out
LOCKED => clk_lock, -- DCM LOCK status output
PSDONE => open, -- Dynamic phase adjust done output
STATUS => open, -- 8-bit DCM status bits output
CLKFB => clk_25Mhz, -- DCM clock feedback
CLKIN => clk,--clk_25Mhz, -- Clock input (from IBUFG, BUFG or DCM)
PSCLK => open, -- Dynamic phase adjust clock input
PSEN => open, -- Dynamic phase adjust enable input
PSINCDEC => open, -- Dynamic phase adjust increment/decrement
RST => '0' -- DCM asynchronous reset input
);

DCM_SP_inst2 : DCM_SP
generic map (
CLKDV_DIVIDE => 2.0, -- Divide by: 1.5,2.0,2.5,3.0,3.5,4.0,4.5,5.0,5.5,6.0,6.5
-- 7.0,7.5,8.0,9.0,10.0,11.0,12.0,13.0,14.0,15.0 or 16.0
CLKFX_DIVIDE => 1, -- Can be any interger from 1 to 32
CLKFX_MULTIPLY => 2, -- Can be any integer from 1 to 32
CLKIN_DIVIDE_BY_2 => FALSE, -- TRUE/FALSE to enable CLKIN divide by two feature
CLKIN_PERIOD => 8.0, -- Specify period of input clock
CLKOUT_PHASE_SHIFT => "NONE", -- Specify phase shift of "NONE", "FIXED" or "VARIABLE"
CLK_FEEDBACK => "2X", -- Specify clock feedback of "NONE", "1X" or "2X"
DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS", -- "SOURCE_SYNCHRONOUS", "SYSTEM_SYNCHRONOUS" or
-- an integer from 0 to 15
DLL_FREQUENCY_MODE => "LOW", -- "HIGH" or "LOW" frequency mode for DLL
DUTY_CYCLE_CORRECTION => TRUE, -- Duty cycle correction, TRUE or FALSE
PHASE_SHIFT => 0, -- Amount of fixed phase shift from -255 to 255
STARTUP_WAIT => TRUE) -- Delay configuration DONE until DCM_SP LOCK, TRUE/FALSE
port map (
CLK0 => open, -- 0 degree DCM CLK ouptput
CLK180 => open, -- 180 degree DCM CLK output
CLK270 => open, -- 270 degree DCM CLK output
CLK2X => clk2x, -- 2X DCM CLK output
CLK2X180 => clk180, -- 2X, 180 degree DCM CLK out
CLK90 => open, -- 90 degree DCM CLK output
CLKDV => open, -- Divided DCM CLK out (CLKDV_DIVIDE)
CLKFX => open, -- DCM CLK synthesis out (M/D)
CLKFX180 => open, -- 180 degree CLK synthesis out
LOCKED => open, -- DCM LOCK status output
PSDONE => open, -- Dynamic phase adjust done output
STATUS => open, -- 8-bit DCM status bits output
CLKFB => clk2x, -- DCM clock feedback
CLKIN => clk125MHz, -- Clock input (from IBUFG, BUFG or DCM)
PSCLK => open, -- Dynamic phase adjust clock input
PSEN => open, -- Dynamic phase adjust enable input
PSINCDEC => open, -- Dynamic phase adjust increment/decrement
RST => '0' -- DCM asynchronous reset input
);


DCM_SP_inst3 : DCM_SP
generic map (
CLKDV_DIVIDE => 10.0, -- Divide by: 1.5,2.0,2.5,3.0,3.5,4.0,4.5,5.0,5.5,6.0,6.5
-- 7.0,7.5,8.0,9.0,10.0,11.0,12.0,13.0,14.0,15.0 or 16.0
CLKFX_DIVIDE => 1, -- Can be any interger from 1 to 32
CLKFX_MULTIPLY => 2, -- Can be any integer from 1 to 32
CLKIN_DIVIDE_BY_2 => FALSE, -- TRUE/FALSE to enable CLKIN divide by two feature
CLKIN_PERIOD => 40.0, -- Specify period of input clock
CLKOUT_PHASE_SHIFT => "NONE", -- Specify phase shift of "NONE", "FIXED" or "VARIABLE"
CLK_FEEDBACK => "1X", -- Specify clock feedback of "NONE", "1X" or "2X"
DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS", -- "SOURCE_SYNCHRONOUS", "SYSTEM_SYNCHRONOUS" or
-- an integer from 0 to 15
DLL_FREQUENCY_MODE => "LOW", -- "HIGH" or "LOW" frequency mode for DLL
DUTY_CYCLE_CORRECTION => TRUE, -- Duty cycle correction, TRUE or FALSE
PHASE_SHIFT => 0, -- Amount of fixed phase shift from -255 to 255
STARTUP_WAIT => TRUE) -- Delay configuration DONE until DCM_SP LOCK, TRUE/FALSE
port map (
CLK0 => clk_fb, -- 0 degree DCM CLK ouptput
CLK180 => open, -- 180 degree DCM CLK output
CLK270 => open, -- 270 degree DCM CLK output
CLK2X => open, -- 2X DCM CLK output
CLK2X180 => open, -- 2X, 180 degree DCM CLK out
CLK90 => open, -- 90 degree DCM CLK output
CLKDV => clk_dv, -- Divided DCM CLK out (CLKDV_DIVIDE)
CLKFX => open, -- DCM CLK synthesis out (M/D)
CLKFX180 => open, -- 180 degree CLK synthesis out
LOCKED => open, -- DCM LOCK status output
PSDONE => open, -- Dynamic phase adjust done output
STATUS => open, -- 8-bit DCM status bits output
CLKFB => clk_fb, -- DCM clock feedback
CLKIN => clk_25Mhz, -- Clock input (from IBUFG, BUFG or DCM)
PSCLK => open, -- Dynamic phase adjust clock input
PSEN => open, -- Dynamic phase adjust enable input
PSINCDEC => open, -- Dynamic phase adjust increment/decrement
RST => '0' -- DCM asynchronous reset input
);

 

I dont have any reset?   

 

I could Monitor the clocks via a scope, that is definetly doable.  

 

I have not simulated the project from a top level, I have simulated majority of the modules individually.  Some modules take longer to simulate than to put into our hardware and use my External logic analyzer to analyze.

 

I have never used chipscope before, I have usually done all debugging with my logic analyzer and simulations.  I fear the learning curve on chipscope tool.

 

 

The extended spartan 3A 700 in industrial is -4 speed grade.  On the physical part it says 5C/ 4I above the line and above TAIWAN

 

FTG256AGQ1225

D4423236A

5C/4I

 

 

I don't know about trce command.

 

I have no specified a SYSTEM_JITTER but I do notice that My 4 ns requirement can range from slightly failing to 200 ps of slack.  If I add jitter of 500 ps the constraint would fail.  I do not know how I could possibly pass that constraint.  250 Mhz risng and falling edge is going into a ODDR.  

 

 

My PCB engineer has gone home for the day but I assume for now that ht power supplies of the FPGA clean?  We have had the project working for couple months.  Only for the last month it has randomly caused more and more issues, until now we are stuck.  

 

We have an undervoltage monitor on the 3.3 volt supply that we monitor in the FPGA.

 

Again if we set it up I can give you the schematic of our FPGA power supply.

 

 

 

 

 

0 Kudos
driesd
Xilinx Employee
Xilinx Employee
14,568 Views
Registered: ‎11-28-2007

Hi Cory,

 

thanks for the quick answers.

 

Good to hear your parts are OK. Indeed, using the package markings, I could verify the batch and that batch is indeed an I4 batch.

 

I've sent you a package through EZmove to which you can respond and send me any files you wish to share.

Remember that EZmove uses the emailaddress and a special password sent over mail for credentials.

 

Those cascaded DCMs look very bad and are most likely the cause of your issues:

I would highly recommend, not to cascade, especially since you already have a SS-clock which can influencing locking.

Secondly, you absolutely need to keep the cascaded DCMs into reset as long as the lock signal isn't asserted. Typically designers invert the lock signal and delay it through an SRL to add some more delay.

Ideally, I would recommend even not to cascade. There are cases that customers absolutely need to cascade due to the odd multiply and divide ratios, but in your case, I think you can simplify your clocking and you can make all DCMs parallel and generate the clocks from the same input clock source.

 

With a scope you would be able to see that the DCMs wouldn't lock and produce the most odd frequencies and drift...

perfectly explaining the odd behaviour you see.

 

Chipscope:

I would really recommend you to give Chipscope a try. It's a very powerful debugging tool and can actually save a lot of time debugging issues.

In terms of learning curve: it's very easy to use. I would recommend to use the inserter flow. For more information, see:

http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/chipscope_pro_sw_cores_ug029.pdf

 

trce:

timing analyzer is the GUI tool. The trce command is the command-line engine behind it. See the ISE Command Line Userguide for more details.

Basically I'm asking you to change a few options and verify that you don't have any unconstrained clocks.

You can also do it from ISE (static timing analysis options)

 

Please give the SYSTEM_JITTER test a try. Start with 200ps and you can see from there.

It doesn't necessiraly mean that when you sometimes fail that it won't be able to meet timing. I do understand your concern, but in the debug process it is sometimes necessary to do a lot of parallel tests to rule out certain causes. This would be a really good test and could potentially be a relative easy workaround.

 

The fact that you say that in the beginning it worked fine and that you see more and more failing, does seem to indicate a power supply issue. Typically, when the FPGA is not fully loaded, you won't see any issues, but the more the FPGA gets filled, the more issues you would see...is it indeed possible to share the schematic and PCB gerber files for a quick sanity check?

Measuring VCCINT, VCCAUX and VCCO will also confirm any issues in this direction.

SYSTEM_JITTER might add enough timing margin to overcome any PCB/power noise issues.

 

 

Best regards

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
0 Kudos
driesd
Xilinx Employee
Xilinx Employee
14,566 Views
Registered: ‎11-28-2007

Oh...and in parallel, since you are a Xilinx alliance partner: it probably helps to open a webcase with Xilinx Technical Support to have your issue investigated: http://www.xilinx.com/support/clearexpress/websupport.htm

 

 

Best regards

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
0 Kudos
csholikowski
Explorer
Explorer
14,563 Views
Registered: ‎06-13-2013

I have opened a Webcase.  I also am messaging and Avnet FAE.  

 

I am even asking the great Gabor for help.

 

Thanks for the help, I will try to look into everything as quickly as possible.  I will try the EZMOVE package.

0 Kudos
driesd
Xilinx Employee
Xilinx Employee
14,554 Views
Registered: ‎11-28-2007

Hi Cory,

 

I received your package:

- the decoupling capacitors seem fine. Although I have to be cautious, it can still be a PCB design issue and I haven't done a PDS simulation!

- I've run an unconstrained paths analysis on the 2 designs and they both checked out just fine. As I was guessing, only a few unconstrained I/O interfaces and pure asynchronous paths, but you should be able to safely ignore these.

 

So, I guess what remains are:

- either a PCB issue: measure with a scope VCCINT, VCCAUX, VCCO on vias close to the FPGA

- either the DCM cascading: monitor clocks on scope + redesign

 

 

Best regards,

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
0 Kudos
csholikowski
Explorer
Explorer
14,537 Views
Registered: ‎06-13-2013

Yes i will check those items.

 

I really hope it is not a power supply issue.

 

 

Thanks a lot.

 

Cory

0 Kudos
gszakacs
Professor
Professor
14,505 Views
Registered: ‎08-14-2007

Are both of the signals, "prev_sync" and "sync", synchronous to the rising edge of "clk?"  If not, you could easily get a runt pulse on the count enable "(prev_sync ='0' and sync ='1')" causing the counter to mis-count because some bits of the counter get the count enable in time and others don't.

-- Gabor
0 Kudos
csholikowski
Explorer
Explorer
14,502 Views
Registered: ‎06-13-2013

Yes they are both synchronous to clk.   I just double checked.    I have made sure unrelated clocks pass through several flip flops to mitigate metastable events from happening.  I haven't changed the input to my module in quite some time.  

 

 

0 Kudos