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

Looking for some explanation (VHDL Coding)

Status
Not open for further replies.
S

sonika111

Member level 2
Joined
Jan 11, 2011
Messages
50
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,288
Activity points
1,716
Hi

While running my code I found that sometimes when you change the order in if -elsif else endif structure; it works. I know it infers priority encoder but I don't get that when conditions are independent why the order of couple of elsif statements matter for it to be recognised correctly.

I saw this behaviour using altera quartus II.

Any idea as to why? Does sometimes synthesis breaks depending on the order or what exactly do you think could be happening.

Many thanks
 

Without the code - we can only guess. But usually changing code will change behaviour.
Post the code.
 

This may or may not be the cause of your problem.... Does your IF statement compare floating point numbers? Sometimes they do not act as expected. For instance, 2 might be stored as 1.9999999999999, and the computer might print it as 2 onscreen. So we think it's stored as 2.
However the computer calls it 'unequal' if we execute a comparison to an integer 2. Sometimes we need to try various programming tricks to get around such behavior.
 

BradtheRad said:
This may or may not be the cause of your problem.... Does your IF statement compare floating point numbers? Sometimes they do not act as expected. For instance, 2 might be stored as 1.9999999999999, and the computer might print it as 2 onscreen. So we think it's stored as 2.
However the computer calls it 'unequal' if we execute a comparison to an integer 2. Sometimes we need to try various programming tricks to get around such behavior.
Click to expand...

The OP wont be using floating point in his synthesisable code.
 

For synthesis, the tools are allowed to infer a priority encoder or anything they can detect as better. This would work if the tools noticed the order of the if/elsif conditions didn't matter.

In simulation, the tools could also do this but it is harder for conditions to be independent. This is because the simulator has to consider values like 'X' or 'U' (as well as some other VHDL features). If you are simulating this, ensure there are no invalid/unknown inputs to this process. If this is something you've synthesized, search the systhesis report for "simulation mismatch".

For synthesis, also ensure your design meets timing and has correct constraints.

(also, 2 will never be stored as 1.99999 due to the way the format works. The big issue is 0.1 -- commonly used by humans but doesn't have an exact representation in floating point.)
 

Perhaps it's an interpretation problem of how the if logic works. Suppose we have the following snippets of code...

Code VHDL - [expand]
1
2
3
4
5
6
7

if inc = '1' then
  cnt <= cnt + 1;
elsif dec = '1' then
  cnt <= cnt - 1;
elsif shf = '1' then
  cnt <= cnt(cnt'left-1 downto 0) & '0';
end if;

The order may be significant if inc, cnt, shf are not mutually exclusive. This will result in mysterious behavior if you think they are mutually exclusive, but in reality they aren't.

But if the signals were instead coded as so...
Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11

-- inc: sel="00"
-- dec: sel="01"
-- shf: sel="10"
-- sel="11" - do nothing
if sel = "00" then
  cnt <= cnt + 1;
elsif sel = "01" then
  cnt <= cnt - 1;
elsif sel = "10" then
  cnt <= cnt(cnt'left-1 downto 0) & '0';
end if;

Now the order is no longer significant and any order will have the same results. There is no option for more than one of the encoded comparisons branches to be taken.
 

The OP is asking about synthesis where you don't have 'X' or 'U' inputs.

Without an example of the claimed incorrect behavior, I tend to assume that the synthesis tool is just reading the code literally, which might be different from what the author expects it to mean.
 

OP, if you decide to post some example code don't just post the if statement stuff, post everything so we have proper context of the if code, i.e. how the inputs to the if compares are generated.
 

Thanks everyone for the reply. I really appreciate that.
I can tell that it is similar to

-- inc: sel="00"
-- dec: sel="01"
-- shf: sel="10"
-- sel="11" - do nothing
If sel = "00" then
Cnt <= cnt + 1;
Elsif sel = "01" then
Cnt <= cnt - 1;
Elsif sel = "10" then
Cnt <= cnt(cnt'left-1 downto 0) & '0';
End if

The conditions are (the comparison is with hexadecimal values(not floating point numbers) and are mutually exclusive.

I don't understand that if this is the case why the order should matter for e.g. If sel = 10 is put before sel = 01 then shouldn't it expected to work and vice versa

I am testing it using signal tap of altera (after full compilation/synthesis) ...

Any idea why should the order matter in this case and why is not working( what is broken)??

Thanks again
 
Last edited by a moderator:

I don't understand that if this is the case why the order should matter for e.g. If sel = 10 is put before sel = 01 then shouldn't it expected to work and vice versa.
Click to expand...

Unfortunately you didn't follow ads-ee's suggestion to clarify the code context.

Although the conditions are in fact mutual exclusive, there are at least two possible reasons that might cause unexpected code behavior, including dependency on instruction order.
- it's not scheduled in a clock-edge sensitive process, e.g. enclosed by if rising_edge(clk)
- the sel signal is asynchronous to the process clock domain, e.g. an external signal, and hasn't been properly synchronized to clk
 

    V

    Points: 2
    Helpful Answer Positive Rating
When I encounter unexpected behavior I add verbose statements displaying the latest value of variables, or 'Choosing sel=01', etc.

And it might help if you include an 'ELSE' line at the end of your 'IF' tree, so that every possible situation has its own branch. Supposedly it is not an error if we omit the final 'ELSE', nevertheless we can then add a 'print' statement stating that it did not find one of the above 'if-elseif' choices to be true. And add a 'print' statement displaying your variable's latest value.
 

I set up a minimal test entity around the said code snippet.

Changing the order of the second and third condition results in exactly the same gate level net list, so it won't behave different, even when facing timing violations of input signals.

There may be still accidental differences in placement and routing between compilation passes.

The more interesting point is, changing the order doesn't change logic function. With correct input signal timing, the result won't change.
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
31

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
 
entity test is
port(
    reset   : in STD_LOGIC;
    clk : in STD_LOGIC;
    sel : in STD_LOGIC_VECTOR (1 downto 0);
    cnt : buffer SIGNED(3 downto 0)
);
end test;
 
architecture rtl of test is
begin
 
process (reset, clk)
    begin
        if reset = '1' then
            cnt <= (others => '0');
        elsif rising_edge(clk) then
            If sel = "00" then
                Cnt <= cnt + 1;
            Elsif sel = "01" then
                Cnt <= cnt - 1;
            Elsif sel = "10" then
                Cnt <= cnt(cnt'left-1 downto 0) & '0';
            End if;
        end if;
    end process;
end rtl;
 

FvM said:
I set up a minimal test entity around the said code snippet.

Changing the order of the second and third condition results in exactly the same gate level net list, so it won't behave different, even when facing timing violations of input signals.
Click to expand...

Which is exactly what I said in post #6 (BTW, thanks to FvM for the proof).

In the OP's case they need to supply the exact code they are trying to use, I suspect it's not the if statement or if it is they did something wrong like made it a combonational process and are inadvertently producing latches or sim/syn mismatches due to missing/extra signals in the process sensitivity list.
 

Thanks everyone

I find the bit order reversed while looking at the RTL Viewer (Quartus). Has this anything to do with it not working as expected??

Thanks
 

RTL netlist view is just a visualization of the entered logic definition and can help to recognize e.g. semantic misunderstandings. The actual order of logic operations can be only seen in gate level netlist (Technology Map Viewer).

It's still unclear how you test the code and which are the conditions that cause the reported unexpected behavior.
 

sonika111 said:
Thanks everyone

I find the bit order reversed while looking at the RTL Viewer (Quartus). Has this anything to do with it not working as expected??

Thanks
Click to expand...

This will be because of what you did in your code. Post the code and maybe we can explain...
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top