Verilog/VHDL will infer latches. You can add "x <= x;" for all signals at the top of each process. For clocked processes, this isn't an issue -- you have registers that already do this. For combinatorial logic you get into cases like the less common:
the issue is that if there are two elements, x(0) and x(1), what is x(0) when idx == 1? well, it defaults to x(0). But that means x(0) has to retain it's value when idx != 0. And thus a latch is inferred.
inside a clocked process, it would mean that, on a clock edge x(0) would need to retain its value -- this is a register and was intended.
however, clocked processes are not entirely safe:
Code:
always @ (posedge clk, posedge rst) begin
if (rst == 1'b1) begin
x <= 0;
end else begin
x <= din;
dout <= x;
end
end
in this case, dout isn't reset, but if reset is asserted during a clock, dout will not get x, but will get its current value -- another latch.
as for clock enable vs simple registers, make sure to treat them differently. One of the big issues with VHDL/Verilog is that it is easy to infer registers, and as such you can end up with some registers that have clock enables and others that don't. When you mix the two, the design might work when the clock enable signal has a specific pattern, but not in all cases. Simulations are a terrible thing in this case, as there is a tendancy to try to force the simulation to work by adding some register delays and extra control logic to get the waveforms to "line up". This solves one case, but can easily leave other cases broken.