Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Checksum comparisons

Reply
Thread Tools

Checksum comparisons

 
 
Shannon
Guest
Posts: n/a
 
      09-22-2009
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
 
Reply With Quote
 
 
 
 
KJ
Guest
Posts: n/a
 
      09-22-2009
On Sep 22, 11:54*am, Shannon <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Shannon
Guest
Posts: n/a
 
      09-22-2009
On Sep 22, 10:55*am, KJ <(E-Mail Removed)> wrote:
> On Sep 22, 11:54*am, Shannon <(E-Mail Removed)> 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
 
Reply With Quote
 
Shannon
Guest
Posts: n/a
 
      09-22-2009
On Sep 22, 1:39*pm, Shannon <(E-Mail Removed)> wrote:
> On Sep 22, 10:55*am, KJ <(E-Mail Removed)> wrote:
>
>
>
> > On Sep 22, 11:54*am, Shannon <(E-Mail Removed)> 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?
 
Reply With Quote
 
Shannon
Guest
Posts: n/a
 
      09-22-2009
On Sep 22, 2:49*pm, Shannon <(E-Mail Removed)> wrote:
> On Sep 22, 1:39*pm, Shannon <(E-Mail Removed)> wrote:
>
>
>
> > On Sep 22, 10:55*am, KJ <(E-Mail Removed)> wrote:

>
> > > On Sep 22, 11:54*am, Shannon <(E-Mail Removed)> 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
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      09-23-2009
On Sep 22, 6:09*pm, Shannon <(E-Mail Removed)> 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
 
Reply With Quote
 
Shannon
Guest
Posts: n/a
 
      09-23-2009
On Sep 22, 6:01*pm, KJ <(E-Mail Removed)> wrote:
> On Sep 22, 6:09*pm, Shannon <(E-Mail Removed)> 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
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      09-23-2009
On Sep 22, 11:45*pm, Shannon <(E-Mail Removed)> wrote:
> On Sep 22, 6:01*pm, KJ <(E-Mail Removed)> wrote:
>
>
>
>
>
> > On Sep 22, 6:09*pm, Shannon <(E-Mail Removed)> 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
 
Reply With Quote
 
Shannon
Guest
Posts: n/a
 
      09-23-2009
On Sep 23, 5:43*am, KJ <(E-Mail Removed)> wrote:
> On Sep 22, 11:45*pm, Shannon <(E-Mail Removed)> wrote:
>
>
>
> > On Sep 22, 6:01*pm, KJ <(E-Mail Removed)> wrote:

>
> > > On Sep 22, 6:09*pm, Shannon <(E-Mail Removed)> 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
 
Reply With Quote
 
Shannon
Guest
Posts: n/a
 
      09-23-2009
On Sep 23, 7:21*am, Shannon <(E-Mail Removed)> wrote:
> On Sep 23, 5:43*am, KJ <(E-Mail Removed)> wrote:
>
>
>
> > On Sep 22, 11:45*pm, Shannon <(E-Mail Removed)> wrote:

>
> > > On Sep 22, 6:01*pm, KJ <(E-Mail Removed)> wrote:

>
> > > > On Sep 22, 6:09*pm, Shannon <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: new IOS invalid checksum (broken flashcard?) gglggl Cisco 0 12-23-2004 03:21 AM
PIMSM:Which Cisco IOS sends PIM register messages with checksum ONLY over the PIM header? Farida Cisco 0 10-26-2004 02:12 PM
vhdl code for crc32 checksum anupam VHDL 4 09-06-2004 09:05 PM
PIX VPN and DNS Problem with udp checksum errors Oliver Rahn Cisco 0 08-30-2004 11:28 AM
checksum errors with my 2611 Sameer Cisco 2 01-27-2004 12:37 AM



Advertisments