cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Newbie
Newbie
416 Views
Registered: ‎04-17-2019

Design does not finish synthesizing after 4 hours

Jump to solution
In my design I have a matrix of 1024 integers. Under certain circumstances, I need to increase the value of some of these integers in a unit. The problem is that I cannot make this design finish synthesizing, I have waited more than four hours and it still does not end or returns an error.
 

Previously I had a code that synthesized in a few minutes, but when I added this (actually a very similar one), he spent more than 12 hours synthesizing and never finished.

I hope you can help me, I am finishing my degree work and I have not been able to finish it because of this problem.

Thank you

The design is as follows:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity Proof_Array is
  Port (
    reset                  :   in  std_logic;
    Peak_height_detected_1 :   in  std_logic_vector(9 downto 0);
    Add_this_height        :   in  std_logic;
    S_clk_ADC_15MHz        :   in  std_logic;
    S_Out                  :   out std_logic_vector(31 downto 0));
end Proof_Array;

architecture Behavioral of Proof_Array is
    type PHA_Array_Type is array (0 to 1023) of integer;
    signal PHA_Array: PHA_Array_Type;
    signal number: integer range 0 to 1023;
    
    signal Peak_height_detected_1_int: integer range 0 to 1023;
begin
    Peak_height_detected_1_int <= to_integer(unsigned(Peak_height_detected_1));
    S_Out <= std_logic_vector(to_unsigned(PHA_Array(number), S_Out'length));
    
    process(reset, S_clk_ADC_15MHz)    
    begin
        if reset = '1' then 
            for k in 0 to 1023 loop 
                PHA_Array(k) <= 0; 
            end loop;
        elsif rising_edge(S_clk_ADC_15MHz) then
            if Add_this_height = '1' then
                PHA_Array(Peak_height_detected_1_int) <= PHA_Array(Peak_height_detected_1_int) + 1;
            end if;
            if number > 1022 then 
                number <= 0;
            else 
                number <= number + 1;
            end if;
        end if;    
    end process;
end Behavioral;
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
392 Views
Registered: ‎05-23-2018

You are forcing the tools to create a pretty bad structure for your array. You have an asynchronous reset to 1k of unrestricted (IIRC 32-Bit) integers. The only structure in the FPGA that has that is regular flipflops. You cannot reset a BRAM or a distributed RAM like this - you would need a simple state machine that resets one entry per clock cycle for a while.

That means that your array requires 32k Flipflops, which is quite a lot. Now you read that array twice - once to output it to S_Out, once for incrementing writing. Both of these are asynchronous. This will force the tools to generate two big (32x1024) MUX to connect the proper flipflop to the corresponding logic.

I would suggest you modify the structure to not use a reset like this - use a statemachine that on reset initializes the ram to zero and outputs a busy-signal while doing that. Only use the structure afterwards.

Next, change the logic so that you only read synchronously. That would make the tools be able to use 2 BRAMs which shared content. You would use the first BRAM-Port for writing, the second for reading. The content will be the same.

This will obviously introduce a cycle of delay. You would need to modify the surrounding logic to take that into account.

View solution in original post

2 Replies
Highlighted
Adventurer
Adventurer
393 Views
Registered: ‎05-23-2018

You are forcing the tools to create a pretty bad structure for your array. You have an asynchronous reset to 1k of unrestricted (IIRC 32-Bit) integers. The only structure in the FPGA that has that is regular flipflops. You cannot reset a BRAM or a distributed RAM like this - you would need a simple state machine that resets one entry per clock cycle for a while.

That means that your array requires 32k Flipflops, which is quite a lot. Now you read that array twice - once to output it to S_Out, once for incrementing writing. Both of these are asynchronous. This will force the tools to generate two big (32x1024) MUX to connect the proper flipflop to the corresponding logic.

I would suggest you modify the structure to not use a reset like this - use a statemachine that on reset initializes the ram to zero and outputs a busy-signal while doing that. Only use the structure afterwards.

Next, change the logic so that you only read synchronously. That would make the tools be able to use 2 BRAMs which shared content. You would use the first BRAM-Port for writing, the second for reading. The content will be the same.

This will obviously introduce a cycle of delay. You would need to modify the surrounding logic to take that into account.

View solution in original post

Highlighted
Teacher
Teacher
383 Views
Registered: ‎07-09-2009
always think what logic your making

a bram can not be reset , so the tool can not use bram but must use logic. and a lot of it

if u want bram follow the template

http://ece-research.unm.edu/jimp/vhdl_fpgas/slides/2008/BRAM.pdf
see slide 8
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>