For signed 5.23 numbers that have a value of less than zero, SigmaStudio typically writes 4 bytes to RAM, starting with 0xFF. However, the read back value is 0x0F. Why?
The data width of the parameter RAM on many SigmaDSPs is 28 bits. SigmaStudio displays the data as 4 bytes (32 bits), but in truth, the top ‘nibble’ (4 bits) is not stored in RAM because there is no space for it. The reason for this is that typically, things are programmed in terms of whole bytes.
For an example, let's take the value of one LSB below zero. In binary, this is a string of ones.
SigmaStudio expresses this as 4 whole bytes, which have a total of 32 bits, so the value is stored as:
Binary: 1111 1111 1111 1111 1111 1111 1111 1111Hex: F F F F F F F F
However, in the hardware RAM, there are only 28 bits, so the top 4 bits are truncated:
Binary: ---- 1111 1111 1111 1111 1111 1111 1111Hex: ---- F F F F F F F
Hex: ---- F F F F F F F
When SigmaStudio reads the value back, it wants to show 4 full bytes, so it simply replaces the top 4 bits with 0s:
Binary: 0000 1111 1111 1111 1111 1111 1111 1111Hex: 0 F F F F F F F
Hex: 0 F F F F F F F
However, the top 4 bits are “don’t care” because they simply don’t exist in the hardware.
So, Really, this is a bug in Sigma Studio.
It should know this and when reading the data out from the device it should sign extend the data, rather then truncate.
Basically SigmaStudio is set up to show data in multiples of full bytes rather than in multiples of nibbles. If we wanted SigmaStudio to be really accurate to show what's in the hardware, the example above would be simply FFFFFFF (7 nibbles), not FFFFFFFF or 0FFFFFFFF (8 nibbles).
I'll put in a request to have the upper nibble sign-extended rather than zero-filled.
Retrieving data ...