Okay, I only see and and or gates in my diagram. I just realized that all of you may just be idiots.

Or perhaps you don’t even know the logic gate symbols. Perhaps this will help.

 

Or perhaps you don’t even know the logic gate symbols. Perhaps this will help.

In fairness, the diagram was so sloppy that it takes a bit of effort to spot that there are XOR gates there. That's one of the drawbacks of producing sloppy work -- it makes it hard even for the person that did it to correctly read it later, especially if any amount of time has gone by.

Ask me how I know.

 

Certainly creating a "Truth Table" would be a simpler and easier start for a design of the adder function, as well as others.

 

Certainly creating a "Truth Table" would be a simpler and easier start for a design of the adder function, as well as others.

The first step is to clearly define the problem and describe the approach to solving it. It's hard to create a truth table until there is a clear understanding of what the logic it represents is supposed to accomplish.

 

I consider the description "Four Bit Adder" to be a fairly detailed description. All that is missing is to say if it is straight hex code., or BCD.

 

Specification of a 4-bit binary adder is straight forward.
There are two 4-bit inputs (256 possible combinations) giving a 6-bit output.
I can implement this with fast 256-byte ROM.
Can we use this commercially?

In fact, I can better this. I can do 4-bit add, subtract, multiply, divide with one 1k-byte ROM.

 

A straight binary (HEX) adder is different from a BCD 4 bit adder.The carry part is different.

 

I consider the description "Four Bit Adder" to be a fairly detailed description. All that is missing is to say if it is straight hex code., or BCD.

There's actually quite a bit missing from that description since functionality isn't everything. Notice that the entire thread isn't about implementing a circuit that merely adds two four-bit values together, but rather about one that was claimed to perform it sufficiently "better" than the alternatives as to potentially make it commercially viable. If the description "Four Bit Adder" is all that is needed, then every implementation that provides that functionality must be considered equivalent. Yet there is a reason why the world doesn't just use simple ripple-carry adders for everything, nor does it just use a ROM-based lookup table. These represent the extremes of the speed-size tradeoff space, but most adders are somewhere in the middle because most applications can't tolerate the downside of either extreme.

So if your goal is to design a "better" four-bit adder, you need to first determine what the metric is by which "better" is measured. After that, you need to consider ways to achieve that betterness. In the case of a carry-lookahead adder, the basic idea is to quickly determine if each bit position will either generate a carry or propagate a carry from the next lower bit. THAT is the logic that you need to prepare your truth tables for. But it's even more involved than that, since there are several different strategies for implementing the fast carry functionality, and each approach results in its own set of truth tables.

 

Specification of a 4-bit binary adder is straight forward.

Specification of the functionality is straight forward, but functionality isn't everything. How fast does it have to be? How much space is it allowed to occupy?

Just throwing in those two real-world constraints that virtually every commercial adder implementation has to satisfy often considerably complicates the design.

There are two 4-bit inputs (256 possible combinations) giving a 6-bit output.

Huh?

So your adder isn't going to support a carry-in? That's highly restrictive.

What are the six bits of output? Two 4-bit numbers can only sum to a five bit value (even with a carry in).

I can implement this with fast 256-byte ROM.
Can we use this commercially?

In fact, I can better this. I can do 4-bit add, subtract, multiply, divide with one 1k-byte ROM.

And how much is that ROM-based implementation going to cost?

Are you going to be able to scale it to an eight-bit adder economically?

Will you be able to use such an adder in an 8-bit microcontroller that you need to make a profit on at a price point of 1.5 cents each?

 

@WBahn

I wonder if I can get any money for this circuit design.

We were discussing a 4-bit adder.
My answer in post #2 was no.
So anything after that is purely hypothetical. Don't sweat over it.

 

@WBahn

We were discussing a 4-bit adder.
My answer in post #2 was no.
So anything after that is purely hypothetical. Don't sweat over it.

So... just because you say, "no," that means that there is no need to even try to stay in the ballpark of context of the TS's thread?

Just for clarification, is that the case any time after anyone says, "no," in a thread? Or just in post #2 of a thread? Or is it just if you say it?

 

I wonder if I can get any money for this circuit design.

Nobody here's going to give you any money.

 

Nobody here's going to give you any money.

Not when we can buy a 74HC283 for 50p.

 

Who would pay for a circuit that was in a textbook in 1972???