Snuggle Adder V3

[Konstacon]

Hello there! I have recently been working on Insta-carry adders (Kudos to tomys for teaching me how they work) and I suddenly came across a slow 7 tick design. That was V1, which I never posted. The XNOR's in that adder were 4 and 3 ticks, and an additional 1 tick from a flash. Then, after messing around with it, I turned it into a 5 tick adder. 5 tick was much faster, but I knew I had to improve. Finally, I came up with this 4 tick insta-carry adder. It added amazingly fast, but it did stagger. The adder is extremely easy to make into ALU functions.

Size:
16 Long
2 Wide (With 2 block of additional slanting)
7 High
Speed:
4 ticks without flashes
Carry Speed:
0 ticks (Insta-carry)

[CMOSprinkles]

Can you post a picture?

[EDevil]

^ indeed

btw Snug, you do know that there are plenty of awesome designs that operate at 3 ticks, and kinda "buggy" designs that can preform addition at 2 ticks? Just saying...

[Konstacon]

^ indeed

btw Snug, you do know that there are plenty of awesome designs that operate at 3 ticks, and kinda "buggy" designs that can preform addition at 2 ticks? Just saying...

I know, but I thought I could make one, so this is what i came up with. If you don't like it, don't use it. ;3

[Guy1234567890]

[CMOSprinkles]

Evil, I would love to see a link to an 'awesome' 3 tick 2 wide instant carry adder. I don't think it has been done, especially since the instant carry system takes 2 ticks to reset on the falling edge, which makes them only able to be clocked at 2 ticks slower than the time to calculate the sum or carry. For example, if a regular piston based instant carry adder takes 4 ticks to calculate sum or carry (two 2 tick XOR's for sum and a 2 tick AND plus a 2 tick XOR for carry), it takes two more ticks to change states from carry to sum due to the piston taking two ticks to block the carry. So, it can only be clocked at 6 ticks.

tl;dr: Are you sure those '3 tick instant carry adders' aren't actually 5 ticks?

[CMOSprinkles]

Still waiting for those pictures :3

[Billman555555]

Evil, I would love to see a link to an 'awesome' 3 tick 2 wide instant carry adder. I don't think it has been done, especially since the instant carry system takes 2 ticks to reset on the falling edge, which makes them only able to be clocked at 2 ticks slower than the time to calculate the sum or carry. For example, if a regular piston based instant carry adder takes 4 ticks to calculate sum or carry (two 2 tick XOR's for sum and a 2 tick AND plus a 2 tick XOR for carry), it takes two more ticks to change states from carry to sum due to the piston taking two ticks to block the carry. So, it can only be clocked at 6 ticks.

tl;dr: Are you sure those '3 tick instant carry adders' aren't actually 5 ticks?

Sprinkles you derp.
A piston is 1.5 ticks to retract and extend,
Any who if you want a 3 tick adder Dcentricts has one that
Can be converted from 3.5 ticks to 3 ticks with a different XOR
Gate

[CMOSprinkles]

Yes, but is it instant carry? Also, 0.5 ticks does not make much of a difference, most instant carry adders still become 5+ ticks, with 4.5 being the worst case delay in a truly 3 tick instant carry adder. Which would, by the way, require a 1 tick XOR, so I'd still love to see it. I made one, but repeaters had to be used to extend the signal past 3 bits, so I'd like to see 8 bits calculated in 3 ticks since you say it can be done.

[Billman555555]

Yes, but is it instant carry? Also, 0.5 ticks does not make much of a difference, most instant carry adders still become 5+ ticks, with 4.5 being the worst case delay in a truly 3 tick instant carry adder. Which would, by the way, require a 1 tick XOR, so I'd still love to see it. I made one, but repeaters had to be used to extend the signal past 3 bits, so I'd like to see 8 bits calculated in 3 ticks since you say it can be done.

Ask Dcentricts to look at his adder it can do 4 tick addition of 8 bits.

[CMOSprinkles]

If the first half adder calculates the sum in 2 ticks, then it will be a 5.5 tick adder for the reasons that I described earlier (pistons take 1.5 ticks to retract).

[Chibill]

Proper has a one tick xor.

[CMOSprinkles]

I used Proper's '1 tick XOR' to make a 3 tick adder, but the XOR is actually very flawed. It requires a signal strength of at least 10 on both inputs, meaning that a repeater is necessary to extend the carry past 3 bits.

[Dornier]

Henke and I built a 2 tick (rising edge) adder on RDF a long time ago.
2*10*7.
This is an old image but the design works with the fence gates replaced by pistons.

[CMOSprinkles]

I guess that would be 2 ticks to output on the rising edge. I've seen this adder before, it relies on a '1 tick XNOR' that is actually 1.5 ticks (it relies on the state of 1 piston extending on the falling edge) making it 3 ticks on the falling edge. That is rather impressive still, but does this actually support instant-carry? I remember seeing a version of this adder on MinecraftForum, but it was a regular ripple carry adder.

---

When I finally get the chance to design my own CLE (once my laptop stops overheating, haha), I'll probably use this XNOR. It's 1.5 ticks in the worst case scenario, so that would make for a nice 4 tick CLE.

[Dornier]

It is instacarry of course. 2 ticks (again, rising edge) for 8 bits and +1 tick for every 8 bits. Henke came up with a great way of lengthening the carry line without having to put a gap between the adders every eight bits. I can post a picture if you want.

[redstonewarrior]

Ahh, the old 2 tick adder paradigm. Tis my creation, I should test it for 1.5 worky-ness. (Proof of concept was huge, hilariously.)

[CMOSprinkles]

Wow, now that I think about it, that would make the usual piston XOR 1.5 ticks instead of 2. However, that only makes Jxu's 4 tick instant carry adder into a 3.5 tick (5 on the falling edge) adder because it still takes 2 ticks to output carry from the first half adder. How does yours generate a carry in 1.5 ticks?

---

Oh, and how do you manage the instant carry? If it uses pistons to cut the carry, you have to add 1.5 ticks for that on the falling edge (1.5 ticks to XNOR result, 1.5 ticks to cut carry, and 1.5 ticks to second XNOR result would make it a 4.5 tick adder).

[redstonewarrior]

Rising edge only*. The intention was to use it in heavy math units / have control lines (forced power) if used in any sequential environment.

[CMOSprinkles]

Oh. I guess it's still pretty close to a 4 tick adder, and I'm sure it would be much more compact than a 4 tick CLE using the same XNOR's. Although, 4.5 ticks just isn't the same as 4 ticks... Maybe you can use a 1.5 tick piston AND for the carry somehow, I really wish I could just hop on the server and start playing with that 1.5 tick XNOR... Damn you laptop, y u so hot.

[Thor23]

(1.5 ticks to XNOR result, 1.5 ticks to cut carry, and 1.5 ticks to second XNOR result would make it a 4.5 tick adder).

If this is how you're measuring speed, then the adder I've got is 2.5 ticks - 1.5 for the first XNOR, carry is cut by default(I guess? I'm not entirely sure what you mean), 1 tick for the second XNOR. It's three wide though. But there is this little timing bug I found that makes it two ticks under certain circumstances: a repeater powering a piston will yield an output after 2 ticks instead of 2.5. That would make the first XNOR output after just one tick instead of 1.5. And now I just went and tested it with torches (to check that it was different) and it was the same as with a repeater. But using just redstone would yield an output after 1.5 ticks like expected. Weird :S Still, I guess that that makes pistons functionally one tick then doesn't it?

[CMOSprinkles]

Thor, are you using an instant-carry design? What I was saying before does not apply to ripple-carry, CLA, or CLE adders. Only piston-based instant-carry.

---

Also, you claim that you have a 1.5 and 1 tick XNOR in your adder, but is that rising edge only? If the XNOR's take 1.5 ticks to reset, you have to count that as the speed.

[Thor23]

Yes, it's an instant carry design. I'd tell ya to go see it on my plot on the server if you could.

If I'm not mistaken (I've never payed much attention to rising/falling edge), the first is rising and the second is falling. And does the reset time really matter? I mean, no MC computer can run fast enough for it to be a problem, so do you really need to include it? In any case, adding in reset time would bring it from 2 ticks to 3.

[henke9600]

Ahh, the old 2 tick adder paradigm. Tis my creation, I should test it for 1.5 worky-ness. (Proof of concept was huge, hilariously.)

Yes, we just made it (a lot) more compact And fixed some piston derp problems.

Anyway, this kind of adder has always been "broken". It's 3 ticks because of the short pulse generated when you only power bottom input.

Fixing it would require a new AND

[Billman555555]

How would you add the repeater to extend beyond instant 8 to
1 tick 16 ect.

[CMOSprinkles]

What do you mean short pulse? I didn't see right away that anything was broken or derpy... Also, what kind of AND does it currently use, a regular 3 torch AND? If so, I would like to look into using a 1.5 tick piston AND.

[Billman555555]

How would you add the repeater to extend beyond instant 8 to
1 tick 16 ect.

NVM I got it

[CMOSprinkles]

Guy told me that he made a 4 tick CLE with two 2 tick XNOR's and a regular 1 tick NOR, so I wonder if he could make a 3 tick CLE with these 1.5 tick XNOR's...

[Dornier]

These XNORs are 1 tick on rising edge and 2.5 tick on falling.

The "short pulse" is created if only one of the bottom inputs are powered, due to the fact that pistons update after repeaters. The pulse is not too hard to filter out though. I've used the adder as a 2 tick adder in an ALU without problems.

[CMOSprinkles]

Hm, I really don't like that it takes a whole 5 ticks to output on the falling edge. Although, I guess that's why I like CLE adders; they can be synchronized on all edges.

[Billman555555]

I made me an adder that can do 32 bits in 6 ticks using a modified version
Of this. also benny had this before.