In a VHDL assignment, I have to make an ALU which outputs the result of the subtraction and two's complement and some other operations on 16bit inputs. In a way that the rtl code is compared with the functional one.
In the functional code, I have used arithmetic operations like "+", "-" and ..., but in the rtl, I have used structural VHDL. That is why I have to be accurate so the results of these codes show the same output. I don't know what parts of the codes might be useful to share.
I am working on a vhdl code that subtracts two "signed" numbers (signed in two's complement format) in the structural form. Normally for subtracting two unsigned numbers, we change the second one to two's complement and add the numbers.
But, now that we have signed numbers, say we want to subtract two 16 bit signed numbers that the last MSB is the sign bit. How does two's complement work here? (Looking at here), if I want to have a - b (a and b are signed numbers) I should have:
a + (two's complement b)
or
a + (not b)?
(a and b are signed in two's complement format)
Related
How do I represent negative numbers in non-10 bases, eg say in base 20. I know how to do this in binary using two's complement, but what would the equivalent of two's complement be in other bases?
For example, in base 20, the denary number 100 is represented as 50. How would I make this 50 signed? Would I need to convert it to binary, two's complement it, the convert it back to base-20? It seems a little long-winded.
In that case, negative base-20 50 (which is 100 in base-10) would be 7g, and positive would be just 50. But is this the standard way to represent negative numbers in other bases?
The generalisation of two's complement is radix complement.
The radix complement of an 𝑛 digit number y in radix 𝑏 is, by definition, 𝑏𝑛−𝑦. The radix complement is most easily obtained by adding 1 to the diminished radix complement, which is (𝑏𝑛−1)−𝑦
We must however agree what 𝑛 is. For instance, in binary we may say we have 32 bits, so 𝑛 = 32 in that case.
So for the example of base-20 we should make some definitions:
The digits are "0123456789𝑎𝑏𝑐𝑑𝑒𝑓𝑔ℎ𝑖𝑗".
𝑛 is 10 (an arbitrary choice, but it has to be made)
We can also define what the "(diminished) complementary digit" is for each digit. It is the digit that when added to the first will always yield the greatest digit (𝑗20 in this case). For example 220 + ℎ20 = 𝑗20, so ℎ20 is the complement of 220, and vice versa.
For your example number 5020, we proceed as follows:
Replace every digit of the 𝑛-digit representation with its complement:
So the diminished complement of 000000005020 thus becomes 𝑗𝑗𝑗𝑗𝑗𝑗𝑗𝑗𝑒𝑗20
To get the negation of 5020 we just need to add 1 to that:
−5020 = 𝑗𝑗𝑗𝑗𝑗𝑗𝑗𝑗𝑓020
It is important to not reduce this representation to use fewer digits -- we have to stick with the 𝑛-digit representation, otherwise it is not clear when a number is positive or negative.
I have a very basic question regarding computers and number representations. I was wondering why it is that 2^31 -1 is the largest positive integer representation for 32-bit binary while 2^31 is the largest negative value? Why is it not possible for both the positive and negative representations to be expressed as 2^32? Is it related to the fact that for example given a positive representation you want to retain the ability to express a negative number as well? I assume we want to maintain the possibility of using all possible combinations of 0's and 1's in 32-bit.
I assume it's fairly obvious that with 32 bits, you can only have 2^32 different values. For unsigned integers, the choice of those values is entirely straightforward: 0, 1, 2, etcetera, until you have 2^32 values - so the last possible value is 2^32-1.
For floats, the different values are far more complex, but again you can't have more values than you can have bit patterns, because one bit pattern must have one value. (Not the other way around, because -0.0 = +0.0).
Signed integers are not nearly as complex - you still have 2^32 bit patterns, and again 2^32 different values. All values differ by exactly one, so the difference between the min and the max value has to be 2^32-1.
For obvious reasons, the range is chosen centered around 0, so you have roughly 2^32/2 = 2^31 values lower than 0 and 2^31 values higher than 0. And it's only "roughly" 2^31, because you also need a bit pattern for 0, or two bit patterns for +0 and -0. That's why there's a -1 in 2^31-1.
2's complement chooses to reduce the range of positive numbers, because it encodes positive signed integers the same as unsigned integers with the same value. This leaves the top bit to represents -2^31.
I have a need to implement a floating point package for small SBC and have most of the routines now working, but in the course of testing I have noticed that the algorithm in this 1 (attachment) will not (indeed cannot) produce the correct answer in the case where the divisor mantissa is all zeros, for the example 500/2 will produce the answer 255.0 rather than 250.0
01000000011111110100000000000000 = 0x43FA00 (500 base 10) and
01000000000000000000000000000000 = 0x400000 (2 base 10)
will produce
01000011011111111000000000000000 =0x437F0 (255 base 10)
Is there anyone who has a good knowledge of Floating Point arithmetic or indeed FP algorithms that can help out please?
[]
Nothing in the chart shown says to work with the bits that are the primary encoding of the significand of a floating-point number. One should not confuse the bits that encode something with the thing itself. The actual significand of a normal IEEE-754 binary floating-point number, for example, is some binary numeral 1.xxx…xxx with a value in [1, 2) and a number of bits determined by the specific format. (Subnormal numbers use a numeral 0.xxx…xxx.) When the number is encoded in an interchange format, the xxx…xxx bits are stored in the primary significand field, and the leading 1 or 0 bit is encoded by way of the exponent field. (If the exponent field is not zero, and does not indicate an infinity or a NaN, then the leading bit is 1. Otherwise, it is 0.)
Generally, the actual significand is used for arithmetic, not just the bits of the primary significand field.
I am working on a VHDL implementation of the SHA-256 hash function.
I have some 32-bit unsigned signals defined as such:
SIGNAL a, b : UNSIGNED (31 downto 0);
Within the specifications of the SHA-256 algorithm, it says addition must be performed modulo 2^32 in order to retain the 32-bit size in case of an overflow. Now, according to the answer to this question, it sounds like overflow is already handled with modular addition in VHDL:
There is no overflow handling, the overflow carry is simply lost. Thus the result is simply the integer result of your operation modulo 2^MAX.
I have 2 questions:
In my case, MAX = 31 so does that mean that any addition operation I perform on a and b will be modded with 2^31?
I need to perform addition modulo 2^32 which obviously doesn't make sense since I am working with 32-bit numbers and 2^32 is one bit too large. So is it somehow implied that I should actually be modding with 2^31?
You are fine with unsigned(31 downto 0). The 2^MAX in the post you reference is an error and should read 2^length. The length of 31 downto 0 is 32.
Think about it, 31 downto 0 can represent numbers from 0 to 2^32-1, it wouldn't make much sense if any addition of that range would be modulo 2^31 if you can represent larger numbers!
I'm not sure I understand your second question, but addition modulo 2^32 yields results in the range of 0 to 2^32-1. 2^32 is illegal, thus it's quite fine that you can't represent it with your unsigned.
How can i write VHDL code for 4-digit binary numbers so that it outputs 1 only when the 4-digit number is divisible by 3 or 4 using only NOR gates?
Thanks for any help.
The answer is yes. Because you can build any logic with only NAND and NOR.
1) List the numbers (3,4 etc) for which the output is to be 1.
2) Write down the binary representation of each of these numbers, 0011, 0100, etc
3) Write down the expression for the output as the logical OR of these terms :
Output <= 0011 + 0100 + ...
This is the expression for your output in SOP (Sum of Products) form.
4) Optionally, (but worth doing because it reduces the size of the problem you are dealing with) minimise this expression using standard techniques such as drawing the Karnaugh map, and combining adjacent terms to simplify the expression.
5) Use De Morgan's rules to transform the simplified SOP expression into POS (Product of Sum) form.
6) You can now implement the POS form as two levels of NOR gate.
One best way I guess was to manually derive the equations from truth table through karnaugh map you will get a combination of AND and OR gate convert all that to NOR gate using standard technique after that you can go for implementing the same using gate level modelling.