Quartus compiler vs end of line encoding

If you are seeing a difference, then I suspect yes.

For a given tool version, on the same platform, with identical source code, you should get identical build results. If ANYTHING changes, you will get a different build file.

Is there an issue for you? as long as the design has good timing specs and it meets timing, then any build should function identically. If you have one build that works and another doesnt, then I suspect you do not have good enough SDC specs or you are not following best design practice.

You're right. That shoudn't be an issue. But in this case it is so unfortunately.

We have a version in version control that isn't working properly and we have a version which was used for version control and which is working. Of course there will be other issues that we should find but there's still one thing that makes no sense for me.

I also expect like you that we will get the same compiling result when we are using same files. That is the reason why I wanted to know if end of line encoding is important for the compiler. Because in our case not all TDF files have the same influence. Some can change their end of line encoding without making any difference and others make differences. That makes no sense to me. Either all end of line encodings are important for the compiler or even none. That's what I would expect.

I can set up our version control not to change any end of line encoding in TDF files automatically but that is just a workaround problably. I don't know if that happens only to TDF files. I just want to understand why some files are special. If I cannot figure it out I will fix it in version control.

And please don't get stuck at the fact that one version isn't working. I just like to know why some end of line encodings are more important than other.

So do you have any idea?

Quartus uses any change in source code to change the fitter seed. So if you do not have good timing specs this can cause 1 build to work, and another to fail, from what is apparently the same source.

With the design properly specced, all builds that meet timing should work, regardless of source files.

It is only an idea but I'm trying to think of a situation where two white space characters might behave differently to one. Do you by any chance use a C preprocessor (or similar) on your files? In C programming some long-ago preprocessors, expecting Unix LF-separated lines, would misinterpret CR-LF lines as having two white-space characters. Because backslash as the last character on a line has a special meaning (continuation lines), some compilers would make errors if they recognised backslash-CR-LF as backslash-whitething-endofline instead of backslash-endofline.

My understanding of AHDL is that it's entirely free-form, so I confess this is entirely speculative.

Jonathan.

PS. I do not believe current C implementations have this problem, just dredging for ideas.