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.

[SOLVED] [Netlist 29-101] Netlist 'b0_decision' is not ideal for floorplanning

Status
Not open for further replies.

rafimiet

Member level 5
Joined
May 21, 2015
Messages
94
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,288
Activity points
2,364
I have a VHDL code as below

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
entity b0_decision is
    GENERIC (N : integer := 256);
    Port ( b0_addr : in integer range 0 TO N*N/4-1;
           clk,update : in STD_LOGIC;
           valid : out STD_LOGIC := '1');
end b0_decision;
 
architecture Behavioral of b0_decision is
signal b0 : STD_LOGIC_VECTOR (N*N/4-1 downto 0) := (1 TO 3 => '1', OTHERS => '0');
begin
valid <= b0(b0_addr);
process(clk)
begin
    if clk'event and clk = '1' then
        if update = '1' then
            b0(b0_addr) <= '1';
        end if;
    end if;
end process;
end Behavioral;


Description: I have a signal b0, which is initialized as some 1's and some 0's. Then it is updated by some other components of the main architecture.
It shows me an error "[Netlist 29-101] Netlist 'b0_decision' is not ideal for floorplanning, since the cellview 'b0_decision' contains a large number of primitives. Please consider enabling hierarchy in synthesis if you want to do floorplanning."
Also it takes 21050 LUTs and 16381 FFs:cry:
Can you make me understand what is being wrong here and how to correct it? Also I need to understand with what logic does it implement it?
 
Last edited:

I'm not sure why it isn't inferring dmem here, although that is still fairly large.

This looks somewhat like a RAM, other than the "only write 1" aspect being a bit odd as the design can't ever be reset without reprogramming the FPGA.

If valid can be registered, that would be more ideal. First because it is uncommon to have unregistered outputs. It would also allow this to infer block ram, which would map to a BRAM18 in devices that Vivado targets.

The large lut count is based on generating such a large number of write enables as well as a very large output mux.

- - - Updated - - -

I'm not sure why it isn't inferring dmem here, although that is still fairly large.

This looks somewhat like a RAM, other than the "only write 1" aspect being a bit odd as the design can't ever be reset without reprogramming the FPGA.

If valid can be registered, that would be more ideal. First because it is uncommon to have unregistered outputs. It would also allow this to infer block ram, which would map to a BRAM18 in devices that Vivado targets.

The large lut count is based on generating such a large number of write enables as well as a very large output mux.
 

This looks somewhat like a RAM, other than the "only write 1" aspect being a bit odd as the design can't ever be reset without reprogramming the FPGA. If valid can be registered, that would be more ideal.
I have edited the code like this:

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
architecture Behavioral of b0_decision is
signal b0 : STD_LOGIC_VECTOR (N*N/4-1 downto 0) := (1 TO 3 => '1', OTHERS => '0');
begin
process(clk)
begin
    if clk'event and clk = '1' then
        valid <= b0(b0_addr);
        if update = '1' then
            b0(b0_addr) <= '1';
        end if;
    end if;
end process;
end Behavioral;


But the result is same. The resources used and the error remain unchanged...
The large lut count is based on generating such a large number of write enables as well as a very large output mux.
What are the other ways to reduce the logic?
 

You dont specify what device you are using, and what compiler?
Looking at your code, this is something that should be a ram and not LUTRAM, but there are some subtle differences depending on what compiler you have. An older version of the XST manual for -6 devices says only supports data port widths of 16-36 bits for ram inferrence.
Also, all inferrence templates I have ever seen expect an array of std_logic_vector, not a single SLV in isolation. This probably makes the tool think it is a massive register array rather than a RAM. All BRAMS for both Altera and Xilinx support 1 bit mode. So maybe try this code instead:


Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
type ram_t is array(N*N/4-1 downto 0) of std_logic_vector(0 downto 0);
signal b0 : ram_t := (1 TO 3 => "1", OTHERS => "0");
begin
process(clk)
begin
    if rising_edge(clk) then
        valid <= b0(b0_addr)(0);
        if update = '1' then
            b0(b0_addr) <= "1";
        end if;
    end if;
end process;
end Behavioral;

 
yes, good catch. I've had this come up in the past as well. Vivado does expect an array of vectors for inferring RAM, even for 1 bit cases.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top