Clock Edge notation

A

ALuPin

Hi,

I have a question concerning the following phenomenon:

I have a signal which is registered by the following way:


entity xy is
port (...
DQS : inout std_logic_vector(15 downto 0);
);
end xy;

architecture zy of xy is
signal l_input_cell : std_logic_vector(15 downto 0);
begin

process(Reset, Clk)
begin
if Reset='1' then
l_input_cell <= (others => '0');
elsif rising_edge(Clk) then
l_input_cell <= DQS;
end if;
end process;
end zy;

When I simulated the design (I had changed a different design to my
own
VHDL style) I got different simulation results (functional simulation
Modelsim) with respect to the signal "l_input_cell".

Then I changed "rising_edge(Clk)" back to "Clk'event and Clk='1'" and
I got the same result as in the original design.

So why is there a difference at all?
Does the use of an INOUT port play any role ?

I would appreciate your help.

Kind regards

André
 
J

Jim Lewis

ALuPin,
First read Allan's post.

Bottom line, if Clk is doing a normal 0-1 transition,
these two are equivalent. Highlighting the differences:
rising_edge(Clk) finds 0-1, L-1, 0-H, L-H transitions of Clk
clk='1' and Clk'event finds all changes except 1-1.

If your problem only occurs at time 0, you have run into a
well known issue that is easy to avoid. See below.
If this happens at times other than time 0, the clock
net is misbehaving and it probably needs to be fixed.
I would not consider an X-1 transition of clock a valid
functional clock.

From a different point of view, how are you deciding
that your designs are different? If you mask out
things that occur before reset is applied, are they
the same?


Avoiding time 0 Problems
--------------------------
To avoid time 0 problems, I start clock at the inactive
edge and I initialize it:

signal Clk : std_logic := '0' ;
.. . .

Clk <= not Clk after tperiod_Clk/2 ;

-- or --

process begin
Clk <= '0' ;
wait for tperiod_Clk/2 ;
Clk <= '1' ;
wait for tperiod_Clk/2 ;
end process ;


Use the form that matches your current clock driving methodology.
Although I recommend the first form for new projects, I do
not recommend switching after you have built and run testbenches
because differences in execution of testbenches that can result.
To illuminate this, consider the code below (note Sel is driven
only so you can see the differences in the two clock setups).

Sel <= '0' after tpd ; -- where tpd << tperiod_Clk
wait for 10 * tperiod_Clk ; --
wait until Clk = '1' ; -- align with clock
Sel <= '1' after tpd ;

Simulation differences here are due to differences in
delta cycle setup time of the clocks above.

Long term, when using wait for that is a function of
your clock period, I using the following:

wait for 10*tperiod_Clk - tpd ;
wait until Clk = '1' ;


Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
R

rickman

ALuPin said:
Hi,

I have a question concerning the following phenomenon:

I have a signal which is registered by the following way:

entity xy is
port (...
DQS : inout std_logic_vector(15 downto 0);
);
end xy;

architecture zy of xy is
signal l_input_cell : std_logic_vector(15 downto 0);
begin

process(Reset, Clk)
begin
if Reset='1' then
l_input_cell <= (others => '0');
elsif rising_edge(Clk) then
l_input_cell <= DQS;
end if;
end process;
end zy;

When I simulated the design (I had changed a different design to my
own
VHDL style) I got different simulation results (functional simulation
Modelsim) with respect to the signal "l_input_cell".

Then I changed "rising_edge(Clk)" back to "Clk'event and Clk='1'" and
I got the same result as in the original design.

So why is there a difference at all?
Does the use of an INOUT port play any role ?

I can't say that the INOUT port would make a difference since you never
assign a value to DQS. But there is a difference between the two clock
edge descriptions. I don't recall how "rising_edge()" is defined, but
it is not the same as "Clk'event and Clk='1'". Even so, I would not
expect a difference in how the two operate unless CLK has values other
than '1' and '0'.

I belive "Clk'event and Clk='1'" will detect a transistion from *any*
value to '1' as a valid clock edge, while "rising_edge(Clk)" requires
the previous state to be '0' or possibly 'L'. Does you simulation allow
Clk to be undefined with a 'Z', 'U' or 'X'?


--

Rick "rickman" Collins

(e-mail address removed)
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,766
Messages
2,569,569
Members
45,042
Latest member
icassiem

Latest Threads

Top