Why to register a input signal?

[otis]

Some input signal need to(some time recommanded to) be registered.

some time also recommanded to do with the output signal too.

Why it has to be?

Could anyone explaing at what scenarios this need to be done and how.

Thanks

 

[paulki]

Hi Otis,
Make sure that the "timing" (setup/hold) of signals coming from the external world match with to the input boundary. When it is registered (synchronously clocked with the reg), its try to infer the flop and by the way ensuring the timings are met!!!
This can be treated as RTL Coding guideline 1

Thanks,
paulki

 

[phoenixpavan]

Hi Otis,

It is always recommended to have registered inputs and outputs in your design...but not as a rule. When you have them registered it will be helpful in STA as you can specify your delays accurately when they are associated with your registers. If you do not, you need to pessimistically declare delays in your design for both inputs as well as outputs.

So when you have registered inputs and outputs your timing analysis will be more accurate and will be less pessimistic.

Cheers

 

[enchanter]

If there's no special requirement, register the input/output signals are good choice to avoid timing problem.

 

[ebuddy]

Registering inputs and outputs makes time closure easier. But the down side of this is that it can be pretty expensive in terms of area, especially for wide input/output bus. And it does increase the latency of the data path, where in some applications, it is not acceptable.

 

[otis]

Hi all,
Thanks for your answers. All of you mentioned that it is to avoid the timing issues. But could you please explaing bit more what kind of issue(s) is that.

'paulki' mentioned that to avild setup/hold time issues. Is there any other timing issues?

Thanks in advance!

 

[phoenixpavan]

Hi Otis,

Suppose that you do not have a registered input so what it means that the input is coming as an output from a combinational logic which again includes combinational cell delays. These will be again loaded from the libraries. You may not know the entire logic that drives this input. So you estimate the delay caused by the combi logic which may lead to pessimistic analysis. Assume that you have taken that you have estimated this delay as 3ns but in effect it only takes up 1ns...so you are over constraining the timing by 2ns.

Instead if you have an registered input you can specifically state the cell delay of the f/f instead worrying of the combi delays. So your analysis will be more accurate.

Hope it clarifies!!

 

[otis]

thanks a lot!

 

[sunjianhuigou]

Hi,
pavan, you had explained it so clearly. Helpful!