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.

Register Log in

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

Status
Not open for further replies.
V

vishal_sonam

Full Member level 3
Joined
Jan 19, 2012
Messages
187
Helped
14
Reputation
28
Reaction score
14
Trophy points
1,298
Activity points
2,457
How many D-Latches are generated here?
Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

entity COUNTER is
port (
CLK : in std_logic;
COUNT : buffer integer range 0 to 18);
end entity COUNTER;
architecture RTL of COUNTER is
begin
process (CLK)
begin
if CLK = ’1’ then
if (COUNT >= 12) then
COUNT <= 0;
else
COUNT <= COUNT + 1;
end if;
end if;
end process;
end architecture RTL;
 
Last edited by a moderator:

Being a complete vhdl n00b myself I thought I'd do this as a test. First I though aha maybe a trick question and it's 0 latches. But it does look like a latch, what with the lack of clock edge, and purely depending on the logic level of CLK. I'd guess 19 latches, but I don't know enough about how the optimizer treats those MSB's that will always result in 0 values. Anyways, 19 is my guess. If you want the correct answer best wait for the vhdl posse to show up. ;-)
 
"counter" is defined as an integer with a maximum value of 18 ( "10010" ) - I'd say 5 latches.
To be sure, I suggest that you synthesize your code and review the result with the synthesizer's RTL viewer - Think of it as "Google Translate" for digital logic - only more accurate and without the curse words. Very important tool, especially if you're new to the language.

Taking it a step further...
Assuming that your code is targeted towards FPGAs - you're doing it wrong.
Latches are bad choice for FPGA's. To find out why - google: "why not use latches in FPGAs".
The correct way to do it is with D-Flip Flops:

Code: 
CLK : in std_logic;
COUNT : buffer integer range 0 to 18);
end entity COUNTER;

architecture RTL of COUNTER is
begin

process ( CLK )
begin
   if rising_edge ( CLK ) then -- edge sensitive instead of level sensitive 
     if (COUNT >= 12) then
        COUNT <= 0;
     else
        COUNT <= COUNT + 1;
    end if;
end if;
end process;
end architecture RTL;
 
1. The original code doesn't work as a counter in real hardware.
2. A state-of the art synthesis tool recognizes that the counter'high is restricted to 12 by the code, thus the fifth FF will be discarded and replaced by a constant 0 bit. Only 4 Latches, respectively D-FFs if using the working code suggested by shaiko.

- - - Updated - - -

Unfortunatelly my expectations turned out wrong.

I tested with Altera Quartus, both V9.0 and 13.1. The synthesis tool doesn't optimize the unused counter[4] bit, it's less intelligent than expected. O.K.

Surprizingly, Quartus treats CLK = '1' identical to rising_edge(CLK) and infers D-FFs for the counter. But why?
 
FvM said:
Surprizingly, Quartus treats CLK = '1' identical to rising_edge(CLK) and infers D-FFs for the counter. But why?
Click to expand...

That indeed sounds weird. Maybe you have a DIE_LATCHES_DIE option enabled and you forgot about it?
 

FvM said:
Surprizingly, Quartus treats CLK = '1' identical to rising_edge(CLK) and infers D-FFs for the counter. But why?
Click to expand...

Synth tools are trying to take into account sensitivity lists now. Im sure something like this came up in a similar discussion a while ago.
In simulation, using "if clk = '1'" with clk in the sensitivity list will behave exactly like a register, as the process is triggered by an 'event on clk, this will only occur on rising edge.
Its probably from the similar way Verilog does rising edges.
 

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;


 

FvM said:
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.
Click to expand...
There is nothing not compliant about what is going on here. If you have one signal in your sensitivity list and an 'if' statement that compares that signal then you will get a flip flop. In order to infer a latch there must be two signals in the list, the Enable and the Data.

Kevin Jennings
 

There is nothing not compliant about what is going on here. If you have one signal in your sensitivity list and an 'if' statement that compares that signal then you will get a flip flop. In order to infer a latch there must be two signals in the list, the Enable and the Data.
Click to expand...

From which VHDL specification do you conclude that a level sensitive behavioral description can optionally generate edge sensitive hardware? IEEE 1076.6 (Standard for VHDL Register Transfer Level (RTL) Synthesis) e.g. requires an event expression to model edge sensitive logic.

It's clear of course that a behavioral simulation would create edge sensitive behaviour in this case by strict evaluation of the sensitivity list. In so far, the observed behaviour results in best possible simulation match. But we have learned so far that the sensitivity list is effectively ignored in synthesis, and in most cases it surely is.
 

vishal_sonam,
here is a very good example of how HDL - applied to describtion of combinatorial circuits can have very ambiguous synthesis results.

I suggest that in the beginning of your learning curve you stick to known templates and understand why & why they yeild the logic circuits that they do...

And forget about using combinatorial elemets on FPGA's as memory components - i.e No Latches.
 
FvM said:
From which VHDL specification do you conclude that a level sensitive behavioral description can optionally generate edge sensitive hardware?
Click to expand...
The LRM is the defining document...not sure what you mean by 'optionally generate', since a tool that conforms to the LRM will treat the posted code as something that wakes up on any transition on CLK and will only execute the code inside the 'if' statement when CLK is also 1. There are no 'options' per the LRM. From the perspective of synthesis, the only possible interpretation (per the LRM) would be that of a flip flop.

I do not agree that the posted code is a 'level sensitive behavioral description' since the process will not trigger (per the LRM) when the input to be stored changes whereas the description of a transparent latch would have that input as a second signal that would wake up the process.

IEEE 1076.6 (Standard for VHDL Register Transfer Level (RTL) Synthesis) e.g. requires an event expression to model edge sensitive logic.
Click to expand...
I haven't perused 1076.6 in a long time, but the intention of that standard was to create a synthesizable subset of the LRM that synthesis tools were supposed to adhere. I certainly agree that most synthesis tools ignored the sensitivity list and created logic based on what it found in the process (i.e. equivalent to what VHDL-2008 defines as 'process(all)'), but I would find it surprising if 1076.6 allowed that since it would have violated the LRM that was in existence at that time. Such a violation would not be a 'subset' of the LRM. In any case, adherence to the LRM would override adherence to 1076.6...which by the way is no longer even an active standard, it has been withdrawn (https://standards.ieee.org/findstds/standard/1076.6-2004.html).

It's clear of course that a behavioral simulation would create edge sensitive behaviour in this case by strict evaluation of the sensitivity list. In so far, the observed behaviour results in best possible simulation match.
Click to expand...
I agree
But we have learned so far that the sensitivity list is effectively ignored in synthesis, and in most cases it surely is.
Click to expand...
But that ignoring of the sensitivity list is not compliant with the LRM. Since Quartus is correctly interpreting the code per the LRM, what's the complaint?

Kevin Jennings
 
Last edited:

But that ignoring of the sensitivity list is not compliant with the LRM. Since Quartus is correctly interpreting the code per the LRM, what's the complaint?
Click to expand...
I'm not actually complaining. I have no problems to describe either a latch or FF and get it synthesized correctly, because I'm used to write a complete description, including a sensitivity list. And I basically know which constructs are synthesizable and which aren't.

It's well known that you can write a lot of VHDL constructs that are legal according to the LRM and can be simulated but don't synthesize at all (e.g. dual edge clocked FFs) or don't work in real hardware (e.g "asynchronous" counters based on latches). Although it was never completely adopted by a synthesis tool vendor and finally withdrawn as far as I know, IEEE 1076.6 is close to the VHDL subset implemented in recent tools. Before IEEE 1076.6, a de-facto standard defined by Synopsys and probably other tool vendors ruled the "VHDL for hardware synthesis" field.

One of the simple rules of synthesizable VHDL is that you have to write an edge sensitive event expression to infer a FF. And it's still necessary in most cases, I believe. Now we see that in some cases (don't mind whether it's a bug or a feature), a level sensitive condition does the trick. That's at least surprizing.
 

FvM said:
One of the simple rules of synthesizable VHDL is that you have to write an edge sensitive event expression to infer a FF. And it's still necessary in most cases, I believe. Now we see that in some cases (don't mind whether it's a bug or a feature), a level sensitive condition does the trick. That's at least surprizing.
Click to expand...
It's not a 'level sensitive condition'. If you believe it is it's because you are not considering the sensitivity list consisting of one signal and how the LRM defines the operation of the sensitivity list. I know you understand this, so I want to belabor the point any longer.

In the end, the best way to write the 'if' statement is 'if rising_edge(CLK)', and the reason it is the best is because it clearly expresses the design intent.

Kevin Jennings
 

I agree that the code doesn't contain a valid level-sensitive condition because the sensitivity list is incomplete. IEEE 1976.6 says in this regard "The process sensitivity list shall contain all signals read within the process statement."

But it's neither a valid DFF description (with edge-sensitive condition) according to IEEE 1976.6 or Synopsys reference manual (the previous de-facto standard for synthesizable VHDL). Can we expect similar behaviour with other synthesis tools?

I wonder if I'm the only who's surprized about register inference for the discussed code?
 

I wonder if I'm the only who's surprized about register inference for the discussed code?
Click to expand...
Certainly not, I was pretty sure that a latch will be inferred.

However...it's new to me that synthesis tools have to consider sensitivity lists as part of the elaboration process. This of course changes the whole picture.
 

I wonder if this issue is to do with the altera tools themselves, or the fact the VHDL parser is bought in from Verific (probably the latter).
 

K-J said:
But that ignoring of the sensitivity list is not compliant with the LRM. Since Quartus is correctly interpreting the code per the LRM, what's the complaint?
Click to expand...

VHDL is a simulation language, and the intention of the sensitivity list is to reduce the simulation time by only executing the process when necessary. The sensitivity list is (was?) not needed for synthesis, and that is one big advantage over Verilog. I don't want the sensitivity list to have any effect on the synthesis. It doesn't help me as a designer. It is only confusing.
 

I would like to hear reports from users of other synthesis tools if a similar behaviour as observed with Quartus can be found there or if it's a specific feature or bug (whatever you think) of the Altera tool.

It's still the case that sensitivity lists will be ignored for synthesis in most cases, simply because they can't be mapped to hardware. And also because the purpose of sensitivity lists in simulation (reduction of computation effort) is irrelevant for synthesis, as explained by std_match.

But here we have a special case where the behaviour of the sensitivity list can be mapped to hardware, although the result contradicts an intuitive view of synthesizable VHDL.
 

std_match said:
The sensitivity list is (was?) not needed for synthesis, and that is one big advantage over Verilog.
Click to expand...
The sensitivity list was ignored by some synthesis tools in direct violation of the LRM. Per FvM, the withdrawn standard 1076.6 seems to have legitimized this practice, but it is still in contradiction with the governing standard VHDL 1076 (aka LRM). As an aside, I don't believe that 1076.6 allows for the use of 'time' or 'real' in any context, but synthesis tools vendors have moved beyond that as well. Type 'time' and 'real' can now be used to define constants but there was a time when they did not. Tools that might still not support this usage are falling behind their competitors.

I don't want the sensitivity list to have any effect on the synthesis. It doesn't help me as a designer. It is only confusing.
Click to expand...
Then I would suggest you use 'process(all)' instead which was introduce in VHDL-2008.

Kevin Jennings
 

IMHO, the discussion isn't about what's exactly required, permitted or prohibited by IEEE 1076.6. I referred to the standard because it's a well considered concept how synthesizable VHDL should be written. As already said, apart from details, it's quite close to the operation of recent synthesis tools. IEEE 1076.6 doesn't say that sensitivity lists should be ignored. Regarding latch descriptions, it says the data input "shall" be included. It however doesn't tell what should happen in case of incomplete sensitivity lists.

I think it misses the point to say that synthesis tool deliberately ignored or still ignore sensitivity lists. The point is that in many cases they can't map it to hardware, respectively only VHDL that is written in aware of synthesis requirements can be mapped to hardware and achieves matching results in simulation.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top