cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
2,569 Views
Registered: ‎04-16-2009

Incremental XPS implementation (e.g. resuming impl. from the par)

Jump to solution

I see the fpga.flw and xflow_script.bat in the implement directory, which runs the comblete implementation flow: ngdbuild, map, par and timing check. If there is a timing violation in par, it fails. For instance, it often happens that one or two gen_dqs[6].u_iob_dqs/en_dqs_sync signals fail timing. But, I managed to reroute them with FPGA editor with reduced delay so that timing must succeed now. How do I proceed? I know that par can continue with -k option, which can be specified with etc/xflow.opt. However, I do not know how to start the XPS from the middle so that it takes the updated system.ncd, completes the routing (it has nothing to do since design is par-ed already), makes the timing check, generates bitstream and exports it into SDK, as normally. I can replace the system_map.ncd with corrected system.ncd file but the system.make-based flow does not seem to recognize that system.ncd needs to be regenerated even when I remove it. How do I tell the XPS that this needs to be done?

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Explorer
Explorer
3,170 Views
Registered: ‎04-16-2009

In XPS 14.4, I first fixed the timing by opening FPGA Editor, selected "all nets", located *gen_dqs[6].u_iob_dqs/en_dqs_sync*,that caused timing violation, rerouted it and saved as system_map.ncd. Normally, Unroute followed by Auto-route meets the timing. If not, there is an obstacle. Unroute the obstacle and auto-route again. Now, save the design as system_map.ncd.

 

Now comes the answer. You resume the failed XPS flow by executing the xflow_script.bat. (It needs to be fixed first: comment out the ngdbuild and map invocations and add -k(ontinue) option to the par:

 

par -mt 2 -k -w -ol high system_map.ncd system.ncd system.pcf

 

The xflow_script.bat is ready to be executed from the implementaion dir by XPS > Project > Launch Xilinx Shell.

 

Alternatively, instead of running the batch, we can remove the system.bit found in implementation, SDK\export and SDK\hw and xflow_script will be executed when we export the project into SDK in XPS.

 

Should we use this solution bravier? It is also curious to know why FPGA auto-routing succeeds to meet the timings, after par fails? Is it because mt option is used for par?

 

 

View solution in original post

0 Kudos
1 Reply
Highlighted
Explorer
Explorer
3,171 Views
Registered: ‎04-16-2009

In XPS 14.4, I first fixed the timing by opening FPGA Editor, selected "all nets", located *gen_dqs[6].u_iob_dqs/en_dqs_sync*,that caused timing violation, rerouted it and saved as system_map.ncd. Normally, Unroute followed by Auto-route meets the timing. If not, there is an obstacle. Unroute the obstacle and auto-route again. Now, save the design as system_map.ncd.

 

Now comes the answer. You resume the failed XPS flow by executing the xflow_script.bat. (It needs to be fixed first: comment out the ngdbuild and map invocations and add -k(ontinue) option to the par:

 

par -mt 2 -k -w -ol high system_map.ncd system.ncd system.pcf

 

The xflow_script.bat is ready to be executed from the implementaion dir by XPS > Project > Launch Xilinx Shell.

 

Alternatively, instead of running the batch, we can remove the system.bit found in implementation, SDK\export and SDK\hw and xflow_script will be executed when we export the project into SDK in XPS.

 

Should we use this solution bravier? It is also curious to know why FPGA auto-routing succeeds to meet the timings, after par fails? Is it because mt option is used for par?

 

 

View solution in original post

0 Kudos