+ Post New Thread
Results 1 to 17 of 17
  1. #1
    Member level 4
    Points: 1,414, Level: 8

    Join Date
    Dec 2011
    Posts
    77
    Helped
    0 / 0
    Points
    1,414
    Level
    8

    signal value conflict in VHDL

    I use a reset (rst) signal to first disable a write enable (we) signal and then upon a condition, the 'we' signal will later become active.

    testbench:
    Code:
    architecture myarch of big_design_tb is
    	component detector port( ...,   clk: in std_logic;   rst: in std_logic;  we: out std_logic);
    	end component;	
    	component writer port( ...,	clk: in std_logic;   oe: in std_logic );
    	end component;	 			 
            signal r: std_logic := '1';	
            signal clk: std_logic := '0';
            signal we: std_logic;
    begin
            u2: detector port map( ..., clk, r, we );	 
    	u3: writer port map( ..., clk, we );
          	process( clk )	
    	begin
    		clk <= not clk after 2 ns;
    	end process;	
    	process
    	begin
    		r <= '0';
    		a <= 4;  -- some inputs
    		wait for 4 ns;
                    ...
           end process;
    end
    detector:
    Code:
            port( ...,   rst: in std_logic;  we: out std_logic); 
            ...
            ...
    	process( rst )
    	begin
    		if rst = '1' then
    			we <= '0';
    		end if;
    	end process;
    	process( clk )	   -- clk is in the port list
    	begin			 
    		if (clk'event and clk = '1') then
    			q <= mout;        -- these are OK!
    			if count = 1 then
    				we <= '1';   -- this is where 'we' is activated
    			end if;
    		end if;
    	end process;

    writer :
    Code:
    	port( ...,	oe: in std_logic );
            ...
            ...
    
    	process( clk )
    	begin
    		if (clk'event and clk = '1' and oe = '1') then
    			if (count < n) then	
    				z <= a(0);   -- sending the detected value to the output which is OK
    			end if;
    		end if;
    	end process;
    In the simulation with activehdl, I see that 'we' (in the testbench) is first set to U and then X. I can not figure out why. At least the 'r' signal is initially set to '1' and 'we' should be '0' according to the process.
    Can someone shed light on that?
    Last edited by mahmood.n; 9th July 2017 at 12:26.

  2. #2
    Super Moderator
    Points: 236,416, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    40,889
    Helped
    12495 / 12495
    Points
    236,416
    Level
    100

    Re: signal value conflict in VHDL

    Many relevant information missing. We e.g. can't see if and how reset or clk of the detector are stimulated.

    I presume activehdl has a "trace 'X' source" feature like other industry standard simulators, using it would be the first step to solve the problem yourself.



    •   Alt9th July 2017, 12:18

      advertising

        
       

  3. #3
    Member level 4
    Points: 1,414, Level: 8

    Join Date
    Dec 2011
    Posts
    77
    Helped
    0 / 0
    Points
    1,414
    Level
    8

    Re: signal value conflict in VHDL

    Actually debugging is pretty hard due to the concurrent statements, signal assignments at the end of the process and ...
    If you know a better way for debugging, please let me know. I was thinking to synthesize the design to see the blocks and other things to manually check if that point of the design is OK.

    We e.g. can't see if and how reset or clk of the detector are stimulated
    The 'r' signal is the reset and 'clk' is the clock.
    I updated the post to include the clock signal. I have to say that other parts are working fine i.e. if I ignore this 'we', the design is fine.

    I presume activehdl has a "trace 'X' source" feature like other industry standard simulators
    Student edition doesn't support that feature!
    Last edited by mahmood.n; 9th July 2017 at 12:44.



  4. #4
    Super Moderator
    Points: 236,416, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    40,889
    Helped
    12495 / 12495
    Points
    236,416
    Level
    100

    Re: signal value conflict in VHDL

    Did you ever watch the signals inside the detector component? Why not show the wave display for clk, reset and we?



  5. #5
    Member level 4
    Points: 1,414, Level: 8

    Join Date
    Dec 2011
    Posts
    77
    Helped
    0 / 0
    Points
    1,414
    Level
    8

    Re: signal value conflict in VHDL

    Considering

    Code:
    if count = 1 then
        we <= '1';   -- this is where 'we' is activated
    end if;
    the cou signal in the picture is actually the count. As you can see, when cou is 1, the value of we becomes X. If the previous value of we is U (according to the wave figure) and the new value of we is 1 (due to count=1), then according to the resolution table , the value should be U (1 and U is U).



    •   Alt9th July 2017, 14:18

      advertising

        
       

  6. #6
    Super Moderator
    Points: 236,416, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    40,889
    Helped
    12495 / 12495
    Points
    236,416
    Level
    100

    Re: signal value conflict in VHDL

    First observation, there's no reset pulse at all. Respectively, we has initial state of 'U' (uninitialized) instead of '0'. Please correct.

    we should be still set to '1' at 6 ns, thus it either has multiple drivers, or the actual logic is different from the posted code in other regards. Let's check again with working reset. We should also see the count logic.



  7. #7
    Member level 4
    Points: 1,414, Level: 8

    Join Date
    Dec 2011
    Posts
    77
    Helped
    0 / 0
    Points
    1,414
    Level
    8

    Re: signal value conflict in VHDL

    First observation, there's no reset pulse at all.
    The signal r: std_logic := '1'; in the testbench is the reset signal connected to the rst port of the components.

    Code:
    Respectively, we has initial state of 'U' (uninitialized) instead of '0'
    Yes and that is the problem as I saw in the picture.

    we should be still set to '1' at 6 ns, thus it either has multiple drivers
    Well yes it has multiple sources if you look at the detector code. It is driven by explicit '0' and '1' in two processes.

    Let me try to write a minimal code to test only that situation. I will come back again.

    - - - Updated - - -

    Here is an example code. Please see the files
    test_detector.vhd
    test_write.vhd
    test_tb.vhd

    I also uploaded a picture of the test code.
    As you can see in the test_tb, count gets inital value of 2, but r inital value is seen as 0? Why? Because I set r to 0 in the process of test_tb?



    •   Alt9th July 2017, 16:07

      advertising

        
       

  8. #8
    Super Moderator
    Points: 236,416, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    40,889
    Helped
    12495 / 12495
    Points
    236,416
    Level
    100

    Re: signal value conflict in VHDL

    Please try a regular text book template for operating reset.

    Code:
    process
    begin
        r <= '1';
        wait for 4 ns;
        r <= '0';
        wait;
    end process;



  9. #9
    Member level 4
    Points: 1,414, Level: 8

    Join Date
    Dec 2011
    Posts
    77
    Helped
    0 / 0
    Points
    1,414
    Level
    8

    Re: signal value conflict in VHDL

    Then we will always be U
    !
    I remember a problem with ActiveHDL v10.1 which was fixed with 10.3 student version (same codes). So, if someone check the test example in my previous post with his tool, I appreciate that.

    - - - Updated - - -

    I also checked with ISE 14 and got the same result. The we remains U



  10. #10
    Advanced Member level 5
    Points: 34,876, Level: 45
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,390
    Helped
    1861 / 1861
    Points
    34,876
    Level
    45

    Re: signal value conflict in VHDL

    Lets go through the problems here:
    1. While r (reset) is initialised to '1', it is set to '0' at time 0ns. In VHDL, all processes are started at time 0, so r gets set to '0' immediatly.
    2. This is why we never gets set '0' and remains at 'U' until the count gets to 1 (when it goes to '1').
    3. If you do assert reset, we will be '0' until count gets to 1, where it will become 'X', as you have two processes driving we.
    4. Why is the clock set to 250Mhz?

    Your code is very simple code - and I doubt would be affected by any bugs in ActiveHDL.



  11. #11
    Member level 4
    Points: 1,414, Level: 8

    Join Date
    Dec 2011
    Posts
    77
    Helped
    0 / 0
    Points
    1,414
    Level
    8

    Re: signal value conflict in VHDL

    Well I use the idea we discussed here which is setting an initial value and change it in the process of the testbench. At least this is what I understood from the previous topic. If I misunderstood, please let me know.


    1. While r (reset) is initialised to '1', it is set to '0' at time 0ns. In VHDL, all processes are started at time 0, so r gets set to '0' immediatly.
    Is that a simulation model? Is it possible to set 1 at time 0?

    I agree with you, if r is initially set to 0, the condition is not true and we will be U.
    I want to set the reset to 1 initially and then set it to 0 after a delay.



  12. #12
    Advanced Member level 5
    Points: 34,876, Level: 45
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,390
    Helped
    1861 / 1861
    Points
    34,876
    Level
    45

    Re: signal value conflict in VHDL

    FVM gave you the code for that already, http://www.edaboard.com/showthread.p...=1#post1582118



  13. #13
    Member level 4
    Points: 1,414, Level: 8

    Join Date
    Dec 2011
    Posts
    77
    Helped
    0 / 0
    Points
    1,414
    Level
    8

    Re: signal value conflict in VHDL

    Well it doesn't work as I said....


    Please see the attached pictures. As you can see in the first picture, the we remains U all the time regardless of the value of r.

    In the second picture, I intentionally assigned 1 to the count, so that the condition inside the clk process becomes true. In other words, at the raising edge of the clock and with the correct condition, 1 is given to we. What is the result? we becomes X.



    P.S: I don't know why the thread has been marked as solved....
    Last edited by mahmood.n; 10th July 2017 at 02:53.



    •   Alt10th July 2017, 02:47

      advertising

        
       

  14. #14
    Super Moderator
    Points: 236,416, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    40,889
    Helped
    12495 / 12495
    Points
    236,416
    Level
    100

    Re: signal value conflict in VHDL

    Something is obviously missing in the posted code snippets. z is assigned 7 and we 'X' at the same time. Usual reason, we has multiple drivers.

    Useless discussion without a complete, compilable code example.



  15. #15
    Member level 4
    Points: 1,414, Level: 8

    Join Date
    Dec 2011
    Posts
    77
    Helped
    0 / 0
    Points
    1,414
    Level
    8

    Re: signal value conflict in VHDL

    Well I have uploaded the codes in previous posts. You can check and simulate it.

    I have found that if I use one process (instead of two), then it will be fine. I mean, instead of

    Code:
    process( rst )
    process( clk )
    I wrote

    Code:
    procss( clk, rst )
    Have no idea what is the difference between these two since my code uses std_logic which is the resolved version.



  16. #16
    Advanced Member level 5
    Points: 34,876, Level: 45
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,390
    Helped
    1861 / 1861
    Points
    34,876
    Level
    45

    Re: signal value conflict in VHDL

    Quote Originally Posted by mahmood.n View Post
    Well I have uploaded the codes in previous posts. You can check and simulate it.

    I have found that if I use one process (instead of two), then it will be fine. I mean, instead of

    Code:
    process( rst )
    process( clk )
    I wrote

    Code:
    procss( clk, rst )
    Have no idea what is the difference between these two since my code uses std_logic which is the resolved version.
    Its a resolved signal, but you're creating 2 drivers for 1 signal, which results in 'X' - iots trying to drive a '1' and '0' at the same time on the same signal - so what do you expect it to be?
    This is illegal in an FPGA anyway - so stop now.


    1 members found this post helpful.

  17. #17
    Super Moderator
    Points: 27,697, Level: 40
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    6,323
    Helped
    1535 / 1535
    Points
    27,697
    Level
    40

    Re: signal value conflict in VHDL

    Quote Originally Posted by mahmood.n View Post
    Code:
    process( rst )
    process( clk )
    I noticed this back in post #1, I was waiting patiently for someone else to point it out.

    As much as others seem to think software concepts apply to HDL. I'm thinking this was a case of two software concepts that once again don't apply to HDLs.

    1. you can't rely on the sequential ordering of the code to expect something to occur first before something else...we rst has priority over we generation based on count due to the ordering of the process statements.
    process statements are concurrent. So for hardware they represent parallel pieces of logic. Within a single process the statements are usually sequentially ordered (though this is not required, though is usually how simulators order them, so you can't rely on this), variables though are sequentially ordered as they are immediately updated.

    2. you can't assign the same signal on multiple lines of code like software...you can only assign to the same signal within the same process to not end up with multiple drivers.
    different process will generate drivers for each signal in the process, so having multiple process driving the same signal will result in multiple drivers. My recommended rule is 1 signal == 1 process, which may be more verbose (in an already overly verbose language) but avoids any problems with multiple drivers and avoids issues where overly complex if statements with logic holes due to having multiple signals in each branch of an if or case statement that don't all have the exact same conditions.


    1 members found this post helpful.

--[[ ]]--