Handling Quartus executable return codes

[Altera_Forum]

First post... 

I'm very new to Quartus and the FPGA world so be gentle.  I've written a script to perform each step of the build step by step using the executables...  quartus_map -blabla quartus_fit -blabla quartus_asm -blabla quartus_sta -t atclscript.tcl  What I need to put between the executables is a touch of code to look at the return codes and exit the rest of the script if necessary.  Any suggestions gretfully received.  Witty.

[Altera_Forum]

just wondering if you have tried quartus_sh --flow instead of running each individual binary.

[Altera_Forum]

--- Quote Start ---  just wondering if you have tried quartus_sh --flow instead of running each individual binary.  --- Quote End ---    Yes I had considered using quartus_sh --flow but I thought I may have more control by executing them individually with the potential of passing a unique tcl script to each one. For instance I'm running quartus_sta with a unique tcl file that produces our custom timing reports. I thought this was the way to go. Thanks.

[Altera_Forum]

i see. interestingly the example end to end flow manually runs TAN reports after a full compilation on page 10: 

 http://www.altera.com/literature/hb/qts/qts_qii52002.pdf  how about something like:  quartus_map myproj | grep -c unsuccessfulthe count of unsuccessful will be 0 if you can continue to the next stage and > 0 if not.  not sure if internal errors will trigger "unsuccessful", i'll check.

[Altera_Forum]

Note that in Assignments -> Settings -> TimeQuest you can manually add a .tcl file to be run as part of the TimeQuest step for compilation. There are also pre-flow Tcl scripts that can be run as part of any step. In general, these have been enough that I've never needed anything else outside of the commands to do what I want.

[Altera_Forum]

now there's the proper solution.

[Altera_Forum]

Thanks for the replies. 

 It's my task to setup up something to enable the designers in the company to quickly run a quartus build of the designs. I must mention that I'm from the ASIC (Synopsys DC etc) world and new to FPGA tool world. The concept of a gui is a strange one. To this end what I've basically done is produce an executable script which basically consists of... # -- project_new etc quartus_sh -t setup.tcl  quartus_map --read_settings_files=on --write_settings_files=off $BUILD -c $REVISION  quartus_fit --read_settings_files=off --write_settings_files=off $BUILD -c $REVISION  quartus_sta -t timequest_run.tcl  As you can see the only tcl I'm using is that to set up the project up and one to pass to TimeQuest to produce the custom reports. I've not actually come across any reason to pass anything to 'map' and 'fit' yet but I thought I'd do it this way instead of using quartus_sh --flow just in case in the future I did. From what you are saying you have never needed this ability or it can be done with a script and 'quartus_sh --flow'.  The problem I'm trying to solve is: I'm trying to add something between the quartus executables that will exit the script on the event of errors and give the user a clear indication of the cause.   Maybe I should us quartus_sh --flow after all.

[Altera_Forum]

Just a comment, but just because the GUI seems strange, take the time to delve into it some. Lauching compiles makes perfect sense for a script, but the Quartus GUI has a lot of really nice things. Even something that seems good for text like the reports are nice in the GUI. The hierarchical utilization sections have +/- by each hierarchy so you can roll everything up and make it more readable. Going to the Fitter -> Resource Section -> Control SIgnals and being able to sort by hierarchy or Usage and you can find how many clock enables in a particular section, or all the asynchronous clears. Go to the Fitter RAM summary and sort by MLAB usage and find exactly which RAMs use MLABs, which use M9Ks, etc. Cross-probing is huge too. Double-click on an error in synthesis and that HDL file pops up at the line number with the error. Right-click Locate on that signal and you can find it in the Pin Planner to see where it's assigned, or in the Assignment Editor to see if it has any other assignments. Highlight a bunch of failing paths in TimeQuest, right-click Locate to Chip Planner, and you can see them drawn out across the die. There are all sorts of niceties that you would never find going through the text files.

[Altera_Forum]

Thanks Rysc. 

Ye I've more than made up for the years of command line work. I've found the GUI excelent (and much better than a competetors).  Oh I've now gone to quartus_sh --flow compile which means I now no longer require the error code handling.  Plus I'm using... set_global_assignment -name POST_FLOW_SCRIPT_FILE quartus_sh:script.tcl in the qsf, where the script does a load_report and I interrogate the panels to get all the reports my heart desires.  I think you gurus are going to have your work cut out with me on these forums.:)  Thanks.

[Altera_Forum]

here's a bash script if you didn't want to use quartus_sh --flow. looking at the exit code of the app was a better idea than grep -c unsuccessful. this one also catches internal errors. 

 #!/bin/bash quartus_map myproj out=$? if ; then quartus_fit myproj out=$? fi if ; then quartus_asm myproj out=$? fi

[Altera_Forum]

Hi Witty. I think I have a solution to your task. You can write a Tcl script for the whole process of the compilation step by step and let the "quartus_sh -t xxxx.tcl" command run the script for you. You can use "[catch { } result]" command in the Tcl script file to capture the returned report for every step in the compilation process. 

Here are some examples:  Script style 1: load_package ::quartus::flow project_open execute_flow -compile project_close  Script style 2: load_package ::quartus::flow project_open execute_module -tool map execute_module -tool fit execute_module -tool sta execute_module -tool asm project_close  Script to get the reports: load_package ::quartus::report project_open load_report get_report_panel_id write_report_panel unload_report project_close

[Altera_Forum]

The principle is it is hard to get return codes from the command-line-executable commands, but it is easy to get return codes from the Quartus-extented-Tcl commands.  

So handle the return codes in the Tcl domain, like conditional jumpings and writing to a report file.  If you are working under Windows, Use Tcl, do Not use the command line. If you are working under Linux, both will do.

[Altera_Forum]

--- Quote Start ---  The principle is it is hard to get return codes from the command-line-executable commands, but it is easy to get return codes from the Quartus-extented-Tcl commands.  So handle the return codes in the Tcl domain, like conditional jumpings and writing to a report file.  If you are working under Windows, Use Tcl, do Not use the command line. If you are working under Linux, both will do.  --- Quote End ---    Riple, After a lot of messing I've now gone fully over to quartus_sh using tcl scripts as you advise and wish I'd started that method when I first started with Quartus. Cheers.