SOF Files content are Different after each time of Compilation!!!! Is It Normal??

[Altera_Forum]

Why the SOF files content (in binary) are different every time I recompile a same project? Is it normal? 

Is it possible to make the SOF files content always the same for each time compilation?  Will creating the design partition or region lock will make the SOF files content the same?:confused::confused:   Thanks in advance;);)

[Altera_Forum]

The same initial conditions should create the same result. Initial conditions cover everything about the design, including input files, .qsf settings, etc. It even includes OS, as Linux and Windows give different results(due to different floating point calculations). One thing I've seen is designs that create a timestamp in them naturally have a different input each time. Also, there was an issue where you'd get a different result if you had a /db from the previous compile around(that should have been fixed). In that case, there were two diffferent results, i.e. if there was no /db you got result A, and if there was a /db you would get result B and could keep compiling over and over and get B. 

Make two identical copies of the design and compile them. Are they really different?  (Finally, if it's a build going into production, and that doesn't happen that often, I recommend zipping it up with the /db and storing it that way. Minimally, it just makes it easier to open and go back and look at timing, reports, etc., but now you don't have to worry about regenerating it exactly either.)

[Altera_Forum]

Thanks Rysc. 

I tried to make two identical copies and compile them as you suggested. Two of the SOF files are slightly different (they will have huge different if one of them compiled with no \db) since some of the files in /db will be have minor different each time of compilation. Since they are all in binary, i can not understand which parts that they are different. https://www.alteraforum.com/forum/attachment.php?attachmentid=13014  https://www.alteraforum.com/forum/attachment.php?attachmentid=13016  https://www.alteraforum.com/forum/attachment.php?attachmentid=13015

[Altera_Forum]

knowfish, 

Did you remove this thread? I received an email that you had updated it, but when I clicked on the link it says it was invalid. I thought the poster name on that one was vitlachbach? (I have an issue where I see posts I can answer, but often click on them and the link is invalid, and so trying to track down if it's a technical issue or the original poster taking it down, changing it, etc.)  FYI, I can't see the .jpg files(I downloaded them, but the screenshots are too coarse grained). I assume it's a diff showing different files.  1) There is no random number generator or anything like that in Quartus, so given the same inputs, as previously discussed, will produce the same outputs. Is there a QSYS system in your project, as sometimes those have an ID component, which puts a timestamp in it. 2) Debugging what's causing this can be a pain. What I recommend is starting with the .map.rpt and diffing them. I would actually start with the messages at the bottom. It may take a little massaging, i.e. if the projects are in different locations then the reports will all show different paths, so you have to do a search and replace, but you can get there. 3) Why are you worried about this? The number one reason of concern is the case I mentioned earlier, whereby there is an image in the field and the entire project wasn't saved. There might be a problem and they want to go back to that exact fit and run Timequest on it, or do a post-fit SignalTap, to try and debug the issue. Again, in most circumstances it's easier to just zip up everything including the /db. If you're finding that you get different results and some of them work and some of them don't, then I would worry much more about why the non-working ones fail. Different results should just be like a different seed, e.g. a randomly different fit that is still trying to meet all of your requirements. If the design is fully constrained, then both designs should work and you shouldn't be able to tell the difference in hardware(only doing something like comparing .sofs shows a difference). In fact, I'm not sure why you're recompiling to try and get the same results. I generally keep recent results around if I need to go back and look at them. I'm not saying you don't have a good reason, and the fitter is designed to give identical results so not doing that is wrong, but I'm just checking if something else is going on.

[Altera_Forum]

Hi Rysc, 

 Appreciate for the reply. I didn't remove the thread. It still can be found in the Altera forum.^^ Here is the reason on why i'm coming out with this question.. Because I'm a firmware engineer, normally when i want to leverage or change some codes from the previous releasing firmware on a existing product. I'll try to recompile the source code and generate the binary file and compare with those released to production to ensure that source code that I'll taking is the working one (I think this can be skipped if there have a proper version control managing system). So I do the same thing on comparing the FPGA binary file but eventually found out they are always different, not like the hex file for the processor or micro-controller. And now I know why they're always different as u explained in previous posts.  If there is a sophisticated system and there are a lot of source files, I think there will be time wasted by recompiling it and retest it on the hardware just to verify the source files are the right one for the production released binary file.  I think can only trust on the previous engineer have properly check-in the source codes in the version control managing system.

[Altera_Forum]

Thanks. That's a good reason. As you say, proper version control management would take care of this, but we all make mistakes, and that's a good way to check. Is there a reason it should change, like a timestamp in the design? As I said, it really shouldn't if all the initial conditions are the same.

[Altera_Forum]

Hi Rysc, 

FYI,normally if we want to enhance a product in the market like adding a new feature or value engineering on a product, then we'll do so^^.  No relate to the timestamp^^