1
\$\begingroup\$

I'm following MIT 6.004x course, where in the pipeline section, it's stated that "our pipeline convention requires that every pipeline stage has a register on its output". I absolutely understand the reason to add a register in the mid-stage, but why to use it in the final output wire. I mean, can't we just pipe the output directly, what's the purpose to add a register to remember the output result?

For example, I have the following pipeline conforming to the aforementioned convention:

enter image description here

why can't I delete the last register and output the result directly?

enter image description here

Could anyone give some explanation? Thanks for any help!

\$\endgroup\$
  • \$\begingroup\$ the register is to sync the pipeline data to the system clock. \$\endgroup\$ – Sunnyskyguy EE75 Nov 3 '16 at 6:09
2
\$\begingroup\$

You can use your own convention if you like, but in your OP you say that MIT 6.004x says that their convention is to have a pipeline output registered.

But there are better reasons than 'it's their convention'.

Why are you adding a pipeline register into the random logic of gates F, G and H? Because they are not fast enough. Not fast enough for what? Not fast enough to receive inputs on this clock cycle, and have the result ready to be used somewhere next cycle. So by adding the output register, we are being explicit about where the timing must be right.

When designing a pipeline, the easy bit of the timing is 'can one register drive another, in a clock period?'. The hard bit is 'can one register output ripple through the random combinatorial logic I have between stages, in a clock period?' Using an output register means that all the difficult timing is under the control of the designer of that module (or the student answering the question), and the interfaces are easy timing only.

Using a pure register at the beginning or end of a pipelined process gives you the cleanest I/O timing with respect to the clock. If you need to connect your process to something, that's important as it allows for easier calculation of setups and holds, and tolerance for extra delays and clock skew between processes. If I go to the modules catalogue, I'm more likely to be able to successfully use the design with the cleaner interface timing.

If you find you have connected two processes, and that there are two registers between them when there only needs to be one, it's trivial to remove one of them. So where the two processes meet, you generally have a register that you could call either the output of the previous process, or the input to the next. The MIT convention is that you call that register part of the previous.

\$\endgroup\$
  • \$\begingroup\$ the register can be in hardware or software but can also have a lot to do with electronics in the implementation. \$\endgroup\$ – Sunnyskyguy EE75 Nov 3 '16 at 7:02
2
\$\begingroup\$

If you do not use a register after your last stage, you are effectively merging the last stage with any following logic. Your diagram will not show the complete pipeline and it will be useless for checking timing constraints.

From a technical perspective, you perfectly could connect your last stage to an output driver and even route it off-chip without any register. But in the design view (at least for timing), all the logic up to the next register must be considered as part of that stage.

\$\endgroup\$
1
\$\begingroup\$

What you're missing with the question is that this pipeline is only a part of a larger design. Something will always consume the result of the pipeline, frequently another unit which can itself be treated as a pipeline. If you look at the fragment you've drawn, you can take several of these fragments and stack them end-to-end making a longer pipeline - this also follows the same pattern. If you omitted the final flop, but connected two small pipelines, you find twice the logic depth at one stage. Hence the convention which makes for an easy to transform element.

A more real-world convention might insist on 3 flops for a 2 stage pipeline (adding a redundant input capture flop). This would add some timing margin for the scenario where you have physical separation between the two pipelines - but now its not so trivial to sub-divide, so this 2nd convention isn't so good to teach with. Obviously, in a real-world scenario, this convention is just a starting point, you might make optimisations in some or all of the interfaces (as you have already identified might be possible once the whole picture hangs together).

\$\endgroup\$
-1
\$\begingroup\$

Glitches due to soft errors can act as a severe deterrent to asynchronous circuit operations. A register improves basic operation for variable latency.

A pipeline pushes commands or data without having to wait for a response. A register is a 2 way handshake at the register, so the receiving end can control flow . Once read by the receiver, the sender can update the register. The same happens in the burst of responses with client side control.

The server is always " the listener" and the client the original "requester "

\$\endgroup\$
  • \$\begingroup\$ Hi, @Tony, could you please be more specific? I'm just starting to learn this course and don't quite understand what you mean. Thank you so much! \$\endgroup\$ – user123 Nov 3 '16 at 6:32

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.