UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Reply
Highlighted
Participant
Posts: 38
Registered: ‎02-08-2013
Accepted Solution

Why Vivado sooooooo slow!!!!!!!!!!!

This is my first design using Vivado. There is not much I like about the interface being it hides so much behind the scenes making it difficult to do anything but simple things like shown in the example videos. But that said why the hell is it taking 3 1/2 hours to synthesize? This design is no larger similar designs I have done in ISE that would only take 1 hour to both synthesize AND P&R. One would think with all the IP OOC synthesis being done that the synthesis time would be improved or at least not worse. I'm starting to think I made a big mistake using Vivado over ISE. But steered away from ISE because of terminated support and not fixing bugs I have found in the past. Vivado has been out for years, is this the best Xilinx can do? Bring back ISE!!!!!!!!!!!!! 

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA

Accepted Solutions
Scholar
Posts: 944
Registered: ‎09-16-2009

Re: Why Vivado sooooooo slow!!!!!!!!!!!

Ok, I understand what you're doing.  The good news (which you're probably already aware) that your quality of results should be fine with letting the synthesizer optimize away any unused register output bits.  The bad news is it'll take a bit more run time.

 

Have you considered using parameters (err. generics in VHDL speak).  For that case you''d instantiate exactly how many registers bits you'd need on an instance-by-instance basis, by just passing in appropriate generic overrides.

 

That'd run much quicker within the tools.

 

The problem with generics and parameters is they aren't really handled very well within the silly Xilinx Wizards like IPI.  IPI wants everything to be constants.  For some reason Xilinx thinks that entering generics override values within a GUI dialog box is somehow better than entering it within an expressive, textual, revision control friendly, industry standard HDL...

 

Our solution is to avoid IPI (and other silly Xilinx wizards) like the plague...

 

Regards,

 

Mark

View solution in original post


All Replies
Moderator
Posts: 501
Registered: ‎09-15-2016

Re: Why Vivado sooooooo slow!!!!!!!!!!!

Hi @rayhaynes,

 

Did you check which part of synthesis is taking more time from the runme log? So is this 2017.2?

You can cross verify that with your RTL then to see which logic is causing this problem...

Xilinx Employee
Posts: 563
Registered: ‎10-11-2007

Re: Why Vivado sooooooo slow!!!!!!!!!!!

Do you have any large loops that need unrolling? Such as large genvars for example.

Participant
Posts: 38
Registered: ‎02-08-2013

Re: Why Vivado sooooooo slow!!!!!!!!!!!

I don't know that a genvar is. But I do have something like this. Is this what you call large?

 

-- AXI Register Write Block
process (S_AXI_ACLK)
  variable loc_addr : std_logic_vector(OPT_MEM_ADDR_BITS downto 0);
  begin
    if rising_edge(S_AXI_ACLK) then
      if S_AXI_ARESETN = '0' then
        slv_reg <= i_reg_default;
      else
        o_reg_wstrb <= (others => '0'); -- default
        loc_addr := axi_awaddr(ADDR_LSB + OPT_MEM_ADDR_BITS downto ADDR_LSB);
        if (slv_reg_wren = '1') then
          for i in 0 to 511 loop
            if loc_addr = std_logic_vector(to_unsigned(i, 9)) then
              for byte_index in 0 to (C_S_AXI_DATA_WIDTH/8-1) loop -- 0 to 3
              if (S_AXI_WSTRB(byte_index) = '1') then
                -- Respective byte enables are asserted as per write strobes
                -- slave registor 0
                slv_reg(i*32+byte_index*8+7 downto i*32+byte_index*8) <= S_AXI_WDATA(byte_index*8+7 downto byte_index*8);
              end if;
              o_reg_wstrb(i) <= '1';
            end loop;
          end if;
        end loop;
      end if;
    end if;
  end if;
end process;

 

If something like this is causing a problem then I see why the original AXI register was done with brute force and not using loops. I could reduce the loop size from 512 to something smaller but I don't know how much smaller yet, so I had planned on letting the unused synthesis out. Do you think this might be causing the slow down? Should I expect similar performance to ISE, though I would hope better with all the IP OOC synthesizing?

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
Participant
Posts: 38
Registered: ‎02-08-2013

Re: Why Vivado sooooooo slow!!!!!!!!!!!

@prathikm thanks for the reply. I will see if I can determine that.
Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
Scholar
Posts: 944
Registered: ‎09-16-2009

Re: Why Vivado sooooooo slow!!!!!!!!!!!

[ Edited ]

If I'm reading the VHDL correctly, then slv_reg looks to be 16 Kbits wide correct?

 

That's pretty wide, but not totally unreasonable to have registers that wide.  Are you sure your logic cannot target a block ram instead?  (The shear size seems to be begging for a block RAM).  Large register arrays can get out-of-hand quickly. 

 

Most of us have found Vivado run times to me better than ISE.  Hard to compare apples-to-apples of course.  And it'll never be fast enough. 

 

Regards,

 

Mark

Participant
Posts: 38
Registered: ‎02-08-2013

Re: Why Vivado sooooooo slow!!!!!!!!!!!

Hi @markcurry

Yes that register bank is 16384 bits wide. This is a cpu register so all register output bits must be available at all times which eliminates using a BRAM. I created this block to be universal and there are 16K bits at this level because I didn't want to have to be rerunning the IP Integrator each time I needed more bits.  Only a fraction of the bits are used in a specific design so there is a register mapping block that connects only the used bits and I rely on synthesis to remove the unused ones. I used global synthesis when I made the register block so synthesis could remove the unused bits and that appears to be working fine. I will probably cut the size of the array down from 512x32 to maybe 128x32 and see it that is where the speed problem is. I noticed when I created the register from the AXI IP Integrator the supplied code was brute forced using 512 32bit signals for the registers with no use of loops. I guess when you have code writing code this kind of brute forcing is easy to generate. I'm still trying to get through implementation but I may have to address this 3 1/2 hour long synthesis time if I'm to have a chance of fixing the implementation problems.

 

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
Scholar
Posts: 944
Registered: ‎09-16-2009

Re: Why Vivado sooooooo slow!!!!!!!!!!!

Ok, I understand what you're doing.  The good news (which you're probably already aware) that your quality of results should be fine with letting the synthesizer optimize away any unused register output bits.  The bad news is it'll take a bit more run time.

 

Have you considered using parameters (err. generics in VHDL speak).  For that case you''d instantiate exactly how many registers bits you'd need on an instance-by-instance basis, by just passing in appropriate generic overrides.

 

That'd run much quicker within the tools.

 

The problem with generics and parameters is they aren't really handled very well within the silly Xilinx Wizards like IPI.  IPI wants everything to be constants.  For some reason Xilinx thinks that entering generics override values within a GUI dialog box is somehow better than entering it within an expressive, textual, revision control friendly, industry standard HDL...

 

Our solution is to avoid IPI (and other silly Xilinx wizards) like the plague...

 

Regards,

 

Mark

Participant
Posts: 38
Registered: ‎02-08-2013

Re: Why Vivado sooooooo slow!!!!!!!!!!!

Just to close this loop I determined my problem was CPU RAM. I have 24GB but that wasn't enough and it was having to use the page file causing upwards of 4 hours of synthesize time. Once I reduced the size of my register array from 512x32 to 128x32 and not sure how much this helped but I moved the register module outside of my AXI block design allowing me to use OOC synthesis on the BD the complete design now synthesizes in about 5 minutes. 

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA