Matching timing constraints regularly fails when Full Moon

Hi, from your crazy scene, I cannot observe same behavior but strange thing happen also at my side.

I am working on how to isolate and avoid they can plague me...

I observed strange mangling of files, clipboard content appear somewhere.

Loss of files lines.

Loss of file file link as if they where stored in m$ mode but I am using Linux.

Non deterministic Behavior as VHDL has to be.

Sometimes loses lot of setting...

Refuse programming .pof files and old 15.0 programmed without problem...

Odd Havoc, BUT not moon influence ;) I am missing this great feature.

I am not currently working on Cyclone, I don't have this moment board at hand, tomorrow I try some core to that board to see what happen.

Please add more details about what happen, OS version.

Did you try'd clean project?

Yes, I regularly clean project files and I even remove rubbish left somewhere after removal. Normally I run Quartus with seed set e.g. to 1, then use Design Space Explorer to try 40 or 60 seeds. Meeting timing constraints never works when full moon time. Our design takes about 75% of logic resources, I use Windows 7. We have 2 iterations of the design, one in Cyclone III using Quartus 12.1, the other in Cyclone V using Quartus 17.1 or 18.1. Our design takes time stamp from a server, so a design varies every day as far as date (in separate vhdl file) concerns.

May be that time stamp causes that chaos ?

>> May be that time stamp causes that chaos ?

Hi Paul, sorry my magic bowl still at repair service so I have to struggle over and look somewhere for a cure.

Don't remember what was version when I started using Cyclone V but 12.1 seems have cyclone support, did you try'd compile on that version to see if meet timing constraint?

https://www.intel.com/content/www/us/en/programmable/support/support-resources/knowledge-base/tools/2018/vulnerability-in-jtag-server-potentially-allows-a-local-attacker.html

Some issue remain open for a long time, I seen intermixing Verilog/VHDL sometimes has oddity like wrong signal propagation or signal name not assigned to, but you as me appear as using VHDL.

In the past I experienced trouble on constant conversion, sometimes where ok sometimes if then elsif else failed.

Actually I discovered VHDL 2018 sometimes fail convert , 3x"5" compare ok with "101", no warning no error but seldom havoc on code.

This forum is also bad and doesn't work searching old thread hiding knowledge.

try this link:

https://forums.intel.com/s/question/0D70P000005Peb5/is-if-elsif-else-in-this-case-errant?s1oid=00DU0000000YT3c&s1nid=0DB0P000000U1Hq&emkind=chatterCommentNotification&s1uid=0050P0000081Uem&emtm=1551062347309&fromEmail=1&s1ext=0

Actually changing constants from format 3x"hex digit" 3x"0", 3x"1", 3x"2" .. to binary "000", "001", "010"... seems mitigated, more work in progress but primary task is to finish my work on time, then i can beta test Quartus.

Last question by KTAN9, yes I am using VHDL 2008, otherwise 3x"n" is invalid syntax.

No idea when and why sometimes fail nor found how to repeat in non stocastic mode.

I am expecting some feedback from Altera, sorry, Intel. The behaviour persists.

Can you help to clarify few things below?

1) Does your design need to run 3 days in order to finish the compilation? Or only this happened when you used DSE?

2) Did you try analyze your design on the timing violation before using the DSE to close timing? Using DSE is one of the method to close timing, but you will need to analyze the path is that make sense to use DSE to close timing, if you have a slack that is very large, it does not make sense to use DSE to close the timing.

3) Is that fine for you to send the timing report to have a look on the failure path?

4) I am not sure what it means by full moon, may be you can make some explanation on it?