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.

Help tracking down very long synthesis time

Status
Not open for further replies.

whaleeee

Newbie level 4
Joined
Nov 13, 2017
Messages
5
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
43
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;
 

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.
 

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;
 

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).
 

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.
 

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.
 

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

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.
 

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.
 
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.
 

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.
 
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.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top