OSERDES output data delay - Page 1
Forum section: electronics / general

author: alexeyey_0
author_rank: Newbie
timestamp: April 02, 2025, 11:31:54 am
content: Hello everyone, I'm currently writing an image processing project on systemverilog (somewhat similar to MIPI DSI). When working with the Xilinx ip block, I encountered such a problem that the data is not displayed at the moment specified in the specification. I decided to compare the implementation on systemverilog and on vhdl. The result: there is a 0.1 ps delay on sv, and data is displayed strictly in clock cycles on vhdl. I want to get the result as on vhdl, that is, without delays in sending data to the output transmission line. What could be the problem and how to solve it? I am attaching 2 testbench, one is written strictly on sv, the other on vhdl. I also attach 2 time charts.: 1 - sv, 2 - vhdl1. sv tbCode:`timescale 1ns / 1psmodule tb_dvi;logic clk = 0;logic clk_x5 = 0;logic [9:0] data = 10'b0;logic reset = 1;logic serial;logic shift1;logic shift2;logic ce_delay;logic [7:0] reset_delay;localparam time clock_period = 20;// Master OSERDESE2OSERDESE2 #(.DATA_RATE_OQ("DDR"),.DATA_RATE_TQ("DDR"),.DATA_WIDTH(10),.INIT_OQ(1'b1),.INIT_TQ(1'b1),.SERDES_MODE("MASTER"),.SRVAL_OQ(1'b0),.SRVAL_TQ(1'b0),.TBYTE_CTL("FALSE"),.TBYTE_SRC("FALSE"),.TRISTATE_WIDTH(1)) master_serdes (.OFB(),.OQ(serial),.SHIFTOUT1(),.SHIFTOUT2(),.TBYTEOUT(),.TFB(),.TQ(),.CLK(clk_x5),.CLKDIV(clk),.D1(data),.D2(data),.D3(data),.D4(data),.D5(data),.D6(data),.D7(data),.D8(data),.OCE(ce_delay),.RST(reset),.SHIFTIN1(shift1),.SHIFTIN2(shift2),.T1(1'b0),.T2(1'b0),.T3(1'b0),.T4(1'b0),.TBYTEIN(1'b0),.TCE(1'b0));// Slave OSERDESE2OSERDESE2 #(.DATA_RATE_OQ("DDR"),.DATA_RATE_TQ("DDR"),.DATA_WIDTH(10),.INIT_OQ(1'b1),.INIT_TQ(1'b1),.SERDES_MODE("SLAVE"),.SRVAL_OQ(1'b0),.SRVAL_TQ(1'b0),.TBYTE_CTL("FALSE"),.TBYTE_SRC("FALSE"),.TRISTATE_WIDTH(1)) slave_serdes (.OFB(),.OQ(),.SHIFTOUT1(shift1),.SHIFTOUT2(shift2),.TBYTEOUT(),.TFB(),.TQ(),.CLK(clk_x5),.CLKDIV(clk),.D1(1'b0),.D2(1'b0),.D3(data),.D4(data),.D5(1'b0),.D6(1'b0),.D7(1'b0),.D8(1'b0),.OCE(ce_delay),.RST(reset),.SHIFTIN1(1'b0),.SHIFTIN2(1'b0),.T1(1'b0),.T2(1'b0),.T3(1'b0),.T4(1'b0),.TBYTEIN(1'b0),.TCE(1'b0));always_ff @(posedge clk) begince_delay <= ~reset;endinitial forever #(clock_period / 4) clk = ~clk;initial forever #(clock_period / 20) clk_x5 = ~clk_x5;initial begin#200 reset = 0;#200 data = 10'b1100010101; // 10'h315#20 data = 10'b1100110101; // 10'h335#20 data = 10'b1100100100; // 10'h324#20 $finish;endendmodule2. vhdl tbCode:library IEEE;use IEEE.STD_LOGIC_1164.ALL;library UNISIM;use UNISIM.VComponents.all;ENTITY tb_ser ISEND tb_ser;ARCHITECTURE behavior OF tb_ser ISsignal clk : std_logic := '0';signal clk_x5 : std_logic := '0';signal data : std_logic_vector(9 downto 0) := (others => '0');signal reset : std_logic := '1'; -- Начальное состояние '1'signal serial : std_logic := '0';signal shift1 : std_logic := '0';signal shift2 : std_logic := '0';signal ce_delay : std_logic := '0';signal reset_delay : std_logic_vector(7 downto 0) := (others => '0');constant clock_period : time := 20 ns;BEGINmaster_serdes : OSERDESE2generic map (DATA_RATE_OQ => "DDR", -- DDR, SDRDATA_RATE_TQ => "DDR", -- DDR, BUF, SDRDATA_WIDTH => 10, -- Parallel data width (2-8,10,14)INIT_OQ => '1', -- Initial value of OQ output (1'b0,1'b1)INIT_TQ => '1', -- Initial value of TQ output (1'b0,1'b1)SERDES_MODE => "MASTER", -- MASTER, SLAVESRVAL_OQ => '0', -- OQ output value when SR is used (1'b0,1'b1)SRVAL_TQ => '0', -- TQ output value when SR is used (1'b0,1'b1)TBYTE_CTL => "FALSE", -- Enable tristate byte operation (FALSE, TRUE)TBYTE_SRC => "FALSE", -- Tristate byte source (FALSE, TRUE)TRISTATE_WIDTH => 1 -- 3-state converter width (1,4))port map (OFB => open,OQ => serial,SHIFTOUT1 => open,SHIFTOUT2 => open,TBYTEOUT => open,TFB => open,TQ => open,CLK => clk_x5,CLKDIV => clk,D1 => data(0),D2 => data(1),D3 => data(2),D4 => data(3),D5 => data(4),D6 => data(5),D7 => data(6),D8 => data(7),OCE => ce_delay,RST => reset,SHIFTIN1 => SHIFT1,SHIFTIN2 => SHIFT2,T1 => '0',T2 => '0',T3 => '0',T4 => '0',TBYTEIN => '0',TCE => '0');slave_serdes : OSERDESE2generic map (DATA_RATE_OQ => "DDR",DATA_RATE_TQ => "DDR",DATA_WIDTH => 10,INIT_OQ => '1',INIT_TQ => '1',SERDES_MODE => "SLAVE",SRVAL_OQ => '0',SRVAL_TQ => '0',TBYTE_CTL => "FALSE",TBYTE_SRC => "FALSE",TRISTATE_WIDTH => 1)port map (OFB => open,OQ => open,SHIFTOUT1 => shift1,SHIFTOUT2 => shift2,TBYTEOUT => open,TFB => open,TQ => open,CLK => clk_x5,CLKDIV => clk,D1 => '0',D2 => '0',D3 => data(8),D4 => data(9),D5 => '0',D6 => '0',D7 => '0',D8 => '0',OCE => ce_delay,RST => reset,SHIFTIN1 => '0',SHIFTIN2 => '0',T1 => '0',T2 => '0',T3 => '0',T4 => '0',TBYTEIN => '0',TCE => '0');delay_ce: process(clk)beginif rising_edge(clk) thence_delay <= not reset;end if;end process;-- Генерация основного тактового сигнала (clk 50 MHz)clock_process : processbeginwhile true loopclk <= '0';wait for clock_period / 4;clk <= '1';wait for clock_period / 4;end loop;end process;-- Генерация быстрого тактового сигнала (clk_x5 250 MHz)clock_x5_process : processbeginwhile true loopclk_x5 <= '0';wait for clock_period / 20;clk_x5 <= '1';wait for clock_period / 20;end loop;end process;-- Стимулы для тестированияstim_proc: processbeginwait for 200 ns;reset <= '0'; -- Сброс выключенwait for 200 ns;-- Подача данных на входdata <= "1100010101"; -- 10'h315 в двоичном форматеwait for 20 ns;data <= "1100110101"; -- 10'h335wait for 20 ns;data <= "1100100100"; -- 10'h324wait for 20 ns;wait;end process;END behavior;

author: asmi
author_rank: Super Contributor
timestamp: April 02, 2025, 01:25:06 pm
content: Your clocks are aligned differently in those two tests. And I hope you do know that this is NOT the proper way to clock these blocks - you HAVE to use MCMM/PLL to generate phase-aligned clocks.Another thing - as per spec, youneedto reset these blocks in the beginning before you can use them so that you can synchronize several blocks as otherwise their internal state might not be aligned.

author: alexeyey_0
author_rank: Newbie
timestamp: April 02, 2025, 01:36:41 pm
content: Quote from: asmi on April 02, 2025, 01:25:06 pmHow can my clocks be aligned differently if I look at the timeline and they are the same?I'll try to connect the MCMM and see what happens, thanks.I reset these blocks at the beginning: initialize reset 1 and then lower it to 0

author: alexeyey_0
author_rank: Newbie
timestamp: April 02, 2025, 01:51:35 pm
content: Quote from: alexeyey_0 on April 02, 2025, 01:36:41 pmNothing changed1. sv tb (added mcmm)Code:`timescale 1ns / 1psmodule tb_dvi;logic clk = 0;logic [9:0] data = 10'b0;logic reset = 1;logic serial;logic shift1;logic shift2;logic ce_delay;logic [7:0] reset_delay;logic clk_50;logic clk_250;logic clkfb;localparam time clock_period = 10;MMCME2_BASE #(.BANDWIDTH ( "OPTIMIZED" ),.DIVCLK_DIVIDE ( 1 ),.CLKFBOUT_MULT_F ( 10.0 ),.CLKFBOUT_PHASE ( 0.0 ),.CLKIN1_PERIOD ( 10.0 ),.CLKOUT0_DIVIDE_F ( 1.0 ),.CLKOUT1_DIVIDE ( 20 ),.CLKOUT2_DIVIDE ( 4 ),.CLKOUT3_DIVIDE ( 1 ),.CLKOUT4_DIVIDE ( 1 ),.CLKOUT5_DIVIDE ( 1 ),.CLKOUT6_DIVIDE ( 1 ),.CLKOUT0_DUTY_CYCLE ( 0.5 ),.CLKOUT1_DUTY_CYCLE ( 0.5 ),.CLKOUT2_DUTY_CYCLE ( 0.5 ),.CLKOUT3_DUTY_CYCLE ( 0.5 ),.CLKOUT4_DUTY_CYCLE ( 0.5 ),.CLKOUT5_DUTY_CYCLE ( 0.5 ),.CLKOUT6_DUTY_CYCLE ( 0.5 ),.CLKOUT0_PHASE ( 0.0 ),.CLKOUT1_PHASE ( 0.0 ),.CLKOUT2_PHASE ( 0.0 ),.CLKOUT3_PHASE ( 0.0 ),.CLKOUT4_PHASE ( 0.0 ),.CLKOUT5_PHASE ( 0.0 ),.CLKOUT6_PHASE ( 0.0 ),.CLKOUT4_CASCADE ( "FALSE" ),.REF_JITTER1 ( 0.0 ),.STARTUP_WAIT ( "FALSE" )) MMCME2_BASE_inst (.CLKOUT0 ( ),.CLKOUT0B ( ),.CLKOUT1 ( clk_50 ),.CLKOUT1B ( ),.CLKOUT2 ( clk_250 ),.CLKOUT2B ( ),.CLKOUT3 ( ),.CLKOUT3B ( ),.CLKOUT4 ( ),.CLKOUT5 ( ),.CLKOUT6 ( ),.CLKFBOUT ( clkfb ),.CLKFBOUTB ( ),.LOCKED ( locked_o ),.CLKIN1 ( clk ),.PWRDWN ( 0 ),.RST ( 0 ),.CLKFBIN ( clkfb ));// Master OSERDESE2OSERDESE2 #(.DATA_RATE_OQ ( "DDR" ),.DATA_RATE_TQ ( "DDR" ),.DATA_WIDTH ( 10 ),.INIT_OQ ( 1'b1 ),.INIT_TQ ( 1'b1 ),.SERDES_MODE ( "MASTER" ),.SRVAL_OQ ( 1'b0 ),.SRVAL_TQ ( 1'b0 ),.TBYTE_CTL ( "FALSE" ),.TBYTE_SRC ( "FALSE" ),.TRISTATE_WIDTH ( 1 )) master_serdes (.OFB ( ),.OQ ( serial ),.SHIFTOUT1 ( ),.SHIFTOUT2 ( ),.TBYTEOUT ( ),.TFB ( ),.TQ ( ),.CLK ( clk_250 ),.CLKDIV ( clk_50 ),.D1 ( data ),.D2 ( data ),.D3 ( data ),.D4 ( data ),.D5 ( data ),.D6 ( data ),.D7 ( data ),.D8 ( data ),.OCE ( ce_delay ),.RST ( reset ),.SHIFTIN1 ( shift1 ),.SHIFTIN2 ( shift2 ),.T1 ( 1'b0 ),.T2 ( 1'b0 ),.T3 ( 1'b0 ),.T4 ( 1'b0 ),.TBYTEIN ( 1'b0 ),.TCE ( 1'b0 ));// Slave OSERDESE2OSERDESE2 #(.DATA_RATE_OQ ( "DDR" ),.DATA_RATE_TQ ( "DDR" ),.DATA_WIDTH ( 10 ),.INIT_OQ ( 1'b1 ),.INIT_TQ ( 1'b1 ),.SERDES_MODE ( "SLAVE" ),.SRVAL_OQ ( 1'b0 ),.SRVAL_TQ ( 1'b0 ),.TBYTE_CTL ( "FALSE" ),.TBYTE_SRC ( "FALSE" ),.TRISTATE_WIDTH ( 1 )) slave_serdes (.OFB ( ),.OQ ( ),.SHIFTOUT1 ( shift1 ),.SHIFTOUT2 ( shift2 ),.TBYTEOUT ( ),.TFB ( ),.TQ ( ),.CLK ( clk_250 ),.CLKDIV ( clk_50 ),.D1 ( 1'b0 ),.D2 ( 1'b0 ),.D3 ( data ),.D4 ( data ),.D5 ( 1'b0 ),.D6 ( 1'b0 ),.D7 ( 1'b0 ),.D8 ( 1'b0 ),.OCE ( ce_delay ),.RST ( reset ),.SHIFTIN1 ( 1'b0 ),.SHIFTIN2 ( 1'b0 ),.T1 ( 1'b0 ),.T2 ( 1'b0 ),.T3 ( 1'b0 ),.T4 ( 1'b0 ),.TBYTEIN ( 1'b0 ),.TCE ( 1'b0 ));always_ff @( posedge clk ) begince_delay <= ~reset;endinitial forever #( clock_period / 2 ) clk = ~clk;// initial forever #( clock_period / 4 ) clk = ~clk;// initial forever #( clock_period / 20 ) clk_x5 = ~clk_x5;initial begin#200;reset = 0;#200;data = 10'b1100010101; // 10'h315#20;data = 10'b1100110101; // 10'h335#20;data = 10'b1100100100; // 10'h324#20;$finish;endendmodule2. vhdl tb (added mcmm)Code:library IEEE;use IEEE.STD_LOGIC_1164.ALL;library UNISIM;use UNISIM.VComponents.all;ENTITY tb_ser ISEND tb_ser;ARCHITECTURE behavior OF tb_ser ISsignal clk : std_logic := '0';signal data : std_logic_vector(9 downto 0) := (others => '0');signal reset : std_logic := '1';signal serial : std_logic := '0';signal shift1 : std_logic := '0';signal shift2 : std_logic := '0';signal ce_delay : std_logic := '0';signal reset_delay : std_logic_vector(7 downto 0) := (others => '0');constant clock_period : time := 10 ns;signal clk_50 : std_logic := '0';signal clk_250 : std_logic := '0';signal clkfb : std_logic := '0';signal locked : std_logic := '0';BEGINMMCME2_BASE_inst : MMCME2_BASEgeneric map (BANDWIDTH => "OPTIMIZED",DIVCLK_DIVIDE => 1,CLKFBOUT_MULT_F => 10.0,CLKFBOUT_PHASE => 0.0,CLKIN1_PERIOD => 10.0,CLKOUT0_DIVIDE_F => 1.0,CLKOUT1_DIVIDE => 20,CLKOUT2_DIVIDE => 4,CLKOUT3_DIVIDE => 1,CLKOUT4_DIVIDE => 1,CLKOUT5_DIVIDE => 1,CLKOUT6_DIVIDE => 1,CLKOUT0_DUTY_CYCLE => 0.5,CLKOUT1_DUTY_CYCLE => 0.5,CLKOUT2_DUTY_CYCLE => 0.5,CLKOUT3_DUTY_CYCLE => 0.5,CLKOUT4_DUTY_CYCLE => 0.5,CLKOUT5_DUTY_CYCLE => 0.5,CLKOUT6_DUTY_CYCLE => 0.5,CLKOUT0_PHASE => 0.0,CLKOUT1_PHASE => 0.0,CLKOUT2_PHASE => 0.0,CLKOUT3_PHASE => 0.0,CLKOUT4_PHASE => 0.0,CLKOUT5_PHASE => 0.0,CLKOUT6_PHASE => 0.0,CLKOUT4_CASCADE => FALSE,REF_JITTER1 => 0.0,STARTUP_WAIT => FALSE) port map (CLKOUT0 => open,CLKOUT0B => open,CLKOUT1 => clk_50,CLKOUT1B => open,CLKOUT2 => clk_250,CLKOUT2B => open,CLKOUT3 => open,CLKOUT3B => open,CLKOUT4 => open,CLKOUT5 => open,CLKOUT6 => open,CLKFBOUT => clkfb,CLKFBOUTB => open,LOCKED => locked,CLKIN1 => clk,PWRDWN => '0',RST => '0',CLKFBIN => clkfb);master_serdes : OSERDESE2generic map (DATA_RATE_OQ => "DDR",DATA_RATE_TQ => "DDR",DATA_WIDTH => 10,INIT_OQ => '1',INIT_TQ => '1',SERDES_MODE => "MASTER",SRVAL_OQ => '0',SRVAL_TQ => '0',TBYTE_CTL => "FALSE",TBYTE_SRC => "FALSE",TRISTATE_WIDTH => 1) port map (OFB => open,OQ => serial,SHIFTOUT1 => open,SHIFTOUT2 => open,TBYTEOUT => open,TFB => open,TQ => open,CLK => clk_250,CLKDIV => clk_50,D1 => data(0),D2 => data(1),D3 => data(2),D4 => data(3),D5 => data(4),D6 => data(5),D7 => data(6),D8 => data(7),OCE => ce_delay,RST => reset,SHIFTIN1 => SHIFT1,SHIFTIN2 => SHIFT2,T1 => '0',T2 => '0',T3 => '0',T4 => '0',TBYTEIN => '0',TCE => '0');slave_serdes : OSERDESE2generic map (DATA_RATE_OQ => "DDR",DATA_RATE_TQ => "DDR",DATA_WIDTH => 10,INIT_OQ => '1',INIT_TQ => '1',SERDES_MODE => "SLAVE",SRVAL_OQ => '0',SRVAL_TQ => '0',TBYTE_CTL => "FALSE",TBYTE_SRC => "FALSE",TRISTATE_WIDTH => 1) port map (OFB => open,OQ => open,SHIFTOUT1 => shift1,SHIFTOUT2 => shift2,TBYTEOUT => open,TFB => open,TQ => open,CLK => clk_250,CLKDIV => clk_50,D1 => '0',D2 => '0',D3 => data(8),D4 => data(9),D5 => '0',D6 => '0',D7 => '0',D8 => '0',OCE => ce_delay,RST => reset,SHIFTIN1 => '0',SHIFTIN2 => '0',T1 => '0',T2 => '0',T3 => '0',T4 => '0',TBYTEIN => '0',TCE => '0');delay_ce: process(clk) beginif rising_edge(clk) thence_delay <= not reset;end if;end process;clock_process : process beginwhile true loopclk <= '0';wait for clock_period / 2;clk <= '1';wait for clock_period / 2;end loop;end process;-- clock_process : process begin-- while true loop-- clk <= '0';-- wait for clock_period / 4;-- clk <= '1';-- wait for clock_period / 4;-- end loop;-- end process;-- clock_x5_process : process begin-- while true loop-- clk_x5 <= '0';-- wait for clock_period / 20;-- clk_x5 <= '1';-- wait for clock_period / 20;-- end loop;-- end process;stim_proc: process beginwait for 200 ns;reset <= '0';wait for 200 ns;data <= "1100010101"; -- 10'h315wait for 20 ns;data <= "1100110101"; -- 10'h335wait for 20 ns;data <= "1100100100"; -- 10'h324wait for 20 ns;wait;end process;END behavior;

author: asmi
author_rank: Super Contributor
timestamp: April 02, 2025, 02:18:45 pm
content: from UG471:QuoteYou need to keep OSERDES in reset at least until "locked" signal of MCMM goes "high" - which indicates that MCMM is locked on the incoming clock successfully, and output clocks are stable and match requested parameters.

author: alexeyey_0
author_rank: Newbie
timestamp: April 02, 2025, 02:31:28 pm
content: Still have a delay on sv and dont have on vhdl.I try this:1. svCode:.OCE ( ce_delay && locked_o ),.RST ( reset || !locked_o ),2. vhdlCode:OCE => ce_delay and locked,RST => reset or not locked,I replaced it with this in both the master and the slave

author: asmi
author_rank: Super Contributor
timestamp: April 02, 2025, 08:00:29 pm
content: As per UG471, the latency of 10:1 DDR mode is 5 serial clocks ±1 clock if clocks are phase-aligned.But why does that matter at all? In SERDES applications the only thing that ever matters is a relative alignment of several SERDES outputs between each other, so that for example forwarded clock would allow for proper framing in case of Display LVDS or DVI/HDMI protocols. Nobody cares when exactly output begins relatively to inputs as long as it's always the same for all primitives - and this is why reset is required to ensure proper syncronization.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 02, 2025, 09:58:01 pm
content: 0.1 ps of delay, shocking!!

author: nctnico
author_rank: Super Contributor
timestamp: April 02, 2025, 11:01:10 pm
content: This could be a simulation issue. When assigning a clock to a different clock signal in VHDL, the edge will appear 1 clock cycle later. This has to do with how the simulator deals with simulation events. Maybe Verilog is simulated differently.

author: hamster_nz
author_rank: Super Contributor
timestamp: April 03, 2025, 03:56:04 am
content: I took your SV and VHDL modules, and made them have common inputs and outputs, and then run them both at the same time from this top testbench:Code:library IEEE;use IEEE.STD_LOGIC_1164.ALL;use IEEE.NUMERIC_STD.ALL;entity tb_top isend tb_top;architecture Behavioral of tb_top iscomponent tb_ser ISport (clk : in std_logic;reset : in std_logic;data : in std_logic_vector(9 downto 0);serial : out std_logic);END component;component tb_dvi ISport (clk : in std_logic;reset : in std_logic;data : in std_logic_vector(9 downto 0);serial : out std_logic);END component;signal clk : std_logic := '0';signal serial_vhdl : std_logic;signal serial_sv : std_logic;signal reset : std_logic := '1';signal data : std_logic_vector(9 downto 0) := "0101001111";signal difference : std_logic;beginclk_proc: processbeginclk <= '0';wait for 5 ns;clk <= '1';wait for 5 ns;end process;stim_proc: process beginwait for 400 ns;reset <= '0';wait for 400 ns;data <= "1100010101"; -- 10'h315wait for 20 ns;data <= "1100110101"; -- 10'h335wait for 20 ns;data <= "1100100100"; -- 10'h324wait for 20 ns;end process;-- VHDL impelemntationi_tb_ser: tb_ser port map (clk => clk,reset => reset,data => data,serial => serial_vhdl);i_tb_dviz: tb_dvi port map (clk => clk,reset => reset,data => data,serial => serial_sv);difference <= serial_vhdl xor serial_sv;end Behavioral;The simulation shows that after reset the VHDL and SV output are the same.

author: alexeyey_0
author_rank: Newbie
timestamp: April 03, 2025, 07:57:54 am
content: Quote from: asmi on April 02, 2025, 08:00:29 pmQuote from: SiliconWizard on April 02, 2025, 09:58:01 pmI wouldn't have cared if I hadn't been asked to make a signal for verification. I can either make a conditional valid signal for debug only, or I can say count n number of clock cycles and get the data. But I can't do either of the first or the second, because the output data is not synchronized by clock.

author: Tation
author_rank: Regular Contributor
timestamp: April 03, 2025, 12:01:51 pm
content: Use separate clocks for:driving the DUTgenerating stimulito ensure that stimuli are generated slightly after the DUT clock edge. Say CLK_stim is CLK_dut delayed by 1 ps.I think that your issue is the typical delta-delay gotcha often seen in no-delay simulations.NOTE: arrived at this topic by accident. The title is not descriptive IMHO.

author: asmi
author_rank: Super Contributor
timestamp: April 03, 2025, 06:03:26 pm
content: Quote from: alexeyey_0 on April 03, 2025, 07:57:54 amLast sentence makes no sense - output is always synchronized bysomeclock, and receiver will need to have this clock somehow in order to successfully receive the data. if it's not explicitly passed along (like in case of source-synchronous signals), receiver will either need to recover the clock if it's embedded into the signal (this is how most modern serial protocols work), or if receiver knows transmitting clock parameters in advance and can generate a local clock with those parameters - this typically requires dynamic link training to allow receiving to find best sampling points.The goal of verification circuit is not to 100% codify intended behavior via a million of timed transition checks ("at X ps signal A needs to go HIGH"), but to simulate circuit that your DUT connects to and ensure it works properly with whatever outputs your DUT creates.One more thing - functional verification does not simulate any internal delays (routing delays, logic delays, clock tree skew, clock-to-out delays, etc.), and so you can not use it to find out those delays - this is what post-p&r timing sims are for, but they are SLOOOOOOW (because they simulate at a gate level) and so you'd better really need this and know what you are doing, or you can easily waste enormous amount of time without achieving anything useful.

author: glenenglish
author_rank: Frequent Contributor
timestamp: April 09, 2025, 09:21:25 pm
content: try adding an extra layer of naming in the test bench interface. IE DUTname <= aliasname <= testbenchName;I used to find strange things , wrong clock edges/delays in Modelsim if I didnt add an extra level of naming (not extra registers)I never got to the bottom of it in the corner cases, just added extra level ... maybe someone can enlighten me. The Modelsim people thought it was something to do with the XIlinx Black Box interface between languages.anyway : As ASMI says....0) use an MMCM(the datasheet says you must, so you must)1) put the resets in. 2) tie in the MMCM stable outputs.check what it does in the ILAin real hardware.... THENif it works, then check if it still behaves correctly if, in a running system, pull reset (warm start) and let it go (IE state recovered) . If it warm starts correctly, you probably have a usable system....if my stuff doesnt run from a warm reset, then I know I have not taken care of all reset considerations or init paths....