Problem with two’s complement format

[EDA_hg81]

two complement

Let me explain the problem first.
In the new design, the high voltage output means signal is low and low voltage output means signal is high.
But in the old design, the situation is reversed. The high voltage output means signal is high and low voltage output means signal is low.
I have to modify VHDL code inside old design.
The output data from ADC is two’s complement format. Output is 16 bit.
The following is the code:
Old code :

ad_data_regh <= AD_DAT;

New code:

 ad_data_regh <= "0111111111111111" + (not(AD_DAT) + "0000000000000001");

But above modification is not working.
What is the problem?
Thanks.

 

[tkbits]

twos-complement format

 ad_data_regh <= "0111111111111111" + (not(AD_DAT) + "0000000000000001");

is equivalent to

ad_data_regh <= (not(AD_DAT)) + "0111111111111111" + "0000000000000001";

which is equivalent to

ad_data_regh <= (not(AD_DAT)) + "1000000000000000";

 

[EDA_hg81]

adc two’s complement

any more ideas?

Thanks.

 

[tkbits]

abs twos complement

Can you give examples of what your results ought to be?

 

[FvM]

.twos format

Why don't you use simply ad_data_regh <= not AD_DAT;[/]

 

[EDA_hg81]

convert binary two complement

In the old design, FPGA transfers the data to a TI DSP chip, which transfers the final data to the PC for displaying on the monitor.
Since the voltage range of ADC is 0V to 2.5V, I only want to invert data by this way: 2,5V – input voltage.
Such as:
2.5 -2.5 = 0V
2.5 – 0.8 = 1.7V
2.5 – 0 = 2.5V
Since the data format is two’s complement, I have to use that way to convert data.
Thanks.

Added after 1 minutes:

Why don't you use simply ad_data_regh <= not AD_DAT;[/]

I have used this way and my way.

both of them didn't work.

the data showing on monitor are not changed.:|

 

[FvM]

2s complement format

I don't understand, why the ADC output is two's complement with an unipolar range of 0..2.5V.This would mean using only half of the 16-Bit number range. Something is wrong with the explanation, I think. Can you please tell the ADC representation of 0 and 2.5 V and the intended ad_data_regh values?

 

[EDA_hg81]

xor twos complement zero

The ADC is AD7664.

The 5th pin of AD7664 for controlling output data format is pulled low on last design.

Description of 5ht pin is:

Straight Binary/Binary Twos Complement. When OB/2C is HIGH, the digital output is
straight binary; when LOW, the MSB is inverted resulting in a twos complement output from
its internal shift register.

I wish you can help me to find out.

I have read the design manual for last design, it is true 2.5V is "0111111111111111".

Merry Holiday.

 

[FvM]

vhdl two complement format

Twos complement representation of an unipolar signal range sounds somewhat strange, but can make sense if the range is shifted to bipolar by applying an offset.

I have read the design manual for last design, it is true 2.5V is "0111111111111111".

Yes, in twos complement representation.

Basically, twos complement and straigth binary differ only by an inverted MSB respectively an XOR x"8000" in VHDL. Signal inversion can be achieved for both representations by inverting all bits respectively perform XOR x"FFFF".

 

[EDA_hg81]

adc out 2 complement

they told me they applied offset correction inside DSP.

But I can't rearch that code. :|

 

[tkbits]

twos complement format

Here is how the MSB inversion works...

I'll use 3-bit numbers to keep it short.

Notice that the INV column is created from the BIN column by inverting the MSB only.

The 2-COMP column is the INV column interpreted as values in 2's complement form.

What the table shows is that inverting the MSB is the same as adding the smallest possible (most negative) 2's complement value as an offset. You either use the two's complement value directly as a signed value, or you undo the offset by inverting the MSB.

BIN ABS INV 2-COMP
VAL VAL MSB VALUE
000  0  100   -4
001  1  101   -3
010  2  110   -2
011  3  111   -1
100  4  000    0
101  5  001    1
110  6  010    2
111  7  011    3

 

[EDA_hg81]

complement formate

The following pictures show the inverting results.

The sensor I am working on is a photo-diode sensor.

Do you have any ideas?

Thanks.

 

[FvM]

I don't see the results related to the previous discussion.

 

[EDA_hg81]

Those pictures are related to my topic.

P1shows the wrong output when sensor is totally cover and the outputs of sensor are all 2.5V (which means totally dark), which should be inverted to 0 or negative.

The output of FPGA should be

output of FPGA = x"FFFF" xor x"7FFF" = x"8000" when input is 2.5V (x"7FFF").

after inverting inside FPGA, x"8000" is send to DSP chip and x"8000" means -2.5V.

But why the output is still plus 2.5V?

I think DSP processing is overflow or it can not deal with -2.5V

Thanks.

 

[FvM]

We can discuss a problem related to number format and format conversion only in terms of input code and expected versus observed output code. The output can be either correct, than there isn't any number format problem and the discussion would be out-of-topic - or incorrect, than you should clearly tell, what's the expected output.

 

[EDA_hg81]

my question is when the input is 2.5V(x"7FFF")

The output of FPGA should be when we doing the inversion:

output of FPGA = x"FFFF" xor x"7FFF" = x"8000" in two's complement format.

Let's convert x"8000" from two's complement:

The inversion of x"8000" number is:

x"7FFF"

Then we add one.

x"0001"

So the negative of x"8000" is x"8000",

Is this a problem?

The rest conversion looks fine.

 

[FvM]

Yes, this is a wellknown problem. Your conversion doesn't work for 0x8000. That's why I suggested a different one.

ad_data_regh <= not AD_DAT;

It has an offset of one LSB, but is defined for the full number range. With numerical exact inversion, you need saturation logic respectively a special treatment of the maximum negative input value.

 

[EDA_hg81]

I think I solved this problem by xor x"fffe".

Thank you FVM, you help me a lot.

Happy new year.

 

[FvM]

Not exactly. xor x"fffe" is inverting the LSB, which results in a non-monotic order of converted codes, effectivly reducing the ADC resolution. xor x"ffff" is the better solution to my opinion. The resulting offset of 1 is not reducing the resolution. Or convert <= x"7fff" WHEN value = x"8000" ELSE -value;

 

[EDA_hg81]

thank you FVM.

Or convert <= x"7fff" WHEN value = x"8000" ELSE -value;

This way I have tried but it didn't work for me.

I will keep trying other methods.

Let you know the results.

Happy new new year!!!