I need help in VHDL. I am completely new to VHDL

[ads-ee]

I must confess, I never noticed this before. In both Quartus versions, I get the below results by including or excluding the data input in the sensitivity list. I don't think that the behaviour corresponds to the VHDL LRM. I'm also not yet aware of a synthesis attribute controlling the automatic latch to dff conversion.

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
 
entity lat is
port( 
   enable: in std_logic;
   Output: out std_logic;
   Input: in std_logic);
end;
 
architecture behavioral of lat is
begin
-- Infers a latch
process (enable, input) is
begin
   if enable = '1' then
      output <= input;
   end if;
end process;
end;

---

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
 
entity lat is
port( 
   enable: in std_logic;
   Output: out std_logic;
   Input: in std_logic);
end;
 
architecture behavioral of lat is
begin
-- Unexpectedly infers a synchronous register
process (enable) is
begin
   if enable = '1' then
      output <= input;
   end if;
end process;
end;

---

Given the exact same two files above with the change of the entity name of the 2nd to lat_reg. I got the following consistent results from two different synthesis tools: XST and Vivado synthesis (I believe for both of these, the core synthesis technology was purchased by Xilinx).

Vivado 2014.3.1
lat:

lat_reg:

lat_reg warnings


ISE 14.7
lat:

lat_reg:

lat_reg warnings


Currently I don't have Synplify installed so I can't check its results.

So the question remains, which tool is doing the correct synthesis? ISE and Vivado both think the description is a poorly written latch as it seems to expect that a register has to have an edge controlled event.

 

[TrickyDicky]

How about compiling with VHDL 2008 set on in vivado ? Quartus has had the 2008 support for a while and Vivado only just supports it.

 

[ads-ee]

There is no explicit setting for VHDL 2008 in Vivado at least in the GUI nor in the synth_design Tcl command, I'm not exactly sure what language version it supports.

I did enable 200X support in ISE.

- - - Updated - - -

Regardless, I think that Quartus is taking a rather loose interpretation of the IEEE-1076 in regards to synthesis of the enable in the sensitivity list and enable = '1' in the if statement. This is more like finding a loophole in the LRM and taking advantage of it to create registers using edge-triggering of a process and then checking the level of the signal in the if statement. This seems to be sort of a half baked way of implementing enable'event and enable = '1'. IMO this is a flaw in the implementation of the VHDL standard.

For Verilog if you want a edge triggered flip-flop you're only going to get one if you use posedge enable nothing else will suffice unless you go down to a gate level implementation of a master-slave flip-flop design, there is nothing ambiguous about it and no loophole coding methods to make latch like code turn into an edge triggered flip-flop.

Regards

- - - Updated - - -

Almost forgot...

Give me a break there's even the wait version of a synthesizable edge triggered flip-flop:

---

Code VHDL - [expand]
1
2
3
4
5
wait_dff : process (clk)
begin
  wait until rising_edge(clk);
  q <= d;
end process

---

So now we have three options in VHDL to write an edge sensitive D-FF. Seems rather ridiculous to have three ways to define something when one would have sufficed.

 

[FvM]

Given the exact same two files above with the change of the entity name of the 2nd to lat_reg. I got the following consistent results from two different synthesis tools: XST and Vivado synthesis (I believe for both of these, the core synthesis technology was purchased by Xilinx).

So the question remains, which tool is doing the correct synthesis? ISE and Vivado both think the description is a poorly written latch as it seems to expect that a register has to have an edge controlled event.

That's what I had expected for Quartus synthesis, too.

By the way, with a small change Quartus switches to latch (combinational logic loop) synthesis, with a warning about incomplete sensitivity list. That's probably what I have seen before and made me expect latch inference also for the case without reset signal.

process (enable, reset) is
begin
   if reset = '1' then
      output <= '0';
   -- infers a latch with a warning
   elsif enable = '1' then
      output <= input;
   end if;
end process;

 

[std_match]

The LRM is no help, on the contrary. It defines the syntax and how the simulation should be performed. It does not specify how synthesis should be done.

We all agree that the code follow the LRM and how it should be simulated. The synthesized hardware from Quartus will behave as the simulation, but I don't think that is the "best" behavior for a synthesis tool.
The problem is that the code here is bad for synthesis. I agree with XST and Vivado that is it a poorly described transparent latch which "tricks" the simulator to behave as a D-flipflop. There is nothing strange with getting the wrong simulation result when you leave out signals in the sensitivity list. Trying to invent strange hardware to mimic the wrong simulation result is bad.

If the Quartus behavior is accepted we will get the bad things from Verilog, where the sensitivity list is important for synthesis and an asynchronous reset is described as an edge. It is an advantage for VHDL that we must do things explicitly.
Let the sloppy code stay in the Verilog world.

 

[ads-ee]

Oops I should have said four options:

---

Code VHDL - [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
-- Option 1: bogus D-FF
process (clk)
begin
  if (clk = '1') then
    q <= d;
  end if;
end process;
 
-- Option 2: WTF D-FF Gotta save one line of code!!!
process (clk)
begin
  wait until rising_edge(clk);
  q <= d;
end process;
 
-- Option 3: I'm old school and I don't care if my clock has Z-1, X-1, U-1, or 0-1 transitions
process (clk)
begin
  if (clk'event and clk = '1') then
    q <= d;
  end if;
end process;
 
-- Option 4: This is what VHDL should have had from the start. DUH!
process (clk)
begin
  if rising_edge(clk) then
    q <= d;
  end if;
end process;

---

- - - Updated - - -

Let the sloppy code stay in the Verilog world.

Sloppy!? I think the VHDL language itself is sloppy and overly verbose. I get carpal tunnel just thinking about typing a VHDL description. ;-)

Perhaps you've looked at too much of the cr@p code posted on this forum by clueless newbies that haven't even read the Verilog LRM. My code, never looks like cr@p and certainly isn't sloppy. Most of the descriptive statements used after looking at my code have been...Wow that's a nice piece of code, mind if I use this as a template for my code, etc. :-D

Regards

 

[std_match]

Sloppy!? I think the VHDL language itself is sloppy and overly verbose. I get carpal tunnel just thinking about typing a VHDL description. ;-)

It was not my intention to create a VHDL-Verilog war in this thread. VHDL is not perfect. The code that made Quartus generate a D-flipflop is similar to the Verilog code for the same thing. I like that hardware is fully described by a VHDL process "body" and that the sensitivity list is only a help for the simulator to speed things up. The Quartus behavior to create a DFF from a missing signal in the sensitivity list is not good for VHDL as a synthesis language. A transparent latch and a warning is what I prefer.

 

[vishal_sonam]

but what should be the exact answer 4 or 5 d latches?

 

[ads-ee]

It was not my intention to create a VHDL-Verilog war in this thread. VHDL is not perfect. The code that made Quartus generate a D-flipflop is similar to the Verilog code for the same thing. I like that hardware is fully described by a VHDL process "body" and that the sensitivity list is only a help for the simulator to speed things up. The Quartus behavior to create a DFF from a missing signal in the sensitivity list is not good for VHDL as a synthesis language. A transparent latch and a warning is what I prefer.

I was joking, I actually prefer Verilog over VHDL mostly because I tend to have problems with typing all the verbose language constructs of VHDL. Come on why have a common keyword like architecture (12-characters). I think endgenerate (11-characters) is the longest normally used keyword in Verilog and that was borrowed from VHDL! The next largest that is used frequently is localparam (10-char). Of course Verilog can also beat VHDL in the longest keyword category with pulsestyle_ondetect (19-char) now choke on that std_match!. ;-)

Seriously as an HDL, VHDL works just as well as Verilog.

- - - Updated - - -

but what should be the exact answer 4 or 5 d latches?

Run it through a synthesis tool like I did and start counting latches...

 

[std_match]

but what should be the exact answer 4 or 5 d latches?

First of all, you should not write "if CLK = ’1’ then" since it is not compatible with all synthesis tools.
Use "if rising_edge(CLK) then".

It is not possible to say in general what the correct answer is. A smart tool may decide that it is enough with 4 DFF's.
The real hardware could power up with a value higher than 15, so 5 DFF's is not wrong.

I recommend that you don't use port type "buffer". You will get into trouble when you put modules together to a larger system. Use an intermediate signal to do the increment.

 

[ads-ee]

How many D-Latches are generated here?

but what should be the exact answer 4 or 5 d latches?

First of all, you should not write "if CLK = ’1’ then" since it is not compatible with all synthesis tools.
Use "if rising_edge(CLK) then".

But they keep saying how many "LATCHES" not "edge triggered D-Flip-Flops". Maybe they don't know the difference?

So vishal_sonam, do you want transparent latches or edge-triggered D-flip-flops?

 

[FvM]

But they keep saying how many "LATCHES" not "edge triggered D-Flip-Flops". Maybe they don't know the difference?

So vishal_sonam, do you want latches or edge-triggered D-flip-flops?

As the discussion revealed, it's no so easy to predict how a synthesis tool will interpret your code. But what we can clearly say, if you are using d-latches for a counter, either intentionally or by accident, the counter won't work in hardware.

 

[vishal_sonam]

I want transparent latches

 

[ads-ee]

I want transparent latches

Hmmm, FvM pretty much said it. You can't make a counter out of transparent latches.

WHY!? you ask.

When the latch is transparent....

count <= count +1;
count <= (count+1) +1;
count <= ((count+1)+1) +1;
count <= (((count+1)+1)+1)+1;
...

Uh, when is it supposed to stop? You have a feedback loop. I guess it will randomly stop when you latch whatever value is sitting at the count latch d input. Not very predictable over temperature and process variations.

 

[shaiko]

Hmmm, FvM pretty much said it. You can't make a counter out of transparent latches.

WHY!? you ask.

When the latch is transparent....

count <= count +1;
count <= (count+1) +1;
count <= ((count+1)+1) +1;
count <= (((count+1)+1)+1)+1;
...

Uh, when is it supposed to stop? You have a feedback loop. I guess it will randomly stop when you latch whatever value is sitting at the count latch d input. Not very predictable over temperature and process variations.

Maybe not so good as a counter...but it'd make for an interesting weather dependent RNG.

I want transparent latches

vishal_sonam,
stop wanting them! DFFs are much cooler!