0
\$\begingroup\$

Basically what the title says, I guess I've got some sort of misconception or somthing probably. The ALU can have, say, a ripple carry adder which doesn't produce its entire output all at the same time (it ripples). So how does a computer know when the output is ready? Does it have to do with the clockspeed and propagation delay?

\$\endgroup\$
  • \$\begingroup\$ Given the need for addition in many computer operations, such as computing array element locations in memory, or relative-register addressing, the Clock period is usually somewhat larger than the ADDER propagation delay. \$\endgroup\$ – analogsystemsrf Apr 17 '19 at 1:22
  • \$\begingroup\$ the "computer" does not know ..... the person that designed the cpu knows and has designed the circuitry in a way that allows the output of the ALU to be read at the correct time \$\endgroup\$ – jsotola Apr 17 '19 at 1:30
5
\$\begingroup\$

Let's say that you work out the worst-case propagation delays through the ripple-carry adder and all associated logic as being \$178\:\text{ns}\$ (this includes both subtraction and addition, let's say.) Then you might choose to arrange the minimum clock period to be \$250\:\text{ns}\$ so that you are certain there is enough time. If so, then you might latch the inputs to the ALU on the prior clock period (assuming you can latch both inputs on the same clock, which may not be true) and latch the output of the ALU on the current (following) clock period. That's fine, because you know for sure that there has been enough time for the ALU output to stabilize.

That's not the only way, though. You might have a system which, for other design reasons, has a minimum clock period of \$100\:\text{ns}\$. So, to be safe you arrange things so that you latch the inputs on \$c_0\$ and then only latch the output of the ALU on \$c_3\$ (\$300\:\text{ns}\$ later.) The faster clock may serve other uses well, despite causing the addition/subtraction to take even longer than it might had the minimum clock period been longer. Of course, you could also consider latching the output on \$c_2\$ in this case because \$200\:\text{ns}\$ is longer than the required \$178\:\text{ns}\$.

The above is for clocked CPUs. There are also asynchronous CPUs where the reasoning and methods mentioned above are handled differently. That's a whole different area of research and the answer would be very much different than I gave above. But I don't know much about these, so I'll hold short of saying more about it.

These are all design choices, though. It's not left to the electronics itself to "guess at." (Not in my experience, anyway.) The designer works out the details and makes decisions. Where I was involved some, the design is simulated first. Then it is placed on a huge cube of FPGAs that can run the design almost at full speed. A little "pod" reaches out from the cube to plug into a CPU socket on a real board for further testing. All this before committing to an ASIC and an IC FAB run.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Suppose that we talk about the 8086, and the 16-bit register DIV instruction. It takes 144 to 162 clock cycles ( oocities.org/mc_introtocomputers/Instruction_Timing.PDF ). A few questions: (1) does the 8086 simply "stall" for so many clock cycles?, (2) if so, do these cycles count as part of the Execution step?, (3) how does the CPU decide how many clock cycles (i.e. between 144 and 162) to actually wait? \$\endgroup\$ – obe Sep 1 '19 at 0:55
  • \$\begingroup\$ @obe I don't know the exact design internals of the 8086 (it has the same 40-pin package as the 8088 except that the 8086 shares 16 bits of the 20 bit address bus for data instead of just sharing 8 bits.) The DIV instruction does operate as a state-machine in the execution unit, but it obviously includes some "early-out" tests (an all-0 or all-1 test for some part of a word is easily implemented.) Perhaps the best way to see how that might work would be to examine the ADSP-2100 Family manual and study their DIV instruction (1 bit at a time) and how to perform division over long word lengths. \$\endgroup\$ – jonk Sep 1 '19 at 3:46
  • \$\begingroup\$ @obe (Both the DIVS and DIVQ provide good details about division -- look for their behavioral schematic in the manual.) \$\endgroup\$ – jonk Sep 1 '19 at 4:12
  • \$\begingroup\$ thanks! i'm using DIV as an example. So if I understand you correctly, the 8086 (likely) has some logic outside the ALU to examine the numbers and in some cases deduce the length of the division information, but once "submitted" to the ALU - it simply waits out the number of cycles it had previously determined the operation would take, but doesn't communicate with the ALU (e.g. to get completion signal or more accurate estimations). Is that it? \$\endgroup\$ – obe Sep 1 '19 at 10:46
  • \$\begingroup\$ @obe Division logic is expensive. The more bits per clock or cycle time, the more expensive it is. It's likely that their division algorithm produced one bit per internal cycle time (3 clocks each?) That's why I referred you to the ADSP-2100 family -- they tell you everything you need to understand about that process. But it also likely they included some cheap logic to detect special cases that could be used to shorten the process by a few cycles (up to 6*3?) The state machine is part of the exec unit and controls the ALU logic process. \$\endgroup\$ – jonk Sep 1 '19 at 18:15
0
\$\begingroup\$

It's a fixed number of clock cycles after the data is put in the ALU. The exact number depends on the processor, and sometimes also on the specific instruction. You might find it useful to look up the term "pipelining" as it applies to computing.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.