Flip Flop problem (asynchronous or synchronous???? )

Hi everybody,

i have a missunderstanding of the flip flop behavior: usually the output of a flip flop is assigned its input of the previous clock period (that's true for internal signal), but i observed that when i connect the flip flop to an external input the output of the flip flop is assigned to the input of the same clock period: it works like an "asynchronous flip flop", an example of the problem is described below.

anyone of you can explain me the problem or the behavior of this flip flop please? thank you!!!

clk : 01010101010101010101 input : 00001111100000111111 ouput : U0000111110000011111 (expected) output:00000111110000011111 (obtaine)

d=E9claration of the flip flop

process (Reset_n, Clk) begin if (reset_n=3D'0') then Output

The flip flop must behave in the same way whether it is connected to an internal signal or an external signal (how can it know what it is connected to?)

How have you observed this problem? In simulation? In hardware?

Just for fun, I simulated the following code with the XST simulator, and it behaves as expected.

I was having fun trying to understand your post in French :-)

Alan Nishioka

library IEEE; use IEEE.std_logic_1164.all; use IEEE.std_logic_arith.all; use IEEE.std_logic_unsigned.all;

entity goat is port ( Reset_n : in std_logic; Clk : in std_logic; Input : in std_logic; Output : out std_logic ); end goat;

architecture implementation of goat is begin process (Reset_n, Clk) begin if (reset_n='0') then Output

Well that's the digram that i get, as you can see the expected ouput is shifted by one, the first one (in my previous message) includes a blank space,

clk : 01010101010101010101 input : 00001111100000111111 ouput : u00000111110000011111 (expected) output: 00000111110000011111 (obtaine)

what i get is during the presynthese simulation and post synthese simulation.

Sure that the flip flop should behave the same either it s connected to the internal or external signal and that s what i was expecting unfortunatly it wasn't the case.

here the VHDL code, probably you will see some unusefull signals, it is just for testing, can you see any problem in this code??????

(concerning my french message: when i posted it i realized to have more coverage and answers it is better to send an english version :)))))))) )

library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; use ieee.NUMERIC_BIT.all; use ieee.STD_LOGIC_ARITH.all;

------------------------------------

-- entity declaration --

------------------------------------ entity FSM_load is generic(n:integer:=6; s:integer:=6); PORT ( -- input Reset_n : in std_logic; Clk : in std_logic; Start : in std_logic; Data_in : in std_logic; Proc_Ready : in std_logic; Length_q : in std_logic_vector(N-1 downto 0);

Output1 : out std_logic;

-- Output1 : out std_logic_vector (39 downto

0);

-- Output2 : out std_logic_vector (39 downto

0); Output2 : out std_logic;

-- output Reset_n_FSM_Stat : out std_logic; Start_FSM_Stat : out std_logic; Write_en : out std_logic; Seq_element : out std_logic_vector(S-1 downto 0); SRAM_addr : out std_logic_vector(N-1 downto 0) ); end FSM_load;

------------------------------------

-- end if entity declaration --

------------------------------------

------------------------------------

-- archtecture declaration --

------------------------------------

architecture RTL of FSM_load is

-- type declaration type state_fp_ce_type is (S_idle, S0, S1, S2, S3,S4, S5, S6, S7, S8);

-- signal declaration signal state_fp_ce : state_fp_ce_type; signal state_fp_ce_2 : state_fp_ce_type; signal Const : std_logic_vector (S-2 downto 0); signal Shift_en : std_logic; signal Shift_out_en : std_logic; signal Load_en : std_logic; signal Reset_n_local : std_logic; signal Pre_load_reg : std_logic_vector(39 downto 0); signal Load_reg : std_logic_vector(39 downto 0); signal Data_out : std_logic_vector(39 downto 0); signal Count : std_logic_vector(5 downto 0); signal Count_2 : std_logic_vector(5 downto 0); signal SRAM_addr_tmp : std_logic_vector(N-1 downto 0);

signal output_tmp : std_logic;

begin

process ( Reset_n , Clk, Start) begin if reset_n='0' then count '0'); Shift_en if (Proc_Ready = '1') then Reset_n_local

Alan,

Perhaps the confusion is between a (asynchronous) latch, and an edge triggered flip-flop (hence the reference to asynchronous vs. synchronous 'flip-flop' 'bascule' behavior)?

The HDL code, when synthesized, gets implemented in whatever library of hardware is available, based on the instructions given.

If there were no D type edge-triggered flip flops in the library, would the resulting synthesis create one?

Or, would the resulting synthesis use a latch instead? How does one force a latch, or a DFF?

[verilog] "always @(posedge CLK)" infers the synchronous DFF, so there is no latch possible.

If you tried to make a shift-register from placing latches in series and clocking all the clocks at once, you would not get what you need! The synthesis needs to be able to recognize how to build the proper circuit.

Austin

hi, thank you all, for your answers and comments, I simulated the VHDL code of Alan (may be i did some mistake that i can't see :) in the flip flop declaration) and the output of the flip- flop is exactly equal to its input, but usually what's expected from a flip-flop is an output swhich is equal to the input signal shifted by one clock period (assuming that there is no enabling signal), again the problem is faced inly with external signal not with internal signal, i know that there is no difference between internal and external in that case but after simulation (pre and post synthese) there is! personnally i can t find any explanation for that problem,

Regards!!

I think that i found the problem! The problem wasn't in the flip flop declaration but in the testbench, in fact in my testbench the input is changing excatly at the clock edge, in that case the simulator consider the input value : the value excatly after the clock edge, and it is explains why the flip flop has a different behaviour with internal Vs. external, with external i mean input signal generated by user. In the case of internal signal it looks like the simulator considers some delay and .... The solution is to make the input signal changing before or after the clock edge, This solution doesn t solve my problem because my input signal is changing on the clock edge but it is an interpretation of the problem, so the real behaviour will be get with hardware simulation using digital analyser! ( Probably it is the limit of the simulator tools :)) it s just a simulator )

Thank you all for your comments

Amine

The FF is right. The problem is what I would call clock skew. For VHDL- Simulations your FF will get the value it has at the input during the rising edge of clk. This is the first delta tick when clk='1'. If your "external" signal change is faster than your clock distribution, you will see the new value. e.g.: process (clk_ext) sig_ext

Hi Thomas

yes that's what i did in simulation to get the expected signal, but the problem is that my signal is changing whith the clock edge so what i ll do is to use a digital analyzer to send the signal to the fpga and i ll check the FPGA behavior,

thank you, A.