FPGA compilation ignores selected Clock Source

[Aditya_Dhananjay]

Hello again,

I "repaired" the installation of LV FPGA 2014, LV Real-Time, and the Xilinx compile tools Vivado 2013.4. Unfortunately, the problem remains when I try to compile again.

The compilation succeeds, but ignores the 60MHz clock that I've specified, and instead uses the default 40MHz clock.

http://www.cs.nyu.edu/~aditya/XilinxLog_Nov5_2014.txt

Above is the link to the Xilinx compilation log. I tried to make sense of it, but couldn't accomplish much. 🙂 If anyone could perhaps eyeball it to figure out where this is going wrong, it would be super useful indeed.

Thanks again!

best,

aditya

[Aditya_Dhananjay]

Apologies for not posting all relevant information in the same post:

http://www.cs.nyu.edu/~aditya/Archive_Of_NI_Compilation_Results_Nov5_2014.rar

At this link, you can find the files relevant to the compilation process.

-> BuildResults

-> lvXilinxLog

-> output_files (zip file)

-> UnitOfWork

-> CodeGenerationResults

-> source_files (directory that contains the VHDL and XDC files)

Thank you!

best,

aditya

[David-A]

Do you see the same compile issues if you create an FPGA VI that only adds two numbers together in the 60MHz clock domain? What if you change the derived clock to 59MHz?

[Aditya_Dhananjay]

Hello David,

1. If the FPGA VI is simple (simply add two numbers together), then the compilation succeeds at 60MHz. This is the expected and correct behavior.

2. Now, coming back to the large project (Streaming Vulcan). Each of the sub-cases corresponds to the clock selected in the top-level VI:

2a. 40MHz: Compilation succeeds at 40MHz. (Expected behavior)

2b. 60MHz (3/2 Derived Clock): Compilation succeeds, but ignores the 60MHz requirement. The compilation result states that the VI has been compiled against a 40MHz clock. (Weird case)

2c. 80MHz: (2/1 Derived clock): The compiler attempts to compile against an 80MHz clock, but fails due to a timing violation error. This is also expected behavior.

2d. 65MHz (13/8 Derived Clock): Exactly the same behavior as case 2b. (Weird case)

[Aditya_Dhananjay]

Hello David,

If you wouldn't mind, would you please share the LV Xilinx compilation log that you got when you successfully compiled the large project? Thanks!

[David-A]

Here's the xilinx log from the successful compilation. You can try comparing the two to see if there is anything relevant in the difference.

This one has me stumped though. I'm not too sure what could be causing this. You could try diagram disabling large swaths of the code to see if you can narrow down any one portion of code that may give rise to the behavior. Other than that my only recommendation is try another compile farm or to open a service request with an AE that can dig into it a little more.

[Aditya_Dhananjay]

Hello David,

Thank you once again for all the time you've taken to help me out!

I will also try to open the project and compile on a different machine. In the mean time, I'll open a service request as you had suggested.

Thanks again!

Best,

Aditya

[Aditya_Dhananjay]

Hello All,

Here is a little update. I wrote to an AE, who informed me that this is expected behavior! Here's a snippet of what I was told:

Basically, when the code inside a timed loop takes more time to execute than
the period of the time base that have been set it won’t allow you to use that
time base. The higher the time base frequency [MHz] the shorter the period
[ns]. This is the reason why it fails and gives a timing violation error when
attempting to use 80 MHz. In the other hand, it will happen the same if 60 MHz
is not a feasible time base, but it won’t give you the same error than when
attempting to use 80 MHz, instead of that it will just returns to the default
40 MHz because 60 MHz is not an integer multiple of 40MHz so it just throw you
to the default if it can’t use that time base because of the reason mentioned
above.

Weirdly, when I try to compile at 80MHz, the timing violation error indicates that the maximum supported

clock rate is 67MHz. What I do not understand is why, when I try to compile against 60MHz, it needs to

default down to 40MHz.

Also: It would be great if the compilation failed at a non-integer multiple of the base clock, the compilation

output would explicitly say so, and then indicate that the system has defaulted down to 40MHz -- instead of

a silent compilation "success" at a lower clock rate. This looks unmistakably like a bug! 🙂

Best,

Aditya

[Aditya_Dhananjay]

Hello All,

Here's another update:

The AE wrote back to me informing me that his previous email was erronous. It is *not* expected behavior for the compiler to silently default down to a lower clock rate.

We are still trying to figure out why this behavior is being exhibited.

Best,

Aditya

[Newton_Petersen]

Hi Aditya,

This definitely seems suspicious. I'm a latecomer to this thread and missed downloading your source to reproduce the issue. Could you post it again? Also, who is the AE working with you on this - perhaps I can just get the code from them?

-Newton