MIG DDR3 on Virtex-6 - Unroutable situation in PaR

Hello,
I have a SP6 design with MIG and at P&R I get this warning:
WARNING:Route:436 - The router has detected an unroutable situation for one or more connections. The router will finish the rest of the
design and leave them as unrouted. The cause of this behavior is either an issue with the placement or unroutable placement constraints.
To allow you to use FPGA editor to isolate the problems, the following is a list of (up to 10) such unroutable connections:
Unroutable signal: u_ddr3_controller/memc1_wrapper_inst/memc1_mcb_raw_wrapper_inst/ioi_drp_clk_c pin:
u_ddr3_controller/memc1_wrapper_inst/memc1_mcb_raw_wrapper_inst/ioi_drp_clk_derived_clock_cb/I0
This results in one signal not routed. There were some necessary tweaks in the default generated files to configure the correct clocking, and since this is within those files, are there any other changes necessary to get P&R running without this issue?
Thanks in advance.

Thanks guys.
From FPGA editor i can in fact see that the problem is in the calibration clock. ioi_drp_clk is not somehow connected to the BUFG. But i don't understand why. I checked vsrunga's tip and i'm setting the calibration clock at 66MHz. So it should be good.
Firstly I was using a 25MHz source clock, but now I managed to get a low-jitter external clock synthesizer to get me 166.66MHz. So my clocking configuration for the MIG is:
C1_CLKOUT0_DIVIDE : integer := 1;  -- 666MHz sysclk_2x
C1_CLKOUT1_DIVIDE : integer := 1;  -- 666MHz sysclk_2x_180
C1_CLKOUT2_DIVIDE : integer := 4;  -- 166MHz user fabric
C1_CLKOUT3_DIVIDE : integer := 10; -- 66.6MHz calibration clock
C1_CLKFBOUT_MULT : integer := 4;  -- Generate 666MHz from 166
C1_DIVCLK_DIVIDE : integer := 1;
I guess that this is correct (tell me if not), so i don't see why P&R is having trouble.
[NOTE] Device is a Spartan-6, not a Virtex-6 as wrongly mentioned in the topic.
PCF and NCD files attached as requested by vemulad.
Thanks.

Similar Messages

  • Fpga compilation xilinx error 'Process "Map" failed' - 'unroutable situation'

    When I try to compile a Labview fpga project on our new system, it fails with the following error summary (the full Xilinx log is attached):
    LabVIEW FPGA: The compilation failed due to a xilinx error.
    Details:
    ERROR:LIT:536 - IBUF symbol "aUserGpio<1>_IBUF" (output
    signal=aUserGpio<1>_IBUF) has the attribute IOBDELAY set to value NONE and it
    is driving an IODELAY. If the IOBDELAY attribute is on the driving PAD, it
    has precedence over the IBUF one. Either the constraint or the design need
    modification to prevent an unroutable situation.
    Errors found during logical drc.
    Design Summary
    Number of errors : 1
    Number of warnings : 349
    Process "Map" failed
    Start Time: 10:31:49 AM
    End Time: 10:55:32 AM
    Total Time: 00:23:43
    Hardware:
    NI PXIe-1071 Chassis
    NI PXIe-8108 Embedded controller
    NI PXIe-7965R FPGA FlexRIO FPGA module
    NI 5761 250 MS/s 14 bit Analog input digitizer
    Installed software:
    Labview 2011 version 11.0
    Labview FPGA module 11.0.0
    FPGA compilation tools (Xilinx12_4)
    NI FlexRIO Adapter Module Support 2.2.0
    NI-RIO 4.0 (FlexRIO 2.1.0)
    Xilinx DRAM compilation bug fix patch from NI article id 5E4FNCDP
    Xilinx clock bug fix patch from NI article id 5GFAB7DP
    replaces c:\NIFPGA\programs\Xilinx11_5\ISE\xilinx\lib\nt\libPlXil_Clocks.dll; The installed version is c:\NIFPGA\programs\Xilinx12_4-> Manually copied the dll to the installed version
    The Project uses the 5761 low speed clip and a DRAM FIFO.
    I tried to compile it before installing any patch, after installing the DRAM patch, and after installing both patches and always got a Xilinx error after ~10 minutes compile time. The error summary shown above and the attached Xilinx log are from compiling with both patches installed.
    It compiled correctly on our older system:
    Hardware:
    NI PXIe-1082 Chassis
    NI PXIe-8133 Embedded controller
    NI PXIe-7965R FPGA FlexRIO FPGA module
    NI 5761 250 MS/s 14 bit Analog input digitizer
    Installed software:
    Labview2011version10.0.0
    LabviewFPGAmodule10.0.0
    FPGAcompilationtools (Xilinx11_5)
    NIFlexRIOAdapterModuleSupport2.1.0
    NI-RIO3.5.1 (FlexRIO1.5.0)
    XilinxDRAMcompilationbugfixpatchfromNIarticleid5E4FNCDP
    Any help / suggestions greatly appreciated,
    Fabrizio
    Attachments:
    XilinxLog.txt ‏1482 KB

    Hi Torpedotown, 
    Can you tell me what version of FlexRIO Adapter Module Support you are using? 
    The 5761 Low Speed CLIP has a constraint that doesn't work properly with some versions of the compilation tools.  In order to solve this you should be able to upgrade to our latest version of FAM support, or go change the constraint manually.  
    For the latest version of FAM support, go to http://ni.com/info and enter code "famsoftware"
    If you've modified constraint files before and feel comfortable doing it yourself, let me know and I can provide you with the details on how to do that. 
    Thanks!
    National Instruments
    FlexRIO & R-Series Product Support Engineer

  • DDR3 Memory on NetFPGA (Timing error)

    Hi,
    I am using NetFPGA 1G-CML Board (Kintex 7 is used as FPGA).
    I cloned NetFPGA-1G-CML-live projects from Github(https://github.com/NetFPGA/NetFPGA-1G-CML-live), and tried to add 7 series MIG core to reference_switch_nf1_cml project.
    But after PAR running, I got following timing error...
    and,
    7 constraints not met.
    INFO:Timing:2761 - N/A entries in the Constraints List may indicate that the
       constraint is not analyzed due to the following: No paths covered by this
       constraint; Other constraints intersect with this constraint; or This
       constraint was disabled by a Path Tracing Control. Please run the Timespec
       Interaction Report (TSI) via command line (trce tsi) or Timing Analyzer GUI.
    Generating Pad Report.
    1 signals are not completely routed. See the system.unroutes file for a list of all unrouted signals.
    WARNING:Par:100 - Design is not completely routed. There are 1 signals that are not
       completely routed in this design. See the "system.unroutes" file for a list of
       all unrouted signals. Check for other warnings in your PAR report that might
       indicate why these nets are unroutable. These nets can also be evaluated
       in FPGA Editor by selecting "Unrouted Nets" in the List Window.
    WARNING:Par:283 - There are 393 loadless signals in this design. This design will cause Bitgen to issue DRC warnings.
    Total REAL time to PAR completion: 5 mins 3 secs
    Total CPU time to PAR completion: 5 mins 16 secs
    Peak Memory Usage:  2612 MB
    Placer: Placement generated during map.
    Routing: Completed - errors found.
    Timing: Completed - 724 errors found.
    Number of error messages: 0
    Number of warning messages: 400
    Number of info messages: 1
    Writing design to file system.ncd
    PAR done!
    ERROR:Xflow - Program par returned error code 30. Aborting flow execution...
    Done!
    I attached my ucf file and mhs file.
    How can I solve this error?
    Thanks.

    Hi 
    The net which is failing to route is from MMCM to IDELAYCTRL. The MMCM is placed in X1Y2 clock region and the IDELAYCTRL is placed in X0Y4 clock region hence the router fails. Please insert a BUFG in between MMCM and IDELAYCTRL instances. Adding a snapshot of failing net.
    Thanks,
    Deepika.

  • [svn:cairngorm3:] 21174: Landmark does not work under complex situations

    Revision: 21174
    Revision: 21174
    Author:   [email protected]
    Date:     2011-04-29 11:21:00 -0700 (Fri, 29 Apr 2011)
    Log Message:
    Landmark does not work under complex situations
    https://bugs.adobe.com/jira/browse/CGM-39
    Ticket Links:
        http://bugs.adobe.com/jira/browse/CGM-39
    Modified Paths:
        cairngorm3/trunk/libraries/Navigation/src/com/adobe/cairngorm/navigation/core/EnterAndExi tInvoker.as
        cairngorm3/trunk/libraries/Navigation/src/com/adobe/cairngorm/navigation/waypoint/Waypoin tHandler.as

    Hi John,
    1) I like that the new model adds parameterization. It's cleaner than pulling in parameters from pre-set variables. However, the given example didn't actually make much use of it. The only non-constant parameter multiply-used in the example is the "table" variable. Seems like a lot of work for not a lot of gain, at least in this case?
    2) I am cautious that this new template/model condenses the paradigm sooo much, that it is no longer clear where XPath is involved vs straight constant tag names. Yes, Adobe's example is overly-expanded but that's common in code meant to be a demonstration.
    3) I also am cautious that the example intermingles direct node creation into the XPath search/processing chain. I've learned to be VERY careful with this. It only can work when the changes made do not interfere with the rule processing. In my model, I simply avoid it completely (by not making node-position or node-add/remove/move changes until after tree parsing is complete.) This will always be a safe model.
    Bottom line: while I very much appreciate the parameterization and lintability (is that a word? Sure makes sense to me )... I think I would still define each rule separately rather than bring them all together as an inline array in the rule processing call. To me it seems sooo condensed that the XPath meaning can become lost. (Would someone recognize that //para/section-head is actually an XPath statement that could (in another situation) be //para/* or //para/following-siblings::* ... while some of the other strings are exact-match tag names?)
    I realize this is all a matter of style... my preference: clarity for the future reader, particularly when the future reader is me a year later who forgot what all those parameters and embedded methods were all about ...
    Blessings,
    Pete

  • PAR done but shows PAR Error on planahead 14.7

    hi,
    am getting PAR error while in log it shows PAR done!!!
    this happens only when i change the reset pin of my design from V5 to any other pin.
    my design consists of microblaze also.
    Thanks

    following is the logi file
    *** Running ngdbuild
    with args -intstyle ise -p xc6slx45fgg484-2 -dd _ngo -uc "top_module.ucf" -bm "top_module.bmm" "top_module.edf"
    Command Line:
    D:\InstalledSW\Xilinx147\14.7\ISE_DS\ISE\bin\nt64\unwrapped\ngdbuild.exe
    -intstyle ise -p xc6slx45fgg484-2 -dd _ngo -uc top_module.ucf -bm top_module.bmm
    top_module.edf
    Executing edif2ngd -quiet "top_module.edf" "_ngo\top_module.ngo"
    Release 14.7 - edif2ngd P.20131013 (nt64)
    Copyright (c) 1995-2013 Xilinx, Inc. All rights reserved.
    Reading NGO file
    "D:/BEL_DRC/BEL_DRC/mohammad_ADC_july24/spartan6_adc2.runs/impl_1/_ngo/top_modul
    e.ngo" ...
    Gathering constraint information from source properties...
    Done.
    Annotating constraints to design from ucf file "top_module.ucf" ...
    Resolving constraint associations...
    Checking Constraint Associations...
    Done...
    Processing BMM file "top_module.bmm" ...
    Checking expanded design ...
    WARNING:NgdBuild:443 - SFF primitive
    'test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Perform
    ance.Decode_I/Using_FPGA.Gen_Bits[27].MEM_EX_Result_Inst' has unconnected
    output pin
    Partition Implementation Status
    No Partitions were found in this design.
    NGDBUILD Design Results Summary:
    Number of errors: 0
    Number of warnings: 1
    Writing NGD file "top_module.ngd" ...
    Total REAL time to NGDBUILD completion: 37 sec
    Total CPU time to NGDBUILD completion: 9 sec
    Writing NGDBUILD log file "top_module.bld"...
    NGDBUILD done.
    *** Running map
    with args -intstyle pa -w "top_module.ngd"
    Using target part "6slx45fgg484-2".
    Mapping design into LUTs...
    Running directed packing...
    Running delay-based LUT packing...
    Updating timing models...
    INFO:Map:215 - The Interim Design Summary has been generated in the MAP Report
    (.mrp).
    Running timing-driven placement...
    Total REAL time at the beginning of Placer: 17 secs
    Total CPU time at the beginning of Placer: 16 secs
    Phase 1.1 Initial Placement Analysis
    Phase 1.1 Initial Placement Analysis (Checksum:1f7146f2) REAL time: 19 secs
    Phase 2.7 Design Feasibility Check
    Phase 2.7 Design Feasibility Check (Checksum:1f7146f2) REAL time: 19 secs
    Phase 3.31 Local Placement Optimization
    Phase 3.31 Local Placement Optimization (Checksum:c84c17d2) REAL time: 19 secs
    Phase 4.2 Initial Placement for Architecture Specific Features
    Phase 4.2 Initial Placement for Architecture Specific Features
    (Checksum:fb9deab) REAL time: 38 secs
    Phase 5.36 Local Placement Optimization
    Phase 5.36 Local Placement Optimization (Checksum:fb9deab) REAL time: 38 secs
    Phase 6.30 Global Clock Region Assignment
    Phase 6.30 Global Clock Region Assignment (Checksum:fb9deab) REAL time: 38 secs
    Phase 7.3 Local Placement Optimization
    Phase 7.3 Local Placement Optimization (Checksum:fb9deab) REAL time: 39 secs
    Phase 8.5 Local Placement Optimization
    Phase 8.5 Local Placement Optimization (Checksum:fb9deab) REAL time: 39 secs
    Phase 9.8 Global Placement
    Phase 9.8 Global Placement (Checksum:fe784d) REAL time: 53 secs
    Phase 10.5 Local Placement Optimization
    Phase 10.5 Local Placement Optimization (Checksum:fe784d) REAL time: 53 secs
    Phase 11.18 Placement Optimization
    Phase 11.18 Placement Optimization (Checksum:bc17e6b8) REAL time: 1 mins 3 secs
    Phase 12.5 Local Placement Optimization
    Phase 12.5 Local Placement Optimization (Checksum:bc17e6b8) REAL time: 1 mins 4 secs
    Phase 13.34 Placement Validation
    Phase 13.34 Placement Validation (Checksum:ee3892b6) REAL time: 1 mins 4 secs
    Total REAL time to Placer completion: 1 mins 13 secs
    Total CPU time to Placer completion: 1 mins 9 secs
    Running post-placement packing...
    Writing output files...
    Design Summary:
    Number of errors: 0
    Number of warnings: 19
    Slice Logic Utilization:
    Number of Slice Registers: 2,768 out of 54,576 5%
    Number used as Flip Flops: 2,761
    Number used as Latches: 0
    Number used as Latch-thrus: 0
    Number used as AND/OR logics: 7
    Number of Slice LUTs: 2,495 out of 27,288 9%
    Number used as logic: 2,244 out of 27,288 8%
    Number using O6 output only: 1,810
    Number using O5 output only: 48
    Number using O5 and O6: 386
    Number used as ROM: 0
    Number used as Memory: 157 out of 6,408 2%
    Number used as Dual Port RAM: 64
    Number using O6 output only: 0
    Number using O5 output only: 0
    Number using O5 and O6: 64
    Number used as Single Port RAM: 0
    Number used as Shift Register: 93
    Number using O6 output only: 26
    Number using O5 output only: 1
    Number using O5 and O6: 66
    Number used exclusively as route-thrus: 94
    Number with same-slice register load: 90
    Number with same-slice carry load: 4
    Number with other load: 0
    Slice Logic Distribution:
    Number of occupied Slices: 1,309 out of 6,822 19%
    Number of MUXCYs used: 228 out of 13,644 1%
    Number of LUT Flip Flop pairs used: 3,563
    Number with an unused Flip Flop: 1,031 out of 3,563 28%
    Number with an unused LUT: 1,068 out of 3,563 29%
    Number of fully used LUT-FF pairs: 1,464 out of 3,563 41%
    Number of unique control sets: 256
    Number of slice register sites lost
    to control set restrictions: 1,096 out of 54,576 2%
    A LUT Flip Flop pair for this architecture represents one LUT paired with
    one Flip Flop within a slice. A control set is a unique combination of
    clock, reset, set, and enable signals for a registered element.
    The Slice Logic Distribution report is not meaningful if the design is
    over-mapped for a non-slice resource or if Placement fails.
    IO Utilization:
    Number of bonded IOBs: 4 out of 316 1%
    Number of LOCed IOBs: 4 out of 4 100%
    Specific Feature Utilization:
    Number of RAMB16BWERs: 32 out of 116 27%
    Number of RAMB8BWERs: 8 out of 232 3%
    Number of BUFIO2/BUFIO2_2CLKs: 1 out of 32 3%
    Number used as BUFIO2s: 1
    Number used as BUFIO2_2CLKs: 0
    Number of BUFIO2FB/BUFIO2FB_2CLKs: 1 out of 32 3%
    Number used as BUFIO2FBs: 1
    Number used as BUFIO2FB_2CLKs: 0
    Number of BUFG/BUFGMUXs: 14 out of 16 87%
    Number used as BUFGs: 14
    Number used as BUFGMUX: 0
    Number of DCM/DCM_CLKGENs: 5 out of 8 62%
    Number used as DCMs: 5
    Number used as DCM_CLKGENs: 0
    Number of ILOGIC2/ISERDES2s: 0 out of 376 0%
    Number of IODELAY2/IODRP2/IODRP2_MCBs: 0 out of 376 0%
    Number of OLOGIC2/OSERDES2s: 0 out of 376 0%
    Number of BSCANs: 1 out of 4 25%
    Number of BUFHs: 0 out of 256 0%
    Number of BUFPLLs: 0 out of 8 0%
    Number of BUFPLL_MCBs: 0 out of 4 0%
    Number of DSP48A1s: 3 out of 58 5%
    Number of ICAPs: 0 out of 1 0%
    Number of MCBs: 0 out of 2 0%
    Number of PCILOGICSEs: 0 out of 2 0%
    Number of PLL_ADVs: 1 out of 4 25%
    Number of PMVs: 0 out of 1 0%
    Number of STARTUPs: 0 out of 1 0%
    Number of SUSPEND_SYNCs: 0 out of 1 0%
    Average Fanout of Non-Clock Nets: 3.63
    Peak Memory Usage: 536 MB
    Total REAL time to MAP completion: 1 mins 18 secs
    Total CPU time to MAP completion: 1 mins 14 secs
    Mapping completed.
    See MAP report file "top_module.mrp" for details.
    *** Running par
    with args -intstyle pa "top_module.ncd" -w "top_module_routed.ncd"
    Constraints file: top_module.pcf.
    Loading device for application Rf_Device from file '6slx45.nph' in environment
    D:\InstalledSW\Xilinx147\14.7\ISE_DS\ISE\.
    "top_module" is an NCD, version 3.2, device xc6slx45, package fgg484, speed -2
    Initializing temperature to 85.000 Celsius. (default - Range: 0.000 to 85.000 Celsius)
    Initializing voltage to 1.140 Volts. (default - Range: 1.140 to 1.260 Volts)
    Device speed data version: "PRODUCTION 1.23 2013-10-13".
    Device Utilization Summary:
    Slice Logic Utilization:
    Number of Slice Registers: 2,768 out of 54,576 5%
    Number used as Flip Flops: 2,761
    Number used as Latches: 0
    Number used as Latch-thrus: 0
    Number used as AND/OR logics: 7
    Number of Slice LUTs: 2,495 out of 27,288 9%
    Number used as logic: 2,244 out of 27,288 8%
    Number using O6 output only: 1,810
    Number using O5 output only: 48
    Number using O5 and O6: 386
    Number used as ROM: 0
    Number used as Memory: 157 out of 6,408 2%
    Number used as Dual Port RAM: 64
    Number using O6 output only: 0
    Number using O5 output only: 0
    Number using O5 and O6: 64
    Number used as Single Port RAM: 0
    Number used as Shift Register: 93
    Number using O6 output only: 26
    Number using O5 output only: 1
    Number using O5 and O6: 66
    Number used exclusively as route-thrus: 94
    Number with same-slice register load: 90
    Number with same-slice carry load: 4
    Number with other load: 0
    Slice Logic Distribution:
    Number of occupied Slices: 1,309 out of 6,822 19%
    Number of MUXCYs used: 228 out of 13,644 1%
    Number of LUT Flip Flop pairs used: 3,563
    Number with an unused Flip Flop: 1,031 out of 3,563 28%
    Number with an unused LUT: 1,068 out of 3,563 29%
    Number of fully used LUT-FF pairs: 1,464 out of 3,563 41%
    Number of slice register sites lost
    to control set restrictions: 0 out of 54,576 0%
    A LUT Flip Flop pair for this architecture represents one LUT paired with
    one Flip Flop within a slice. A control set is a unique combination of
    clock, reset, set, and enable signals for a registered element.
    The Slice Logic Distribution report is not meaningful if the design is
    over-mapped for a non-slice resource or if Placement fails.
    IO Utilization:
    Number of bonded IOBs: 4 out of 316 1%
    Number of LOCed IOBs: 4 out of 4 100%
    Specific Feature Utilization:
    Number of RAMB16BWERs: 32 out of 116 27%
    Number of RAMB8BWERs: 8 out of 232 3%
    Number of BUFIO2/BUFIO2_2CLKs: 1 out of 32 3%
    Number used as BUFIO2s: 1
    Number used as BUFIO2_2CLKs: 0
    Number of BUFIO2FB/BUFIO2FB_2CLKs: 1 out of 32 3%
    Number used as BUFIO2FBs: 1
    Number used as BUFIO2FB_2CLKs: 0
    Number of BUFG/BUFGMUXs: 14 out of 16 87%
    Number used as BUFGs: 14
    Number used as BUFGMUX: 0
    Number of DCM/DCM_CLKGENs: 5 out of 8 62%
    Number used as DCMs: 5
    Number used as DCM_CLKGENs: 0
    Number of ILOGIC2/ISERDES2s: 0 out of 376 0%
    Number of IODELAY2/IODRP2/IODRP2_MCBs: 0 out of 376 0%
    Number of OLOGIC2/OSERDES2s: 0 out of 376 0%
    Number of BSCANs: 1 out of 4 25%
    Number of BUFHs: 0 out of 256 0%
    Number of BUFPLLs: 0 out of 8 0%
    Number of BUFPLL_MCBs: 0 out of 4 0%
    Number of DSP48A1s: 3 out of 58 5%
    Number of ICAPs: 0 out of 1 0%
    Number of MCBs: 0 out of 2 0%
    Number of PCILOGICSEs: 0 out of 2 0%
    Number of PLL_ADVs: 1 out of 4 25%
    Number of PMVs: 0 out of 1 0%
    Number of STARTUPs: 0 out of 1 0%
    Number of SUSPEND_SYNCs: 0 out of 1 0%
    Overall effort level (-ol): Standard
    Router effort level (-rl): High
    Starting initial Timing Analysis. REAL time: 8 secs
    Finished initial Timing Analysis. REAL time: 8 secs
    WARNING:Par:288 - The signal test_module_inst/mb_inst/dlmb_LMB_ABus[31] has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[12].ra
    m32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[9].ram
    32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[13].ra
    m32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[7].ram
    32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[4].ram
    32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal test_module_inst/mb_inst/dlmb_LMB_ABus[30] has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[11].ra
    m32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[8].ram
    32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[6].ram
    32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[5].ram
    32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[1].ram
    32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[0].ram
    32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[14].ra
    m32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[10].ra
    m32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[15].ra
    m32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[2].ram
    32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    WARNING:Par:288 - The signal
    test_module_inst/mb_inst/microblaze_0/microblaze_0/MicroBlaze_Core_I/Performance.Data_Flow_I/Register_File_I/Using_LUT6.All_RAM32M[3].ram
    32m_i_RAMD_D1_O has no load. PAR will not attempt to route this signal.
    Starting Router
    Phase 1 : 20567 unrouted; REAL time: 9 secs
    Phase 2 : 15210 unrouted; REAL time: 13 secs
    WARNING:Route:436 - The router has detected an unroutable situation for one or more connections. The router will finish the rest of the
    design and leave them as unrouted. The cause of this behavior is either an issue with the placement or unroutable placement constraints.
    To allow you to use FPGA editor to isolate the problems, the following is a list of (up to 10) such unroutable connections:
    Unroutable signal: clk_adc_sig pin: test_module_inst/adc_wrapper_inst/clk_wizard_gen[0].clk_wizard_inst/dcm_sp_inst/CLKIN
    Unroutable signal: clk_adc_sig pin: test_module_inst/adc_wrapper_inst/clk_wizard_gen[2].clk_wizard_inst/dcm_sp_inst/CLKIN
    Unroutable signal: clk_adc_sig pin: test_module_inst/adc_wrapper_inst/clk_wizard_gen[3].clk_wizard_inst/dcm_sp_inst/CLKIN
    Phase 3 : 5729 unrouted; REAL time: 33 secs
    Phase 4 : 5729 unrouted; (Setup:0, Hold:0, Component Switching Limit:0) REAL time: 35 secs
    Updating file: top_module_routed.ncd with current fully routed design.
    Phase 5 : 3 unrouted; (Setup:0, Hold:0, Component Switching Limit:0) REAL time: 49 secs
    Phase 6 : 3 unrouted; (Setup:0, Hold:0, Component Switching Limit:0) REAL time: 49 secs
    Phase 7 : 3 unrouted; (Setup:0, Hold:0, Component Switching Limit:0) REAL time: 49 secs
    Phase 8 : 3 unrouted; (Setup:0, Hold:0, Component Switching Limit:0) REAL time: 49 secs
    Phase 9 : 3 unrouted; (Setup:0, Hold:0, Component Switching Limit:0) REAL time: 49 secs
    Phase 10 : 3 unrouted; (Setup:0, Hold:0, Component Switching Limit:0) REAL time: 50 secs
    Total REAL time to Router completion: 50 secs
    Total CPU time to Router completion: 50 secs
    Partition Implementation Status
    No Partitions were found in this design.
    Generating "PAR" statistics.
    Generating Clock Report
    +---------------------+--------------+------+------+------------+-------------+
    | Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max Delay(ns)|
    +---------------------+--------------+------+------+------------+-------------+
    |test_module_inst/mb_ | | | | | |
    | inst/clk_50_0000MHz | BUFGMUX_X2Y10| No | 960 | 0.064 | 1.774 |
    +---------------------+--------------+------+------+------------+-------------+
    |test_module_inst/adc | | | | | |
    |_wrapper_inst/clk180 | | | | | |
    | _sig[0] | BUFGMUX_X2Y9| No | 28 | 0.057 | 1.766 |
    +---------------------+--------------+------+------+------------+-------------+
    | clk_rd_sig | BUFGMUX_X2Y4| No | 104 | 0.052 | 1.770 |
    +---------------------+--------------+------+------+------------+-------------+
    |test_module_inst/adc | | | | | |
    |_wrapper_inst/clk180 | | | | | |
    | _sig[1] | BUFGMUX_X2Y11| No | 28 | 0.028 | 1.743 |
    +---------------------+--------------+------+------+------------+-------------+
    |test_module_inst/adc | | | | | |
    |_wrapper_inst/clk180 | | | | | |
    | _sig[2] | BUFGMUX_X2Y1| No | 27 | 0.031 | 1.771 |
    +---------------------+--------------+------+------+------------+-------------+
    |test_module_inst/adc | | | | | |
    |_wrapper_inst/clk180 | | | | | |
    | _sig[3] | BUFGMUX_X3Y8| No | 27 | 0.028 | 1.739 |
    +---------------------+--------------+------+------+------------+-------------+
    |test_module_inst/mb_ | | | | | |
    |inst/microblaze_0_md | | | | | |
    | m_bus_Dbg_Clk | BUFGMUX_X3Y13| No | 61 | 0.055 | 1.767 |
    +---------------------+--------------+------+------+------------+-------------+
    | clk_counter_sig | BUFGMUX_X2Y2| No | 2 | 0.002 | 1.738 |
    +---------------------+--------------+------+------+------------+-------------+
    |test_module_inst/adc | | | | | |
    |_wrapper_inst/clkout | | | | | |
    | _wiz_sig[1] | BUFGMUX_X3Y5| No | 2 | 0.000 | 1.770 |
    +---------------------+--------------+------+------+------------+-------------+
    |test_module_inst/adc | | | | | |
    |_wrapper_inst/clkout | | | | | |
    | _wiz_sig[0] | BUFGMUX_X3Y15| No | 7 | 0.045 | 1.767 |
    +---------------------+--------------+------+------+------------+-------------+
    |test_module_inst/adc | | | | | |
    |_wrapper_inst/clkout | | | | | |
    | _wiz_sig[3] | BUFGMUX_X3Y16| No | 2 | 0.000 | 1.722 |
    +---------------------+--------------+------+------+------------+-------------+
    |test_module_inst/adc | | | | | |
    |_wrapper_inst/clkout | | | | | |
    | _wiz_sig[2] | BUFGMUX_X2Y12| No | 2 | 0.000 | 1.766 |
    +---------------------+--------------+------+------+------------+-------------+
    |test_module_inst/adc | | | | | |
    |_wrapper_inst/clk270 | | | | | |
    | _sig[0] | BUFGMUX_X3Y14| No | 4 | 0.022 | 1.765 |
    +---------------------+--------------+------+------+------------+-------------+
    |test_module_inst/mb_ | | | | | |
    |inst/microblaze_0_md | | | | | |
    | m_bus_Dbg_Update | Local| | 20 | 4.177 | 6.233 |
    +---------------------+--------------+------+------+------------+-------------+
    * Net Skew is the difference between the minimum and maximum routing
    only delays for the net. Note this is different from Clock Skew which
    is reported in TRCE timing report. Clock Skew is the difference between
    the minimum and maximum path delays which includes logic delays.
    * The fanout is the number of component pins not the individual BEL loads,
    for example SLICE loads not FF loads.
    Timing Score: 0 (Setup: 0, Hold: 0, Component Switching Limit: 0)
    Number of Timing Constraints that were not applied: 1
    Asterisk (*) preceding a constraint indicates it was not met.
    This may be due to a setup or hold violation.
    Constraint | Check | Worst Case | Best Case | Timing | Timing
    | | Slack | Achievable | Errors | Score
    TS_test_module_inst_mb_inst_clock_generat | SETUP | 7.791ns| 12.209ns| 0| 0
    or_0_clock_generator_0_SIG_PLL0_CLKOUT0 | HOLD | 0.240ns| | 0| 0
    = PERIOD TIMEGRP "test_mod | | | | |
    ule_inst_mb_inst_clock_generator_0_clock_ | | | | |
    generator_0_SIG_PLL0_CLKOUT0" TS_ | | | | |
    sys_clk_pin HIGH 50% | | | | |
    TS_sys_clk_pin = PERIOD TIMEGRP "sys_clk_ | MINLOWPULSE | 15.000ns| 5.000ns| 0| 0
    pin" 50 MHz HIGH 50% | | | | |
    Derived Constraint Report
    Review Timing Report for more details on the following derived constraints.
    To create a Timing Report, run "trce -v 12 -fastpaths -o design_timing_report design.ncd design.pcf"
    or "Run Timing Analysis" from Timing Analyzer (timingan).
    Derived Constraints for TS_sys_clk_pin
    +-------------------------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------+
    | | Period | Actual Period | Timing Errors | Paths Analyzed |
    | Constraint | Requirement |-------------+-------------|-------------+-------------|-------------+-------------|
    | | | Direct | Derivative | Direct | Derivative | Direct | Derivative |
    +-------------------------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------+
    |TS_sys_clk_pin | 20.000ns| 5.000ns| 12.209ns| 0| 0| 0| 358509|
    | TS_test_module_inst_mb_inst_cl| 20.000ns| 12.209ns| N/A| 0| 0| 358509| 0|
    | ock_generator_0_clock_generato| | | | | | | |
    | r_0_SIG_PLL0_CLKOUT0 | | | | | | | |
    +-------------------------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------+
    All constraints were met.
    Generating Pad Report.
    1 signals are not completely routed. See the top_module_routed.unroutes file for a list of all unrouted signals.
    WARNING:Par:100 - Design is not completely routed. There are 1 signals that are not
    completely routed in this design. See the "top_module_routed.unroutes" file for a list of
    all unrouted signals. Check for other warnings in your PAR report that might
    indicate why these nets are unroutable. These nets can also be evaluated
    in FPGA Editor by selecting "Unrouted Nets" in the List Window.
    WARNING:Par:283 - There are 18 loadless signals in this design. This design will cause Bitgen to issue DRC warnings.
    Total REAL time to PAR completion: 53 secs
    Total CPU time to PAR completion: 52 secs
    Peak Memory Usage: 515 MB
    Placer: Placement generated during map.
    Routing: Completed - errors found.
    Timing: Completed - No errors found.
    Number of error messages: 0
    Number of warning messages: 23
    Number of info messages: 0
    Writing design to file top_module_routed.ncd
    PAR done!

  • XML Rule + JS example: group elements under new parents

    Thanks again to everyone here for helping me get started! I'm now making real progress. In token of my appreciation, here's something that hopefully will eventually help others.
    I've worked out how to use the XML Rule facility (together w/ some JS management) to collect groups of XML elements and create new parent elements containing each group.
    The sample code here demonstrates several things in both JavaScript and InDesign Script, including:
    Use of the XML Rules facility to quickly retrieve data from the XML structure
    Use of the following-sibling XPath facility to obtain same-level XML elements
    Creating XML tags, parent elements, and moving elements
    Multi-dimensional JS array for managing XML elements
    By the way, here are a few more things that were not obvious to this noob (I'm sure they are documented; just took time to find them...)
    In the InDesign script editor, you can bring up the Object Model Viewer by pressing F1
    In the object model viewer, you must click below "Browser" and select the InDesign Object Model before doing a search
    At the following link is a list of links to incredibly valuable documents and a huge collection of "Scripting Guide" sample scripts. http://www.adobe.com/products/indesign/indepth.displayTab2.html#Scriptingresources
    Using try { xyzzy; } catch (myErr) { alert(myErr); }  ... is your friend
    Below is a description of what my sample code actually accomplishes. But first, here are some things I learned about the XML Rules facility. Probably obvious to someone who has used this before but hey, I'm new to this:
    You create a set of XML Rules and pass them to the "glue code." Each time the set of rules is run, a single (potentially complex) traversal is made through the XML Structure.
    The implication of #1 is that for any given element in the structure, the first rule that matches the element will process it. Thus, the sequence of rule definitions is always important. This both simplifies and sometimes makes more complex how one designs a set of rules.
    An example in my case:
    I wanted to collect all elements at one level into "groups", with a particular (known) tag as the first element in each group.
    It was pretty clear how to find the known tag; use an XPath like "/devices/name" if the tag is "name" underneath "/devices."
    But how to collect the intervening tags? In normal XPath/XSLT syntax, this is a bit complicated. But in the XML Rule system, it's actually easy...
    Since the first rule will always collect every "name" element, my second rule becomes simply "/devices/name/following-sibling::*" which means "collect all siblings after the 'name' element. Normally, that would include following name elements as well, but it does not do so here since the first rule collects those.
    Don't bother trying to rearrange the XML structure from within XML Rule processing. In certain limited situations it can work... but it is just as easy, and quite reliable, to collect the needed info during XML Rule processing, then make the structure changes as a later step.
    The MakeXMLGroups(myXPath,myParentTag,myHeadTag) function changes:
    Devices
       Name
       Type
       Desc
       Name
       Quantity
       Type
       Desc
       Name
       Desc
    To:
    Devices
      Device
          Name
          Type
          Desc
      Device
          Name
          Quantity
          Type
          Desc
      Device
           Name
          Desc
    In this case, the function call was MakeXMLGroups("/Devices","Device","Name").
    (NOTE: I'm on personal travel this week so may not get back to answer questions until next week...)
    Here are links to the necessary files:
    http://ds.org/files/adobe/MakeXMLGroups.jsx
    http://ds.org/files/adobe/grpXMLRulesExampleSetup.jsx
    http://ds.org/files/adobe/grpXMLRulesExampleData.xml
    Message was edited by: SLTyPete to insert file links

    Hi John,
    1) I like that the new model adds parameterization. It's cleaner than pulling in parameters from pre-set variables. However, the given example didn't actually make much use of it. The only non-constant parameter multiply-used in the example is the "table" variable. Seems like a lot of work for not a lot of gain, at least in this case?
    2) I am cautious that this new template/model condenses the paradigm sooo much, that it is no longer clear where XPath is involved vs straight constant tag names. Yes, Adobe's example is overly-expanded but that's common in code meant to be a demonstration.
    3) I also am cautious that the example intermingles direct node creation into the XPath search/processing chain. I've learned to be VERY careful with this. It only can work when the changes made do not interfere with the rule processing. In my model, I simply avoid it completely (by not making node-position or node-add/remove/move changes until after tree parsing is complete.) This will always be a safe model.
    Bottom line: while I very much appreciate the parameterization and lintability (is that a word? Sure makes sense to me )... I think I would still define each rule separately rather than bring them all together as an inline array in the rule processing call. To me it seems sooo condensed that the XPath meaning can become lost. (Would someone recognize that //para/section-head is actually an XPath statement that could (in another situation) be //para/* or //para/following-siblings::* ... while some of the other strings are exact-match tag names?)
    I realize this is all a matter of style... my preference: clarity for the future reader, particularly when the future reader is me a year later who forgot what all those parameters and embedded methods were all about ...
    Blessings,
    Pete

  • Impossible de télécharger une application dans App World

    Je dispose d'un BB Curve 8320 et un compte BB ID ouvert recemment. Le Téléchargement s'effectue jusqu'à la moitié du temps prévu puis s'arrête brutalement et le message suivant s'affiche: "Un problème s'est produit pendant l'installation. Veuillez réessayer". puis "BB App World rencontre des problèmes de connexion au serveur BB App World. Vérifier vos connexions réseau et réessayez". C'est ce que j'ai fait plusieurs fois, sans succès. Le téchargement s'arrête toujours au même endroit. Bien entendu il me reste suffisamment de mémoire pour installer l'appli (17 Mo pour une appli de 1,2 Mo) Que faire pour sortir de cette situation ? Par avance merci pour vos conseils.

    Bonjour,
    as-tu pu résoudre ton pb ?
    Est-ce que tu as le droit d'utiliser BlackBerryWorld? Je te conseille d'appeler la hotline d'Orange pour le vérifier.
    The search box on top-right of this page is your true friend, and the public Knowledge Base too:

  • MIG : K7 - DDR3 - 1600 MHz - IBIS Model for addr/cmd with VccAux = 2.0V

    Hi everybody !
    I have a problem in the generation of my IBIS file...
    I'm using Vivado 2015.1 and MIG v2.3. My FPGA is xc7k325tffg900-2.
    In the xdc file (generated by the MIG), I have this type of constraint for all of my address and control signals :
    # PadFunction: IO_L8P_T1_33
    set_property VCCAUX_IO HIGH [get_ports {ddr3_addr[0]}]
    set_property SLEW FAST [get_ports {ddr3_addr[0]}]
    set_property IOSTANDARD SSTL15 [get_ports {ddr3_addr[0]}]
    set_property PACKAGE_PIN AC12 [get_ports {ddr3_addr[0]}]
    It therefore seems logical to me that when I try to generate my IBIS file, it tries to find the SSTL15_F_AUX20_HP model for these signals. But this model does not exist !!!
    Two questions :
    Is it normal to have the property "VCCAUX_IO HIGH" for cmd/addr signals ?
    Can I use SSTL15_F_HP model (which exists) instead ?
    Many Thanks
    Arnaud

    Hi Vinay,
    Thanks for the answer ! It seemed logical to me but I wanted to make sure.
    In that case, why the SSTL15_F_AUX20_HP model is not defined in the Xilinx IBIS file for the Kintex-7 ?
    Electrical standard is SSTL15 (DDR3), my slew is Fast, we are in HP bank and my VccAux_IO = 2.0V.
    And if the SSTL15_F_AUX20_HP model is equivalent to the SSTL15_F_HP so the VCCAUX_IO HIGH property has no effect ...
    I can not believe I'm the only one to ask ...
    Arnaud

  • No ILA debug cores in example DDR3 MIG design

    Vivado 2014.3.1
    Micron MT41K256M16MA-107E
    XC7VX980T-2FFG1926C
    Using MIG 2.2 wizard, created a stand-alone core with appropriate definitions, including debug (4096).  Generated the core. Selected the core and created example design.  
    Synthesis successfully completes.
    Debug panel view:
    Launching Implementation Run generates message:
    Have not been unable to resolve problem.
     

    Hi Vinay.  Thank you for the suggestion, but I have already completed that step (several times).  Going through setup debug again simply removes 1 debug core and adds 1 debug core at the end.  The schematic shows chipscope in the design. Yes I have searched with google, but not finding an answer to this situation.  I have consulted other users on my project, they are also stumped.

  • 400MHz DDR3 MIG with 25MHz input clock

    I’m generating a memory controller to interface our DDR3 with x16@400MHz and I need to clarify the clocking configuration of the MIG.
    From ug388 I’ve understood that the controller has a PLL to generate the necessary clocks and the MIG generates the default parameters (mult/div) assuming that the input clock is the same as that of the DDR bus, so 400MHz. I have 25MHz as input to the PLL. Ug388 states that we need to modify the following parameters to set the correct clocking for a different input:
    C1_CLKFBOUT_MULT
    C1_DIVCLK_DIVIDE
    C1_CLKOUT0_DIVIDE (for sysclk_2x)
    C1_CLKOUT1_DIVIDE (for sysclk_2x_180)
    C1_CLKOUT2_DIVIDE (for user clock)
    C1_CLKOUT3_DIVIDE (for calibration clock)
    From my understanding sysclk_2x is two times the DDR bus clock, so in this case 800MHz (seems extremely high for a Sp6!). Anyway the only way I can do this is to have
    C1_CLKFBOUT_MULT = 32 (Generate the 800MHz)
    C1_DIVCLK_DIVIDE = 1 (Generate the 800MHz)
    C1_CLKOUT0_DIVIDE = 1; 800MHz sysclk_2x
    C1_CLKOUT1_DIVIDE = 1; 800MHz sysclk_2x_180
    C1_CLKOUT2_DIVIDE = 4; (for user clock at 200MHz)
    C1_CLKOUT2_DIVIDE = 8; (for calibration clock at 100MHz)
    Is this correct? To be honest I’m worried about the 800MHz, but this is my interpretation from ug388. Also I’m worried about generating an 800MHz from a 25MHz source, wouldn’t jitter be a problem?
    I also find it strange right away for the MIG to assume by default an input (user) clock of 400MHz, as this is a very high frequency for a spartan6…
    Too many doubts, looking forward for your answers. Thanks!

    Hi
    I agree that is it strange to choose memory clock as input clock by default , it is improved in later versions like 7 series and Ultrascale but for older devices this is still a limitation.
    You should be able to generate 800 Mhz with out any issues, you can cross check in clocking wizard for jitter etc.,
    There should be an AR with more details on how to change the input clock for MCB,  but looks removed from web.
    Here is its content 
    "To modify the clocking setup to create the necessary MCB clocks from a different input clock frequency or to adjust the user or calibration clock frequencies, the following PLL parameters can be adjusted at the top level of the MIG example or user design:
    Cx_CLKFBOUT_MULT
    Cx_DIVCLK_DIVIDE
    Cx_CLKOUT0_DIVIDE (for sysclk_2x)
    Cx_CLKOUT1_DIVIDE (for sysclk_2x_180)
    Cx_CLKOUT2_DIVIDE (for user clock)
    Cx_CLKOUT3_DIVIDE (for calibration clock)
    where "x" represents the MCB block number.
    Cx_MEMCLK_PERIOD is mapped to the CLKIN1_PERIOD of the PLL and is also used to determine a number of other parameters defined in mcb_raw_wrapper.v/vhd. So, an additional input clock parameter should be used to specify the input clock frequency and it should be mapped to the CLKIN1_PERIOD of the PLL (instead of Cx_MEMCLK_PERIOD). This has already been included in MIG v3.6 so that users do not need to do this in the future.
    There are two options to determining the correct values for the other parameters listed above:
    Use the Clocking Wizard found in the Xilinx CORE Generator (Coregen) tool to determine the appropriate parameter settings based on the desired input and output clock frequencies for the PLL. Choose "Manual Selection" and the "PLL_BASE" primitive on the opening dialogue page to ensure that a PLL is used. Only the above parameter values produced by the Clocking Wizard should be transferred back into the MIG design; no other output from the Clocking Wizard is needed. The Clocking Wizard also determines the resulting output jitter from a specific PLL configuration that can be used to validate the main MCB system clocks against the memory device input clock jitter requirements.
    Refer to the PLL chapter in the Spartan-6 FPGA Clocking Resources User Guide (UG382) to verify the proper settings of the above parameters for the desired input and output clock frequencies for the PLL: http://www.xilinx.com/support/documentation/user_guides/ug382.pdf. This method requires a better understanding of such aspects as keeping the PLL VCO operating frequency within the specification.
    In addition to providing the parameter values for the various output clocks in design top module, the following changes are required to reflect to the MIG rtl environment:
    1. UCF changes
    MIG generates the clock constraints in the UCF for the design frequency provided in the MIG GUI. When the input clock frequency is changed, users need to change the design frequency in the UCF. In the below constraint, modify the period value.
    NET "memc5_infrastructure_inst/sys_clk_ibufg" TNM_NET = "SYS_CLK5"; TIMESPEC "TS_SYS_CLK5" = PERIOD "SYS_CLK5" 5 ns HIGH 50 %;
    2. Testbench (sim_tb_top.v/.vhd) Changes
    MIG provides the clock generation logic in the simulation testbench (sim_tb_top module) for the design frequency provided in the GUI. This logic needs to be modified to reflect the new input clock frequency:
    Original Verilog Code:
    always #(C3_MEMCLK_PERIOD/2) c3_sys_clk = ~c3_sys_clk;
    Modified Verilog Code:
    Instead of using the parameter C3_MEMCLK_PERIOD/2 in the above logic, the bit time period value needs to be provided. For example, for input clock frequency of 50MHz (20000 ps), C3_MEMCLK_PERIOD/2 should be replaced with a value of 10000. After making this change, thecode looks like the following:
    always #10000 c4_sys_clk = ~c4_sys_clk;
    Original VHDL Code:
    process
    begin
    c1_sys_clk <= not c1_sys_clk;
    wait for (C1_TCYC_SYS_DIV2);
    end process;
    Modified VHDL Code:
    For an input clock frequency of 50MHz, code looks as follows:
    process
    begin
    c1_sys_clk <= not c1_sys_clk;
    wait for (10 ns);
    end process;"
     Hope this helps
    -Vanitha

  • Axi Master DDR (MIG) tester

    Hi guys I'm trying to create a DDR stresser on my project, so I created an Vivado HLS IP core that has one axi-master interface and one axi-lite-slave(for parameters) the code is bellow
    #include <stdio.h>
    #include <string.h>
    #include <stdlib.h>
    unsigned int memDDR3Tester(unsigned int start, unsigned int size, unsigned int mode, unsigned int data, volatile unsigned int *memPtr, unsigned int *expectedVal, unsigned int *failedAddr, unsigned int *numErrors)
    #pragma HLS INTERFACE s_axilite port=numErrors bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=failedAddr bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=expectedVal bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=start bundle=CRTL_BUS
    #pragma HLS INTERFACE m_axi depth=512 port=memPtr
    #pragma HLS INTERFACE s_axilite port=data bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=mode bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=size bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=return bundle=CRTL_BUS
    unsigned int result = 0;
    unsigned int idxMemAddr = 0;
    unsigned int errorCounter = 0;
    *numErrors = 0;
    *expectedVal = 0;
    *failedAddr = 0;
    switch (mode)
    * Send 0xAA55 (16b1010101001010101) or 0x55AA if the address is odd/even
    * write then read and stop on the first error
    case 0:
    // Write
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    unsigned char isOdd = (idxMemAddr % 2);
    unsigned int value = (isOdd)?0x55AA:0xAA55;
    memPtr[idxMemAddr] = value;
    // Read
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    unsigned char isOdd = (idxMemAddr % 2);
    unsigned int value = (isOdd)?0x55AA:0xAA55;
    if (memPtr[idxMemAddr] != value)
    result = 1;
    *expectedVal = value;
    *failedAddr = idxMemAddr;
    // Bail out on the first error
    *numErrors = 1;
    break;
    break;
    * Send an incremental value but don't stop if some error occured and return the number of errors
    case 1:
    // Write
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    unsigned int value = idxMemAddr;
    memPtr[idxMemAddr] = value;
    // Read
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    unsigned int value = idxMemAddr;
    if (memPtr[idxMemAddr] != value)
    result = 1;
    errorCounter++;
    *numErrors = errorCounter;
    break;
    * Send just a value and read it back
    case 2:
    memPtr[start] = data;
    if (memPtr[start] != data)
    result = 1;
    *expectedVal = data;
    *failedAddr = start;
    break;
    * Send on mode burst (memset) the value 0xAA55 (16b1010101001010101)
    case 3:
    //memset((unsigned int*)memPtr,(int)0xAA55,(size_t)(sizeof(unsigned int)*size));
    // Write
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    memPtr[idxMemAddr] = 0xAA55;
    // Read
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    if (memPtr[idxMemAddr] != 0xAA55)
    result = 1;
    errorCounter++;
    *numErrors = errorCounter;
    break;
    return result;
    #include <stdio.h>
    unsigned int memDDR3Tester(unsigned start, unsigned int size, unsigned int mode, unsigned int data, volatile unsigned int memPtr[512000000], unsigned int *expectedVal, unsigned int *failedAddr, unsigned int *numErrors);
    int main()
    unsigned int memPtr[10];
    unsigned int expectedVal;
    unsigned int failedAddr;
    unsigned int numErrors;
    unsigned int result;
    printf("Test mode 0\n");
    result = memDDR3Tester(0,10,0,0,memPtr,&expectedVal,&failedAddr,&numErrors);
    printf("Result mode 0: %d Expected: %d failedAddr:%d numErrors:%d\n",result,expectedVal,failedAddr,numErrors);
    for (int idx = 0; idx < 10; idx++)
    printf("DDR3[%d]=%x\n",idx,memPtr[idx]);
    return 0;
    The first problem is that I can simulate the on C/C++ but not co-simulate I get those errors:
    Determining compilation order of HDL files.
    INFO: [VRFC 10-2263] Analyzing Verilog file "C:/Users/laraujo/memDDR3Tester/solution1/sim/verilog/AESL_axi_master_memPtr.v" into library xil_defaultlib
    INFO: [VRFC 10-311] analyzing module AESL_axi_master_memPtr
    INFO: [VRFC 10-2263] Analyzing Verilog file "C:/Users/laraujo/memDDR3Tester/solution1/sim/verilog/AESL_axi_slave_CRTL_BUS.v" into library xil_defaultlib
    INFO: [VRFC 10-311] analyzing module AESL_axi_slave_CRTL_BUS
    ERROR: [VRFC 10-46] write_start_count is already declared [C:/Users/laraujo/memDDR3Tester/solution1/sim/verilog/AESL_axi_slave_CRTL_BUS.v:201]
    ERROR: [VRFC 10-46] write_start_run_flag is already declared [C:/Users/laraujo/memDDR3Tester/solution1/sim/verilog/AESL_axi_slave_CRTL_BUS.v:202]
    ERROR: [VRFC 10-46] write_start is already declared [C:/Users/laraujo/memDDR3Tester/solution1/sim/verilog/AESL_axi_slave_CRTL_BUS.v:738]
    ERROR: [VRFC 10-552] declarations not allowed in unnamed block [C:/Users/laraujo/memDDR3Tester/solution1/sim/verilog/AESL_axi_slave_CRTL_BUS.v:738]
    ERROR: [VRFC 10-1040] module AESL_axi_slave_CRTL_BUS ignored due to previous errors [C:/Users/laraujo/memDDR3Tester/solution1/sim/verilog/AESL_axi_slave_CRTL_BUS.v:11]
    ERROR: Please check the snapshot name which is created during 'xelab',the current snapshot name "xsim.dir/memDDR3Tester/xsimk.exe" does not exist
    These are the results for C/C++ simulation:
    Compiling ../../../test_core.cpp in debug mode
    Generating csim.exe
    Test mode 0
    Result mode 0: 0 Expected: 0 failedAddr:0 numErrors:0
    DDR3[0]=aa55
    DDR3[1]=55aa
    DDR3[2]=aa55
    DDR3[3]=55aa
    DDR3[4]=aa55
    DDR3[5]=55aa
    DDR3[6]=aa55
    DDR3[7]=55aa
    DDR3[8]=aa55
    DDR3[9]=55aa
    @I [SIM-1] CSim done with 0 errors.
    Anyway after exporting to vivado and connecting the mig and the microblaze through an Axi Interconnect, I got this: (Artix 7 Avnet demoboard)
    The addresses:
    On Xilinx SDK my code to initialize the core and test it this:
    #include <stdio.h>
    #include <xmemddr3tester.h>
    #include <xparameters.h>
    #include <xil_cache.h>
    XMemddr3tester doMemDDR3Test;
    XMemddr3tester_Config *doMemDDR3Test_cfg;
    #define SIZE_ARRAY 10
    unsigned int *topMemDDR = (unsigned int *)0x80000000;
    void initDDRTester()
    int status = 0;
    doMemDDR3Test_cfg = XMemddr3tester_LookupConfig(XPAR_MEMDDR3TESTER_0_DEVICE_ID);
    if (doMemDDR3Test_cfg)
    status = XMemddr3tester_CfgInitialize(&doMemDDR3Test,doMemDDR3Test_cfg);
    if (status != XST_SUCCESS)
    printf("Failed to inititalize\n");
    int main()
    int idx = 0;
    unsigned int error;
    initDDRTester();
    for (idx = 0; idx < SIZE_ARRAY; idx++)
    topMemDDR[idx] = idx*2;
    printf("DDR3 tester console\n");
    Xil_DCacheFlushRange((unsigned int)topMemDDR,sizeof(unsigned int)*SIZE_ARRAY);
    XMemddr3tester_Set_mode(&doMemDDR3Test,0);
    XMemddr3tester_Set_data(&doMemDDR3Test,0);
    XMemddr3tester_Set_start(&doMemDDR3Test,0x80000000);
    XMemddr3tester_Set_size(&doMemDDR3Test,(unsigned int)SIZE_ARRAY);
    XMemddr3tester_Start(&doMemDDR3Test);
    while (!XMemddr3tester_IsDone(&doMemDDR3Test));
    error = XMemddr3tester_Get_return(&doMemDDR3Test);
    printf("Test done %d\n",error);
    Xil_DCacheInvalidateRange((unsigned int)topMemDDR,sizeof(unsigned int)*SIZE_ARRAY);
    for (idx = 0; idx < SIZE_ARRAY; idx++)
    printf("DDR3[%d]=%x\n",idx,topMemDDR[idx]);
    return 0;
    By some reason it seems that is the data is not been sent to the MIG (I though initialiy that could be a problem with the Cache but it seems that is not the case, anyway I disabled the cache on the microblaze)
    So to resume the questions:
    1) Someone knows what could be wrong on the Co-Simulation
    2) The address autogenerated for the mig is also updated somehow on the HLS core? (I tried to manually set the pointer address on Vivado HLS but it didn't synthesised)
    3) Do you guys seem something wrong on this design?
    4) Can I use the ILA to see the DDR3 interface (Or should I use the "Mark Debug option?)
    Thanks.

    Hi  thanks, I've changed the parameter name and the previous error on the simulation disappeared, but now I have a comsim.pc.exe crash during the C post checkign phase.
    INFO: [Common 17-206] Exiting xsim at Tue Jul 14 10:48:04 2015...
    @I [SIM-316] Starting C post checking ...
    @E [SIM-379] Detected segmentation violation, please check C tb.
    @E [SIM-362] Aborting co-simulation: C TB post check failed.
    @E [SIM-4] *** C/RTL co-simulation finished: FAIL ***
    So what I did was to simplify the IP core more to only send 0xaa55 or 0x55aa on the master interface:
    core.cpp (Used to generate the IP core)
    #include <stdio.h>
    #include <string.h>
    #include <stdlib.h>
    // 1Gb limit
    #define MAX_MEM_SIZE 200000
    unsigned int memDDR3Tester(unsigned int size, volatile unsigned int *memPtr, unsigned int *expectedVal, unsigned int *failedAddr, unsigned int *numErrors)
    #pragma HLS INTERFACE s_axilite port=numErrors bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=failedAddr bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=expectedVal bundle=CRTL_BUS
    #pragma HLS INTERFACE m_axi depth=512 port=memPtr
    #pragma HLS INTERFACE s_axilite port=size bundle=CRTL_BUS
    #pragma HLS INTERFACE s_axilite port=return bundle=CRTL_BUS
    unsigned int result = 0;
    unsigned int idxMemAddr = 0;
    unsigned int errorCounter = 0;
    *numErrors = 0;
    *expectedVal = 0;
    *failedAddr = 0;
    * Send 0xAA55 (16b1010101001010101) or 0x55AA if the address is odd/even
    * write then read and stop on the first error
    // Write
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    #pragma HLS LOOP_TRIPCOUNT min=256000000 max=256000000 avg=256000000
    unsigned char isOdd = (idxMemAddr % 2);
    unsigned int value = (isOdd)?0x55AA:0xAA55;
    memPtr[idxMemAddr] = value;
    /*if (idxMemAddr > size)
    break;*/
    // Read
    for (idxMemAddr = 0; idxMemAddr < size; idxMemAddr++)
    #pragma HLS LOOP_TRIPCOUNT min=256000000 max=256000000 avg=256000000
    unsigned char isOdd = (idxMemAddr % 2);
    unsigned int value = (isOdd)?0x55AA:0xAA55;
    if (memPtr[idxMemAddr] != value)
    result = 1;
    *expectedVal = value;
    *failedAddr = idxMemAddr;
    // Bail out on the first error
    *numErrors = 1;
    break;
    /*if (idxMemAddr > size)
    break;*/
    return result;
    test core
    #include <stdio.h>
    unsigned int memDDR3Tester(unsigned int size, volatile unsigned int *memPtr, unsigned int *expectedVal, unsigned int *failedAddr, unsigned int *numErrors);
    unsigned int memPtr[20];
    int main()
    unsigned int expectedVal;
    unsigned int failedAddr;
    unsigned int numErrors;
    unsigned int result;
    printf("Test mode 0\n");
    result = memDDR3Tester(10,memPtr,&expectedVal,&failedAddr,&numErrors);
    printf("Result mode 0: %d Expected: %d failedAddr:%d numErrors:%d\n",result,expectedVal,failedAddr,numErrors);
    for (int idx = 0; idx < 10; idx++)
    printf("DDR3[%d]=%x\n",idx,memPtr[idx]);
    return 0;
    But again the simulation on C/C++ works but I have some trouble on the co-simulation part.
    I also tried to change the for loop to hava a fixed constant iteration and on the midle of its code break if the condition size is met:
    // Write
    for (idxMemAddr = 0; idxMemAddr < MAX_MEM_SIZE; idxMemAddr++)
    unsigned char isOdd = (idxMemAddr % 2);
    unsigned int value = (isOdd)?0x55AA:0xAA55;
    memPtr[idxMemAddr] = value;
    if (idxMemAddr > size)
    break;
    The problem is that if I try to synthesize this I got this error:
    Stack dump:
    0. Running pass 'Generate interface primitives' on module 'C:/Users/laraujo/ddrStresserVIV_2015/solution1/.autopilot/db/a.o.2.bc'.
    0x000007FEC7CBE4E0 (0x0000000000000003 0x00000000059368D0 0x00000000059368D8 0x0000000002924BF0), ?save_object_ptr@?$pointer_oserializer@Vxml_oarchive@archive@boost@@VTransition@DBFsm@fsmd@@@detail@archive@boost@@EEBAXAEAVbasic_oarchive@234@PEBX@Z() + 0x331210 bytes(s)
    0x000007FEC773080A (0x0000000000000004 0x0000000005553D20 0x0000000006A51FB0 0x00000000001D8200), ?main@Syn@@YAHHPEAPEAD@Z() + 0x5A1C3A bytes(s)
    0x000007FEC77300D3 (0x0000000006E80350 0x00000000001D7DC0 0x0000000006A52E60 0x00000000001D81C0), ?main@Syn@@YAHHPEAPEAD@Z() + 0x5A1503 bytes(s)
    0x000007FEC7732D7A (0x0000000000000000 0x0000000006E819D0 0x0000000005553D20 0x0000000006DBEDD0), ?main@Syn@@YAHHPEAPEAD@Z() + 0x5A41AA bytes(s)
    0x000007FEC7731385 (0x00000000001D8300 0x00000000001D8410 0x00000000059366F0 0x00000000059366F0), ?main@Syn@@YAHHPEAPEAD@Z() + 0x5A27B5 bytes(s)
    0x000007FEC7738D25 (0x0000000000000000 0x00000000059366F0 0x0000000000000000 0x0000000000000001), ?main@Syn@@YAHHPEAPEAD@Z() + 0x5AA155 bytes(s)
    0x000007FEC7C56777 (0x0000000000000004 0x0000000006E04480 0x0000000005936460 0x0000000006D8EE90), ?save_object_ptr@?$pointer_oserializer@Vxml_oarchive@archive@boost@@VTransition@DBFsm@fsmd@@@detail@archive@boost@@EEBAXAEAVbasic_oarchive@234@PEBX@Z() + 0x2C94A7 bytes(s)
    0x000007FEC7C557B0 (0x0000000000000004 0x00000000001D8CD9 0x0000000006D8EE90 0x0000000000000000), ?save_object_ptr@?$pointer_oserializer@Vxml_oarchive@archive@boost@@VTransition@DBFsm@fsmd@@@detail@archive@boost@@EEBAXAEAVbasic_oarchive@234@PEBX@Z() + 0x2C84E0 bytes(s)
    0x000007FEC7149148 (0x00000000000011C2 0x00000000001D8CD9 0x0000000000000000 0x000007FEC827CF70)
    0x000007FEEFB2B1A4 (0x000000000235DCC0 0x000000006DED2E12 0x0000000006A303B0 0x00000000002FD600), ??1TclManager@xpcl@@QEAA@XZ() + 0x1F94 bytes(s)
    0x000007FEEFB2D9C9 (0x000000006DF52B18 0x0000000000000096 0x0000000006A3CA50 0x000000006DF1937C), ?setResultObj@TclCommand@xpcl@@QEAAXPEAUTcl_Obj@@@Z() + 0x49 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000096 0x0000000006A3DA50 0x0000000000000096), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE51D9E (0x00000000002FD600 0x0000000006A3CA50 0x0000000000000096 0x0000000000000096), Tcl_EvalEx() + 0x99E bytes(s)
    0x000000006DE52A28 (0x0000000000000000 0x00000000023268B8 0x0000000000000001 0x0000000000000002), TclEvalObjEx() + 0x348 bytes(s)
    0x000000006DE5A88A (0x0000000000000000 0x00000000002FD600 0x00000000002FD600 0x0000000000000000), TclDumpMemoryInfo() + 0x340A bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000002 0x00000000023268B8 0x00000000023268B8), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000006A0BCA0 0x000000006DF53178 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DE94464 (0x0000000003771A50 0x00000000002FD600 0x000000006DF53178 0x000000006DEE329B), Tcl_ExprObj() + 0x634 bytes(s)
    0x000000006DE52AA6 (0x0000000000000753 0x0000000000000000 0x0000000000000003 0x0000000000000003), TclEvalObjEx() + 0x3C6 bytes(s)
    0x000000006DE59F00 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x00000000002EFE60), TclDumpMemoryInfo() + 0x2A80 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000003 0x0000000002326848 0x0000000002326848), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000006978220 0x000000000027BE36 0x6666666600000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DE94464 (0x0000000006A30110 0x00000000002FD600 0x0000000000000000 0x0000000000000000), Tcl_ExprObj() + 0x634 bytes(s)
    0x000000006DE52AA6 (0x0000000002326800 0x00000000002FD600 0x0000000000000000 0x0000000000000002), TclEvalObjEx() + 0x3C6 bytes(s)
    0x000000006DE6909A (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x00000000023267F0), TclDumpMemoryInfo() + 0x11C1A bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000002 0x00000000023267E8 0x00000000023267E8), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000006A3C250 0x0000000000000000 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DEDFED4 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x000000006DF193BD), TclObjInterpProcCore() + 0x74 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000004 0x00000000023265B8 0x00000000023265B8), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000006A46280 0x0000000000000000 0xFFFFFFFF00000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DEDFED4 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x0000000000000000), TclObjInterpProcCore() + 0x74 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000100000005 0x0000000002326348 0x0000000002326348), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000006B2E270 0x0000000000000000 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DEDFED4 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x0000000000000000), TclObjInterpProcCore() + 0x74 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000001 0x00000000023261F8 0x00000000023261F8), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000006A39340 0x0000000002326040 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DE94464 (0x0000000006BA4660 0x00000000002FD600 0x0000000002325DA0 0x00000000001DBCA0), Tcl_ExprObj() + 0x634 bytes(s)
    0x000000006DE52AA6 (0x0000000006A2AF20 0x0000000000000000 0x0000000000000003 0x0000000002325FF0), TclEvalObjEx() + 0x3C6 bytes(s)
    0x000000006DE59F00 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x00000000002EFE60), TclDumpMemoryInfo() + 0x2A80 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000003 0x0000000002326040 0x0000000000000003), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE51D9E (0x00000000002FD600 0x00000000028FD7AB 0x0000000000000003 0x0000000000000003), Tcl_EvalEx() + 0x99E bytes(s)
    0x000000006DED5952 (0x00000000002FD600 0x0000000000000002 0x0000000000000001 0x0000000000000000), Tcl_SubstObj() + 0x832 bytes(s)
    0x000000006DE51991 (0x00000000002FD600 0x00000000028FD6D0 0x0000000000000002 0x000007FE00000002), Tcl_EvalEx() + 0x591 bytes(s)
    0x000000006DE52638 (0x00000000029335F0 0x00000000029335F0 0x00000000001DC270 0x000007FEC7E5C184), Tcl_Eval() + 0x38 bytes(s)
    0x000007FEC711D735 (0x0000000000000FD5 0x0000000000000FD5 0x00000000029335F0 0x0000000000000FD5)
    0x000007FEEFB2B1F3 (0x0000000006CB7430 0x0000000006A4B554 0x0000000000000001 0x00000000002FD600), ??1TclManager@xpcl@@QEAA@XZ() + 0x1FE3 bytes(s)
    0x000007FEEFB2D9C9 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x000000006DF193BD), ?setResultObj@TclCommand@xpcl@@QEAAXPEAUTcl_Obj@@@Z() + 0x49 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000005 0x0000000002325960 0x0000000002325960), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x00000000058C2F40 0x0000000000000000 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DEDFED4 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x000000006DE93BFC), TclObjInterpProcCore() + 0x74 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000001 0x0000000002325798 0x0000000002325798), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000005A24060 0x00000000023255E0 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DE94464 (0x0000000006CB4370 0x00000000002FD600 0x0000000002325340 0x00000000001DD280), Tcl_ExprObj() + 0x634 bytes(s)
    0x000000006DE52AA6 (0x0000000006CB5120 0x0000000000000000 0x0000000000000003 0x0000000002325590), TclEvalObjEx() + 0x3C6 bytes(s)
    0x000000006DE59F00 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x00000000002EFE60), TclDumpMemoryInfo() + 0x2A80 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000003 0x00000000023255E0 0x0000000000000003), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE51D9E (0x00000000002FD600 0x000000000564D91E 0x0000000000000003 0x0000000000000003), Tcl_EvalEx() + 0x99E bytes(s)
    0x000000006DED5952 (0x00000000002FD600 0x0000000000000002 0x0000000000000001 0x0000000000000000), Tcl_SubstObj() + 0x832 bytes(s)
    0x000000006DE51991 (0x00000000002FD600 0x000000000564CFB0 0x0000000000000002 0x000007FE00000002), Tcl_EvalEx() + 0x591 bytes(s)
    0x000000006DE52638 (0x0000000000275870 0x0000000000275870 0x00000000001DD850 0x000007FEC7E5C184), Tcl_Eval() + 0x38 bytes(s)
    0x000007FEC711D735 (0x00000000000008EB 0x00000000000008EB 0x0000000000275870 0x00000000000008EB)
    0x000007FEEFB2B1F3 (0x0000000000000001 0x00000000069D3448 0x0000000000000001 0x00000000002FD600), ??1TclManager@xpcl@@QEAA@XZ() + 0x1FE3 bytes(s)
    0x000007FEEFB2D9C9 (0x0000000000000000 0x0000000000000001 0x00000000055CDFE0 0x000000006DF193BD), ?setResultObj@TclCommand@xpcl@@QEAAXPEAUTcl_Obj@@@Z() + 0x49 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000009 0x0000000002324ED8 0x0000000002324ED8), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x0000000005A86490 0x0000000000000000 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DEDFED4 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x0000000000000000), TclObjInterpProcCore() + 0x74 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000001 0x0000000002324D48 0x0000000002324D48), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE95688 (0x00000000002FD600 0x00000000033DBBE0 0x0000000002324B90 0x0000000000000000), Tcl_ExprObj() + 0x1858 bytes(s)
    0x000000006DE94464 (0x00000000055CC390 0x00000000002FD600 0x00000000023248F0 0x00000000001DE860), Tcl_ExprObj() + 0x634 bytes(s)
    0x000000006DE52AA6 (0x00000000055CA650 0x0000000000000000 0x0000000000000003 0x0000000002324B40), TclEvalObjEx() + 0x3C6 bytes(s)
    0x000000006DE59F00 (0x0000000000000000 0x00000000002FD600 0x0000000000000000 0x00000000002EFE60), TclDumpMemoryInfo() + 0x2A80 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000003 0x0000000002324B90 0x0000000000000003), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE51D9E (0x00000000002FD600 0x00000000033CBBD1 0x0000000000000003 0x0000000000000003), Tcl_EvalEx() + 0x99E bytes(s)
    0x000000006DED5952 (0x00000000002FD600 0x0000000000000002 0x0000000000000001 0x0000000000000000), Tcl_SubstObj() + 0x832 bytes(s)
    0x000000006DE51991 (0x00000000002FD600 0x00000000033CBA10 0x0000000000000002 0x000007FE00000002), Tcl_EvalEx() + 0x591 bytes(s)
    0x000000006DE52638 (0x0000000000275CD0 0x0000000000275CD0 0x00000000001DEE30 0x000007FEC7E5C184), Tcl_Eval() + 0x38 bytes(s)
    0x000007FEC711D735 (0x00000000000008EB 0x00000000000008EB 0x0000000000275CD0 0x00000000000008EB)
    0x000007FEEFB2B1F3 (0x000000000286D420 0x000000006DED2E12 0x00000000055CCE70 0x00000000002FD600), ??1TclManager@xpcl@@QEAA@XZ() + 0x1FE3 bytes(s)
    0x000007FEEFB2D9C9 (0x0000000005931EF0 0x0000000000000000 0x0000000000000000 0x0000000000000002), ?setResultObj@TclCommand@xpcl@@QEAAXPEAUTcl_Obj@@@Z() + 0x49 bytes(s)
    0x000000006DE50E50 (0x0000000000000000 0x0000000000000001 0x0000000002324370 0x0000000000000001), Tcl_ListMathFuncs() + 0x590 bytes(s)
    0x000000006DE51D9E (0x00000000002FD600 0x00000000055978F0 0x0000000000000001 0x0000000000000001), Tcl_EvalEx() + 0x99E bytes(s)
    0x000000006DEBA4F0 (0x00000000002F7FD0 0x00000000002F7FD0 0x00000000002FD600 0x0000000000000000), Tcl_FSEvalFileEx() + 0x250 bytes(s)
    0x000000006DEC5B24 (0x0000000000000001 0x0000000000000008 0x0001F82056300000 0x000000000020C5A0), Tcl_Main() + 0x554 bytes(s)
    0x000007FEEFB2D1F1 (0x0000000000000002 0x0000000000282B3A 0x0077005C00640065 0x000007FEF5AE43B8), ?issue@TclManager@xpcl@@QEAAHHPEAPEAD_N@Z() + 0x371 bytes(s)
    0x000007FEC718FC52 (0x0000000000000000 0x01D0BE1535026984 0x0000000000000000 0x0000000000000000), ?main@Syn@@YAHHPEAPEAD@Z() + 0x1082 bytes(s)
    0x000000013F0B124B (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
    0x00000000776C652D (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0xD bytes(s)
    0x00000000778FC521 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x21 bytes(s)
    @E [HLS-102] Encountered an internal error;
    For technical support on this issue, please visit http://www.xilinx.com/support.

  • Survey URL Missing MIG

    Dear Experts,
    We have a mail form with Survey URL, we tested it via TEST SEND functionality. However when we send the mail form in french we get MIG generated in the mail, but when we select dutch language while TEST SEND , there is no MIG and hence when user clicks on survey URL , he gets message as " Parameters Missing in URL"
    FRENCH  " http://www************************==)/survey/survey.htm?applid=CRM_SURVEY_MARKETING&svyid=BE_INGELICHT&vers=0000000004&lang=FR&parid=ZCRM_SVY_BSP_SYSTEMPARAM_2%2eXML&appl_BUPA=0100460918&=&=&MIG=7292834D95700B39E10000001A600A02&URLGUID=1900864D65351139E10000001A600A02 " WORKS
    Dutch :
    http://www******************************==)/survey/survey.htm?applid=CRM_SURVEY_MARKETING&svyid=BE_INGELICHT&vers=0000000004&lang=NL&parid=ZCRM_SVY_BSP_SYSTEMPARAM_2%2eXML "
    Any Inputs
    Thanks in advance
    Smitha

    I am not sure if this will work or not.
    please check the language of the people in the target group you are sending the mail to. Is it the same as mentioned in the mail form?
    While testing this scenario I have faced a similar kind of situation.
    If you are sending it in NL, check the language of people in the target group it should be NL. just give it a try.

  • MIG mania

    After updating a Mac Pro from OS-X 10.6.8 to 10.8.2, syslogd is burning one of the 8 CPUs constantly, repeating the same 3 messages at the rate of 1000 lines per minute:
    12/16/12 12:58:34.010 PM com.apple.launchd[1]: MIG request.
    12/16/12 12:58:34.010 PM com.apple.launchd[1]: MIG callout: 421
    12/16/12 12:58:34.010 PM com.apple.launchd[1]: MIG demux succeeded.
    The computer is running 10 degree F hotter than before the update.
    MIG (Mach Interface Generator) is used by the Mach kernel to communicate among system processes.
    It may have been installed when I installed Xcode, which is where it is documented.
    https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages /man1/mig.1.html
    How do I track down the culprit?

    I found another statement that looks wrong to me.
    UG586 p.64 :
    ADDR_WIDTH
    This is the memory address bus
    width. It is equal to RANK_WIDTH +
    BANK_WIDTH + ROW_WIDTH +
    COL_WIDTH.
    I think it is incorrect. For instance in my case, I use a 4Gb (256M x 16b) DDR3 memory chip (Micron M41J256M16-HA125).
    RANK_WIDTH=1, BANK_WIDTH=3, ROW_WIDTH=15, COL_WIDTH=10, which gives ADDR_WIDTH=29 with your calculation.
    but the address should be 28b as my memory actually contains 256M x 16b = 4Gb.
    I think the mistake comes from using RANK_WIDTH instead of RANK_WIDTH-1. Because if RANK_NUMBER = 1 (my case), 0 address bit should be added. If RANK_NUMBER = 4, 2b should be added.
    The code of MIG IP also gives me the same calculation as above, which is wrong in my opinion, as the address is 29b whereas 28b ([27:0]) should be enough.

  • Impossible de mettre à jour mon Mac Book Air avec Mavericks. Pourquoi ? MacBook Air 13 ", mi-2011 Proc  1.7 GHz Intel Core i5 Mem  4 Go 1333 MHz DDR3 Graph  Intel HD Graphics 3000 384 MB N°  C02GDCBADJWT Logiciel  Mac OS X 10.7.5

    Impossible de mettre à jour mon Mac Book Air avec Mavericks. Pourquoi ? MacBook Air 13 ", mi-2011 Proc  1.7 GHz Intel Core i5 Mem  4 Go 1333 MHz DDR3 Graph  Intel HD Graphics 3000 384 MB N°  C02GDCBADJWT Logiciel  Mac OS X 10.7.5

    UPDATING post above.
    Excel slowing down is particularly when I do "copy" or "paste" (up to 3 seconds before the action is taken into account).
    I tried with empty or very small files, problem is the same.
    I checked autoupdates of Microsoft, everything is up to date.
    I made the test of David Linc, with no issue.
    Anyone having same situation or solution ?
    Thank you
    F.

  • DDR3 sys_clk & reference clock

    Hi,
    I want to use one DDR3 MIG with 800Mhz.
    Can I use internal clock as MIG sys_clk and ref_clk instead of external clock source?
    For example, the input clock is 100MHz. I use MMCM generate 200Mhz internal clock as DDR3MIG sys_clk and ref_clk?
    Thanks
     

    Hi,
    Check this thread http://forums.xilinx.com/t5/MIG-Memory-Interface-Generator/Regrading-system-clock-generated-with-no-buffer-option-for-DDR3/td-p/464398
    The reference clock can be driven internally but system clock should come from CCIO pins.
    Thanks,
    Deepika.

Maybe you are looking for