Also the timing constraints for SGMII tx/rx (LVDS SERDES) in TSE are missed (the timing analyser reports about that). SGMII tx/rx ios are not constrained for delays.
From the formal point of view it's bad. From SGMII point of view it's irrelevant but gives the alarm bell.
There is more serious problem with clock constraints or clock domain crossing between PCS / SGMII bridge (LVDS SERDES) and MAC logic itself in TSE.
For some builds in 18.0 I have no link between phy and device itself. I can verify it from the PCS registers of TSE MAC. And it's on the Cyclone 10 GX reference board with the reference design from intel. MAC is ok but PCS fails.
As far as I tested it - it's because of two clocks from two different io banks.
Logically with the right clock domain crossing, the proper design and the correct clock constraints it must(!) be irrelevant or fail the timing(!). Timing is ok but in the real hardware it fails.
The reference sof file from the Dev Kit contents was compiled by the old version of Quartus and works ok.
However as soon as the placement of the logic inside of Cyclone is changed (for example Signal Tap is added or you recompile the reference design in the newer version of Quartus) it may fail in the real hardware. And the timing constraints are met (except the missed delays - for the test I left the original constraints intact).
So something is wrong or with the TSE / PCS hdl code and/or with the timing constraints.
Because of this limitation for the reference clock I added the internal pll just to generate 50 MHz clock from 125 MHz PCS reference clock.
50 MHz clock becomes physically derived clock and the bug is bypassed! Builds are stable!
First of all for me it's another alarm bell about the clock constraints and clock domain crossing in TSE / PCS. (I just can't verify it more because I can't see the all source code).
Secondary there is far better and far more elegant solution for the reference clock limitation that is in the style of Altera and SDC rather than the typical badware from brand x (yes, in that respect brand x goes even worse.)
If the "bad placement" of the clock inputs affects the signals integrity, clock edges and the overall performance why it's not reflected by the timing analysis?
There is such good thing in SDC as the clocks uncertainty. Just increase it for the bad routing so if design has do the bad placement you see the timing failure! It's in line with the timing!
I understand that the reason this limitation is the high performance but not everybody needs the high clock rates. (For example I just need to use dev kit for a while and for me it’s unfair that I can’t use it with the latest Quartus.)
Also you can't protect yourself from the dumb users who has no idea about the timing. They will just fail their designs somewhere else and even ignore the timing failures from the timing analyser report. In fact from my recent experience in two companies I had to clean designs from the timing failures after brand x zombies in brand x software (that is far more manipulative) but failed(!) to turn them in the right direction.
It's better to take example from the success of Google with Chrome that was designed to be good first of all for the web developers(!) and not(!) for the web uses.
Occasional Contributor
