There are various kinds of synthesis and implementation strategies in Xilinx Vivado.
When you have timing violations with your own codes, which you can check with the timing report, you need to modify your own codes to shorten the critical paths. However the timing violation came from the IPs which are already proven, you can use other synthesis and implemenation strategies.
Different strategies makes different timing, area, and power
Below table shows my case. I cannot test for all of strategies, because it consumes so many time.
It seems that synthesis strategy make very few changes with my design.
There is no a absolute winner of synthesis and implementation strategy. You need to use various strategies but it may need some time, computing power and storages. In my case, I ran 8 synthesis strategies and 19 implementation strategies for each of synthesis. It takes about 2 days with 24 parallel processing on total 56 thread intel CPU, and it releases 96GB of data.
When you are using Xilinx SDK, you have to distinguish pointer and array. If you declare a variable as a pointer, you have to use it as a pointer not array. If a pointer is used as array, synchoronous interrupt handler(exception) may occur.
volatile unsigned int* mem;
for(i=0; i<SIZE; i++){
mem[i] = i; //Synchoronous Interrupt Handler(exception) may occur
//you have to use like this
//*(mem+i) = i;
}
Bash if statement can be used with regular expression
if [[ "hello world" =~ "hello" ]] ## this is true
then
echo "'hello world' has 'hello'"
fi
if [[ "hello" =~ "hello world" ]] ## this is false
then
echo "'hello' has 'hello world'"
fi
if [[ "hello world" =~ e.* ]] ## this is true
then
echo "'hello world' has 'e' followed by any character"
fi
Note that
- the bracket should be double
- use "=~", not "~="
- use the regular expression without quotation mark
When you are using very large concatenated signals in Vivado simulation, it may cause elaborate step failure. You can release this problem with breaking into several smaller signals.
AR# 62969 says it may be fixed in 2015.1 version, however, it still exists in 2017.2 version
When you get [Opt 31-67] Problem from running Vivado opt_design phase, you have to check all the related input/output pins. If one of your input/output pins is not connected, it can occur. And also, even if you connect all the input/output pins, it can occur with a non-driving output pin.
Because the original SODIMM from Micron no longer produced, the newer ZCU102 boards have changed SODIMM (You can find this issue from Xilinx AR#71961).
If you have ZCU102 Evaluation board labeled as 0432055-05 and you are using some old version of Vivado, you may have to change some parameters from either of followings:
1. Change in each Vivado project
You can change some DRAM parameters from block design - Zynq Ultrascale+ MPSoC - DDR Controller
2. Change in board preset
You can find a board preset file from <Xilinx install directory>/Vivado/<version>/data/boards/board_files/zcu102/<board_version>/preset.xml
Among so many parameters, you have to change 4 parameters:
When you are using multi-version of Xilinx hardware servers on a computer, you may find out some conflicts:
1. port conflict
The default port for the Xilinx hardware server is 3121. If two versions of hardware server working on a computer, the ports have to be different
In this case, you can use -stcp::<port> argument to change the port number
hw_server.bat -S -stcp::3122
2. XVC(Xilinx Virtual Cable) conflict
If one hardware server is working for a device, then the other hardware server doesn't work for another device. It is because the first one uses two devices even if one of them is not necessary.
Therefore you need to map the server and device.
For this, the cable id is needed. you can use -e "set jtag-port-filter <cable_id>" argument to filter specific cable