Checksum comparisons

Discussion in 'VHDL' started by Shannon, Sep 22, 2009.

  1. Shannon

    Shannon Guest

    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
     
    Shannon, Sep 22, 2009
    #1
    1. Advertising

  2. Shannon

    KJ Guest

    On Sep 22, 11:54 am, Shannon <> wrote:
    > 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
     
    KJ, Sep 22, 2009
    #2
    1. Advertising

  3. Shannon

    Shannon Guest

    On Sep 22, 10:55 am, KJ <> wrote:
    > On Sep 22, 11:54 am, Shannon <> wrote:
    >
    > > 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


    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, Sep 22, 2009
    #3
  4. Shannon

    Shannon Guest

    On Sep 22, 1:39 pm, Shannon <> wrote:
    > On Sep 22, 10:55 am, KJ <> wrote:
    >
    >
    >
    > > On Sep 22, 11:54 am, Shannon <> wrote:

    >
    > > > 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

    >
    > 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, Sep 22, 2009
    #4
  5. Shannon

    Shannon Guest

    On Sep 22, 2:49 pm, Shannon <> wrote:
    > On Sep 22, 1:39 pm, Shannon <> wrote:
    >
    >
    >
    > > On Sep 22, 10:55 am, KJ <> wrote:

    >
    > > > On Sep 22, 11:54 am, Shannon <> wrote:

    >
    > > > > 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

    >
    > > 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?


    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
     
    Shannon, Sep 22, 2009
    #5
  6. Shannon

    KJ Guest

    On Sep 22, 6:09 pm, Shannon <> wrote:
    >
    > 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
     
    KJ, Sep 23, 2009
    #6
  7. Shannon

    Shannon Guest

    On Sep 22, 6:01 pm, KJ <> wrote:
    > On Sep 22, 6:09 pm, Shannon <> wrote:
    >
    >
    >
    > > 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


    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
     
    Shannon, Sep 23, 2009
    #7
  8. Shannon

    KJ Guest

    On Sep 22, 11:45 pm, Shannon <> wrote:
    > On Sep 22, 6:01 pm, KJ <> wrote:
    >
    >
    >
    >
    >
    > > On Sep 22, 6:09 pm, Shannon <> wrote:

    >
    > > > 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

    >
    > 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
     
    KJ, Sep 23, 2009
    #8
  9. Shannon

    Shannon Guest

    On Sep 23, 5:43 am, KJ <> wrote:
    > On Sep 22, 11:45 pm, Shannon <> wrote:
    >
    >
    >
    > > On Sep 22, 6:01 pm, KJ <> wrote:

    >
    > > > On Sep 22, 6:09 pm, Shannon <> wrote:

    >
    > > > > 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

    >
    > > 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


    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, Sep 23, 2009
    #9
  10. Shannon

    Shannon Guest

    On Sep 23, 7:21 am, Shannon <> wrote:
    > On Sep 23, 5:43 am, KJ <> wrote:
    >
    >
    >
    > > On Sep 22, 11:45 pm, Shannon <> wrote:

    >
    > > > On Sep 22, 6:01 pm, KJ <> wrote:

    >
    > > > > On Sep 22, 6:09 pm, Shannon <> wrote:

    >
    > > > > > 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

    >
    > > > 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

    >
    > 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, Sep 23, 2009
    #10
  11. Shannon

    Shannon Guest

    On Sep 23, 7:23 am, Shannon <> wrote:
    > On Sep 23, 7:21 am, Shannon <> wrote:
    >
    >
    >
    > > On Sep 23, 5:43 am, KJ <> wrote:

    >
    > > > On Sep 22, 11:45 pm, Shannon <> wrote:

    >
    > > > > On Sep 22, 6:01 pm, KJ <> wrote:

    >
    > > > > > On Sep 22, 6:09 pm, Shannon <> wrote:

    >
    > > > > > > 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

    >
    > > > > 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

    >
    > > 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


    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, Sep 23, 2009
    #11
  12. Shannon

    Shannon Guest

    On Sep 23, 9:03 am, Shannon <> wrote:
    > On Sep 23, 7:23 am, Shannon <> wrote:
    >
    >
    >
    > > On Sep 23, 7:21 am, Shannon <> wrote:

    >
    > > > On Sep 23, 5:43 am, KJ <> wrote:

    >
    > > > > On Sep 22, 11:45 pm, Shannon <> wrote:

    >
    > > > > > On Sep 22, 6:01 pm, KJ <> wrote:

    >
    > > > > > > On Sep 22, 6:09 pm, Shannon <> wrote:

    >
    > > > > > > > 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

    >
    > > > > > 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

    >
    > > > 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

    >
    > 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)
     
    Shannon, Sep 23, 2009
    #12
  13. Shannon

    Dave Guest

    On Sep 23, 12:03 pm, Shannon <> wrote:
    > On Sep 23, 7:23 am, Shannon <> wrote:
    >
    >
    >
    > > On Sep 23, 7:21 am, Shannon <> wrote:

    >
    > > > On Sep 23, 5:43 am, KJ <> wrote:

    >
    > > > > On Sep 22, 11:45 pm, Shannon <> wrote:

    >
    > > > > > On Sep 22, 6:01 pm, KJ <> wrote:

    >
    > > > > > > On Sep 22, 6:09 pm, Shannon <> wrote:

    >
    > > > > > > > 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

    >
    > > > > > 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

    >
    > > > 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

    >
    > 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?
     
    Dave, Sep 23, 2009
    #13
  14. Shannon

    Shannon Guest

    On Sep 23, 9:34 am, Dave <> wrote:
    > On Sep 23, 12:03 pm, Shannon <> wrote:
    >
    >
    >
    > > On Sep 23, 7:23 am, Shannon <> wrote:

    >
    > > > On Sep 23, 7:21 am, Shannon <> wrote:

    >
    > > > > On Sep 23, 5:43 am, KJ <> wrote:

    >
    > > > > > On Sep 22, 11:45 pm, Shannon <> wrote:

    >
    > > > > > > On Sep 22, 6:01 pm, KJ <> wrote:

    >
    > > > > > > > On Sep 22, 6:09 pm, Shannon <> wrote:

    >
    > > > > > > > > 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

    >
    > > > > > > 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

    >
    > > > > 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

    >
    > > 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?


    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
     
    Shannon, Sep 23, 2009
    #14
  15. Shannon

    JimLewis Guest

    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
     
    JimLewis, Sep 24, 2009
    #15
  16. Shannon

    Shannon Guest

    On Sep 24, 6:02 am, JimLewis <> wrote:
    > 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.
     
    Shannon, Sep 24, 2009
    #16
  17. Shannon

    KJ Guest

    On Sep 24, 6:51 pm, Shannon <> wrote:

    >
    > 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
     
    KJ, Sep 25, 2009
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. anupam

    vhdl code for crc32 checksum

    anupam, Sep 3, 2004, in forum: VHDL
    Replies:
    4
    Views:
    7,917
    Kai Harrekilde-Petersen
    Sep 6, 2004
  2. Alessio

    Checksum java

    Alessio, Oct 6, 2004, in forum: Java
    Replies:
    16
    Views:
    6,563
    Thomas G. Marshall
    Oct 12, 2004
  3. moongate

    checksum and JARs

    moongate, Jan 13, 2005, in forum: Java
    Replies:
    0
    Views:
    687
    moongate
    Jan 13, 2005
  4. Steve
    Replies:
    3
    Views:
    16,374
    Roedy Green
    May 7, 2006
  5. wilk

    Internet Checksum

    wilk, Dec 11, 2003, in forum: C++
    Replies:
    3
    Views:
    1,160
Loading...

Share This Page