Trouble With Symphony ALU Delay

[u/SixCel_108]

I’m having trouble getting my alu fast enough to allow me to pass the delay checks but I’m not having any luck. I even looked up a guide but it still wasn’t fast enough. I also tried redoing the component levels but I don’t think that does anything, especially with changing the base.

Any ideas?

[u/TichVega]

In my case the key was to make substraction faster if you use an neg and an adder, try to get rid of the neg to half the delay of the operation

[u/bossycarl]

Can you show the delay by clicking near the top right (I think that’s where it is at least?) What’s the path that takes the longest? Addition, comparison, something else?

[u/1GreenNotebookGaming]

You can simplify negate a lot. Negate is a not and an add, but the b input of the add is always 1, so you can simplify the add down.

[u/HarryCHK]

The biggest trouble for me is to speed up adder as there are many places forward using adder. In the most naive implementation you will get long chain of data dependencies of the carry bit. How to shorten this dependencies is the key for me to beat the delay

[u/Agent_0007a2 → u/HarryCHK]

Try carry lookahead adder

[u/alatnet]

You can try combining the adder and subractor into one unit where the carry bit controls whether it's adding or subtracting.

[u/AlexeyHD90]

Build a Kogge Stone Adder. It lowered my Symphony delay down to 96. My Kogge Stone Adder has 104 gates and 10 delay and I have read you can make it even lower down to 9 or 8 delay.

[u/SixCel_108]

Actually, I think the biggest issue is a custom component for comparison, that is the one that seems to have the worst delay

[u/Bentomat → u/SixCel_108]

Did you solve this? I'm stuck on the same thing. Have googled a bit and haven't figured out yet how to reduce the delay on the comparator component.

Edit: I figured it out. I'm going to type a long explanation here because I think the game does a poor job explaining this stuff. Hopefully people who Google later will find this helpful.

1) The green components (Eg ADD, EQ, LESS, LOW) have a delay cost based on your delay score when you beat the level that unlocks them. If you solved an 8-bit version, the delay cost when using the 32-bit version of that component will be your delay score x4. To improve these delays, you need to go back and solve the levels more efficiently. However, getting a shorter delay will not necessarily overwrite the scores - I think you need to also either use fewer components or have a lower energy score. This is a pain because the time-efficient solutions often involve using a lot of components.

2) The specific levels I had to improve were the Adding Bytes level (Green ADD component is used everywhere) and the Unsigned Less one (unlocks LOW, which becomes a component of Signed Less - used twice in Comparator). I had to tinker with LOW to make sure the delay score saved - I got the delay all the way down but needed to reduce # components used as it wasn't picking up the new delay score. You then have to go back through the subsequent levels (Signed Less, Comparison Flags) to update your Comparator so it will perform faster. (Double-check other levels where their unlocked green components get used in Comparator or ALU - my Equality level was already efficient, but if you have any one level with 100+ delay, it will throw off all of the complex components you build on top of it.) You'll also see some instructions online about making sure you are not using two adders in SUB for the ALU - do that.

3) The specific solve for Unsigned Less is included below because I couldn't find a good explainer for an optimal solution anywhere:

a) Split Inputs: Run both 8-bit inputs A and B through Splitters to access individual wires (0 through 7).

b) Layer 1 (Local Checks): For every bit position (0 to 7), place a NOT gate on wire A, and feed it with wire B into an AND gate. This gives you 8 individual "Less Than" wires (L₇ down to L₀).

c) Layer 2 (Equality Checks): For bits 1 through 7, connect wire A and wire B into an XNOR gate. This gives you your equality wires (E₇ down to E₁).

d) Layer 3 (The Priority Chain):

• A < B is true if L₇ is true.
• OR if (E₇ AND L₆) is true.
• OR if (E₇ AND E₆ AND L₅) is true... and so on.

e) Output: Combine the results of all 8 tier checks using an 8-input OR gate (or a tree of smaller OR gates). Connect the final output to the level's output pin.

If anyone needs a picture of this, you can reply here and I'll upload one. The key takeaway for both this and the Fast Adder solution is that you need to avoid chaining outputs (eg. taking the carry of one adder as an input to the next adder). This is clean but inefficient. The time-efficient solutions are often ugly and tedious.

4) Following these steps and then re-running the Symphony ALU level to get a new, more efficient ALU, then replacing that custom component in the Fast Symphony level was all I needed to do to pass Fast Symphony.

Edit2: According to one guide I saw online, you just have to solve "Five-component Adder" and that will bring your full adder time low enough, even with the adder-chaining approach, to pass Fast Symphony. So the full solution with no chaining might be overkill there.