Forums - Open Redstone Engineers - Concepts

FREE COMP ARCH BOOK!

Thu, 28 Jun 2018 22:33:14 +0000

Okay so I have been often requested to link people for a university book on Computer Architecture so to be a good soul I will: https://www.amazon.com/Computer-Organization-Design-MIPS-Fifth/dp/0124077269/ref=sr_1_1?ie=UTF8&qid=1529277209&sr=8-1&keywords=computer+organization+and+microprocessor+design

its pretty cheap....

But I have something thats free: http://submit4m.nl/bestanden/jeroen/patterson_book.pdf

This is an older version of that amazon book and if you skip to chapter 6 (goes over pipelining in 10 sections about 10 pages each)you should be set!

Edit**
Here is another link, its the newest version on github: https://github.com/hamadkh/MIPS-iVerilog/blob/master/Morgan.Kaufmann.Computer.Organization.And.Design.5th.Edition.Oct.2013.ISBN.0124077269.pdf

CPU Architecture slides

Fri, 01 Dec 2017 22:25:22 +0000

I had received requests for these so I hope you like them!
Here is where you can download OR view the folder containing the files!

hope this was useful

Logic gate formulas

Sat, 01 Jul 2017 23:27:12 +0000

Me and Data are working on a hex ALU, i.e. inputs have 16 states, and I devised a common formula for make logic gates with n input states. Sorry if this post doesn't go into much detail, I will update it with a much more in-depth explanation.

OR gate: max(x,y)
AND gate min(x,y)

Now the XOR gate is a little tricky but I've found a formula: |x-y|. Now, when doing hex subtraction, compactors have the function max(0, back - side), only using one side. You can using max(x - y, y - x) when doing a hex XOR. Simply put, and XOR gate is the absolute difference between the inputs. The max function is easier, just combine all lines, highest signal strength wins. For the min function, first do invert on each input, i.e. 15-x, then combine (max) each line, then hex invert back again. This is actually the structure of a common and gate, just now using hex NOTs instead of binary NOTs. Please comment any questions!

Cordic - algorithm

Sat, 29 Aug 2015 15:01:38 +0000

Hey guys!
Some of you asked me a lot about the implementation of the Cordic - algorithm built by robinch and me, which dominates my plot at the moment.
To answer all this questions i thought of doing a brief explanation of the algorithm and here it is.

In this paper I describe the approach of the algorithm, the computation of the trigonometric functions and some implementation possibilites.

I do NOT explain the whole algorithm in this paper, because time and stuff. To compute the hyperbolic functions the hardware does not change drastically.

If there are questions don't hesitate to ask them.

Feel free to take a look into it. <--------

Please leave feedback.

Cordic - algorithm.pdf (Size: 234.19 KB / Downloads: 87)

Pipelining basics

Thu, 12 Mar 2015 21:07:38 +0000

I found a nice page on pipelining :3

http://www.gamedev.net/page/resources/_/technical/general-programming/a-journey-through-the-cpu-pipeline-r3115

First Quantum Signal and Comparator Behavior Analytics

Sat, 07 Mar 2015 03:53:35 +0000

Recently i've been finding more and more discrepencies between comparators in 1.7.10 and 1.8.3. Most of these differences are ONLY in Direction, Configuration (same parts and connections) or both.

So I will no longer be building in 1.7 for fear of having to make things twice but same only different...

there is a rabbit hole in 1.8, and i'm afraid i've fallen in. I've started to document my findings in a series I'm calling Comparator Behavior Analytics (CBA). The laws for creating the quantum signal will be called Apo's Law. Just a head's up, it won't add up, but it is like a 1 inch punch breaking a boulder. It may be hard to automate until i get better at manipulating timing at a game tick level. Nothing is seen as impossible through these eyes.

Quantum Signal (works in 1.7 also)
http://imgur.com/a/Rd7lY

1 tick Comparator Do's and Don'ts in 1.8 (CBA part 1)
http://imgur.com/a/Z9a70

In 1.7 1 tick comparators don't stop 1 before the end when chained, and from what i've seen were easier to produce.

In 1.8 1 tick comparators have transfer rules different than the 1.5 tick. slight game tick differences between comparators and repeaters can cause adverse effects to the game ticks without any visual change to the signal. In specific wiring such as chaining comparators the game tick can be slowed to misalign 2 synced signals.

Here was the start of my 1 tick endevor, the circuit that broke my logic, it only works with those 3 comparators chained. other wire setups with same values just output a 2 tick signal of 3 but this outputs a 1 tick value. And when the 1 value is replaced with 15, this circuit will not output, but now other wiring will now output 1 tick! I believe even pulsers used affect the signal at a game tick level.

^1st rule of Apo's law, there are no laws.

^outputs a 2 tick value of 3, only slight differences in setup, no added ticks.

^outputs 1 tick when the 1 is upped to 15

Architecture Comparison,questions. ..

Thu, 20 Nov 2014 13:31:30 +0000

So I have been thinking about doing a write up of overview of different architectures like, SuperScalar OOOexe, Basic MIPS, VLIW, Belt, basic SIMD and maybe some MIMD and graphical stuff GPU stuff,
This would include technical references, a bunch of books and papers for you to read and a compare and contrast writwrite by me with assistance from friends, on when each architecture is good to use and when it's bad..
This will be a multipage write up, and will take a while,
so this post is to see,,, who wants me to do this? Who thinks it's a good idea? Who just doesn't give 2 shits? Lol

How to calculate the Sine ?

Mon, 06 Oct 2014 23:03:52 +0000

Calculate the sine of an angle

(in combinatorial)

Hello, it's Link !

Today (or now...), I'm going to explain you how to calculate a sine. There is algorithme for this (like CORDIC), but I will show you how to do this in combinational.

Important to know :

We give a angle, and the system return a new value : The sine. But there some trouble you have to know :

An angle can be given in radian or in degree,
The sine is always between -1 and 1. And, the floating number are very difficult to work with.
The precision of the system is very important. I'll show you my result below

Also in this condition, I will said those things for making the task easier for us :

The input value is between 0 and 90 (corresponding to the value in degrees)
For the sign, us an additional circuit
For deleting the float problem, the sine value will be given between 0 and 255 (8 bits). You have only to divide the given sine value by 255 and then you will have the true value

All right ? Then fallow me into the darkness world without any poney of :

Mathematics

Chapter 1 : Taylor Series

for further information, look at the link.
See : Sine Series

With this series we have :

Code:
'      1     3

x - ( --- * x  )  // with x in Radian !!!!

       6

I voluntary stop at the 3rd power. Because, after, we have term in X^5 ... See what the mess it would be ^^.

Chapter 2 : Magic formula

I skip the formula transformation, see official French topic for further precision

So, this is the final formula

And what this function looks like ? Let see :

What is the Floor ?

Floor() means that we take the integer portion of a division. Example: Floor(1,8) = 1 !

I choose C=76 (the best curve), and we have for precision something like that :

The yellow curve represents the error due to the 8 bits resolution. See that Sin(87)=255... So not so good.

And Minecraft with all this S*** ?

A little example :

A quick view

down : the input (here = 32), and lamp up : the result in 8 bits (here = 134) !
(and if you do ArcSin(134 / 255) you will found : 31,7 ° ! AMAZING)

You just have to divide the given value by 255 to have the truth sinus !

Analog to Binary Conversion

Wed, 21 May 2014 20:08:04 +0000

We all know how to convert binary to analog. It is simply subtracting/adding the values 8,4,2, and 1 to a line of comparators.

When it comes to converting analog to binary, it is a bit more difficult.

There are two kinds of conversion that I know of:
1. get a single output from the analog and then decode it from there.
or
2. Logically process the analog signal.

I'll try to go over both.

Table Decoder
This design is big, but is easy to understand and also easy to sync the outputs.

First you need some kind of analog selector. This takes the analog signal and gives a single output among 15 lines.

Second you need to hook up a decoder to the selector. depending on the output of the selector, the decoder will display the correct binary value which you have laid out(normally with torches).

Logic Decoder
This design involves using the compare and subtract functions of the comparator to get the desired result. It can be confusing but once you get it, it makes a lot of sense.

There are 2 lines of comparators in this: a logic line, and a bypass line.
First, you take the incoming signal and compare it to a value of 8. If its less than 8, the signal will be ignored and pass through the bypass comparator. If its 8 or more, it will pass through that comparator and make some things happen. It disables the bypass, displays a 1 in the 8s place, and sends the signal on through a comparator to subtract 8.

The logic line is then reconnected with the bypass line and the process is repeated with values 4 and 2.

After all 3 processes, the only possible leftover is 1, so you don't need to have a process for that. Just combine the lines after the 2 process , put a repeater on it, and there's your 1s place.

Here's a block diagram I drew up in autocad for reference.

You can also subtract from the bypass instead of having a separate comparator to subtract from.

I hope this is informative. I know analog isn't very popular here but its my favorite subject in redstone.

ACD (Analog Coded Decimal)

Fri, 25 Apr 2014 23:32:22 +0000

Analog Coded Decimal is a version of BCD I created because it is compact and can be converted from and to BCD with ease. It can also transmit Decimal.

To convert from ACD to BCD is as simple a signal strength to 4 bit binary decoder.

But it convert to ACD to BCD is a binary to signal strength converter.

Now for ACD to Binary is a bit of a challenge because you must decode each line to is binary equivalent then add them all which I figure for a system that can count to 99 to be maybe 6 ticks.

For Binary to ACD you need ether a loop that runs till its done or many subtractors.

Because to get a number like 25 to be ACD from Binary you need to first subtract 20 but you ask how do we know what to subtract?

Its simply a matter of starting at the highest you number in binary can be in tens then subtract if it is negative don't then go down by 10 and try again. If it is not negative disable all the other out puts.

Then repeat for the ones.

This has been a documentation by Chibill. Thank you for reading.

More info on speeds and designs as I test and try them.

Two's Complement: Conversion, Arithmetic and more

Tue, 31 Dec 2013 01:20:48 +0000

So recently for the line algorithms in my upcoming GPU, I found myself requiring a two's complement adder. I sort of skated around building it because it seemed foreign and strange to me, and many of the tutorials I found gave me only a piece of the puzzle. Today I'd like to give you the whole picture all at once, in understandable terms for redstone. I'm still learning more advanced signed operations such as optimized comparison, subtraction, and mult/div, so this thread will be updated with tutorials as I myself learn the concepts.

What is two's complement?

You've heard the term time and time again, you know it makes a number negative, but what really is two's complement? Two's complement is essentially an intuitive representation of a negative binary number with altered bits and a sign. Many devices, such as subtractors, natively return outputs in two's complement, which is why it is so widely used.

Conversions

Note: Numbers' sign bits will be shown on every binary number I represent, as the first bit. It will be in italics. It's good to know that 0=positive and 1=negative.

Let's say we have the positive binary number 01010, and we want to negate it using the simple system of two's complement. This is a two-step process that you've probably heard all the time when making binary subtractors, which are actually just adding the two's complement negative. (Fun fact! )

Well first let's figure out what 01010 is in binary, 8+2=10 decimal, if you don't know binary then that's a definite prerequisite to two's complement. We've got a bunch of tutorials laying around the forums.

Okay, so now we have our 01010. Time for the process! It's the two-step subtractor process:

1. Invert all the bits.
2. Add 1.
3. Profit!

So let's do this with our 10 decimal. We start with 01010, inverting all bits gives us 10101. (Yes, we also invert the sign bit! Which makes sense, since we're just making the number negative.) Now, we can add 1:

10101
+0001
-------------
10110

And this answer is indeed 01010 in two's complement! You can use this process to convert negative to positive as well.

Addition

HEY! LISTEN! HEY!: You must must must know binary addition for this. I'm not going to explain the binary addition process for this, only how it applies to two's complement.

Alright, so at first the concept of two's complement addition is a lot like regular binary addition that just includes the signs, with the COUT truncated. There's some extra crap that can happen, but if I could I would make all adders two's complement, because it completely eliminates the need to make seperate adders and subtractors... they're the same!

So let's start by saying we want to add 7+(-3). Obviously, this simplifies to 7-3, so in the addition section we're already subtracting! Well, 7 in binary is 0111 and 3 is 0011.

But we need to convert 3 to two's complement! Let's do that!

0011 --> 1100 --> 1101! That's just a simple conversion, obviously you should read conversions before this.

Okay, so now let's add!

    0111
  +1101
  10100

Wait... what? We just got 20... what just happened? Well, when adding two's complement we get this extra carry on the end that nobody cares about. We can simply get rid of the COUT 1 and get 0100. And that's positive 4, which is indeed 7-3. You can do this with most numbers, and you can literally implement this in redstone with little more than a simple adder. Just remember to use the signs in the addition and to discard the final COUT!

But are we done? Well, sadly... no. ;-; We have a slight problem which I'll now show you. Let's do 0111+0101.

    0111
  +0101
01100

We take off the extra COUT and get 1100... and that's 12 in binary, right? But wait! Why is that one there in our sign spot! This is certainly not a negative number!

And welcome to a very annoying part of two's complement arithmetic: sign extension. Basically, the idea is that if we add another extra bit to our number before the sign, the sign will stay in the sign spot and other things will stay out of it. Sign extension in two's complement is actually really easy: just copy the sign bit for all your extras. For instance:

+9: 01001 = 001001
In this example, we add an extra 0 (which is our sign).

-9: 11001 = 111001
In this example, we add an extra 1 (which is our sign).

Alright, so let's do our sign extension and try our problem again.

    00111
  +00101
    01100

And look at that, folks! Our extra 1 is now in a normal bit. Thus we have just created a perfect algorithm for redstone two's complement adders. To sum it up:

A. Have two extra bits to the left both connected to the sign

B. Ignore the final COUT

Easy as they come! Because this is so simple, once again I'd like to recommend two's complement adders to be used everywhere due to their versatility. But that's just my thought.

Sign Extension Intuition

Because I was having so much fun writing tutorial, I decided to do a quick intuition on why the whole sign extension idea works. To recap, sign extension in two's complement is just taking the sign and copying it over however many times. For instance:

0101 = 000...0101

1101 = 111...1101

Well the first example is obvious, you can stick as many 0s at the front of a regular binary number as you want and it won't change. That's the easy part. But what about the second example? Well, we know that two's complement is pretty much an inverted form of a regular binary number, so if we convert that negative back to a positive all those extra 1s will become 0s when we invert.

I don't know, just kinda felt like putting that in there.

Subtraction

Well, if we can already add signed numbers, then we can add positive to negative. This gives us subtraction, so there's no need for a seperate two's complement subtraction.

More to come in the near future!

Principles of Analog (signal strength) Arithmetic

Sun, 22 Dec 2013 10:23:40 +0000

Note: This is a re-post of a topic of mine that I rescued from the old RDF forums.

The ability to subtract the strength of one signal from another using a Comparator opens up the possibility of doing arithmetic and numerical manipulations by using the charge strength to encode a numerical value. This, most of us know. Knowing the possibility exists however is rather different from understanding how to manipulate the mechanics to create Arithmetic Devices.

With the Comparator, we have a subtractor, but one of limited utility. It's chief weakness is that it cannot produce negative numbers. However, via clever manipulation and special configurations, it is possible to do more than just subtract. The project I am working on right now is building a 4-wide analog adder, and in the process of design and refinement, I have made much use of the following arithmetic operations:

-Inversion
To perform this operation, you subtract the current signal value "A" from 15.
15 - A = ~A
You might wonder how you can perform inversion on positive non-binary numbers. The answer is that you technically can't (you're taking the complement, but it doesn't matter because it's functionally equivalent to the uses of Inversion in Binary Arithmetic.

Here is the table of complements: (can you decipher the pattern?)
0<->15
1<->14
2<->13
3<->12
4<->11
5<->10
6<->9
7<->8

It is interesting to note that if you look at the Binary representation of each of the Complement pairs, they are in fact the bitwise inverses of each other; Six (0110) and Nine (1001), for example. This lends further justification to the functional equivalence of Inversion and Complement. (It is important to note though that this equivalence holds even for numerical bases that are not readily converted into Binary, such as Decimal.)

The important principle to keep in mind for conceptualizing Inversion/Complement is: Big becomes Small, Small becomes Big. Seems trivial, but it's vital to allow you to keep track of what's going on in a circuit and why.

-Negation
Inverting a number is mathematically the same as flipping the sign and subtracting 1.
~B = -B -1
-B = ~B +1

These two equivalent equations are the mathematical basis that allows you to use Inversion to create Negative values (or make negative ones positive). In many cases their utility will be merely conceptual, since Comparators cannot yield negative numbers.

-Addition
Converting a Subtractor to an Adder requires Negating the "subtractant" input. Negating a single input is done in ALUs all the time to turn an Adder into a Subtractor. Fortunately, two negations cancel out, so the same tweaks that convert A+B into A-B can be used to turn A-B into A+B.
There are two ways of doing this for adders:
A - B = A + ~B +1 (this isn't feasible since it requires addition in the first place which we don't have yet.)
~(~A + B) = A - B (This is the one we'll use, when reconfigured for addition)

You can indirectly Negate the B input by Inverting A and then Inverting the Output. When applied to a subtraction operation (A-B) you get:
~(~A - B) = A + B

Structurally, you have a Subtractor that lies between two Inverters. I like to think of the 'between-two-Inverters' as "The Negative Zone" where any operation you perform has the opposite of it's normal effect. Thus, performing Subtraction while in the "Negative Zone" results in addition. Let's see it in action with an example:

Suppose we want to do 8+5. Let 8 be 'A' and 5 be 'B' (it works either way).
~8 = 7
7 - 5 = 2
~2 = 13

Thus, 8 + 5 = 13. Crazy, huh?

Let's try another example: 12 + 9!
~12 = 3
3 - 9 = 0 Uh-oh! Comparators can't give negative numbers
~0 = 15 Hmm...not looking good
Thus 12 + 9 = 15. This is not correct. This is far from correct. This is bad, since it's not uncommon when adding numbers that the result will exceed 15. How do we deal with this?

-Overflow Sum
You can't have negative signal strength values, and you can't have a signal strength that exceeds 15. What do you do? You use a second adder designed to handle exactly these cases! One that can compute sums for values greater than 15 (and ONLY for greater than 15).

The problem was that we were getting a negative number from subtraction, but as I'm sure you know, if you swap the values in subtraction, the answer is the negative of what it was before.

Instead of doing (~A - B), we will do (B - ~A). (To swap the inputs on a Comparator, all you have to do is rotate it 90 degrees).

Let's see how this works with that 12+9 example again:

~12 = 3 (~A)
9 - 3 = 6 (B - ~A)
...And then we keep the 6. We're done here. (B - ~A) is actually the value we want out of this. Why? Because MATH!!!

Remember the definition of Inversion in the first section?
~A = 15 - A
Substitute (15-A) for (~A)

(B - ~A)
(B -(15-A)) [substitute]
(B - 15 + A) [distribute the negative]
(A + B - 15) [re-arrange to look pretty]

So...that answer of 6? That's 12 + 9 - 15. The -15 is vitally important here, since it reduces an answer of 21 (out of our range) to an answer of 6 (inside our range). More importantly still, it's just 1 larger than the answer we need for the Sum when the addition produces a Carry.

We're working with base16 here, so whenever you get a number like 21, which cannot fit within the 0-15 range, you have to split it into a 16 and a 5. The 16 gets carried over the the next digit where it acts as a +1, and the 5 remains as the Sum for that digit.

This means that the value for the Sum when A+B exceeds 15 is:
(A + B -16)
This is 1 less than the result of (B-~A), but that's easy enough to fix since subtracting 1 is ridicuously easy to do in Signal-Strength manipulation: Just make the wire 1 longer.

This will be referred to as the "Modified Overflow Sum", for reasons which will become clear in a minute. Unmodified, the Overflow Sum displays values 1-15. Modified, it shows values 0-14. This is not a problem, since the largest value a half-adder will encounter is 30 from 15+15, whose proper Sum is (30-16 =?) 14.

-Carrying
(No algebra in this section, just design principles)
In order to make a useful adding machine, you have to be able to send a "Carry" signal to the next digit. Once you can generate a proper Sum and a Carry, then you have a Half Adder.

Quite fortuitously, the unmodified Overflow Sum is our "Carry" signal. It only ever yields a signal if the total is greater than 15...which is exactly the situation when you have to carry. How convenient!

The Carry signal in this sort of adder though has to do more than just communicate with the next digit though. Although we now have the ability to get the correct Sum for any set of inputs...we still have two different Sum outputs: the "Normal" and "Overflow" Sums. This can't do!

The Normal Sum should only give its output when the value is 15 or less. If it is more than 15, then it needs to kindly STFU, since it's stuck blaring a full-strength signal as it's output. We can't use that! In yet another piece of convenience, whenever the Normal Sum becomes irrelevant...that's when you have to Carry! This means that you can use the Carry Signal to disable the Normal Sum whenever A+B>15. (How you go about doing this is the personal choice of the engineer)

Once you have the Normal-Sum properly controlled, you can then just join the Normal and and Overflow sums together in one SUM wire for the output. The Overflow won't cause any problems, since it just outputs a 0 whenever the value is 15 or less.

Once you have all these things in place, then you've got yourself a Half Adder, my friend!

You should be able to figure out how to go and make a Full-Adder out of Half-Adders. I'm not going to explain that here, since this is kinda long already, and all I was trying to do was explain how you manipulate "Analog" signals to do Addition.

Conclusion
So that's my attempt so far at an algebraic explanation of how Analog Adders can be made from Subtractors (without the use of negative numbers).

And if I stop being a lazy bum, I might even include pictures at some point!
Note: 11 months later and I am still a lazy bum.

PLA, KSA CSA, and PLA losgism files

Fri, 20 Dec 2013 14:51:17 +0000

I've made schematics of these adders in losigm;

LFA: Ladner Fisher Adder
KSA: Kogge Stone Adder
CSA: Carry Save Adder
PLA: Proper Look Ahead

I would like to point out that the CSA and the KSA are both completely optional, and would really only recommend LFA and PLA. Because i like knowing how every type of adder works, i also made these other 2.

Anyhow, you can find the schematics here.

Good luck!

Carry Look-Everywhere Addition [Text + Images] [My first tutorial]

Wed, 04 Dec 2013 00:12:57 +0000

Note: This assumes you know binary logic gates and Ripple-Carry addition
------------------------------------------------------------------------
Carry Look-Everywhere Addition (CLE) is a Minecraft optimized carry-look ahead adder. But what is CLA (Carry Look-Ahead)?
------------------------------------------------------------------------
CLA is an adder that calculates carry at the same time as the sum, unlike RCA, where it is sum-carry rippling through the adders.
The first component of CLA is the half-adder. This is just an XOR and AND gate on the same two input lines. We'll call the XOR's output Pn and the AND's output Gn where n is the number of the half-adder, starting at 0.
So, we have the first part of the adder. Now how can we calculate sums with CLA using them?
Well, lets start at the carry calculation. For the first bit, bit 0 (in computers you start counting at 0, not 1), the only possible way to get a carry input is through Cin. So, the sum for the first bit (S0) is:

Code:
S0 = P0 xor Cin

Remember, P0 is the output of the XOR gate of the half-adder. So, basically it is:

Code:
s0 = (A0 XOR B0) xor Cin

the same as RCA. Simple right?
In fact, the sum of bit 'n' is:

Code:
Sn = Pn xor C(n-1)

where C(n-1) is the carry for the bit before bit 'n.' (For the first bit, C(n-1) is just Cin)
So far, this is the same as RCA. What's the difference? The difference is how C, the carry is calculated. In RCA you need to calculate the bit before to get the carry value, but in CLA you can calculate the value of all carries at the same time. Using equations (where the terms are next to each other is AND, a + is OR) you can get C0:

Code:
C0 = P0Cin + G0

How do you arrive here? Well for bit 0, when can you generate a carry? When one input is on (P0, xors are only on with one input, remember?) AND when it receives a carry in signal (which for bit 0 is just Cin) OR when both inputs are on (When both inputs are on, the carry-in doesn't effect the carry calculation. Remember G0 is the AND of both inputs).
OK, so for CLA carry calculations you OR together all possible combinations. Sounds hard to keep track of it all? Well, here is the equation for bit 1...

Code:
C1 = P1P0Cin + P1G0 + G1

Looking familiar? Yes, the carry calculations for bit 1 is all the terms from the carry calculation with an extra AND P1 added, OR'd with a G1. Why is this? Think about it. The terms for C0 tell you when you get a carry from bit 0. So, how do you calculate a carry from a carry-in? You AND it with the P output. So the "P1P0Cin + P1G0" is just AND'ing the possible carry-ins and adding a + 'Gn'. So, the carry calculation for any bit n can be found by taking the calculation for bit n-1, AND'ing a 'Pn' with the terms, and adding a '+ Gn', all the way to bit 0, where again,

Code:
C0 = P0Cin + G0

Why is this better than RCA? Well, for calculating carries you do NOT have to wait for the sum of the last bit to finish, only the P's, which, if you built your half-adders correctly, are sync'ed. This allows all the sums to be calculated faster, especially the ones near the end of the adder, where in RCA they would have to wait for the signal to 'ripple' to them.
----------------------------------------------------------------------
So, that is CLA. But what is CLE and why is it MC optimized? CLE is the exact same as in it follows the same logic, but different in that carries use the same line. Let me explain. In CLA, even though bit 0 and bit 1 both use the term 'Cin' to calculate their carries, there are different lines from Cin to the bits. In CLE, they use the same line. In this example, bit 0 would have P0Cin going into its carry line, but, with an instant diode or something of the sort. So then, we have a line for P0Cin. We add another instant diode (like glowstone) and wire it to bit 1. Here, we and P1 with P0Cin to git P1P0Cin. Because of the instant diode, it does not interfere with the calculations for bit 0's carry, and because of the instant diode from P0Cin to the carry line of bit 0, the rest of the possible carries does not interfere with P0Cin. This continues for the rest of the adder. Every new bit, one new term that can carry is added, but, we do the same for these. A practical way to do this is to Invert Cin, Invert P0, then use that line as the place for the instant diode to branch off. Then on bit 1, we connect an inverted P1 to the line and instant diode off to bit 2, and so on. Then, on each bit, we invert this signal to input to the carry line. This works on the idea that AND gates are just inverters, ORs, and another inverter. On the first bit, we invert the two inputs on the AND then or them. Next, we invert it to get P0 AND Cin. However, because we carry the inverted line, when we combine with P1 and invert for bit 1's carry line, we are basically making a big AND gate of P1, P0 and Cin that does not interfere with the first AND, and so on.
----------------------------------------------------------------------
Here is an example of the carries from Newomaster's CLE:
The carry lines
The inverted Cin, the only thing needed to calculate carry for bit 0
Using half-slab insta diodes to carry the inverted Cin up to other carry lines
The gold block substitutes for P0. There is a torch on the other side to invert it and add it to the slab line.
We do the same for the rest of the bits.
Now, for the G0, which goes to the line for bit 1. This is the start, so the torch represents an inverted G0 going in.
Now we do the slab tower and torches. Wait for what we do with these.
Finish this up for the rest of the terms....
Here we connect the torches in the horizontals. This is because the horizontals are all the same 'Pn" term.
This example is 4 bits, the 5th carry line is the Cout of the adder. We would XOR each of these lines with their respective P to get the sum.

Line Drawing

Sun, 01 Dec 2013 18:21:15 +0000