Q: Which versions of Xilinx tools are compatible with which versions of MATLAB?
Q: What 10GbE switch and/or NIC should I buy?
Q: How do I use interchip connections on the BEE2?
A: You must take time-of-flight variations into account. For more information, see the Interchip Interconnects page. NRAO is successfully using interchip connections for their GUPPi design, and Caltech is also using them for GAVRT.
Q: My Platform USB cable has stopped responding, and iMPACT will no longer connect to the cable until I restart the computer.
A: See this answer from Xilinx.
Q: Where can I find an inexpensive card cage to house my iBOBs?
A: Some have had luck buying old CompactPCI card cages and gutting them to house iBOBs. Vector electronics makes a number of suitable card cages, though it can be a bit tricky figuring out which ones are the right size. Part number CCK220-6U combined with CG1-220/12 card guides provides a suitable minimalist card cage that can then be mounted in a standard 19" rack.
Q: How can I program several iBOBs with one Platform USB or Parallel IV programmer?
A: Since the programming interface is a standard JTAG port, you can daisy chain multiple iBOBs together. XAPP139 from Xilinx details the connection on page 14, but basically Vref should only be connected to one board. All TMS and TCK signals should be tied together. The signal labeled TDO on the programmer should be connected to the TDO pin on the first iBOB, then the TDI pin from that iBOB should be connected to the TDO pin of the next iBOB and so on until the final iBOB TDI pin is connected back to the programmer. If all iBOBs are grounded externally, it may be wise to only connect one iBOB to the ground of the programmer to avoid a ground loop (although there will still be a ground loop to the ground of the computer that is controlling the programmer). The TCK maximum frequency of the programmer will almost certainly have to be reduced in iMPACT to account for the increased latency in the programming chain. So far I have only tested daisy chaining two iBOBs with one USB programmer.
Q: I'm having trouble getting Impact to run under Linux with a Platform USB cable.
A: This information from Xilinx gives the basics, but is a little sparse and difficult to follow. This site gives more details, but all of the hacking was not necessary with ISE 10.1. Some snags I came across:
- setup_pcusb must be run as root. su, then source setup_pcusb.
- fxload must be installed on your machine. Xilinx doesn't mention this, so I guess maybe it is standard with RedHat, but was not on Ubuntu.
- setting the XIL_IMPACT_USE_LIBUSB environment variable to 1 is crucial.
Q: How can I use the flexibility of the Xilinx DCM to generate an arbitrary clock from a given reference?
A: I am not an expert on this, but I managed to generate a 250MHz "simulink" clock (the clock domain of your Simulink design) from a 100 MHz external reference driving the User Clock input on the BEE2. The DCM configuration is done in the XPS_base/system.mhs file. First, compile your design with usr_clk2x selected as the clock source. Then edit the system.mhs to look like this:
... BEGIN dcm_module PARAMETER INSTANCE = dcm_2 ... PARAMETER C_CLK90_BUF = TRUE PARAMETER C_CLKFX_DIVIDE = 2 //divisor PARAMETER C_CLKFX_MULTIPLY = 5 //multiplier PARAMETER C_CLKFX_BUF = TRUE PARAMETER C_DFS_FREQUENCY_MODE = HIGH //chosen HIGH based on Coregen PORT LOCKED = dcm_2_lock ... PORT CLK90 = usr_clk90 PORT CLKFX = usr_clk2_5x_dcm //arbitrary name END
BEGIN dcm_module PARAMETER INSTANCE = dcm_3 ... PARAMETER C_CLKIN_PERIOD = 4.000000 //new period ... PORT CLKIN = usr_clk2_5x_dcm //same arbitrary name ... END
After modification, it took a few tries to get the system to rebuild the necessary parts (you basically need to run xflow again) without overwriting the changes to the mhs file. Note: using the frequency synthesizer mode seems to make the DCM much more sensitive to variation in input clock frequency as might be expected. I found in this case the DCM would lock with an reference ~90-110 MHz.
Q: How do the iBOB LWIP MAC and IP addresses get set?
A: The file in XPS_iBOB_base/drivers/xps_lwip/lwipinit.c sets everything up. You can change the IP and MAC there. By default, the lowest two bytes of the IP are equal to the lowest two bytes of the MAC. The lowest 14 bits of the MAC are set with headers on the 14 positions of J8 starting from the little dot.
Q: How can I plot/visualize the data coming out of my instrument?
A: With the plotting libraries listed on the Software page.
Q: How can I increase or decrease the number of Block-RAMs assigned to the PowerPC?
A: You can change the total size of the memory block allocated to the PowerPC by editing the
plb_bram_if_cntlr line in
~design/XPS_iBOB_base/system.mhs. The size must be a power of 2 (eg, 16k, 32k, 64k, etc.). To decrease BRAM usage from 64k (the default) to 32k, change:
PARAMETER INSTANCE = plb_bram_if_cntlr_1 PARAMETER HW_VER = 1.00.b PARAMETER c_plb_clk_period_ps = 10000 PARAMETER c_baseaddr = 0xffff0000 PARAMETER c_highaddr = 0xffffffff
PARAMETER INSTANCE = plb_bram_if_cntlr_1 PARAMETER HW_VER = 1.00.b PARAMETER c_plb_clk_period_ps = 10000 PARAMETER c_baseaddr = 0xffff8000 PARAMETER c_highaddr = 0xffffffff
Then you need to recompile your design. You can do this in Linux by running
xps -nw system.xmp from your shell, and then
run init_bram at the XPS prompt. You can also recompile in Windows from the XPS GUI, but you should be careful not to rebuild system.mhs.
You must also edit the LinkerScript in
~design/XPS_iBOB_base/Software to reflect the size of the new memory region.
Q: My LWIP design builds OK but the software compile fails with a message like...
/cygdrive/c/EDK71/gnu/powerpc-eabi/nt/bin/../lib/gcc/powerpc-eabi/3.4.1/../../.. /../powerpc-eabi/bin/ld: region plb_bram_if_cntlr_1 is full (Software/executable.elf section .text
A: Be sure you have the EDK 7.1 Service Pack 2 installed.
This problem can also occur in designs with additional code (LWIP takes up a significant amount of space, leaving less room for custom functions). In this case, try editing the system.xmp file in XPS_iBOB_base. Find the line CompilerOptLevel: 2 and change to CompilerOptLevel: 4 which optimizes for size rather than speed.
Q: Why didn't adding latency help my timing closure?
A: If you used a
Delay block to add latency, turn on the Enable Register Retiming option. This turns your delay line into a string of registers, which can help with spatial propagation. By default, it will pack a 16-element shift register into a single slice, which does very little to help you cross the chip. But you should use this technique sparingly. If you're just using a
Delay block to synchronize signals, leaving the delay line as a shift register greatly reduces resource usage.
If you are having trouble getting an
Multiplier block to meet timing, make sure that the Pipeline to Greatest Extent Possible option under Show Implementation Parameters is enabled. This builds the latency into the operation. Without this option, it still tries to complete the operation in a single cycle, and then tacks all the latency onto the end.
Also see this memo
Q: Why am i getting a brefclk error when building a BEE2 design with 10GbE?
A: On the BEE2, it is standard practice to stop the toolflow and manually trim unused clock nets. Which nets need removing depends on which serdes ports are used.
To get the 10GbE block to compile on the BEE2, you have to stop bee_xps after step 4 (Copy base package) and edit the system.ucf in XPS_BEE2_usr_base\data to remove the references to the unused clock nets. Then, continue with steps 5-9 of bee_xps.
Depending upon which XAUI ports are used, you will have to trim the references to brefclk_top_p and brefclk_top_m or brefclk_bottom_p and brefclk_bottom_m. The error messages will indicate whether top or bottom needs excision.
More specifically, adapted from advice from Jason: After compiling up to EDK/ISE/Bitgen, open XPS_BEE2_usr_base/data/system.ucf and comment the four lines near the top that mention brefclk_top or brefclk_bottom depending on which is giving an error message. Save the UCF file and run the EDK/ISE/Bitgen backend. From BEE_XPS, unselect all check boxes except Update Design and EDK/ISE/Bitgen.
================================================================================== COMMENT OUT THE FOLLOWING FOUR LINES IF YOU ARE ONLY USING 10GBE PORTS 2 and/or 3: ================================================================================== NET "brefclk_top_p" TNM_NET = "brefclk_top_p"; TIMESPEC "TS_brefclk_top_p" = PERIOD "brefclk_top_p" 156.25 Mhz; NET "brefclk_top_m" TNM_NET = "brefclk_top_m"; TIMESPEC "TS_brefclk_top_m" = PERIOD "brefclk_top_m" 156.25 Mhz; ================================================================================== COMMENT OUT THE FOLLOWING FOUR LINES IF YOU ARE ONLY USING 10GBE PORTS 0 and/or 1: ================================================================================== NET "brefclk_bottom_p" TNM_NET = "brefclk_bottom_p"; TIMESPEC "TS_brefclk_bottom_p" = PERIOD "brefclk_bottom_p" 156.25 Mhz; NET "brefclk_bottom_m" TNM_NET = "brefclk_bottom_m"; TIMESPEC "TS_brefclk_bottom_m" = PERIOD "brefclk_bottom_m" 156.25 Mhz;
Q: Why am I getting an 'igncr: unknown option name' error?
A: If you see something like:
Processor: ppc405_1 ERROR:MDT - :MDT - ERROR FROM TCL:- lwip () - /usr/bin/bash: igncr: unknown option name while executing "exec bash -c "cd src;make all \"COMPILER_FLAGS=$compiler_flags\" \"EXTRA_COMPILER_FLAGS=$extra_compiler_flags\" >& logs"" (procedure "::sw_lwip_v2_00_a::execs_generate" line 48) invoked from within "::sw_lwip_v2_00_a::execs_generate 44056320" ERROR:MDT - Error while running "execs_generate" for processor ppc405_1... make: *** [ppc405_1/lib/libxil.a] Error ERROR:MDT - Error while running "make -f system.make init_bram"
Update your installation of CYGWIN by visiting [www.cygwin.com] and try the last build step again.
A: Accessing Block-RAMs, SW Registers and FIFOs from BORPH in ASCII mode is known to be buggy. If possible, avoid ASCII mode at all costs. Instead, write your own interactive wrappers to read and write shared memory regions in binary mode.
Q: Why do i get permissions errors when i run "make bits" from the xps prompt?
A: If you are getting this error:
NGCBUILD done. ********************************************* Running Xilinx Implementation tools.. ********************************************* xilperl /tools/xilinx/10.1/EDK/data/fpga_impl/ manage_fastruntime_opt.pl -reduce_fanout no ERROR: can not chmod implementation/xflow.opt: Operation not permitted gmake: *** [__xps/system_routed] Error 1 ERROR:MDT - Error while running "gmake -f system.make bits" 1
then you should check the permissions of your build directory. If the permissions already look OK, there might be a more subtle problem. If your Linux build machine is NFS or SMB mounting a share on a Windows file server, the Linux permissions might not accurately reflect the permissions on the Windows server. From the Windows machine, make sure that you have "Full Control" of the build directory, and then try building again.
Q: Why is there a permissions error in 10.1 when using LWIP?
A: When compiling in 10.1 using LWIP you get the following error:
Copying files for library lwip_v2_00_a from C:\Xilinx\10.1\EDK\sw\ThirdParty\sw_services\lwip_v2_00_a\src\ to D:\casper_work\ten\snaptestlwip\XPS_iBOB_base\ppc405_1\libsrc\lwip_v2_00_a\ ... Running DRCs for OSes, Drivers and Libraries ... Runnning DRC for lwIP library... Running generate for OS'es, Drivers and Libraries ... Running generate for lwIP library ... Generating xemacliteif_g.c ... Generating lwipopts.h file ... ERROR:MDT - lwip () - error copying "./src/contrib/ports/v2pro/netif/xemacliteif_polled.c" to "./src/contrib/ports/v2pro/netif/xemacliteif.c": permission denied while executing "file copy -force "./src/contrib/ports/v2pro/netif/xemacliteif_polled.c" "./src/contrib/ports/v2pro/netif/xemacliteif.c"" (procedure "::sw_lwip_v2_00_a::generate" line 120) invoked from within "::sw_lwip_v2_00_a::generate 60581752" ERROR:MDT - Error while running "generate" for processor ppc405_1... make: *** [ppc405_1/lib/libxil.a] Error 2 ERROR:MDT - Error while running "make -f system.make init_bram"
This is caused by the read only permissions being carried over from directories in EDK. You need to use cygwin or the EDK Shell to change permissions of the EDK/sw/ directory(and all subdirectories) to be read/write.