Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Problem to simulate project when updating IP made in Vivado 2013.4

Status
Not open for further replies.

Cesar0182

Member level 5
Joined
Feb 18, 2019
Messages
85
Helped
0
Reputation
0
Reaction score
0
Trophy points
6
Activity points
825
greetings ... firstly, I said that I am new by personalizing an IP core and a couple of days ago they gave me a project which uses IPs that were made in Vivado 2013.4. I am currently using Vivado 2018.3, but do not update any of these IPs to a new version, even though I did not have any problem to be able to synthesize, simulate (Modelsim SE 10.5) and implement this project. But now there is a requirement which implies increasing the memory of an IP based on fifo generator v11.0, to try to modify this value I have to update to version v13.2, once updated try to configure some parameters through Re-customize IP and I did not have problems to synthesize, but the simulation did not work anymore, so I returned to re-establish the IP configuration to its previous values ​​and even then I could not simulate correctly again. Apparently the problem is the new version of fifo generator, because I made the change of this IP that did not work for the original version (v11.0) and the simulation came back to work again.
Somebody please that you can help me with this problem, because the simulation works with one version and not with the other. Thanks in advance.
 

Just saying "it doesn't work" tells us absolutely nothing. What are the differences? Have you read the release notes for the new IP generator? Have you looked through the Xilinx website for any information pertinent to the new IP?
 

I would just download and install 2013.4 and generate the modified IP with that version. I've found that upgrading from a really old version of the tools to a new one can result in issues like you are experiencing. Unless it's absolutely necessary or there is a software bug that shows up using the version that the original design was done under results in less headaches in the long run.

If you are stuck with 2018.3 then I suggest instead of updating and re-customize the core, update and then run a simulation to verify that the core's behavior is the same, if not modify the design and/or re-customize the core to behave the same as the previous version. Sometimes they change the defaults (or add new parameters) of a core that make a new core incompatible with the old one.

I've also had better success with updating from older core versions by upgrading through at minimum major tool versions. e.g. 2013.4 core, upgrade to 2014.4, 2015.4, 2016,4, 2017.4, then finally upgrade to 2018.3
 

thanks for your answers ... following the recommendation of Add-ee only update the core and run the simulation, but the problem persists and is the one shown in the following images.

Passed Simulation

passed_sim.PNG

Failed Simulation

failed_sim.PNG

At the moment I do not have a detailed idea of ​​how the module works where the fifos are, but basically it can be seen that in the new version two output signals are added that as far as I read in the documentation of v13.2, these signals they are valid only for UltraScale devices, but even so there is variation in the operation of the rd_en signal and therefore an incorrect reading of the data as shown in the dout output.
 

The first rd_en in the working simulation is two clock high pulse, whereas the non-working simulation shows a three clock high pulse. As the rd_en is not controlled by the FIFO the difference in pulse widths indicates some control of the reading of the FIFO is at fault.

The main difference between the two simulations other than this is the clock skew between the two simulations, the wr_en and rd_en in the working simulation are nearly going active at the same time, whereas the read is trailing the write in the non-working simulation. Maybe the design the FIFO is in doesn't properly use the flags or data_counts in the proper clock domain. Without the code for the module that contains the FIFO core we can only guess what the problem is.

- - - Updated - - -

I'd say the rd_en is a combonational signal as there are glitches on the rd_en in the working simulation that may indicate poorly designed read control code.
 

thanks for all the help Add-ee, I attach the vhdl code of the module where these fifos are located.

Code:
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use IEEE.std_logic_unsigned.all;

entity g1_wbus_client_fifos_vhdl is
    Port ( 
			 -- Clock and reset
             i_aur_clk      : IN std_logic;	
             i_rst          : IN std_logic;   

			 -- wbus stack interface
             o_wbus_ready   : OUT std_logic;    
             i_wbus_wen     : IN std_logic;    
             i_wbus_addr    : IN std_logic_vector(31 DOWNTO 0);    
             i_wbus_data    : IN std_logic_vector(31 DOWNTO 0); 

		     -- 26 Client Channels
             i_wbus_enable  : IN std_logic_vector(25 DOWNTO 0);    
             i_wbus_fws     : IN std_logic_vector(129 DOWNTO 0);    
             i_wbus_clk     : IN std_logic_vector(25 DOWNTO 0);    
             o_wbus_empty   : OUT std_logic_vector(25 DOWNTO 0);    
             i_wbus_ren     : IN std_logic_vector(25 DOWNTO 0);    
             o_wbus_count   : OUT std_logic_vector(259 DOWNTO 0);    
             o_wbus_valid   : OUT std_logic_vector(25 DOWNTO 0);    
             o_wbus_wdata   : OUT std_logic_vector(831 DOWNTO 0);    
             o_wbus_waddr   : OUT std_logic_vector(831 DOWNTO 0);    
			 
			 -- Status and Test Points
             o_ro_wbus_debug : OUT std_logic_vector(31 DOWNTO 0);    
             o_test_points  : OUT std_logic_vector(3 DOWNTO 0)
             
    );
end g1_wbus_client_fifos_vhdl;

architecture Behavioral of g1_wbus_client_fifos_vhdl is

Component g1_ipcat_wbus_client_fifo
port(
          rst           : in std_logic;               
          wr_clk        : in std_logic;           
          din           : in std_logic_vector(51 downto 0);               
          wr_en         : in std_logic;                 
          full          : out std_logic;                    
          wr_data_count : out std_logic_vector(9 downto 0);      
       
          -- The Client Port is connected to all the read signals
                                          
          rd_clk        : in std_logic;     
          rd_en         : in std_logic;     
          dout          : out std_logic_vector(51 downto 0);             
          empty         : out std_logic;   
          rd_data_count : out std_logic_vector(9 downto 0);     
          valid         : out std_logic      
);
end component;  

    CONSTANT Almost_Full_Depth : std_logic_vector(9 downto 0) := "0111110100";  
    type  array_26x10 is array(0 to 25) of std_logic_vector(9 downto 0);
    type  array_26x52 is array(0 to 25) of std_logic_vector(51 downto 0);
    SIGNAL almost_full      : std_logic_vector(25 DOWNTO 0);
    SIGNAL ffdin            : std_logic_vector(51 DOWNTO 0);
    SIGNAL ff_dout          : array_26x52;
    SIGNAL ff_write_count   : array_26x10;	
    SIGNAL wbus_count       : array_26x10;	
    SIGNAL wbr_d            : std_logic;
    SIGNAL upper_adrs_match : std_logic;
    SIGNAL wen              : std_logic_vector(25 downto 0);
    SIGNAL almost_full_d    : std_logic_vector(25 downto 0);
    SIGNAL wbus_addr_fws    : std_logic_vector(25 downto 0);
begin
    
    ffdin <= i_wbus_addr(19 downto 0) & i_wbus_data(31 downto 0);
    
    u_client : for idx in 0 to 25 generate
    
    begin       
        o_wbus_count(10*idx+9 downto 10*idx)    <= wbus_count(idx);        
        upper_adrs_match                        <= '1';       
		
        --Write only one fifo by decoding 5 address bits.
        wbus_addr_fws(idx)  <= '1' when (i_wbus_addr(20 downto 16) = i_wbus_fws(5*idx+4 downto 5*idx)) else '0';          
        wen(idx)            <= i_wbus_enable(idx) and i_wbus_wen and upper_adrs_match and wbus_addr_fws(idx);
		
        almost_full_d(idx)  <= i_wbus_enable(idx) and '1' when (ff_write_count(idx) > Almost_Full_Depth) else '0';
        
         dc_amf: entity work.dreg_clr_vhdl generic map(1)
         port map( 
                c   => i_aur_clk, 
                ar  => i_rst, 
                e   =>  '1', 
                d(0)   => almost_full_d(idx), 
                q(0)   => almost_full(idx)  
            );
			
        -- 52 bits x 512, First Word Fall Through.
        U_client_ff: g1_ipcat_wbus_client_fifo  
        port map(
          rst           => i_rst,              
          wr_clk        => i_aur_clk,          
          din           => ffdin,             
          wr_en         => wen(idx),                
          full          => open,                    
          wr_data_count => ff_write_count(idx),      
       
          -- The Client Port is connected to all the read signals
                                          
          rd_clk        => i_wbus_clk(idx),     
          rd_en         => i_wbus_ren(idx),     
          dout          => ff_dout(idx),             
          empty         => o_wbus_empty(idx),   
          rd_data_count => wbus_count(idx),     
          valid         => o_wbus_valid(idx)  
        );            
        o_wbus_waddr(32*idx+31 downto 32*idx)   <= "0000000000000" & ff_dout(idx)(50 downto 32);
        o_wbus_wdata(32*idx+31 downto 32*idx)   <= ff_dout(idx)(31 downto 0);
            
    end generate u_client;
    wbr_d <= NOT (OR almost_full);
    
     dc_wbr : entity work.dreg_clr_vhdl generic map(1)
       PORT MAP (
           c    => i_aur_clk,
           ar   => i_rst,
           e    => '1',
           d(0) => wbr_d,
           q(0) => o_wbus_ready);
           
    o_ro_wbus_debug <= X"E" & "00" & almost_full(25 DOWNTO 0);
    o_test_points <= x"0";              
end Behavioral;
 

You aren't showing the code that generates the rd_en a.k.a. i_wbus_ren(idx), actually all the read signals are not generated in this file. This is just a wrapper for the IP core FIFO to replicate the decode and flag logic for all 26 FIFOs.

You need to trace the logic for the read side (i.e. the Client Port) logic to determine why it's reading incorrectly between the two IP cores.

Debugging a design involves tracing signals back through the code to their source, then looking at the inputs that generate the traced back signal and tracing those back if necessary.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top