> >'cos it isn't necessary - *if programmed correctly*, ROM corruption
> >just doesn't happen, so the extra cost of a verification mechanism
> >isn't justified. Unfortunately, some standards have been written which
> >require it, and MCT added a facility to the 16C715 for this reason.
>
> Well, I wouldn't (and haven't) use it for ROM checksumming, but I think
> it's nice to be able to put big tables in ROM space (especially with the
> ADSP-2181, where it makes FIR filters much nicer).  Something like a
> sine-table lookup could use the extra precision.

The only time a ROM checksum routine is really useful is if the checksum
routine itself is stored in a more reliable medium than the code being
checked.  For example, some devices have a checksum routine in masked ROM
while the main code is in OTP or EEPROM; even more common are flash-based
systems were the checksum routine is in a hardware-write-protected block
of flash.

Otherwise, the ability to store information more densely in code space would
be a plus, definitely; it would have to be balanced, though, against the
possibly-increased-ease of reading out code-protected devices.  Of course,
this probably isn't the reason for Microchip's decision not to include that
facility, but it should be a consideration.  The crack for the DS5000 series
chips relies upon this sort of weakness, and similar cracks could probably
be weaseled for other chips as well.