The warning about missing elements in the sensitivity list means that
your simulation will not match the synthesized logic. This is because
a gated latch needs to update its outputs continuously when the
gate is "open" or active. So in simulation you would need to "trigger"
the always block when nibble changes.
In this case you should ignore the latch warning. Under normal
circumstances you do not want to unintentionally create latches by
leaving out "else" conditions. In your case you intended to create
the latch. For larger designs, where you may have to pore through
pages of warnings, it is a good idea to name your latch signals
in a way that makes it easy to see you intended to create a latch,
for example:
reg [3:0] latched_bits;
always @(load) begin
if(load) begin
latched_bits = nibble;
end
end
Then you will see the warning that a latch was created for "latched_bits" and you
can easily ignore it.
You also asked why this takes 12 macrocells and if there is a more efficient way
to generate your logic. If you were using an FPGA, I would say you found the most
efficient way. However for macrocell-based CPLD's you should think of the
architecture of the part, which has combinatorial logic feeding a register. In this
case latching the input bits uses four macrocells, then you need seven more
to convert the latched bits to 7-segment. If you instead latched the decoded
output (seven latches instead of four), you actually use only 7 macrocells
because the latch is added to the same macrocell doing the decoding.
Finally there is a way in Verilog to do what you attempted in the beginning.
If instead of a module, you defined a task for DisplayHex, you could place
the conversion "in line" in your always block. I would suggest finding a
good reference book for Verilog. I learned using Thomas & Moorby's
book, then used the Doulos Golden Reference Guide once I got the
basics and just needed a quick reference with examples. I also have
the official Verilog Language Reference Manual, but find it less useful
for those using the language than for those attempting to write a
simulator or synthesis engine for it.
Regards,
Gabor
-- Gabor
