Checksum comparisons

[Shannon]

I'm using Quartus II ver. 9.0.

I've taken a large chunk of my design and moved it off into it's own
file. It was a clean cut-n-paste. I did not change ANY code. I put
an instance in my top level and recompiled.

Problem is I compared checksums of the programming files and they are
different. Is this too much to assume they would be the same? I'm
guessing that optimizations are not happening across modules. Does
this sound right?

Shannon

 

[KJ]

I'm using Quartus II ver. 9.0.

I've taken a large chunk of my design and moved it off into it's own
file.  It was a clean cut-n-paste.  I did not change ANY code.  I put
an instance in my top level and recompiled.

Problem is I compared checksums of the programming files and they are
different.  Is this too much to assume they would be the same?  

Using Quartus, I've modified designs in ways that 'should' produce the
same binary programming file and they do. I'll do that as a
regression test when I'm getting ready to add in some bell or whistle
but want to make sure that I haven't broken the old and reliable.
It's more accurate than retesting on physical hardware.

I'm
guessing that optimizations are not happening across modules.  Does
this sound right?

Assuming you're compiling all the sources and not instantiating black
boxes or something, then synthesis optomizations do not see any
barrier caused by 'module boundaries'. To synthesis, it's all just a
list of combinatorial logic and registers.

KJ

 

[Shannon]

Using Quartus, I've modified designs in ways that 'should' produce the
same binary programming file and they do.  I'll do that as a
regression test when I'm getting ready to add in some bell or whistle
but want to make sure that I haven't broken the old and reliable.
It's more accurate than retesting on physical hardware.


Assuming you're compiling all the sources and not instantiating black
boxes or something, then synthesis optomizations do not see any
barrier caused by 'module boundaries'.  To synthesis, it's all just a
list of combinatorial logic and registers.

KJ

Bad news then. I've got to figure out what code could have possibly
changed with a cut and paste. Damn. I was afraid of that. This
isn't going to be easy.

Shannon

 

[Shannon]

Bad news then.  I've got to figure out what code could have possibly
changed with a cut and paste.  Damn.  I was afraid of that.  This
isn't going to be easy.

Shannon

Ok, text file comparisons all check out. There must be something I'm
missing. Is there such a thing as an "RTL" file that I can diff?

 

[Shannon]

Ok, text file comparisons all check out.  There must be something I'm
missing.  Is there such a thing as an "RTL" file that I can diff?

I can't prove it yet but I think there is a difference between signals
and ports. (other than the obvious.)

By moving some of my code to a separate file some signals had to
become ports. Even though this doesn't change any logic I think it
explains the different checksums. Maybe I can come up with a simple
piece of code to prove my point.

Shannon

 

[KJ]

I can't prove it yet but I think there is a difference between signals
and ports.  (other than the obvious.)

The difference is that logic for signals can be optomized, ports at
the top level can not. Top level ports also define I/O pins, signals
do not. All these things contribute to producing a different
programming file. Not quite sure what you're doing, but based on what
you're saying here it doesn't sound like what you're doing that one
would have any reasonable expectation of getting the same binary file
for programming the part. Even if the logic that is implemented is
the same, there is more to the programming file for a part then just
the logic (options like I/O pins, drive strength, pullups,
termination, etc. come to mind).

By moving some of my code to a separate file some signals had to
become ports.  Even though this doesn't change any logic I think it
explains the different checksums.  Maybe I can come up with a simple
piece of code to prove my point.

Maybe it would be easier for you to simply answer the question of why
are you trying to do whatever it is you're trying to do? Testbench
verification of your new design might be more productive.

Kevin Jennings

 

[Shannon]

The difference is that logic for signals can be optomized, ports at
the top level can not.  Top level ports also define I/O pins, signals
do not.  All these things contribute to producing a different
programming file.  Not quite sure what you're doing, but based on what
you're saying here it doesn't sound like what you're doing that one
would have any reasonable expectation of getting the same binary file
for programming the part.  Even if the logic that is implemented is
the same, there is more to the programming file for a part then just
the logic (options like I/O pins, drive strength, pullups,
termination, etc. come to mind).


Maybe it would be easier for you to simply answer the question of why
are you trying to do whatever it is you're trying to do?  Testbench
verification of your new design might be more productive.

Kevin Jennings

During development a lot of code was added to the top level. I like
to keep the top level clean. So all I am doing is sweeping up all the
random code that is in the top level and putting it together in it's
own file. Simple cut and paste for the most part. The difference
being is that the new file has ports where it ties to other entities
in the top level.

No top level ins and outs (i.e. pins) have changed.

Shannon

 

[KJ]

During development a lot of code was added to the top level.  I like
to keep the top level clean.  So all I am doing is sweeping up all the
random code that is in the top level and putting it together in it's
own file.  Simple cut and paste for the most part.  The difference
being is that the new file has ports where it ties to other entities
in the top level.

No top level ins and outs (i.e. pins) have changed.

In that case, then you should be able to get to the same output file.
I've refactored code moving stuff from one entity to another, added
new generics to entities and other stuff like that and been able to
get back the same output file.

Sounds like you might need to restart and take some small steps first
(like rebuild with the original design totally unchanged and verify
the output file; then add the new entity/architecture but not put any
code into it and verify; then start moving code). It could also be
where you say 'for the most part'. Any place where you did something
different than a copy/paste operation is a likely spot to cause a
subtle difference.

Are there unaccounted for differences in the QSF file? The only
difference should be adding the new source file. Any other changes
can cause the build to be different and create a different output
file.

Kevin Jennings

 

[Shannon]

In that case, then you should be able to get to the same output file.
I've refactored code moving stuff from one entity to another, added
new generics to entities and other stuff like that and been able to
get back the same output file.

Sounds like you might need to restart and take some small steps first
(like rebuild with the original design totally unchanged and verify
the output file; then add the new entity/architecture but not put any
code into it and verify; then start moving code).  It could also be
where you say 'for the most part'.  Any place where you did something
different than a copy/paste operation is a likely spot to cause a
subtle difference.

Are there unaccounted for differences in the QSF file?  The only
difference should be adding the new source file.  Any other changes
can cause the build to be different and create a different output
file.

Kevin Jennings

I haven't tried compiling with a blank entity. I'll try that next. I
tried to go back and move just one process at a time but things are so
inter-connected that it really has to go in one shot. I'd have to
create a bunch of signals to tie pieces together and I'm sure that
would create a new checksum.

The QSF file should be identical other than the addition of the new
source file. I'll check that however. Also ALL signals in the top
level are tied to pins so there is no chance that pins are being
placed by the fitter in different ways. I've run verification on the
design and as far as I can tell it's working the same but I'm still
very nervous.

One last thing. let me tell you exactly what I do to go from original
design to new design:

1) comment out all unneeded (redundant) signal declarations in the top
level (they are all in one block so that is easy)
2) comment out all the code that was copied to the new source file
(also all in one contiguous block)
3) uncomment the entity declaration/instantiation in the top level for
the new source file
4) add the new source file to the project
5) re-compile

 

[Shannon]

I haven't tried compiling with a blank entity.  I'll try that next.  I
tried to go back and move just one process at a time but things are so
inter-connected that it really has to go in one shot.  I'd have to
create a bunch of signals to tie pieces together and I'm sure that
would create a new checksum.

The QSF file should be identical other than the addition of the new
source file.  I'll check that however.  Also ALL signals in the top
level are tied to pins so there is no chance that pins are being
placed by the fitter in different ways.  I've run verification on the
design and as far as I can tell it's working the same but I'm still
very nervous.

One last thing.  let me tell you exactly what I do to go from original
design to new design:

1) comment out all unneeded (redundant) signal declarations in the top
level (they are all in one block so that is easy)
2) comment out all the code that was copied to the new source file
(also all in one contiguous block)
3) uncomment the entity declaration/instantiation in the top level for
the new source file
4) add the new source file to the project
5) re-compile

oh and one last question. Could it be the compile order changing?
Adding the new source file would necessarily change the compile order.

Shannon

 

[Shannon]

oh and one last question.  Could it be the compile order changing?
Adding the new source file would necessarily change the compile order.

Shannon

I compiled with an empty source file in the project and got the
original checksum. Then I re-compiled with the file filled with the
cut-n-pasted code and got a different checksum.

I did a file compare between the two .qsf files and they were
identical.

I can only conclude from this that re-factoring the code like this
WILL change the logic. I'm going to open a ticket with Altera about
it but I suspect they will conclude the same thing since it is easy to
brush someone off with this one.

Thanks for the help KJ

 

[Shannon]

I compiled with an empty source file in the project and got the
original checksum.  Then I re-compiled with the file filled with the
cut-n-pasted code and got a different checksum.

I did a file compare between the two .qsf files and they were
identical.

I can only conclude from this that re-factoring the code like this
WILL change the logic.  I'm going to open a ticket with Altera about
it but I suspect they will conclude the same thing since it is easy to
brush someone off with this one.

Thanks for the help KJ

oh and I forgot to mention that I looked at the results of the compile
each time and both versions have exactly the same number resources
used (i.e. Combinational ALUTs and Dedicated logic registers)

 

[Dave]

I compiled with an empty source file in the project and got the
original checksum.  Then I re-compiled with the file filled with the
cut-n-pasted code and got a different checksum.

I did a file compare between the two .qsf files and they were
identical.

I can only conclude from this that re-factoring the code like this
WILL change the logic.  I'm going to open a ticket with Altera about
it but I suspect they will conclude the same thing since it is easy to
brush someone off with this one.

Thanks for the help KJ

Depending on the options you're using, the synthesizer may not perform
optimizations and resource sharing across hierarchical boundaries the
same way it does within a hierarchical block (ie, the top level file).
Even if you got the same utilization, could this cause a slightly
different implementation?

 

[Shannon]

Depending on the options you're using, the synthesizer may not perform
optimizations and resource sharing across hierarchical boundaries the
same way it does within a hierarchical block (ie, the top level file).
Even if you got the same utilization, could this cause a slightly
different implementation?

That is what I originally mentioned in my first post. Kevin thinks it
isn't true. I am not using any logic-lock regions or design
partitions so I tend to think it flattens the whole thing but
obviously not. Do you know of some 'options' that might cause it to
view hierarchical bondaries as sacred?

Shannon

 

[JimLewis]

Optimization is an NP complete problem. If something on the input
changes - order of code, file structure, ... I would expect the
optimization, and hence, the gate implementation to change.

If you make the code so it is compiled in the same order as
previously, eventhough now it is in a separate file, you may be able
to get the same results as previously, but maybe not.

Interestingly enough, in an old, old version of one of the synthesis
tools, changing the comments actually changed the optimization - they
fixed this rather quickly though.

Best,
Jim

 

[Shannon]

Optimization is an NP complete problem.  If something on the input
changes - order of code, file structure, ... I would expect the
optimization, and hence, the gate implementation to change.

If you make the code so it is compiled in the same order as
previously,  eventhough now it is in a separate file, you may be able
to get the same results as previously, but maybe not.

Interestingly enough, in an old, old version of one of the synthesis
tools, changing the comments actually changed the optimization - they
fixed this rather quickly though.

Best,
Jim

The answer from Altera:

Hello Shannon,

The checksum is not only based on the functional logic within a
design, but also on how it gets placed in the design and therefore
includes the routing resources.

Though you have the same exact FPGA resources used, you may have
slightly different routing resources used, which will cause the
checksum to be different.

As an example, say that you did not make any changes to the coding,
but changed the routing seed. Your routing would be slightly
different and would cause your checksum to be different.

Any time you change something in the design - including changing the
organization of the coding, Quartus will compile with a slightly
different starting point for the fitter/router and your checksum will
be different.

 

[KJ]

Any time you change something in the design - including changing the
organization of the coding, Quartus will compile with a slightly
different starting point for the fitter/router and your checksum will
be different.

I guess I should open a case with Altera showing how I made non-
trivial code changes, moved code across entities, added new files and
still got the exact same output file

KJ