Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Verilog HDL standard coding practices

Status
Not open for further replies.

vickyuet

Member level 2
Joined
Oct 3, 2006
Messages
50
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Location
pakistan
Activity points
1,691
Dear all,

As lots of books talk about inferring latches in hardware, when we miss few statements during coding like

1- not including else with if
2- not including default case with case statements....

but upon reading XST user manual examples I observed above are missings they not considered both of the above .....code snippet is below for reference.


Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
//
// ROMs Using Block RAM Resources.
// Verilog code for a ROM with registered address
//
module v_rams_21c (clk, en, addr, data);
input clk;
input en;
input [2:0] addr;
output reg [19:0] data;
reg [2:0] raddr;
 
always @(posedge clk) begin
if (en)
raddr <= addr;
end
 
//Table look up 
 
always @(raddr) 
begin
case(raddr)
3’b000: data <= 20’h0200A; 
3’b001: data <= 20’h00301; 
3’b010: data <= 20’h0200A; 
3’b011: data <= 20’h00301; 
3’b100: data <= 20’h0200A; 
3’b101: data <= 20’h00301; 
3’b110: data <= 20’h0200A; 
3’b111: data <= 20’h00301; 
endcase
end
endmodule



else missing in first always and default case missing in second...:shock:
// though default case here is not as necessary bcz all cases are covered .....:!:
 
Last edited by a moderator:

1. This is not necessary in a clocked always block, because you are infering a register. But it is essential in combinatorial block to prevent the creation of latches.
2. If all cases are covered, its not neccessary. Also, see 1.
 

just clear me on case statement .....case is purely a combinational block so for that reason generally we need a default case.....for my code i had fewer cases to cover so i ought to mention default case as well.kindly suggest...
 

Hey,

Can you please elaborate..
case statements used in a process but not clocked must be given default values and case statement inside a clock need not to have a default value.

Also I want to develop the understanding of what kind of activity in VHDL infers registers, latches, flip flops, ect. is there any resource available online or its just a digital insight.

Thanks....
 

Code:
always @(posedge clk) begin
if (en)
raddr <= addr;
end

in above example; means if the en is asserted, raddr is addr at rising edge of the clk. if the en is not asserted, then raddr is equal to previous value of raddr.
 

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:
Code:
assign x(idx) = y;

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.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top