signal value conflict in VHDL

[mahmood.n]

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:

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:

        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 :

	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?

[FvM]

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.

[mahmood.n]

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!

[FvM]

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

[mahmood.n]

Considering

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).

[FvM]

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.

[mahmood.n]

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.

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?

[FvM]

Please try a regular text book template for operating reset.

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

[mahmood.n]

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

[TrickyDicky]

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.

[mahmood.n]

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.

[TrickyDicky]

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

[mahmood.n]

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....

[FvM]

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.

[mahmood.n]

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

process( rst )
process( clk )

I wrote

procss( clk, rst )

Have no idea what is the difference between these two since my code uses std_logic which is the resolved version.

[TrickyDicky]

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

process( rst )
process( clk )

I wrote

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.

[ads-ee]

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.