9 resource sharing - university of california, san...

For further assistance, email [email protected] or call your local support center

HOME CONTENTS INDEX

9 Resource Sharing

Resource sharing is the assignment of similar VHDL operations(for example, +) to a common netlist cell. Netlist cells are theresources—they are equivalent to built hardware. Resourcesharing reduces the amount of hardware needed to imple-ment VHDL operations. Without resource sharing, each VHDLoperation is built with separate circuitry. For example, every +with noncomputable operands causes a new adder to bebuilt. This repetition of hardware increases the area of adesign. In contrast, with resource sharing, several VHDL +operations can be implemented with a single adder toreduce the amount of hardware required. Also, differentoperations such as + and – can be assigned to a singleadder or subtracter to reduce a design’s circuit area further.

To understand resource sharing, study the following topics:

Scope and Restrictions Resource Sharing Methods Resource Sharing Conflicts and Error Messages Reports

VHDL Compiler Reference V3.4


HOME CONTENTS INDEX

The section on “Scope and Restrictions” explains the opera-tions in your VHDL description that can share hardware.

The section on “Resource Sharing Methods” describes thesethree methods:

� Automatic

� Automatic with manual controls

� Manual

The three sharing methods span a range from fully automaticto fully manual.

In automatic sharing, VHDL Compiler evaluates your VHDLdescription and makes resource sharing decisions to optimizethe design to meet your constraints.

In automatic sharing with manual controls, you insert manualcontrol statements in your VHDL source that assign operationsto resources explicitly. These control statements consist ofresource declarations, VHDL attributes, and VHDL Compilerdirectives. If you do not manually assign an operation to aresource, VHDL Compiler assigns it automatically. VHDLCompiler can also merge user-declared resources with eachother or with unbound operations. In general, manual con-trols modify the sharing configuration produced throughautomatic sharing to solve a specific problem, such as aviolated timing constraint.

Manual sharing uses manual controls to assign operations toresources, and shares only operations you explicitly assign tothe same resource.

You can generate reports for resource sharing. If you useautomatic sharing with manual controls, you can use reportinformation to explore design architecture alternatives. Formore information, refer to the section on “Reports”.



HOME CONTENTS INDEX

Scope and RestrictionsNot all operations in your design can be shared.

The following operators can be shared either with otherinstances of the same operators (share one ”+” with another”+” ), or with the operators shown on the same line (share ”+”

with ”–” ).

*+ –> >= < <=

Operations can be shared only if they are in the same pro-cess. Example 9–1 shows several possible sharings.

Example 9–1 Scope for Resource Sharing

P1: process(A1, B1, C1, D1, COND_1)begin if(COND_1) then Z1 <= A1 + B1; else Z1 <= C1 + D1; end if;end process;

P2: process(A2, B2, C2, D2, COND_2)begin if(COND_2) then Z2 <= A2 + B2; else Z2 <= C2 + D2; end if;end process;

Table 9–1 summarizes the possible sharings in Example 9–1. Ano indicates that sharing is not allowed because the opera-tions lie in different processes. A yes means sharing is allowed.



HOME CONTENTS INDEX

Table 9–1 Allowed and Disallowed Sharings for Example 9–1

A1+B1 C1+D1 A2+B2 C2+D2

A1+B1 – yes no no

C1+D1 yes – no no

A2+B2 no no – yes

C2+D2 no no yes –

The next two sections describe two types of conflicts—controlflow conflicts and data flow conflicts—where sharing is notallowed.

Control Flow ConflictsTwo operations can be shared only if no execution path thatreaches both operations exists from the start of the block tothe end of the block. For example, if two operations lie inseparate branches of an if or case statement, they are noton the same path (and can be shared). Example 9–2 illus-trates control flow conflicts for if statements.

Example 9–2 Control Flow Conflicts for if Statement

process(A, B, C, D, E, F, G, H, I, J, K, L, M, N, COND_1, COND_2) begin Z1 <= A + B; if(COND_1) then Z2 <= C + D; else Z2 <= E + F; if(COND_2) then Z3 <= G + H; else Z3 <= I + J; end if; end if; if(not COND_1) then



HOME CONTENTS INDEX

Z4 <= K + L; else Z4 <= M + N; end if; end process;

Table 9–2 summarizes the possible sharings in Example 9–2. Ano indicates that sharing is not allowed because of the flowof control (execution path) through the block. A yes meanssharing is legal.

Table 9–2 Legal and Illegal Sharings for Example 9–2

A+B C+D E+F G+H I+J K+L M+NA+B – no no no no no no

C+D no – yes yes yes no no

E+F no – – no no no no

G+H no yes no – yes no no

I+J no yes no yes – no no

K+L no no no no no – yes

M+N no no no no no yes –

Note that the C+D addition cannot be shared with the K+L

addition, even though no set of input values causes both toexecute. When VHDL Compiler evaluates shareability, itassumes that the values of expressions that control if state-ments are unrelated. The same rule applies to case state-ments, as shown in the next example.



HOME CONTENTS INDEX

Example 9–3 Control Flow Conflicts for case Statement

process(A, B, C, D, E, F, G, H, I, J, OP) begin Z1 <= A + B; case OP is when ”00” => Z2 <= C + D; when ”01” => Z2 <= E + F;

when ”10” => Z2 <= G + H;

when others => Z2 <= I + J; end case; end process;

Table 9–3 summarizes the possible sharings in Example 9–3. Ano indicates that sharing is not allowed because of the flowof control (execution path) through the circuit. A yes meanssharing is legal.

Table 9–3 Legal and Illegal Sharings for Example 9–3

A+B C+D E+F G+H I+JA+B – no no no no

C+D no – yes yes yes

E+F no yes – yes yes

G+H no yes yes – yes

I+J no yes yes yes –



HOME CONTENTS INDEX

Data Flow ConflictsOperations cannot be shared if doing so causes a combina-tional feedback loop. To understand how sharing can causea feedback loop, consider Example 9–4.

Example 9–4 Data Flow Conflict

process(A, B, C, D, E, F, ADD_B) variable TEMP_1, TEMP_2: INTEGER; begin if(ADD_B) then TEMP_1 := A + B; Z <= TEMP_1 + C; else TEMP_2 := D + E; Z <= TEMP_2 + F; end if; end process;

When the A+B addition is shared with the TEMP_2+F addition onan adder called R1, and the D+E addition is shared with theTEMP_1+C addition on an adder called R2, a feedback loopresults. The variable TEMP_1 connects the output of R1 to theinput of R2 . The variable TEMP_2 connects the output of R2 tothe input of R1, and a feedback loop is created. Figure 9–1shows the circuit with the feedback loop highlighted.



HOME CONTENTS INDEX

Figure 9–1 Feedback Loop for Example 9–4

B

F

ADD_B

A

ADD_B

TEMP_1

D

ADD_B

ADD_B

MUXE

C

Z

ADD_B

MUX

MUX

ADDERR1

MUX

MUX

TEMP_2

ADDERR2

The circuit in Figure 9–1 is not faulty, since the multiplexingconditions never allow the entire path to be activated simul-taneously. Still, VHDL Compiler’s resource sharing mechanismdoes not allow combinational feedback paths to be createdbecause most timing verifiers cannot handle them properly.

ErrorsWhen VHDL Compiler runs in automatic mode, the automaticsharing algorithm respects sharing restrictions. However, inmanual mode or automatic sharing with manual controlsmode, a directive may violate one of these restrictions. Whena violation occurs, VHDL Compiler displays an error messageand ignores the directive. Refer to “Resource Sharing Con-flicts” and “Error Messages” for more details.



HOME CONTENTS INDEX

Resource Sharing MethodsThree resource sharing methods are available:

� Automatic sharing

� Automatic sharing with manual controls

� Manual sharing

Automatic Resource SharingAutomatic resource sharing is the simplest way to sharecomponents and reduce design area. This method is ideal ifyou do not know how you want to map the operations in yourdesign onto hardware resources. In automatic sharing, VHDLCompiler identifies the operations that can be shared. DesignCompiler uses this information to minimize the area of yourdesign according to your constraints. To override the auto-matically determined sharing, use automatic sharing withmanual controls or manual sharing.

When resource sharing is enabled for a design, resources areallocated automatically only the first time you compile thatdesign and will not change even if constraints are changed.After the first compile, you can manually change the imple-mentation of a resource with the change_link command.

To enable automatic sharing for all designs, set the dc_shell

variable hlo_resource_allocation before using the compile

command.

dc_shell> hlo_resource_allocation = constraint_driven

The default value for this variable is constraint_driven .



HOME CONTENTS INDEX

To disable automatic sharing for uncompiled designs andenable resource sharing only for selected designs, enter thefollowing commands:

dc_shell> hlo_resource_allocation = none

dc_shell> current_design = MY_DESIGN

dc_shell> set_resource_allocation constraint_driven

Source Code PreparationYou do not need to modify your VHDL source.

Functional DescriptionThe automatic sharing method minimizes the area of yourdesign as it tries to meet your timing constraints. It identifiesthe operators that are eligible to share resources, then evalu-ates various sharing configurations according to the areacriteria described below.

Resource AreaResource sharing reduces the number of resources in yourdesign. Fewer resources require less resource area. The areaof a shared resource is a function of the types of operationsthat are shared on the resource, and their bit-widths. Theshared resource is enlarged enough to handle the largest ofthe bit-widths and make powerful enough to perform all theoperations.

Multiplexer AreaResource sharing usually adds multiplexers to a design tochannel values from different sources into a common re-source input. In some cases, resource sharing reduces thenumber of multiplexers in a design. Example 9–5 shows a casewhere shared operations have the same output targets, andthus fewer multiplexers.



HOME CONTENTS INDEX

Example 9–5 Shared Operations with Same Output Target

process(A, B, COND) begin if(COND) then Z <= A + B; else Z <= A – B; end if; end process;

When the addition and subtraction shown in Example 9–5 arenot shared, a multiplexer selects whether the output of theadder or the subtracter is fed into Z . When they are shared, Zis fed from a single adder or subtracter, and no multiplexing isnecessary. If the inputs to the operations are different, multi-plexers are added on the inputs of the adder or subtracter.VHDL Compiler tends to share operations with commoninputs and outputs to minimize multiplexer area.

Multiplexer area is a function of both the number of multi-plexed values and the bit-widths of the values. VHDL Compil-er therefore tends to share operations with similar bit-widths.

Example of Shared ResourcesExample 9–6 shows a simple VHDL design that adds either Aand B or A and C. The choice depends on whether thecondition ADD_B is true .

Example 9–6 VHDL Design with Two Plus Operators

A, B, C, Z: INTEGER range 0 to 15;. . .process(ADD_B, A, B, C) begin if (ADD_B) then Z <= A+B; else Z <= A+C; end if; end process;



HOME CONTENTS INDEX

Figure 9–2 shows the schematic for Example 9–6 withoutresource sharing. Notice that two adders are built, and theoutputs are multiplexed into Z .

Figure 9–2 Example 9–6 Design without Resource Sharing



HOME CONTENTS INDEX

Figure 9–3 shows the schematic for Example 9–6 with automaticresource sharing. Notice that one adder is built, with B and C

multiplexed into one input and A fed directly into the other.

Figure 9–3 Example 9–6 Design with Automatic Resource Sharing



HOME CONTENTS INDEX

Input OrderAutomatic sharing picks the best order of inputs to the re-sources to reduce the number of multiplexers required. In thefollowing case, automatic sharing permutes B+A to A+B , thenmultiplexes B and C and adds the output to A .

if (ADD_B) then Z <= B+A;else Z <= A+C;end if;

The resulting circuit is shown in Figure 9–3. With manual shar-ing, the input order is not optimized, and multiplexers areneeded for both adder inputs. See Figure 9–4. Note that formanual sharing, you make the permutation in the sourcecode—in this example, you change B+A to A+B .

Automatic Resource Sharing with Manual ControlsIn the automatic sharing with manual controls method, userdirectives influence the sharing configuration that VHDLCompiler chooses automatically. You can control whichsharing configurations are created or not created (regardlessof their area savings or cost). You can use this method tosolve a specific problem such as a violated timing constraint.

Manual controls allow you to perform these operations explic-itly:

� Force the sharing of specified operations.

� Prevent the sharing of specified operations.

� Force specified operations to use a particular type ofresource (such as an adder or subtracter).



HOME CONTENTS INDEX

To control the sharing configuration, you declare resources,then indicate whether the operations in your source file canbe, must be, or must not be implemented on the resource.You can also specify the type of hardware that implementsthe resource.

When you assign operations to the same resource, they areimplemented on the same hardware. Whether or not opera-tions that you assign to a particular resource also share hard-ware with other operations depends on the attributes youspecify on the resource. You can force operations that areassigned to different resources to share the same hardware.To do this, declare a new resource that contains the re-sources you want to merge.

To use automatic resource sharing with manual controls, addthe necessary resource sharing directives to your source files,then set the dc_shell variable as shown before you executethe compile command.

dc_shell> hlo_resource_allocation = constraint_driven

The default value for this variable is constraint_driven .



HOME CONTENTS INDEX

Source Code PreparationManual controls are incorporated in your VHDL source. Exam-ple 9–7 shows the code from Example 9–6, with the minimumcontrols you need to assign two operators to a resource. Themanual control statements are shown in bold.

Example 9–7 Sharing with Manual Controls

entity TWO_ADDS is port(ADD_B: in BOOLEAN; A, B, C: in INTEGER range 0 to 15; Z: out INTEGER range 0 to 15);end TWO_ADDS;

architecture BEHAVIOR of TWO_ADDS isbegin process(A, B, C, ADD_B) subtype resource is INTEGER; constant R0 : resource := 0; attribute ops: STRING; attribute ops of R0 : constant is ”A1 A2”;

begin if (ADD_B) then Z <= A+B; –– pragma label A1 else Z <= A+C; –– pragma label A2 end if; end process;end BEHAVIOR;



HOME CONTENTS INDEX

To modify Example 9–6 for manual sharing, you must makethe changes shown in bold in Example 9–7:

� Declare a resource subtype. You can declare this your-self, or use the declaration in the Synopsys ATTRIBUTES

package (see Appendix B).

subtype resource is INTEGER;

� Declare an identifier for an individual resource.

constant R0 : resource := 0;

� Place labels on the operations.

if (ADD_B) then Z <= A+B; –– pragma label A1 else Z <= A+C; –– pragma label A2 end if;

� Declare the ops attribute. You can declare this yourself,or use the declaration in the Synopsys package AT-

TRIBUTES (see Appendix B).

attribute ops: STRING;

� Use the ops attribute to bind the labeled operations tothe resource they are to share.

attribute ops of R0: constant is ”A1 A2”;

Example 9–7 illustrates only some of the available manualcontrols. All the controls, along with their usage and syntax,are discussed in the next section, “Functional Description”.



HOME CONTENTS INDEX

Functional DescriptionIn the automatic sharing with manual controls method, youadd directives to your source file that influence the choice ofoperations to be shared and not shared. Next, VHDL Compil-er determines the exact sharing configuration that minimizesthe area of your design and respects your directives.

The following descriptions explain how to use manual con-trols.

VHDL Resource Declarations and IdentifiersTo create a resource sharing directive, you first declare aresource, then specify attributes for that resource.

In VHDL, a resource is created by declaring a constant oftype resource . The name of the constant is the name of theresource. You control the implementation of the resourcewith attributes, as described below. The type resource mustbe declared somewhere in your description as a subtype ofINTEGER.

A resource type declaration can be made in an architectureor process, or you can use the definition in the SynopsysATTRIBUTES package (see Appendix B). The syntax is

subtype resource is INTEGER;

You can declare resources in a process or function. Thesyntax is

constant IDENTIFIER : resource := 0;

IDENTIFIER becomes the netlist cell name, unless the resourceis merged with another resource.



HOME CONTENTS INDEX

label DirectiveBefore operations in your source can be associated withresources, they must have unique labels. Assign a label withthe label compiler directive. The syntax is

–– pragma label IDENTIFIER

You can insert label directives after a procedure call state-ment, after function calls, or after infix operators.

SWAP(IN_1, OUT_1); – – pragma label PROC_1Z <= ADD(B,C); – – pragma label FUNC_1Z <= A+B; – – pragma label OP_1return A+B; – – pragma label OP_2You can also insert label directives after the name and leftparenthesis of a function or procedure, or in a call infix opera-tion.

SWAP( –– pragma label PROC_1 IN_1, OUT_1,);Z <= ADD( –– pragma label FUNC_1 B,C);Z <= A+ –– pragma label OP_1 B;return A+ –– pragma label OP_2 B;

To place multiple labels on a single statement, break thestatement into multiple lines.

Z <= a+ –– pragma label ADD_1 b+ –– pragma label ADD_2 c;

return ADD( –– pragma label PROC_1 ADD( –– pragma label PROC_2 A, B), C);

Keep labels unique within a function or process.



HOME CONTENTS INDEX

ops AttributeAssigning operations to resources in manual sharing is calledbinding. The ops attribute binds operations and resources to aresource. The attribute appears after the resource identifierdeclaration. The syntax is

attribute ops of RES_1 : constant is ” { OP_ID} { RES_2}”;

RES_1 is a resource identifier, and OP_ID and RES_2 are part ofa list of operator or resource identifiers separated by spaces,called the ops list. Example 9–8 shows how to use the ops

attribute.

Example 9–8 Using the ops Attribute

use WORK.ATTRIBUTES.ALL;. . .process(A, B, C, ADD_B) constant R0 : resource := 0; attribute ops of R0: constant is ”A1 A2”;

begin if(ADD_B) then Z <= A+B; –– pragma label A1 else Z <= A+C; –– pragma label A2 end if;end process;

If you use the same resource or operator identifier on morethan one ops list, VHDL Compiler generates an error mes-sage. One resource (the parent) can include another (thechild) in its ops list, but only if the child resource (and any ofits children) does not include the parent in its ops list. This typeof error creates an ops list cycle. Example 9–9 shows an illegalops list cycle with three resources.



HOME CONTENTS INDEX

Example 9–9 Illegal ops List Cycle

constant R0 : resource := 0;attribute ops of R0: constant is ”R1”;constant R1 : resource := 0;attribute ops of R1: constant is ”R2”;constant R2 : resource := 0;attribute ops of R2: constant is ”R0”;

When you include a resource on the ops list, it is bound tothe resource being declared, called the parent. The opera-tions on the bound resource are realized on the parent re-source, and the parent resource identifier is used for thename of the netlist cell. Example 9–19 shows a resourcecontained in another resource.

map_to_module AttributeThe map_to_module attribute forces a resource to be imple-mented by a specified type of hardware module. Declarethis attribute after the resource declaration. The syntax is

attribute map_to_module of RES_ID : constant is ” mod_name”;

RES_ID is the resource identifier and mod_name is the name ofthe module. The implementation of a module can be set withthe implementation attribute, as described in the next section.

To list the module names and implementations in a syntheticlibrary, use the command

dc_shell> report_synlib synthetic_library

synthetic_library is the name of a Synopsys synthetic library,such as standard.sldb .

Example 9–10 shows how to use the map_to_module attribute.



HOME CONTENTS INDEX

Example 9–10 Using the map_to_module Attribute

process(A, B, C, ADD_B) constant R0 : resource := 0; attribute map_to_module of R0: constant is ”addsub”; attribute ops of R0 : constant is ”A1 A2”;begin...

VHDL Compiler generates an error message if the specifiedmodule cannot execute all operations bound to the re-source. If you do not use map_to_module , or if you do not givea module name, VHDL Compiler selects the module as de-scribed in “Automatic Resource Sharing”.

implementation AttributeThe implementation attribute sets the initial implementation ofa resource. This attribute, if used, must follow the map_to_mod-

ule attribute. The syntax is

attribute implementation of RES_ID : constant is ” implementation_name ”;

where RES_ID is the resource identifier and implementa-

tion_name is the name of one of the implementations of thecorresponding map_to_module module.

To list the module names and implementations in a syntheticlibrary, use the command

dc_shell> report_lib synthetic_library

synthetic_library is the name of a Synopsys synthetic library,such as standard.sldb . Example 9–11 shows how to use theimplementation attribute.



HOME CONTENTS INDEX

Example 9–11 Using the implementation Attribute

process(A, B, C, ADD_B) constant R0 : resource := 0; attribute map_to_module of R0: constant is ”DW01_add”; attribute implementation of R0: constant is ”rpl”; –– ripple–carry adder attribute ops of R0 : constant is ”A1 A2”;begin

If implementation is not used, or an implementation name isnot given, VHDL Compiler selects the module’s implementa-tion as described in “Automatic Resource Sharing”. VHDLCompiler reports an error if the associated module does nothave the given implementation.

add_ops AttributeVHDL Compiler guarantees that all operations in the ops listof a resource share the same hardware. Whether the hard-ware cell for a resource has additional operations bound to itdepends on the area benefit of the additional sharing. Youcan indicate whether or not VHDL Compiler is to consideradding more operations to a particular resource with theadd_ops attribute. This attribute must follow the declaration ofthe resource, and can be applied only to a top-level re-source. A top-level resource is one that is not included inanother resource’s ops list. The syntax is

attribute add_ops of RES_ID : constant is ” value ”;

RES_ID is the resource identifier, and value is either true (thedefault) or false .



HOME CONTENTS INDEX

By default, VHDL Compiler may merge the operations of aresource with other operations onto the same hardware.VHDL Compiler merges additional operations if it reduces thearea of your design. Additional operations can also bemerged onto a resource by adding individual operations thatare not bound to other resources (called free operations), orby merging two or more resources together.

If you set the add_ops attribute to false , the resource isassigned its own hardware which cannot be used by otheroperations. In the code fragment in Example 9–12, resourcer0 does not share hardware with operations other than A1

and A2 .

Example 9–12 Using the add_ops Attribute

process(A, B, C, ADD_B) constant R0 : resource := 0; attribute ops of R0 : constant is ”A1 A2”; attribute add_ops of R0 : constant is ”false”;begin

Thus, when add_ops is set to true , the resource can mergewith any other resource that does not disallow sharing. Toprevent automatic binding on a resource, set add_ops tofalse .

Note, however, that may_merge_with and dont_merge_with

attributes override the add_ops = ”false” and add_ops =

”true” statements, respectively.



HOME CONTENTS INDEX

may_merge_with AttributeThe may_merge_with attribute overrides add_ops = ”false” forspecific resources. The syntax is

attribute may_merge_with of RES_1 : constant is ”{ RES_2} ” | ”*”;

RES_1 and RES_2 are resource identifiers, and ”*” indicates allresources. The may_merge_with attribute must be set afterRES_1 is declared, but can be set before or after RES_2 isdeclared.

Note:You cannot use operation labels with themay_merge_with attribute. To control the sharing of alabeled operation, put it in a resource.

In Example 9–13, resource R1 can be shared only with resour-ces R2 and R3 .

Example 9–13 Restricting Sharing with the may_merge_with Attribute

process(A, B, C, ADD_B)constant R1 : resource := 0; attribute ops of R1 : constant is ”A1 A2”; attribute add_ops of R1 : constant is ”false”; attribute may_merge_with of R1 : constant is ”R2 R3”;

In Example 9–14, merging with resources is allowed, butmerging with free operations is not.

Example 9–14 Using the may_merge_with Attribute

process(A, B, C, ADD_B) constant R1 : resource := 0; attribute ops of R1 : constant is ”A1 A2”; attribute add_ops of R1 : constant is ”false”; attribute may_merge_with of R1 : constant is ”*”;



HOME CONTENTS INDEX

dont_merge_with AttributeThe dont_merge_with attribute overrides add_ops = ”true”

(the default). The syntax is

attribute dont_merge_with of RES_1 : constant is ” { RES_2} ” | ”*”;

RES_1 and RES_2 are resource identifiers, and ”*” indicates allresources. The dont_merge_with attribute must be set afterRES_1 is declared, but can be set before or after RES_2 isdeclared.

Note:Do not use operation labels with the dont_merge_with

attribute. To control the sharing of a labeled operation,put it in a resource.

In Example 9–15, resource R1 is allowed to share all resourcesexcept R2 and R3.

Example 9–15 Restricting Sharing with the dont_merge_with Attribute

process(A, B, C, ADD_B) constant R1 : resource := 0; attribute ops of R1 : constant is ”A1 A2”; attribute add_ops of R1 : constant is ”true”; attribute dont_merge_with of R1 : constant is ”R2 R3”

In Example 9–16, merging with free operations is allowed, butmerging with resources is not.

Example 9–16 Using the dont_merge_with Attribute

process(A, B, C, ADD_B) constant R1 : resource := 0; attribute ops of R1 : constant is ”A1 A2”; attribute add_ops of R1 : constant is ”true”; attribute dont_merge_with of R1 : constant is ”*”;

If may_merge_with and dont_merge_with conflict, VHDL Com-piler issues an error message. Refer to “User Directive Con-flicts” under “Resource Sharing Conflicts and Error Messages.”



HOME CONTENTS INDEX

Referring to Operations and ResourcesWhen you include a simple identifier in an ops list, VHDLCompiler assumes you are referring to a resource or labeledoperation in the current block or function. To refer to opera-tions and resources declared in other functions that arecalled by the current block or function, use hierarchicalnaming or the label_applies_to directive.

Hierarchical NamingHierarchical naming allows you to refer to resources andoperations that are not defined in the current scope. You canuse hierarchical names to share operations that occur indifferent functions if the functions are called from a singleblock. The syntax for a hierarchical name is

NAME[/ NAME]

The first name identifies a labeled operation in the function orblock in which the name is placed. The next name identifiesa labeled operation in the called function. This identificationcan continue through an arbitrary number of function calls.The last name can refer to either a labeled operation or aresource.

Example 9–17 shows two + operations from different functionsthat are put in the same resource, which causes them to beshared.

Example 9–17 Hierarchical Naming for Two Levels

use WORK.ATTRIBUTES.ALL;...function CALC_1(A, B, C: INTEGER) return INTEGER isbegin return(A + –– pragma label ADD_1 B – –– pragma label SUB_1 C);end;



HOME CONTENTS INDEX

function CALC_2(A, B, C: INTEGER) return INTEGER isbegin return(A – –– pragma label SUB_2 B + –– pragma label ADD_2 C);end;...

process(A, B, C, COND) constant R0 : resource := 0; attribute ops of R0: constant is ”L_1/ADD_1 L_2/ADD_2”;begin if (COND) then Z <= CALC_1(A, B, C); –– pragma label L_1 else Z <= CALC_2(A, B, C); –– pragma label L_2 end if;end process;

Example 9–18 shows a three-level hierarchical name.

Example 9–18 Hierarchical Naming for Three Levels

function CALC_2(A, B, C: INTEGER) return INTEGER is constant R0 : resource := 0; attribute ops of R0: constant is ”ADD_1 SUB_1”;begin if (A < B) then return(B + C); –– pragma label ADD_1 else return(B – C); –– pragma label SUB_1 end if;end;

function CALC_1(A, B, C: INTEGER) return INTEGER isbegin return(CALC_2(A, B, C)); –– pragma label L_2end;...process(A, B, C) constant R1 : resource := 0; attribute ops of R1: constant is ”L_1/L_2/R0”;begin Z <= CALC_1(A, B, C); –– pragma label L_1end process;



HOME CONTENTS INDEX

In Example 9–18, the function CALC_2 has resources within ablock. To refer to these resources, include the name of theblock in the pathname to the resource.

Each time a function is called, the operations in the functionare replicated. You can refer to these operations with hierar-chical names and put them on the same resource to avoidextra hardware.

Example 9–19 shows how you can use ops attribute bindingswith hierarchical names to reduce the number of cellscreated by function calls. If resource sharing is not used,each function call (L5, L6) creates a cell for each of thelower-level function operations (L1, L2 and L3), for a total ofseven cells.

Example 9–19 Resource Sharing with Hierarchical Naming

use WORK.ATTRIBUTES.ALL;package SID is function SUB_INC_DEC(A,B: INTEGER; SUB,INC: BOOLEAN) return INTEGER;end SID;

package body SID is function SUB_INC_DEC(A,B: INTEGER; SUB,INC: BOOLEAN) return INTEGER is constant R1 : resource := 0; attribute ops of R1: constant is “L2 L3”; begin if (SUB) then return (A–B); –– pragma label L1 elsif (INC) then return (A+1); –– pragma label L2 else return (A–1); –– pragma label L3 end if; end;end SID;

use WORK.SID.ALL;



HOME CONTENTS INDEX

use WORK.ATTRIBUTES.ALL;

entity VHDL isport(SUB, INC, SWITCH, ADD: in BOOLEAN; A, B : in INTEGER range 0 to 15; Z : out INTEGER range 0 to 15);end VHDL;

architecture BEHAVIORAL of VHDL isbegin process(A, B, INC, SUB, ADD, SWITCH) constant R2 : resource := 0; attribute ops of R2 : constant is “L4 L5/L1 L6/L1 L5/R1 L6/R1”; begin if (ADD) then Z <= A+B; –– pragma label L4 elsif (SWITCH) then Z <= SUB_INC_DEC( –– pragma label L5 B, A, SUB, INC); else Z <= SUB_INC_DEC( –– pragma label L6 A, B, SUB, INC); end if; end process;end BEHAVIORAL;

Example 9–19 has the following hierarchical naming details:

� The ops list for R1 binds the operations labeled L2 andL3 in the function SUB_INC_DEC.

� The ops list for R2 contains the operation L4 , which is atthe current scope.

� The ops list for R2 also contains L5/L1 and L6/L1,

which identify each invocation of the A–B operation inthe function SUB_INC_DEC.

� Finally, the ops list for R2 uses the names L5/R1 and L6/R1 .You can use R1 as shorthand notation to refer to all opera-tions bound to R1 . For example, L5/R1 refers to L5/L2 andL5/L3 . When you use resource identifiers in hierarchical names,you avoid having to enter the labels under that resource.



HOME CONTENTS INDEX

label_applies_to DirectiveAs an alternative to hierarchical naming, you can refer tolower-level operations and resources directly with the la-

bel_applies_to directive. Insert the label_applies_to direc-tive in the declarations section of a function definition. Usethis directive to name the label on the function call thatinvokes the lower-level function. The syntax is

–– pragma label_applies_to LABEL

LABEL identifies an operation or resource.

When you put a label_applies_to directive in a functiondefinition, the label on any call to the function is equivalentto the operation or resource specified by label . This process isshown in Example 9–20.

Example 9–20 Using the label_applies_to Directive

function FUNC(A, B: INTEGER) return INTEGER is –– pragma label_applies_to L1begin return(A+B); –– pragma label L1end;...process(A, B) constant R1 : resource := 0; attribute ops of R1: constant is ”L2”;begin Z <= FUNC(A, B); –– pragma label L2end process;

In Example 9–20, resource R1 includes the A+B operation inits ops list by referring only to L2 . The label_applies_to

directive makes the L2 label apply to the L1 operation.Without the label_applies_to directive, the reference in theops list is expressed hierarchically as L2/L1 .



HOME CONTENTS INDEX

The label_applies_to directive can be used to make wrap-per functions easier to use. A wrapper function computes itsreturn value by calling another function. In some cases, thewrapper function makes a minor modification to the input oroutput. A simple example of a wrapper function is one thatdefines a new name for a function.

Suppose you have a function called FOO. Example 9–21 showshow you can define a function BAR that is equivalent to FOO.

Example 9–21 Using the label_applies_to Directive for WrapperFunctions

function FOO(A, B: INTEGER) return INTEGER is...

function BAR(A, B: INTEGER) return INTEGER is –– pragma label_applies_to L_NAMEbegin return(FOO(A, B)); –– pragma label L_NAMEend;

Without the label_applies_to directive, FOO and BAR arenot equivalent because a hierarchical name that goesthrough the BAR function needs an additional reference tothe label L_NAME. With the directive, this extra reference is notneeded and FOO and BAR are equivalent.

Wrappers are often are used to sign-extend data, or changedata in some other way. Example 9–22 shows how label_ap-

plies_to connects a string of user-defined function calls to asingle VHDL operator.



HOME CONTENTS INDEX

Example 9–22 Using the label_applies_to Directive withUser-Defined Functions

function FUNC_1(A, B: INTEGER) return INTEGER is –– pragma label_applies_to L2beginreturn(FUNC_2(A, B)); –– pragma label L2end;

function FUNC_2(A, B: INTEGER) return INTEGER is –– pragma label_applies_to L3beginreturn(FUNC_3(A, B)); –– pragma label L3end;

function FUNC_3(A, B: INTEGER) return INTEGER is –– pragma label_applies_to L4beginreturn(A + B); –– pragma label L4end;...

process(A, B) constant R1 : resource := 0; attribute ops of R1: constant is ”L1”;begin Z <= FUNC_1(A, B); –– pragma label L1end process;

Example 9–22 has the following characteristics:

� Function FUNC_1 calls FUNC_2, which calls FUNC_3, and soon.

� A label_applies_to directive connects each level ofthe hierarchy to the next lower level.

� The L1 identifier in the ops list actually points at L4 . Theequivalent hierarchical name is /L1/L2/L3/L4 .



HOME CONTENTS INDEX

Example 9–23 uses a hierarchical name in a label_applies_to

directive. The name A1/PLUS in the label_applies_to directivein function MY_ADD means that a reference to a label on anycall to the function MY_ADD is equivalent to the L+R operationin the function MY_ADD_1.

Example 9–23 Using the label_applies_to Directive withHierarchical Naming

use WORK.ATTRIBUTES.ALL;package MATH is function MY_ADD(L, R : INTEGER) return INTEGER;end MATH;

package body MATH is function MY_ADD_1(L, R : INTEGER) return INTEGER is begin return L + R; –– pragma label PLUS end;

function MY_ADD(L, R : INTEGER) return INTEGER is –– pragma label_applies_to A1/PLUS begin return MY_ADD_1(L, R); –– pragma label A1 end;end MATH;

use WORK.MATH.ALL;use WORK.ATTRIBUTES.ALL;

entity VHDL is port(A, B : in INTEGER; C : out INTEGER);end VHDL;

architecture VHDL_1 of VHDL isbegin process(A, B) constant R0 : resource := 0; attribute ops of R0 : constant is ”A”; begin C <= MY_ADD(A, B); –– pragma label A end process;end VHDL_1;



HOME CONTENTS INDEX

Manual Resource SharingUse manual sharing when you want to assign VHDL operatorsto resources, but you do not want VHDL Compiler to performfurther sharing optimizations.

In manual sharing, you specify all resource sharing with manu-al controls. Like automatic sharing with manual controls,these controls consist of

� Resource declarations that bind operators to resourcesand map resources to specific modules.

� Compiler directives that label operations.

You can bind as many operations to as many resources asyou like. All operations bound to the same resource share thesame hardware. The remaining operations are implementedwith separate hardware.

To use the manual sharing method, add resource sharingdirectives to your source files and set the dc_shell variableas follows before you execute the compile command.

dc_shell> hlo_resource_allocation = none

This command disables automatic sharing. The default valuefor the variable is constraint_driven .



HOME CONTENTS INDEX

Source Code PreparationManual controls are incorporated in your VHDL source. SeeExample 9–7 in “Automatic Sharing with Manual Controls” fordetails.

Functional DescriptionIn manual sharing, you are limited to a subset of the manualcontrols available for automatic sharing with manual controls.This subset of controls includes:

� The ops directive

� The map_to_module attribute

� The implementation attribute

� The –– pragma label directive

� The –– pragma label_applies_to directive

The following manual controls used in automatic sharing withmanual controls are ignored in manual sharing:

� may_merge_with attribute

� dont_merge_with attribute

� add_ops attribute

Refer to “Functional Description” under “Automatic Sharingwith Manual Controls” for a description of these controls.



HOME CONTENTS INDEX

Input OrderingIn automatic sharing mode, VHDL Compiler picks the bestordering of inputs to the cells to reduce the number of multi-plexers required. In the case below, automatic sharing per-mutes B+A to A+B, then multiplexes B and C and adds theoutput to A (see the schematic in Figure 9–3 in “AutomaticSharing with Manual Controls”).

if (ADD_B) thenZ <= B+A;

elseZ <= A+C;

end if;

In contrast, manual sharing does not optimize input orderingfor resources. For example, suppose a resource is declaredthat forces the additions in the previous example onto thesame adder. Under manual sharing, one input of the adder isfed by a multiplexer that chooses between A and B. Theother input is fed by a multiplexer that chooses between Aand C. This process is shown in Figure 9–4.



HOME CONTENTS INDEX

Figure 9–4 Manual Sharing with Unoptimized Inputs

To optimize input ordering with manual sharing, permute theinputs in the source code: rewrite B+A as A+B .Remember thatin manual sharing mode, operator instances that are notexplicitly shared on resources are instantiated as new cells.



HOME CONTENTS INDEX

Resource Sharing Conflicts and Error MessagesRead “Resource Sharing Methods” before you read thissection.

To share a resource, operators must be in the same process . Ifthey are not, a sharing conflict exists. Other kinds of sharingconflicts that can also prevent a resource from being sharedare

� User directive conflicts

� Module conflicts

� Control flow conflicts

� Data flow conflicts

With manual resource sharing, if the manual controls in yoursource create conflicts, they are reported as errors or warn-ings. In fully automatic sharing, VHDL Compiler resolves theseconflicts before the design is built, so no errors are reported.

User Directive ConflictsUser directive conflicts occur when manual controls thatpermit sharing contradict manual controls that preventsharing. Note the user directive conflicts for resources R0 andR1 in the following example.

process ... attribute may_merge_with of R0 : constant is ”R1”; ... attribute dont_merge_with of R1 : constant is ”R0”;...



HOME CONTENTS INDEX

VHDL Compiler generates the following error message:

Warning: may_merge_with and dont_merge_with conflict in resource ’R0’. may_merge_with ignored

However, the following directives for R0, R1, and R2 do notgenerate an error message.

process ... attribute may_merge_with of R0 : constant is ”R1”; ... attribute may_merge_with of R1 : constant is ”R2”; ... attribute dont_merge_with of R2 : constant is ”R0”; ...end process;

These directives do not conflict because a may_merge_with

directive does not mean that the resource will merge. Theuser directives are all satisfied if no sharing is done, or if R0

and R1 are merged, or if R1 and R2 are merged. The directivesdo not permit all three to be merged because of thedont_merge_with attribute on R2.

Module ConflictsIf a hardware module cannot implement all the operationsbound to a resource assigned to it, a module conflict occurs.This conflict happens for two reasons:

1. Inappropriate operations are mapped to a module thathas a map_to_module attribute.

2. Operators are bound to a resource that cannot beimplemented by a single module.



HOME CONTENTS INDEX

Example 9–24 shows the first case.

Example 9–24 Module Conflict

process(A, B, ADD_B) constant R0 : resource := 0; attribute ops of R0 : constant is ”A0”; attribute map_to_module of r0 : constant is ”sub”;begin if (ADD_B) then Z <= A+B; –– pragma label A0...end process;

In Example 9–24, a conflict occurs because the subtracter,sub , cannot perform addition. The error message is

Error: Module ’sub’ cannot implement all of the operations in resource ’R0’ in

routine ADDER line 12 in file ’adder.vhdl’

When resources are not mapped, but operators are bound toa resource and no module can implement all the operationson that resource, the error message is

Error: There is no module which can implement all of the operationsin the resource ’R0’ in routine ADDER line 12 in file ’adder.vhdl’

User-defined functions cannot be shared. If you attempt toshare such functions, VHDL Compiler generates an errormessage. Refer to the earlier section on “Scope and Restric-tions” for supported VHDL operators. High level optimizationscan take place on user defined functions if they are linkedwith synthetic operators. Refer to the DesignWare DeveloperGuide for more information.



HOME CONTENTS INDEX

Control Flow ConflictsAs discussed in “Scope and Restrictions,” two operations canbe shared only if there is no execution path from the start ofthe block to the end of the block that reaches both opera-tions. Example 9–25 shows a control flow conflict.

Example 9–25 Control Flow Conflict

process(A, B, C, D, ADD_B)... constant R0 : resource := 0; attribute OPS of R0 : constant is ”A1 A2”;begin if (ADD_B) then Y <= A+B; –– pragma label A1 Z <= C+D; –– pragma label A2 else Z <= A+C;...end process;

In Example 9–25, the + operations labeled A1 and A2 cannotbe shared because of a control flow conflict. VHDL Compilergenerates the following error message.

Error: Operations in resource ’R0’ can not be shared because they may execute in the same control step in routine CONTROL line 15 in file ’CONTROL.vhdl’

If operations are in the same path in software (which createsa control flow conflict), they occur at the same time in hard-ware. Operations that occur at the same time require sepa-rate resources. Only disjoint operations can share resources.



HOME CONTENTS INDEX

Data Flow ConflictsCombinational feedback that occurs as a result of resourcesharing is not permitted. Example 9–26 shows a data flowconflict.

Example 9–26 Data Flow Conflict

process(A, B, C, D, E, F, ADD_B, X)... constant R0 : resource := 0; constant R1 : resource := 0; attribute OPS of R0 : constant is ”K1 M4”; attribute OPS of R1 : constant is ”K2 M3”;begin if (ADD_B) then X <= A+B; –– pragma label K1 Y <= X+C; –– pragma label K2 else X <= D+E; –– pragma label M3 Y <= X+F; –– pragma label M4...end process;

In Example 9–26, the sharing mandated by resources R0 andR1 creates a feedback loop as described in “Scope andRestrictions”. VHDL Compiler generates the following errormessage.

Error: Operations in resource are part of a data flow cycle inroutine data line 15 in file ’DATA.vhdl’



HOME CONTENTS INDEX

ReportsVHDL Compiler generates reports that show the resourcesharing configuration for a design. The resource report lists theresource name, the module, and the operations contained inthe resource. You can generate this report for any resourcesharing method. If you use manual controls, this informationmakes it easier to explore design alternatives.

Generating Resource ReportsTo display resource reports, read your design, compile it, thenuse the report_resources command.

dc_shell> analyze –f vhdl my_file .vhdl

dc_shell> elaborate my_file

dc_shell> compile

dc_shell> report_resources

Interpreting Resource ReportsExample 9–27 shows the report generated for Example 9–6(repeated here). Resource sharing is not used.

A, B, C, Z: INTEGER range 0 to 15;. . .process(ADD_B, A, B, C) begin if (ADD_B) then Z <= B+A; else Z <= A+C; end if; end process;



HOME CONTENTS INDEX

Example 9–27 Resource Report for Example 9–6 without Sharing

dc_shell> hlo_resource_allocation = nonedc_shell> analyze –f vhdl example.vhdldc_shell> elaborate exampledc_shell> compiledc_shell> report_resources

****************************************Report : resourcesDesign : EXAMPLEVersion: v3.1Date : Wed 1991****************************************

Resource statistics for process at line 11 in file ‘example.vhdl’==========================================================================| | Module | Contained | || Resource |(parameters) | Resources |Contained Operations| | |(implementation) | | |==========================================================================| r19 | add (N=4) | | ”+”’14 || r16 | add (N=4) | | ”+”’16 |==========================================================================

Example 9–28 shows the report for Example 9–7 (repeatedhere), which uses automatic sharing with manual controls.

A, B, C, Z: INTEGER range 0 to 15;. . . process(A, B, C, ADD_B) subtype resource is INTEGER; constant R0 : resource := 0; attribute ops: STRING; attribute ops of R0 : constant is ”A1 A2”;

begin if (ADD_B) then Z <= A+B; –– pragma label A1 else Z <= A+C; –– pragma label A2 end if; end process;end BEHAVIOR;



HOME CONTENTS INDEX

Example 9–28 Resource Report for Example 9–7 (Automatic Sharing withManual Controls)

dc_shell> hlo_resource_allocation = constraint_drivendc_shell> analyze –f vhdl example2.vhdldc_shell> elaborate example2dc_shell> compiledc_shell> report_resources

****************************************Report : resourcesDesign : EXAMPLEVersion: v3.1Date : Wed 1991****************************************

Resource statistics for process at line 11 in file ‘example.vhdl’=====================================================================| | Module | Contained | || Resource |(parameters) | Resources |ContainedOperations| | |(implementation) | | |=====================================================================| r17 | add (n=4) | R0 | A1 A2 |=====================================================================

The entries in each category for each of the previous reportsare explained below.

Resource identifies the cell in the final netlist. Where resources arebound to other resources, the parent resource nameappears. In Example 9–27, two adders are created andtwo resource identifiers are shown in the report. Example9–28, which uses resource sharing, has only one resourceidentifier. Both examples show the lines in source wherethe operations occur.



HOME CONTENTS INDEX

Module is the name of the hardware module used by the re-source. Example 9–27 has two adders. Example 9–28 hasonly one. The N value (N=) is the bit-width of the adder.

Contained Resources are the names of resources bound to the parent re-source, if any.

Contained Operations gives the operations that are shared on the resource.Unlabeled operations, as in Example 9–27, have thisformat.

operation_name’line_number

For labeled operations, as in Example 9–28, the label_name

appears. If the operation lies in a function, a function nameand a slash (/) precede the label_name .

9 resource sharing - university of california, san...

Documents