Question about the different ways to implement PC.hdl

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about the different ways to implement PC.hdl

Sandu2000
The way I implement the PC.hdl chip is by doing something similar to what is done here. The only difference being I didn't specify the a input in the first Mux gate [ Mux16(b=incrementVAl,sel=inc,out=IncrementCond) ] and I didn't keep the load bit of the register as true. So basically I used OR gate to check if any of the inc, reset or load bit were 1. If not, the register doesn't load anything. Is this unnecessary? Wouldn't it be inefficient energy wise to load data into the register when it's not required?
Reply | Threaded
Open this post in threaded view
|

Re: Question about the different ways to implement PC.hdl

WBahn
Administrator
Sandu2000 wrote
The way I implement the PC.hdl chip is by doing something similar to what is done here. The only difference being I didn't specify the a input in the first Mux gate [ Mux16(b=incrementVAl,sel=inc,out=IncrementCond) ] and I didn't keep the load bit of the register as true. So basically I used OR gate to check if any of the inc, reset or load bit were 1. If not, the register doesn't load anything. Is this unnecessary? Wouldn't it be inefficient energy wise to load data into the register when it's not required?
In a real design, you should never have undefined inputs to gates (unless the part specifically allows it). In the case of CMOS, that is asking for all kinds of trouble, including high shoot-through currents that can destroy the part.

As for the inefficiency, look at the internal design of the Register part -- if the load is LO, then the present output of the register is fed back and loaded into the register. Every DFF part in the design ALWAYS loads whatever is on its input into the flip flop on EVERY clock cycle.

In designs that are very energy sensitive (such as applications requiring extended battery-powered operations or that have high total power with limited heat dissipation capabilities) all kinds of games are played to reduce power consumption. The two biggest are using asynchronous logic design within various blocks of the larger design and suppressing the clock signals to blocks that are not active. These are both nontrivial approaches that require significant effort to ensure that glitches on clock signals and critical race conditions do not exist anywhere in the design.