16-bit Processor's ALU Design in Verilog

Hi!
I need help in designing of a 16-bit processor's ALU.
It modifies the flags: zero, sign, overflow, carry
The arithmetic part has two kinds of operations: non-continuous(A+B) and continuous(A+B+C).
The ALU takes only 2 inputs. how am i going to provide three?
Let's take C as Carry; so, with continuous operation I might add a 64 bit number. a little help here would be much appreciated.
I have no idea how to do that.

Now coming to the addition part. It should update all the respected flags. Now, if the sum goes beyond the range, the overflow should be set. Then how am I going to correct my result? Or lets say I am adding (-FFFF-FFFF), So, the result will not fit in the dedicated area.
How am i going to show the result for this such cases.
Please let me know, if the questions are vague.
Thanks in advance.

Re: 16-bit Processor Design in Verilog

tarjina said:

Please let me know, if the questions are vague.
Thanks in advance.

Click to expand...

Yup, your Qs are vague.

Are you sure continuous doesn't just mean an accumulation function, i.e. initialize with A then +B +C +D ....

Or perhaps you mean a full adder implementation (which does have an A, B, and Carry), so for your non-continuous case it would really be (A+B+0).

most ALUs I've seen have a result that is missing the portion that overflows the operation. Also how can you define the values with -FFFF - FFFF? The representation of FFFF is a negative number (-1) in 2s comp. If the number is positive then you can't even represent a negative number in your ALU. So tell us is this 2s complement arithmetic or positive integer only arithmetic?

Re: 16-bit Processor Design in Verilog

I don't think you need to "correct" the result when overflow occurs. Just set the overflow bit and accept the "wrong" value generated by the ALU logic.
Sometimes in signal processing "saturation" is wanted instead. This requires extra logic, and the output should be the highest or lowest possible number, depending on the direction of the overflow.

Re: 16-bit Processor Design in Verilog

Okay, let's try with one by one.
It's 2s complement. Now, for the answer, do I have to correct my result or do I just set the overflow flag?
This whole addition and subtraction with continuous and non-continuous operation is confusing.
I am attaching two figures illustrating the architecture and stating the arithmetic operations.

Architecture:



Arithmetic Operation:



Thanks in advance!

Re: 16-bit Processor Design in Verilog

Don't correct the overflow result.

With "continuous" they mean that the carry bit C is used in the calculation.
It is used for making calculations with numbers that have more bits than the ALU can handle in one step.
The carry bit is the result of the previous operation.

Example, add two numbers with more bits than the ALU:

First add the lower parts with the ADD instruction.
This will generate a value in the carry bit C that we need in the next operation.

Then add the next higher parts with the ADC instruction.
This will use the C value from the previous operation and generate a new C value for possible following operations.
Repeat using the ADC instruction on higher parts until all bits are processed.

In this way, numbers of any size can be added.

All the "continuous" instructions are used in the same way. You first use the non-continuous instruction on the lowest part of the value/values.
You then use the continuous instruction on the next higher part of the value/values and repeat this until all bits are processed.

In "A+B+C", C is only one bit. To do such calculations you need a "full adder".

Re: 16-bit Processor Design in Verilog

Wow!!!
Cleared a lot of things!! thanks a lot.
Just one more question:
to check whether my operand size is more than ALU, do I have to perform any checking??

Re: 16-bit Processor Design in Verilog

tarjina said:

Just one more question:
to check whether my operand size is more than ALU, do I have to perform any checking??

Click to expand...

No, that is a software problem. The hardware can't know the "real" operand sizes.