cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
305 Views
Registered: ‎08-27-2019

Consistency between GUI and command line builds

I'm trying to build a Continuous Integration pipeline for an existing ISE 14.7 project.

I have managed to get at least some bitstream by invoking

/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/xflow \
-synth xst_vhdl.opt \
-implement balanced.opt \
-config bitgen.opt \
-p xc3s50a-vq100-4 \
TOPLEVEL.prj

Obviously, that is only the first step, as this run has not consumed the UCF files, as fpga.flw assumes that there will be a single constraints file, while our project has two, Physical_Constraints.ucf and Timing_Constraints.ucf -- these seem to have been generated from the GUI, and are respected when compiling from the GUI, but ignored from xflow. It seems they are not mentioned in the .prj file, only in the .xise file.

I definitely need to keep ISE integration working as most of the engineers will work in the GUI, but at the same time, I also want to automatically compile and test images in the CI system, which requires me to use command line utilities.

Use commandline to generate .tcl from .xise ran into a similar problem and attempted to solve it by building Tcl files from the .xise file in an automation pipeline, but that thread didn't reach a conclusion.

  1. Is there a command line tool that can build an ISE project from the .xise file?
  2. If not, is there a way to list UCF files in a .prj file so they are consumed from xflow?
  3. Is there a way to ensure that the command line utilities and ISE will always have a consistent view of the project?
0 Kudos
3 Replies
Highlighted
Teacher
Teacher
236 Views
Registered: ‎07-09-2009

Re: Consistency between GUI and command line builds

You might be fighting the dragon there.,

ISE as I rember it, used "artificial aneealing" as part of its process..

   If so, here is no garuntee that and two runs will produce identical bit streams, they garuntee that the design meets your constraints. 

I understand that one of the stated advantages of Vivado is that whist it also meets your constraints  its repetable.

 

ISE was also a lot less TCL / script based than Vivado. So again your figting the system, 

    

Have you seen these ?

https://www.doulos.com/knowhow/tcltk/xilinx/

https://www.xilinx.com/support/answers/30655.html

http://www.campera-es.com/xilinx-ise---vivado-and-tcl

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Highlighted
Visitor
Visitor
172 Views
Registered: ‎08-27-2019

Re: Consistency between GUI and command line builds

Yes, the randomization is part of the problem and part of the solution -- for now, the FPGA is not so full that reproducibility is a problem.

In the long run, I'd like to be able to do multiple builds from the CI system with different random seeds, and then compare both their calculated timings and test them in real hardware to find the most suitable candidate.

Step one would be a command line build from an ISE project though -- it seems there are different flow driver utilities that pull compilation settings from different sources, which is why my UCF files are ignored from an xflow based build: they are mentioned only in the .xise project file, which is converted to Tcl, and the Tcl script then drives the build. I could adjust the xflow build to incorporate them, but there'd be no mechanism to ensure that this remains consistent with the ISE project.

If there was a simple command line tool I can directly point at the ISE project file and tell it to output a bitstream, potentially overriding the random seed later, that would be ideal.

For example, in another project I have an Altera CycloneIV GX, and that project is built with a simple script

quartus_map toplevel.qpf
quartus_fit toplevel.qpf
quartus_asm toplevel.qpf
quartus_pow toplevel.qpf
quartus_eda toplevel.qpf
quartus_sta toplevel.qpf

In this script, all commands directly consume the toplevel project file from the Quartus IDE, and all project settings and files, including chip type and timing/pin constraints, are referenced from there, so if I change anything in the IDE, the automated scripted builds will be consistent with that, while the xflow command I gave in the thread starter contains duplicated knowledge about the project and (silently!) ignores the UCF files.

0 Kudos
Highlighted
Teacher
Teacher
160 Views
Registered: ‎07-09-2009

Re: Consistency between GUI and command line builds

Yes , quartus was always a TCL system with a GUI on top whilst ise was more of a GUI with TCL underneath.
Vivado is more of the TCL with a GUI on top.
In my experience , most ise use was GUI driven.
Ise tcl never was that great,l.


In reality, as ise has not been updated for years , is no longer maintained and only runs under w7 , the way forward for any ise work is destined very soon to be ........

Good luck

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>