+ Post New Thread
Results 1 to 14 of 14
  1. #1
    Newbie level 4
    Points: 31, Level: 1

    Join Date
    Nov 2017
    Posts
    5
    Helped
    0 / 0
    Points
    31
    Level
    1

    Help tracking down very long synthesis time

    I am using Vivado 2015.4 to synthesize my code. I have a small section of code that I use for debugging and it causes synthesis to take > 30 minutes, whereas, if I don't include this part of the code, synthesis takes about 3.5 minutes. I know from experience that problems like this are hard to track down, and it may be impossible with just this code snippet, but I'm hoping there is some poor practice that I'm using here that you all can point out to me.

    Thanks

    Code:
    type test_ram is array (7 downto 0) of std_logic_vector(31 downto 0);
    signal test_ram_inst : test_ram;
    Code:
    generate_debug : if g_enable_debug = true generate
        
            debug_proc_zap : process(i_zap_clk)
            begin
                if rising_edge(i_zap_clk) then
                    if zap_active = '1' then
                        case count is
                            when 0 => test_ram_inst(0) <= s_i_data & s_q_data;
                            when 1 => test_ram_inst(1) <= s_i_data & s_q_data;
                            when 2 => test_ram_inst(2) <= s_i_data & s_q_data;
                            when 3 => test_ram_inst(3) <= s_i_data & s_q_data;
                            when 4 => test_ram_inst(4) <= s_i_data & s_q_data;
                            when 5 => test_ram_inst(5) <= s_i_data & s_q_data;
                            when 6 => test_ram_inst(6) <= s_i_data & s_q_data;
                            when 7 => test_ram_inst(7) <= s_i_data & s_q_data;
                            when others => null;
                        end case;
                        count <= count + 1;
                    else
                        count <= 0;
                    end if;
                end if;
            end process debug_proc_zap;
        
            debug_proc : process(i_clk)
            begin
                if rising_edge(i_clk) then
                    if i_debug = X"00000000" then
                        o_debug <= std_logic_vector(to_signed(sample_count_from_zap,32));
                    elsif i_debug = X"00000001" then
                        o_debug <= std_logic_vector(to_signed(sample_count_to_lpddr,32));
                    elsif i_debug = X"00000002" then
                        o_debug <= std_logic_vector(to_signed(wr_ack_count,32));
                    elsif i_debug = X"00000003" then
                        o_debug <= std_logic_vector(to_signed(data_read_counter,16)) & std_logic_vector(to_signed(samples_read,16));
                    elsif i_debug = X"00001000" then
                        o_debug <= test_ram_inst(0);
                    elsif i_debug = X"00001001" then
                        o_debug <= test_ram_inst(1);
                    elsif i_debug = X"00001002" then
                        o_debug <= test_ram_inst(2);
                    elsif i_debug = X"00001003" then
                        o_debug <= test_ram_inst(3);
                    elsif i_debug = X"00001004" then
                        o_debug <= test_ram_inst(4);
                    elsif i_debug = X"00001005" then
                        o_debug <= test_ram_inst(5);
                    elsif i_debug = X"00001006" then
                        o_debug <= test_ram_inst(6);
                    elsif i_debug = X"00001007" then
                        o_debug <= test_ram_inst(7);
                    else
                        o_debug <= X"DEADDEAD";
                    end if;
                end if;
            end process debug_proc;
        
        end generate generate_debug;

  2. #2
    Super Moderator
    Points: 27,672, Level: 40
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    6,318
    Helped
    1533 / 1533
    Points
    27,672
    Level
    40

    Re: Help tracking down very long synthesis time

    array code that generates FFs (due to accessing all the test_ram_inst locations simultaneously in the if-else) usually takes a long time to synthesize. Seems rather excessive though going from 3.5 to 30 min for only 8 32-bit registers.



  3. #3
    Advanced Member level 5
    Points: 34,868, Level: 45
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,388
    Helped
    1861 / 1861
    Points
    34,868
    Level
    45

    Re: Help tracking down very long synthesis time

    what is test_ram_inst? how is it declared?



    •   Alt13th November 2017, 22:10

      advertising

        
       

  4. #4
    Newbie level 4
    Points: 31, Level: 1

    Join Date
    Nov 2017
    Posts
    5
    Helped
    0 / 0
    Points
    31
    Level
    1

    Re: Help tracking down very long synthesis time

    Quote Originally Posted by TrickyDicky View Post
    what is test_ram_inst? how is it declared?
    It is an array of 32-bit SLVs

    Code:
    type test_ram is array (7 downto 0) of std_logic_vector(31 downto 0);
    signal test_ram_inst : test_ram;



    •   Alt13th November 2017, 22:33

      advertising

        
       

  5. #5
    Super Moderator
    Points: 27,672, Level: 40
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    6,318
    Helped
    1533 / 1533
    Points
    27,672
    Level
    40

    Re: Help tracking down very long synthesis time

    Still doesn't explain why it takes nearly 10x hit on the synthesis when you are only dealing with 256 FFs. I usually see these kinds of long run times with posted code on edaboard that inadvertently has a generate with 2Kx32 arrays being turned into FFs (instead of the intended block RAM).



  6. #6
    Advanced Member level 3
    Points: 4,711, Level: 16

    Join Date
    Feb 2015
    Posts
    781
    Helped
    230 / 230
    Points
    4,711
    Level
    16

    Re: Help tracking down very long synthesis time

    is this synthesis, or synthesis+implementation?

    Eight 32b registers, while not a RAM, don't really use much resources. That said, if the tools found a difficult timing constraint it might spend a lot of time trying to meet the constraint. This might occur due to the multiple clocks.



    •   Alt14th November 2017, 04:23

      advertising

        
       

  7. #7
    Newbie level 4
    Points: 31, Level: 1

    Join Date
    Nov 2017
    Posts
    5
    Helped
    0 / 0
    Points
    31
    Level
    1

    Re: Help tracking down very long synthesis time

    Quote Originally Posted by vGoodtimes View Post
    is this synthesis, or synthesis+implementation?

    Eight 32b registers, while not a RAM, don't really use much resources. That said, if the tools found a difficult timing constraint it might spend a lot of time trying to meet the constraint. This might occur due to the multiple clocks.
    This is for synthesis only. Implementation actually doesn't take any longer whether this code is generated or not.

    I did think it might be something with using two different clocks, but as a test I had both processes use the same clock, but this did not make a difference.



  8. #8
    Super Moderator
    Points: 27,672, Level: 40
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    6,318
    Helped
    1533 / 1533
    Points
    27,672
    Level
    40

    Re: Help tracking down very long synthesis time

    Is there a more complete example you can post that exhibits the problem?



  9. #9
    Newbie level 4
    Points: 31, Level: 1

    Join Date
    Nov 2017
    Posts
    5
    Helped
    0 / 0
    Points
    31
    Level
    1

    Re: Help tracking down very long synthesis time

    Ok, so I have solved the issue of the long synthesis time, though I'm not sure why.

    I sidelined the bit of code I posted originally and moved on to some other areas of my project I needed to work on. I rewrote a rather large if-elsif structure into a case statement for readability purposes, and again, my synthesis time ballooned like crazy. So for some reason, the case statements are causing long synthesis times.

    I ended up replacing:
    Code:
    case count is
        when 0 => test_ram_inst(0) <= s_i_data & s_q_data;
        when 1 => test_ram_inst(1) <= s_i_data & s_q_data;
        when 2 => test_ram_inst(2) <= s_i_data & s_q_data;
        when 3 => test_ram_inst(3) <= s_i_data & s_q_data;
        when 4 => test_ram_inst(4) <= s_i_data & s_q_data;
        when 5 => test_ram_inst(5) <= s_i_data & s_q_data;
        when 6 => test_ram_inst(6) <= s_i_data & s_q_data;
        when 7 => test_ram_inst(7) <= s_i_data & s_q_data;
        when others => null;
    end case;
    with:

    Code:
    write_ram(count) <= s_i_data & s_q_data;
    I should also mention that there is some IP in my design related to some of these signals that is a black box to me, so I'm afraid I will never know the true reason why this is happening.



  10. #10
    Super Moderator
    Points: 27,672, Level: 40
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    6,318
    Helped
    1533 / 1533
    Points
    27,672
    Level
    40

    Re: Help tracking down very long synthesis time

    I'm wondering if it is the null assignment for default. I normally set the default to some benign value (usually a reset condition - a constant).

    - - - Updated - - -

    Actually looking at your code again, I suspect it is due to the lack of assignments to all 32-bit registers in each "case" assignment.
    Indexing each specific 32-bit word doesn't assign any of the other words and the default has to be implemented for all the unassigned values for each of the cases.

    This would explain why the direct assignment using the count index works as the synthesis tool can immediately see the index is used to assign each individual 32-bit register.

    The other case code is probably blowing up into a really large circuit which then reduces down due to all the don't care overlapping conditions that don't assign the outputs.


    1 members found this post helpful.

  11. #11
    Newbie level 4
    Points: 31, Level: 1

    Join Date
    Nov 2017
    Posts
    5
    Helped
    0 / 0
    Points
    31
    Level
    1

    Re: Help tracking down very long synthesis time

    That is quite insightful, thanks!

    In retrospect, it does seem like my original code would be an improper use of a case statement. I suppose the priority nature of an if/elsif statement somehow takes care of this issue, but I need to think about it more.



    •   Alt15th November 2017, 15:05

      advertising

        
       

  12. #12
    Super Moderator
    Points: 27,672, Level: 40
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    6,318
    Helped
    1533 / 1533
    Points
    27,672
    Level
    40

    Re: Help tracking down very long synthesis time

    I think it has more to do with the if statement has only two conditions: TRUE or FALSE and it either does the assignment or doesn't, so it doesn't matter if you didn't specify any of the other array assignments.


    1 members found this post helpful.

  13. #13
    Full Member level 3
    Points: 2,428, Level: 11
    Achievements:
    7 years registered

    Join Date
    Nov 2009
    Location
    Pakistan
    Posts
    183
    Helped
    18 / 18
    Points
    2,428
    Level
    11

    Re: Help tracking down very long synthesis time

    What PC or Laptop are you using?



  14. #14
    Advanced Member level 3
    Points: 4,711, Level: 16

    Join Date
    Feb 2015
    Posts
    781
    Helped
    230 / 230
    Points
    4,711
    Level
    16

    Re: Help tracking down very long synthesis time

    My guess is that there was some logic outside of this structure that required a lot of time to synthesize that could be optimized out when this module wasn't included.



--[[ ]]--