Achronix ACE Version 5.0 - Manual (Page 308)

Optimizing a Design Chapter 4. Tasks
Generating Option Set Implementations and Starting Background Execution
After the Start Selected button has been pressed, but before the behavior described in Starting
Background Execution commences, ACE will:
1. remove implementations in the active project with the same name as to-be-generated implementations
2. create new implementations (exact copies of the template implementation) with the required names
3. apply the appropriate option set implementation options to the new implementations (overriding the
inherited implementation option values with the subset making up the option set)
4. add all selected (checked) implementations to the background processing queue(s), to be run through
the flow
From this point on, the available functionality and behavior is identical to that described in Running
Multiple Flows in Parallel , starting from Starting Background Execution .
Warning: Each generated implementation which is selected will overwrite
without prompting
15 any already-existing implementation with the
same name in the active project. The template (active)
implementation will not be changed/overwritten. If the user
wishes to keep a previously-existing implementation with a
to-be-generated name collision, the previously-existing
implementation must be renamed to avoid the name collision
before the
Start Selected button is pressed.
Interpreting / Utilizing the Results
After Viewing the Results , the final step of an optimization pass is usually to compare the results and
choose which generated option set implementation provides the best QOR in comparison to the template
implementation.
That best generated implementation could then be renamed, so that it doesn’t get overwritten by future
multiprocess runs. (For example, it might be named ”fastest1”, ”lowestpower1”, etc.)
With the newly-renamed implementation selected (making it the active implementation) in the Projects
View, it also becomes the new template implementation in the Multiprocess View, ready for another
multiprocess iteration through the option sets.
Optionally, if the change in latency will not break the design 16 , the best Potential XP values found during
a multiprocess run can be assigned to the design by editing the *.sdc file(s) (or making a new copy
of the original *.sdc files, with only the copy getting the new XP values, thus preserving the original
design values) for the new template implementation, at which point a new optimization pass through the
multiprocess flow should be executed, re-generating the option set implementations.
By iterating through several best template implementations (perhaps each with a new implementation name
for ”breadcrumb” purposes), each potentially with its own XP values, the desired QOR may be reached.
Note: Ensure Generate Implementations from Option Sets is selected for each optimization
iteration, otherwise any changed implementation options in the template implementation
will not be inherited by the option set implementations.
15 it is assumed this will be the standard, desired behavior, and thus constant pop-up confirmation dialogs would be an annoyance
16 Some macros, like the DDR3 controller, have their XP values constrained if the XP varies outside a set range, the design latency
falls outside specification, and the design fails to work. In other cases the user’s own design may have specific latency constraints that
must be met - in these cases the XP impact upon latency will be exposed when simulating using the ACE-generated netlists.
UG001 Rev. 5.0 - 5th December 2012 http://www.achronix.com 296