Added a few constraints to .sdc file and the whole design broke?

[Altera_Forum]

Hello, 

I am using the Arria 10 Dev. Board to test out the transceivers. I have a simple design using the Arria 10 Transciever Native PHY with enhanced PCS as well as the associated reset core and PLL. I have very simple logic driving the PHY and have an SFP plugged into the board with a bus analyzer and a loopback cable. When I synthesize, download and run it works flawlessly. I send some sequences as well as a short frame, see them on the bus analyzer, and receive them back in the FPGA. Now... I add a simple .sdc file defining the clocks that feed the logic and the PHY using the "The Quartus II TimeQuest Timing Analyzer 2014.08.08" as a guideline. The .sdc file is as such: create_clock -name CLK_275MHZ -period 3.636 create_clock -name REFCLK_SFP_RX_P -period 1.55 derive_pll_clocks derive_clock_uncertainty set_clock_groups -asynchronous -group { CLK_275MHZ } -group { REFCLK_SFP_RX_P } Run synthesis again, download, and the whole thing has gone haywire--not just a few bits incorrect, not a frame dropped, but totally haywire without any sensible data. But, there is at least enough being transmitted so that the receiver can lock and descramble--so the cable hasn't gone dark or locked up. I have a bus analyzer, so I can see that the problem originates from the transmit side. Also, if I comment out lines 2-5, it will go back to working fine. I am using Quartus 16.1.2 Standard on Windows. Any suggestions on where to start would be appreciated. I don't think going on and making the design more complex without ever adding an .sdc file is a workable solution, but, for the time-being, it is the only avenue I have. I can share more aspects of the design if that would help.

[Altera_Forum]

I should add: when the .sdc file was in place, there was one failing path, but it was a FIFO_PEMPTY (partially empty) signal, which crosses clock boundaries, so I didn't think much of it.

[Altera_Forum]

--- Quote Start ---  I should add: when the .sdc file was in place, there was one failing path, but it was a FIFO_PEMPTY (partially empty) signal, which crosses clock boundaries, so I didn't think much of it.  --- Quote End ---    just general notes. you must have sdc for any design. there is no point having a design without sdc.   Your refclk is too fast. Can you explain your clocking scheme.

[Altera_Forum]

--- Quote Start ---  Can you explain your clocking scheme.  --- Quote End ---    Sure; the PHY is running at 14.025GHz and I have two clocks going to the FPGA. One clock, at 644MHz (I'm rounding off here for simplicity) goes to the Arria 10 Transceiver ATX PLL and is used to generate (most of) the clocks used by the PHY. The same clock goes to an IO PLL and is used to create a 250MHz clock which drives internal logic. The second clock is a 275MHz clock coming to the FPGA that is used for the CDR of the PHY. So, all the user-created logic is run off of the 250MHz clock--everything else is for the PHY and chosen from the list of possible choices.

[Altera_Forum]

Since I was curious, I tried reducing the REFCLK to 63.75MHz--the lowest allowed by the Transceiver PLL. The results were the same--one failing path and transmissions were garbled.

[Altera_Forum]

you have defined two clocks 644MHz & 275MHz yet you haven't defined the fpga core clock of 250MHz, I assume it is PLL output, that is ok 

I think the ref clk of 644MHz is way too fast and you better go as low as possible. You may not need set clk groups as you only have one core clk and I assume quartus takes care of PHY interfacing with core logic (check if any sdc file is generated for this purpose), if so, you can safely say clk 250 domain is asynchronous, else you should cross clocks safely

[Altera_Forum]

ref clk 644 MHz is fine - we are using exactly that as refclk for PLLs and CDR refclk in our 10GBASE-R design using Arria 10 Transceivers. 

 What is weird, however, is that your design works without .sdc - luck, I guess :)

[Altera_Forum]

Solved?  

I added a line to my .sdc file to disregard the one failing path (recall the failing pempty signal in my second comment of this thread). After that I didn't have any failing nets (but I did have a few unconstrained I/O like LED's and what-not). After doing that, the design works. My guess (and it is just a wild guess) is that the fitter was trying so hard to get that one net to meet timing that it was messing up something else that may not be properly constrained.