Re: Inferred latches questions
- From: Ralf Hildebrandt <Ralf-Hildebrandt@xxxxxx>
- Date: Sun, 01 Jan 2006 10:20:26 +0100
stoyan.shopov@xxxxxxxxx wrote:
Are latches good or bad or what in such cases?
* There are targets, that do no support latches (many FPGAs). * Latches may be forbidden by your company's design rules. * You have to take care, that 1) Latches are transparent. Glitches will propagate, if the latch is open. 2) The data input of a latch must not change short before the latch is disabled. (muxed latch problem) This would lead to a wrong value stored in the latch. * Latches are only half as big as flipflops. * Latches do not consume energy like flipflops, that do it for every clock edge (even if the value is unaltered). Latches are good for low-power designs.
As far as I get it, latches are inferred whenever a signal is not assigned a default value in the process and not all possible paths of execution assign a value to the signal in consideration.
Right. The template for a latch is
process(data_in,enable) begin if (enable='1') then latch_val<=data_in; end if; end process;
Note, that adding a reset _may_ lead to the muxed latch problem.
process(data_in,enable, reset) begin if (reset='1') then latch_val<='0'; elsif (enable='1') then latch_val<=data_in; end if; end process;
This strongly depends on the synthesis tool _and_ on the library. (You need resettable latches and the synthesos tool has to be smart enough to use them.)
simple_alu: process(a, b, op) -- variable to hold the sum a + b when determinig overflow variable tmp : std_logic_vector(8 downto 0); begin
if op = '1' then -- compute the sum -- tmp := ("0" & op_a) + ("0" & op_b); -- detect overflow overflow <= a(7) xor b(7) xor tmp(7) xor tmp(8); else -- compute the exclusive or of a and b tmp := ("0" & op_a) xor ("0" & op_b); end if;
result <= tmp(7 downto 0);
end process simple_alu; ....
In this process the signal 'overflow' is assigned only in the first case of the 'if' statement. As I get it, a latch here shall be inferred for this signal, that ouputs the computed value for 'overflow' whenever signal 'op' equals 1, and will keep the most recent valid output value when 'op' is different than 1. Am I correct?
Right - just test it with your synthesis tool.
Also, here let us assume that the simple ALU is used by some external logic that is clever enough to take care of the 'overflow' signal only when performing additions, effectively discarding its value when performing exclusive-ors. In this case it really does not matter what the ALU outputs when performing xors, so it is safe that the latch be removed, right?
This is something, that has nothing to do with latches, it is logic reduction. (You could model overflow as a flipflop, too.)
It is always a good idea to do logic reduction and in your case to make the other logic discard an unneeded overflow signal.
In all, I simply do not get the purpose of latches in such cases.
Latches are storage elements (registers). Flipflops are registers, too.
You need registers to store an information. If you can eliminate the need for storing an information, you eliminate the register.
In an ALU it may be a good idea, to store flags, like the overflow flag. But this strongly depends on _your_ CPU. Let me give an example:
Try to add a value from one RAM position to a value from a 2nd RAM position. Then you need 2 addresses. Lets assume, that the CPU computes the following steps:
* fetch of the first address
* fetch of the 1st operand, store it to a temp register
* fetch of the 2nd address
* fetch of the 2nd operand, addition with the value from the temp
register and storing the value in the temp register (-> overflow
flag!)
* store the value of the temp register a the 2nd address
Lets also assume, that every move of operands during all this is done by the ALU. (get operand(s) from somewhere -> ALU -> put operand somewhere)
As you can see, the very last step means _moving_ the result. While moving the result the flags must not be altered, because they have to be valid after the complete instruction is finished.
=> Sometimes the ALU is allowed to modify flags, sometimes not. -> You need storage elements. The CPU control, if the flags are altered.
Also, is this not possible - suppose that (as in real life) some synchronous logic changes the inputs to the ALU but the inputs do not change simultaneously, some values are propagated for 'a' and 'b' (perhaps even not all of the values in these vectors - say a(3) and b(7) are slower, for some reason) when the operation is 'addidtion'. The ALU computes (literally) 'something', then the type of operation gets changed to 'xor' and in a short time all signals settle down to their stable states until changed at the next heartbeat of the synchronous logic controlling the ALU. If this is possible (I think it is) then the value of 'overflow' is obviously totally wrong and is therefore useless.
Remember, that an instruction need several steps to be computed and this means often several ALU steps. So the state machine of the CPU has to take care, that the operands and the instruction for the ALU has to be valid. (And the setup- & hold times have to be met.)
Ralf .
- Next by Date: Register initialization
- Next by thread: Register initialization
- Index(es):
Relevant Pages
|
Loading
