Timing regression in Vivado 2015.1

A design that easily meets timing in Vivado 2014.4 all of sudden is failing by over -0.500ns after routing when we simply build using the 2015.1 toolchain.
We build from scripts so the only change is the upgrade of the tool. No violations are found even after placement with 2014.4. In 2015.1 a violation over -1.0ns is present after placement--the difference is night and day.
Anything we should look for, or is this a known issue?

As part of our reports we print out the 5 max paths after both placement and routing. These 5 max paths are completely different using the two versions of the tool, making an apples to apples comparison difficult. All 5 max paths are failing under 2015.1.
I notice the utlization (post-synthesis) is about 4-5% higher with 2015.1, up around 90% as opposed to 85% with 2014.4. I suspect the timing issue is due to routing congestion (this is with a 7-series part). For whatever reason 2014.4 is able to optimize the design down more.

Similar Messages

  • Vivado 2015.2 warning about pipelining adder input

    Hello,
    I wrote RTL to perform a multiply-accumulate function (A*B+C), where either of the operators (mult or add) are optional. As such, it also performs A*B (without the addition to C) and (IN + C) functionally. The way this is performed in the RTL, is by selectively setting B to 1 if only an addition is required or C to 0 for mult only. So - 
    mode 1: A*B+C
    mode 2: A*1+C
    mode 3: A*B+0
    mode 4: Acc only whereby the A input is accumulated with the PREG.
    I get the following warning in Vivado 2015.2 - 
    [DRC 23-20] Rule violation (DPIP-1) Input pipelining - DSP mac_/adder_/result_reg input B C is not pipelined. Pipelining DSP48 input will improve performance.
    My RTL is shown below. I've removed parts that are not relevant to this discussion (such as the code for the mode above, etc) - 
    assign mult_1_in = data_1_in_r; // data_1_in_r is 16 bit reg
    assign mult_2_in = opcode_1r < 2 ? 1 : data_2_in_r; // same for data_2_in_r
    always @(posedge clk) begin
    if(reset) begin
    mult_bypass <= 0;
    end
    else begin // mult_bypass would be CREG of the DSP48E1
    mult_bypass <= opcode_1r < 2 ? data_2_in_r : 0;
    end
    end
    //mult instantiation here with sync reset and registered output (MREG)
    assign add_1_in = mult_out;
    assign add_2_in = opcode_2r == 0 ? mult_bypass :
    opcode_2r == 2 ? 0 :
    add_out; // add_out is (registered) output of adder
    // Adder instantiation here with registered output (PREG)
    So finally, my question is, is this just a warning or is it doing something funny because my code was not written correctly or is not able to be interpreted correctly by the tools?
    The device usage (with the netlist and all) is a bit confusing. It shows the C input being used. If that is the case, then it is registered (because the C input is always registered). So I'm not sure what the pipeline warning is about.
    EDIT: I was able to spot the following statements in the synthesis log - 
    DSP Report: Generating DSP mac_/adder_/result_reg, operation Mode is: (C+(A2*B)')'.
    DSP Report: register mac_/data_1_in_r_reg is absorbed into DSP mac_/adder_/result_reg.
    DSP Report: register mac_/adder_/result_reg is absorbed into DSP mac_/adder_/result_reg.
    DSP Report: register mac_/mult/result_reg is absorbed into DSP mac_/adder_/result_reg.
    DSP Report: operator mac_/adder_/result0 is absorbed into DSP mac_/adder_/result_reg.
    DSP Report: operator mac_/mult/result0 is absorbed into DSP mac_/adder_/result_reg.
    The adder's result register is PREG, the output. It should NOT be combined with MREG into one because the RTL does not specify this or anything remotely close anywhere. How/why is the output of the multiplier getting absorbed into the output of the adder? This is quite bizzare. 
    Thank you.

    I am pretty sure, it's just complaining about timing and there is no consequence about logic implementation. You can test the synthesis output gates and verify this. It is probably complaining about the mux you have at mult_2 and add_2_in. If you want the warnings to go away, register these variables.

  • Show information in log file under Vivado 2015.1?

    In XST and in Vivado through 2014.4 I used something like:
      assert false report "FFV_D sees KEEP_HIERARCHY: " & Value(KeepHierarchy) severity NOTE;
    to figure out what was going on in Vivado during synthesis.
    With Vivado 2015.1, instead of the report from the constant condition assert statement, I now get:
      WARNING: [Synth 8-312] ignoring unsynthesizable construct: assertion statement [h:/Eng/MVhdl/Src/Base/MReg.vhd:1731]
    Is there some other means to write report information into the Vivado log during synthesis?
    I most use this so that I can verify the state of generics within entities, but I use the mechanism all the time for debugging synthesis.
    Ian Lewis
    www.mstarlabs.com
     

    Hello Brian,
    I certainly hope that Vivado has some means of reporting from within HDL.
    I agree that removing static condition assert support is a horrible idea, especially since the Vivado synthesis log does not provide even as good information as XST did: http://forums.xilinx.com/t5/Synthesis/Requests-for-Vivado-synthesis-log-changes/td-p/590481 . Or, at least, I cannot interpret the Vivado synthesis log at all well.
    I have not yet read enough copies of the log for different conditions to be sure that it is fundamentally unclear, but more and more it looks to me like it just does not include enough information for anyone to know exactly what Vivado has done with respect to generic bindings for specific instances. I know it does not include enough information to even have a clue what it has done with respect to applying attributes.
    In any case, even if Vivado synthesis provided a perfect and complete implementation of VHDL, and its log contained every bit of information one could imagine wanting to show how it binds entities and generics, it is essential to be able to see what the compiler is really doing at the level of one's own code: you can read the LRM until you are blue, but at some point you need to see what is really happening in a specific instance of code.
    And, there is good reason to report into the log some facts about how one configured an entity at a higher level than the individual generics so you can quickly see that you did what you intended to do.
    I could live with changing our asserts to something else, but some means to report into the log is important. It is not just some whim.
    Ian Lewis
    www.mstarlabs.com
     

  • VIVADO 2015.2, DisplayPort AXI frequency cannot be changed

    Hi All,
    It looks like a simple problem, but changing the AXI Lite clock frequency is impossible (DisplayPort 6.0, VIVADO 2015.2). See below.
    set_property -dict [list CONFIG.AXI_Frequency {100}] [get_bd_cells inst_displayport]
    WARNING: [IP_Flow 19-3374] An attempt to modify the value of disabled parameter 'AXI_Frequency' from '50' to '100' has been ignored for IP '/inst_displayport'
    Is this a simple bug? Should I ignore it?
    Also, what is this new setting called "SS mode"? It's not explained in the pg064.
    Thank you
    Vlad

    Hi 
    Do you have all the IPs updated ?
    Go to Tools --> report --> report ip status and check if all the IP's are up to date. In case they are not up to date, upgrade them.
    If all IP's are up to date try regenerating block design output products (reset output products followed by generate output products).
    Also, you need to add the User IP to Vivado IP repository.
    You can refer to page-68 of http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_4/ug896-vivado-ip.pdf to know how to add user IP to IP repository.

  • ISE 14.4 BitGen Failing After Vivado 2015.1 Installation

    My node-locked version of Embedded Edition ISE 14.4 has started failing Bitgen with the following warning:
    WARNING:Bitgen:26 - Bitgen only supports DRC but not bitstream generation on
       this device.  This condition can occur if there are problems obtaining a
       license to run bitgen or if the design targets a device which is Early
       Access.
    I have not changed my ISE license file recently, but I have installed Vivado 2015.1 in the last couple of days. Sythesis and Implementation still work. The License Configuration Manager that I can open from the Help menu still indicates that I have permanent licenses for all the features (i.e., nothing has changed to the best of my knowledge).
    Could the Vivado install have messed up my ISE licensing? If so, how do I fix this problem?

    Hi ,
    Are there more than one ISE licenses in the installation directory?
    Please attach the Xinfo file so that we can check if the correct license is being accessed by ISE.
     (also post the name of those .lic files)
    To generate the xinfo file:
    Start --> All Programs --> Xilinx Design Tools --> ISE Design Suite 14.x --> Accessories --> Xinfo System Checker.
    Thanks,
    Tushar.
    Please mark the post as an answer ("Accept as solution") in case it helped resolve your query.
    Give kudos in case a post guided you to the solution.
    This will help others in the long run

  • Opening xapp1082 with Vivado 2015.2 gives errors (pl_eth)

    After sourcing pl_eth.tcl I get the first problem, I had to update manually (in pl_eth_bd.tcl) the AXI ethernet version from 6.2 to 7.0.
    Fixed this problem I get the following:
    INFO: [Device 21-403] Loading part xc7z045ffg900-2 Wrote : </home/parallels/vivado/xapp1082_2014_4/hardware/vivado/runs_pl_eth/pl_eth_sfp.srcs/sources_1/bd/design_pl_eth/ip/design_pl_eth_axi_ethernet_0/bd_0/bd_0.bd>
    Wrote : </home/parallels/vivado/xapp1082_2014_4/hardware/vivado/runs_pl_eth/pl_eth_sfp.srcs/sources_1/bd/design_pl_eth/ip/design_pl_eth_axi_ethernet_0/bd_0/bd_0.bd>
    WARNING: [PS7-6] The applied preset does not match with board preset. You may not get expected settings for board. The ZC706 preset is designed for ZC706 board.
    ERROR: [BD 41-80] Exec TCL: Specified object '' does not exist. Please use an existing object name
    ERROR: [BD 5-14] Error: running create_bd_segment.
    ERROR: [Common 17-39] 'create_bd_addr_seg' failed due to earlier errors. while executing "create_bd_addr_seg -range 0x40000 -offset 0x43C00000 [get_bd_addr_spaces processing_system7/Data] [get_bd_addr_segs axi_ethernet/s_axi/Reg] SEG_axi_et..." (procedure "create_root_design" line 103) invoked from within "create_root_design """ (file "pl_eth_bd.tcl" line 300) while executing "source pl_eth_bd.tcl" (file "pl_eth.tcl" line 21) set_property source_mgmt_mode DisplayOnly [current_project]

    I went through the annoying process of opening the xapp1082 design using Vivado 2014.4 (I sourced pl_eth.tcl), then I opened the resulting project using  Vivado 2015.2 with no luck. The "upgrade" process got stuck while upgrading one of the IP.
    Result is that the bitstream cannot be generated.
    Anyone can point in the right direction?
    Furthermore, why Vivado is not provided as a web application? Like Google Docs, I mean. This would avoid pushing gigabytes of software to customers. I would pay for such a service. 
    Regards,
    Antonio.

  • How to use the Logic Analyser layout in Vivado 2015.1

    Hi,
    I found this quite annoying after upgrading to vivado 2015.1. Whenever I use debug signal, it will bring me to the new logic analyser layout as shown below after bitstream is downloaded. The tiny waveform window, however, is barely useful. So I have to maximize the waveform window every time after downloading, which will disable the trigger window. But then when I want to add trigger probes, I couldn't find an easy way to get to the trigger setup window again, so I have to reset dashboard, then set trigger, then maximize the waveform window again... Can anyone send me some pointer of how to efficiently use the new layout. Also, the scroll bar of the signal name in the waveform window is not available any more. This is also annoying as my signal names are quite long and I have to make sure the panel is wide enough to show the name, otherwises it will be like /topmodule/submodule/....._V.
    Jimmy
     

    Hi Lior,
      The scroll bar is replaced with a feature (Elide Settings) that shortens the name of the probes to fit into the column size you select.
    If there’s enough space in the column, obviously its setting has no effect, and you see the entire probe name.
    If there’s not enough space, then based on this elide setting, the probe name will fit in the column either from the beginning, middle, or end of the probe name (see the attached image).
    This way it's easier for the user to see the portion of the probe names that they need without having to scroll left or right.
    This settings is inside the waveform option on the left side of the waveform viewer as you see in the images. 
    Hope this helps.

  • Porting Xapp1198 to Vivado 2015.2

    Hi,
    I'm trying to port Xapp1198 (transceiver eye scan reference design) to Vivado 2015.2 for Zynq ZC706 board.
    The original reference design was compiled with Vivado 2014.4.
    After sucessfully upgrading IP I run Block Design validation of the eyescan_subsystem, and getting a bunch of errors shown in the attached screenshot.
    I'd appreciate if this reference design is released for the latest Vivado 2015.2.
    Thanks,
    Evgeni
     

    Hi Muzaffer,
    I'm trying to fix this error message given by Vivado during the implementation phase (place & route): [Opt 31-30] Blackbox FIfoA (sfifo_16x8_dr) is driving pin DI[1] of primitive cell sv_op_R1_reg[3]_i_1. This blackbox cannot be found in the existing
    I used entity instantiation of this fifo in my RTL (fifo_i0 : entity target_lib.sfifo_16x8_dr). If Vivado is giving me this error, I'm assuming that it is expecting the Fifo to be in the target_lib library. That why I want to be able to change the library. So, if Vivado ignores library constructs during implementation, how comes I am getting this error?

  • Vivado 2015.2 , 'focus' changes in windows.

    may be some one else can check this for us.
    Running vivado 2015.2 on windows 7 pro 64 bit.
    Also running notepad++ .
    Vivado does lots of thigns in the back ground, including compiling IP blocks.
        It seems when vivado finishes a section of IP, it pops up a little window bottom right to say done etc.
    Well, I have been running vivado on a big job, and I have been editing some big data files with Notepad++ using macro's at the same time whilst waiting for vivado.
    It seems that when vivado pops up the message, focus of the window jumps from notepad++ to the vivado window, 
        which rather upsets the notepad macro as it has lost focus.
    Dont know if this is a notepad problem or vivado should not do this, and its rather anoying, 
      and wonder if anyone else has any thoughts on where I should ask ?
       just wondered , I now know not to run vivado whilst using macro's.
     

     Let me check this and get back to you

  • VIVADO 2015.2 IP Packager ruins all bool type parameters

    Hi All,
    As subject: in one IP of ours, there are 3 boolean parameters (last packaged with IPI 2014.4). The component.xml is attached for Xilinx's comments, as you can see, the parameter is defined properly. When I open the IP Package from the VIVADO 2015.5, I get 3 errors of the following form:
     [IP_Flow 19-343] HDL Parameter 'C_FORCE_BYPASS_MODE (C Force Bypass Mode)': Default value "false" does not match format "long"
    I also get 3 other errors that are derivatives, but in the gui, the 'type' column does not say 'long' but it says 'bool'. The same issue used to appear with 2014.4, but we could work around it by iterative repackaging.
    What is going on? I cannot do anything with the IPI now (did not try manual editing of the XML yet).
    Thanks
    Vlad

    Module declaration can of course be sent, here it is below. Digesting your response though... I am thinking the interpretation of the values may have changed in the 2015.2
    That is, in 2014.4, the value of 0 was treated as false and in 2015.2, the IPI interpreter automatically converts it to 'long'
    BOLD text are the parameters that we are talking about.
    module cmpipe
        parameter C_VIDEO_CFG_SAME_CLK = 0,
        parameter C_ROWS = 768,
        parameter C_PIXELS_PER_CYCLE = 2,
        parameter C_NUM_SRCDRV = 12,
        parameter C_COMP_SUBPIXELS = 3,
        parameter C_COORD_WIDTH = 22,
        parameter C_FORCE_BYPASS_MODE = 0,
        parameter C_LUMINANCE_CORRECTION_LUT_TYPE = "PLAIN",
        parameter C_CMPIPE_GAMMA_DECODE_LUTRAM_STAGES = 0,
        parameter C_GAMMA_DECODE_INPUT_PIXEL_WIDTH = 10,
        parameter C_GAMMA_DECODE_OUTPUT_PIXEL_WIDTH = 10,
        parameter C_M_AXIS_VDMA_VID_BUS_WIDTH = 128,
        parameter C_M_AXIS_VDMA_COMP_BUS_WIDTH = 128,
        parameter C_INPUT_VIDEO_PIXEL_WIDTH = 10,
        parameter C_ACTUAL_VIDEO_PIXEL_WIDTH = 10,
        parameter C_CMPIPE_OUTPUT_PIXEL_WIDTH = 10,
        parameter C_GAMMA_CORRECTION_LUT_TYPE = "PLAIN",
        parameter C_GAMMA_CORR_INPUT_PIXEL_WIDTH = 10,
        parameter C_GAMMA_CORR_OUTPUT_PIXEL_WIDTH = 10,
        parameter C_INCLUDE_RGBW_CONV = 1,
        parameter C_RGB_TO_RGBW_PIXEL_WIDTH = 10,
        parameter C_PNLCCB_INPUT_PIXEL_WIDTH = 10,
        parameter C_PNLCCB_OUTPUT_PIXEL_WIDTH = 10,
        parameter C_INCLUDE_STR_HIST = 0,
        parameter C_STR_HIST_PIXEL_WIDTH = 16,
        parameter C_COLUMNS = 1296,
        parameter C_S_AXI_DATA_WIDTH = 32,
        parameter C_S_AXI_ADDR_WIDTH = 32,
        parameter C_S_AXI_MIN_SIZE = 32'h0000_ffff,
        parameter C_BASEADDR = 32'h0000_0000,
        parameter C_HIGHADDR = 32'hffff_ffff,
        parameter C_FAMILY = "virtex6"
       (/*AUTOARG*/
     

  • Vivado 2015.2 IP Packager Fail

    Vivado 2015.1 IP packager works fine.  In 2015.2 the tool seems to indentifty all the parts of my design correctly and displays well in the Hierarchy window.  But when I try to ipx::package_project in 2015.2 it fails with "ERROR: [IP_Flow 19-272] [HDL Parser] Unable to determine HDL language of top-level HDL model, /..."random.coe.  It seems like the packager thinks the coe is the top-level design.  Any idea how to fix?  

    Yes the top is selected properly.  No I cannot post my design here.  
    If you want to reproduce the failure just try making any .sv your top level.  And make sure the project includes a .coe.  The packager will fail.  Then use a .v as a top level and it will work.  There's a bug in the tool.
    A workaround is to make your top (System Verilog) use the extension .v  Then explicitly label the file system verilog with "set_property type systemVerilogSource" in Vivado.  Now it will package properly.  
    Please fix in a patch or 2015.3.
    Thanks
    jer

  • Download vivado 2015.1 fails with Firefox

    Download is blocked. Activation of Java-plugin not possible.
    I do use latest Firefox, Java, etc.
    IE works, but is unwanted.
     

    Hi,
    Please refer to the answer record link which might help you download Vivado 2015.1 using your browser.
    http://www.xilinx.com/support/answers/64373.html
    Regards
    Praveen
    Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
    Give Kudos to a post which you think is helpful and reply oriented.
    ----------------------------------------------------------------------------------------------

  • VIvado 2015.1 Ultrascale support

    Hi,
    Currently we cannot generate bitstream for designs targeted on Ultrscale device XCVU440 using Vivado 2015.1 due to license issue. Is there any solution for this problem?
    We found bitstream generation for XCVU440 is not supported yet on Vivado 2015.1. Do we need to update our license for this problem?
    Thanks for your time.
    Best,

    Hi,
    for the document reference regarding this info,
    In Vivado 2015.1 this device was newly added which would require a special license to access. If you see following release notes of vivado 2015.1 page #5
    http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_1/ug973-vivado-release-notes-install-license.pdf
    you can see that this device is not supported for bit stream generation.
    However in Vivado 2015.2, (please see following UG page #5, #6 table 1.1)
    http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_2/ug973-vivado-release-notes-install-license.pdf
    The same device is added for bit stream generation support.
    You need not update your license for this purpose (if it matches the version limit).
    Thanks,
    Shreyas

  • Vivado 2015.1 PS7-GMII EMIO broken. Solution inside!

    Hi,
    I have found a huge bug in Vivado 2015.1 when using PS7 GMII on EMIO in a BD design.
    It is impossible to use the PS7 ENET with routing the GMII through EMIO. The problem is thet ENET0_GMII_TXD ENET0_GMII_TXEN and ENET0_GMII_TXER is permanently set to Ground.
    Solution:
    The following file defines the ps7 wrapper when the ps7 instance is created in the BD
    $(XILINX_INSTALL_DIR)Vivado/2015.1/data/ip/xilinx/processing_system7_v5_5/ttcl/processing_system7.ttcl
    In this file the ENET GMII TX signals are *REMOVED*!!!  (They are commented out.)
    So I activated the signals and ethernet is working again.
    I have create a patch (see below) which shows the problem.
    So Xilinx, is any reasonable explanation out there for this? I guess a lot of mainboards requiere an EMIO Ethernet configuration.
    --- processing_system7.ttcl 2015-05-20 13:42:34.978734005 +0200
    +++ processing_system7.ttcl.org 2015-04-22 07:30:05.000000000 +0200
    @@ -1070,8 +1070,8 @@
    wire [11:0] M_AXI_GP1_RID_FULL;
    -wire ENET0_GMII_TX_EN_i;
    -wire ENET0_GMII_TX_ER_i;
    +//wire ENET0_GMII_TX_EN_i;
    +//wire ENET0_GMII_TX_ER_i;
    reg ENET0_GMII_COL_i;
    reg ENET0_GMII_CRS_i;
    @@ -1655,8 +1655,8 @@
    always @(posedge ENET0_GMII_TX_CLK)
    begin
    ENET0_GMII_TXD <= ENET0_GMII_TXD_i;
    - ENET0_GMII_TX_EN <= ENET0_GMII_TX_EN_i;
    - ENET0_GMII_TX_ER <= ENET0_GMII_TX_ER_i;
    + ENET0_GMII_TX_EN <= 1'b0; //ENET0_GMII_TX_EN_i;
    + ENET0_GMII_TX_ER <= 1'b0;//ENET0_GMII_TX_ER_i;
    ENET0_GMII_COL_i <= ENET0_GMII_COL;
    ENET0_GMII_CRS_i <= ENET0_GMII_CRS;
    end
    @@ -3134,9 +3134,9 @@
    .DMA3RSTN (DMA3_RSTN ),
    .EMIOCAN0PHYTX (CAN0_PHY_TX ),
    .EMIOCAN1PHYTX (CAN1_PHY_TX ),
    - .EMIOENET0GMIITXD (ENET0_GMII_TXD_i ),
    - .EMIOENET0GMIITXEN (ENET0_GMII_TX_EN_i),
    - .EMIOENET0GMIITXER (ENET0_GMII_TX_ER_i),
    + .EMIOENET0GMIITXD (), // (ENET0_GMII_TXD_i ),
    + .EMIOENET0GMIITXEN (), // (ENET0_GMII_TX_EN_i),
    + .EMIOENET0GMIITXER (), // (ENET0_GMII_TX_ER_i),
    .EMIOENET0MDIOMDC (ENET0_MDIO_MDC),
    .EMIOENET0MDIOO (ENET0_MDIO_O ),
    .EMIOENET0MDIOTN (ENET0_MDIO_T_n ),
     

    Does not work for me.
    I re-run my 15.1 project in 15.2 and silll getting ENET1_TX pins tied to GND.
    Tried to re-generate block design, unset/set ENET1 - no effect.
    Tried to apply patch for 15.1 (added directory in D:\Xilinx\Vivado\2015.1\patches\AR64531_Vivado_2015_1_preliminary_rev1) then run in 15.1 - no effect
    I noticed that in processing_system7_v5_5_processing_system7 parameter C_EN_EMIO_ENET1 = 0, which blocks TX ports connection.
    Help needed.
     

  • Clocking Wizard broken in Vivado 2015.2?

    Because I'm lazy and I didn't want to compute the PLL/MMCM parameters by hand (some kind of online calculator would be a great tool IMHO), I started up the GUI mode of Vivado 2015.2 and wanted to use the Clocking Wizard IP (which I remebered would do the calculations). To my surprise, this rather basic IP doesn't work anymore.
    When trying to add this IP, I get a pop-up with the following error message:
      Error occurred while initializing 'clk_wiz_0'
      Tcl error in update procedure while setting value 'MMCM' on the parameter 'PRIMITIVE'.
      unexpected "," outside function argument list
      in expression "1000 / 10,000"
    The TCL console has some more Details on the issue:
    create_bd_cell -type ip -vlnv xilinx.com:ip:clk_wiz:5.1 clk_wiz_0
    unexpected "," outside function argument list
    in expression "1000 / 10,000"
    ERROR: [IP_Flow 19-3188] Error occurred while initializing 'design_1_clk_wiz_0_0'
    Tcl error in update procedure while setting value 'MMCM' on the parameter 'PRIMITIVE'. unexpected "," outside function argument list
    in expression "1000 / 10,000"
    CRITICAL WARNING: [IP_Flow 19-973] Failed to create IP instance 'design_1_clk_wiz_0_0'. Error during customization.
    ERROR: [#UNDEF] Error occurred while initializing 'design_1_clk_wiz_0_0'
    Tcl error in update procedure while setting value 'MMCM' on the parameter 'PRIMITIVE'. unexpected "," outside function argument list
    in expression "1000 / 10,000"
    ERROR: [BD 5-7] Error: running create_bd_cell.
    ERROR: [Common 17-39] 'create_bd_cell' failed due to earlier errors.
    How to reproduce:
    start Vivado in GUI mode
    create a New Project (select RTL, no sources, Zedboard)
    select Clocking Wizard from the IP Catalog
    Is there a problem with my installation (it should be clean/new) or is that a problem with the IP/config?
    Thanks in advance,
    Herbert

     problem with system language settings, Check this to workaround
    http://forums.xilinx.com/t5/Design-Entry/clocking-wizzard-throws-error-while-instantiating-in-IPI/td-p/584056
    http://forums.xilinx.com/t5/Design-Entry/Connection-Automation-failed-with-a-simple-MicroBlaze-design/td-p/539137
     

Maybe you are looking for