************************************* * A Brief History of RESTRICT_CLASS * ************************************* ============================================================================== RESTRICT_CLASS definition in ALF 1.1: see chapter 3.6.5.9, page 83 f. http://www.eda.org/alf/homepage/alf_1.1.pdf ============================================================================== RESTRICT_CLASS definition in ALF 2.0: see chapter 6.1.4 through 6.1.6, page 103 ff. http://www.eda.org/alf/homepage/alf_2.0.pdf ============================================================================== Conference call with request for amendment of RESTRICT_CLASS definition http://www.eda.org/alf/homepage/minutes/010710_ALF.txt ============================================================================== From owner-alf@eda.org Wed Jul 11 09:17:26 2001 From: tim.ehrler@philips.com Subject: Re: minutes of today's conference call To: alf@eda.org Cc: ola@si2.org Date: Wed, 11 Jul 2001 11:21:31 -0500 X-MIMETrack: Serialize by Router on AMAUO01/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 11/07/2001 11:20:33 MIME-Version: 1.0 Per my action item regarding a more concise description of restrict class semantics and usage, I have adapted the description of this annotation from the OLA 1.14 specification. Regards, Tim Current ALF 2.0 specification ============================= 6.1.4 RESTRICT_CLASS annotation RESTRICT_CLASS = string ; The value is the name of a declared CLASS. Multi-value annotation can be used. Cells referring to a particular class can be used in design tools identified by the value. The restricted annotations are shown in Table 6-6. < ... Table 6-6 ... > User-defined values are also possible. If a cell has no or only unknown values for RESTRICT_CLASS, the application tool shall not modify any instantiation of that cell in the design. However, the cell shall still be considered for analysis. Proposed ALF 2.0 specification =========================== 6.1.4 RESTRICT_CLASS annotation RESTRICT_CLASS = string ; The value is the name of a declared CLASS. Multi-value annotation can be used. Cells referring to a particular class can be used in design tools associated with the value. Defined restricted annotations are shown in Table 6-6. User-defined values may also be specified, the implications of which are described below. < ... Table 6-6 ... > A wide variety of applications (logic synthesis, floorplanning, placement, routing, etc.) are utilized during the design process, the functionality of which have been categorized as restrict classes. Each tool operation that creates and/or alters the design logic falls into one or more of these categories depending on the operation being performed. For example, a layout tool will want to expand the cellset with those cells restricted only to layout, as well as use the more general cellset of synthesis and scan if it is capable of performing the similar operations of those tools. In many technologies, cells may have been specifically designed for special portions of the design process, such as clock tree synthesis. These special purpose cells shall not used by applications that are not performing that specific design operation for which these cells are intended. The subset of restrict classes associated with a cell is therefore used to indicate which design operation(s) the cell can be used for. A named restrict class identifies a collection of zero or more cells that can be used for specific design operation(s). If a cell does not specify any restrict class(es), or if the specified class(es) is/are unknown to the application, then that application shall not modify any instantiation or allow creation or usage of that cell in the design. However, the cell shall still be considered for analysis and linking. A cell may be associated with zero or more restrict classes. Each cell in the library is responsible for identifying to which of the restrict classes it belongs. The application shall use a cell if, and only if, the restrict class specified by that cell matches the restrict class(es) known to the application. Tools can be multiply classed, and cells used must have a restrict class subset match with the application. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Timothy J. Ehrler, Senior Principal ASIC Technical Programs Manager ASIC Design Flow Department, Design Technology Group Philips Semiconductors 8375 S. River Pkwy. M/S 285 Tempe, Arizona 85284 Phone:(480)752-6389 FAX:(480)752-6019 Email: Tim.Ehrler@philips.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ============================================================================== Conference call discussing Tim's RESTRICT_CLASS proposal http://www.eda.org/alf/homepage/minutes/010710_ALF.txt ============================================================================== From owner-alf@eda.org Thu Jul 12 13:02:20 2001 Date: Thu, 12 Jul 2001 12:59:07 -0700 (PDT) From: Wolfgang Roethig To: alf@eda.org Subject: restrict_class follow up Hello all, Please find my new proposal for restrict_class semantics, based on yesterday's conference call. The objective is to allow a more general usage model, which is compatible with both the existing ALF and OLA usage model and also allows for more sophisticated usage models. The rational is that ALF should not depend on a particular control mechanism for an application tool, but the restrict_class values should have their own merit. As an analogy, I would classify food (contains fat, is soy-based, is meat-based ...) independent of the way how a physician would prescribe a certain diet for a patient. For context, I have also included an excerpt from the minutes as well as Tim Ehrler's email on the subject. Best regards Wolfgang Proposed ALF IEEE specification =============================== RESTRICT_CLASS annotation RESTRICT_CLASS = string ; | RESTRICT_CLASS { string { string } } The value is the name of a declared CLASS. Multiple values can be used. Predefined values are shown in Table x-x. User-defined values may also be specified. < Table x-x contains: synthesis use restricted to logic synthesis scan use restricted to scan synthesis clock use restricted to clock tree synthesis datapath use restricted to datapath synthesis layout use restricted to layout, i.e., place & route > The restrict_class value(s) associated with a cell shall be subject to a set of rules for an application tool, allowing or disallowing the usage of a cell, based on restrict_class values. If the usage of a cell is allowed, the application tool may add, remove, or substitute instances of such a cell in a design. If the usage of a cell is not allowed, the application tool may not add, remove, or substitute instances of such a cell in a design. The application tool shall, at least, support the following specification capability for each particular restrict_class value in the library. 1. Restrict_class value must match: Cell can be used, if the restrict_class value is present. 2. Restrict_class value can match: Cell can be used, regardless whether the restrict_class value is present or not. 3. Restrict_class value must not match: Cell can not be used, if the restrict_class value is present. It is conceivable that the application tool supports more complex rules, such as "cell can be used if restrict_class value A and restrict_class value B or restrict class value C is present". However, implementation details of such rule specification capability are outside the scope of this standard. Note: This boils down to a boolean specification scheme: "must match" equates "true", "can match" equates "don't care", "must not match" equates "false". The ALF 2.0 specification is supported by specifying "must match" for the values of interest and "can match" for all others. The OLA specification is supported by specifying "must match" for the values of interest and "must not match" for all others. ----- Excerpt from conference call minutes ----- RESTRICT_CLASS discussion ------------------------- A.I. Comment on semantic change of RESTRICT_CLASS - Tim Ehrler DONE Tim has sent the paragraph of the OLA semantics to the reflector. The discussion on the subject was lengthy, not all details are captured here. Kevin explained the meaning of "linking" in that paragraph. It does not mean linking of object code to form an executable. It means reading and elaborating a netlist containing the cells in question. This terminology is used by Synopsys tools. Wolfgang did not like the wording of the OLA paragraph because of its verbosity and proposed to discuss the essentials of the semantic difference between ALF and OLA, which is the following: - ALF 2.0 dis-allows usage of cell, if the cell contains "no or only unknown" restrict_class values. - OLA dis-allows usage of cell, if the cell contains "any unknown" restrict_class values. Wolfgang: propose to come up with a more general specification that encompasses both the ALF and OLA usage model. The set of predefined restrict_class values (synthesis, clock, layout ...) lends itself to the ALF usage model. Kevin: Support of the OLA definition is mandatory. It may be impossible to come up with a more general specification without introducing ambiguity. However, tools may have the capability to edit the run-time library to remove certain restrict_class values in order to use otherwise dis-allowed cells. Tim: restrict_class is not used by Philips, agrees with Kevin on the ambiguity concern. Alex: suggest to take the discussion offline, Wolfgang should write his proposal. A.I. write the proposal for restrict_class - Wolfgang NEW ============================================================================== From owner-alf@eda.org Mon Jul 16 05:02:59 2001 Date: Mon, 16 Jul 2001 07:55:32 -0400 From: Sergei Sokolov X-Accept-Language: en MIME-Version: 1.0 To: alf@eda.org CC: sean@sequencedesign.com Subject: FWD: Question on SWAP/RESTRICT classes Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Status: X-Keywords: X-UID: 1412 From the inner parts of Sequence: Hi Sergei, Steve passed your emails to me regarding the swap/restricted_class in ALF 2.0. After briefly read thru the doc, I have a question here - In Chapter 6.1.3, it says "Multi-value annotation can be used [in SWAP_CLASS]." In Chapter 6.1.5, it reads "the set of cells that can be swapped with each other is the set of cells with a non-empty intersection of both SWAP_CLASS and RESTRICT_CLASS." In Chapter 6.1.6, the first paragraph reads "Cells can only be swapped if the intersection of their SWAP_CLASS and the inherited RESTRICT_CLASS is non-empty." So, for example, CLASS foo; CLASS bar; CELL cell1 { SWAP_CLASS { foo } RESTRICT_CLASS { layout } } CELL cell2 { SWAP_CLASS { foo bar } RESTRICT_CLASS { layout } } CELL cell3 { SWAP_CLASS { bar } RESTRICT_CLASS { layout } } By definition, (cell1, cell2) and (cell2, cell3) are swappable sets but not (cell1, cell3). However once an instantiation of cell1 is swapped with cell2 (via foo), it becomes legal for swapping with cell3 (via bar). So natually (cell1, cell2, cell3) is a swappable set. A similar scenario can go across RESTRICT_CLASS. Here is another example, CLASS foo { RESTRICT_CLASS { synthesis } }; CLASS bar { RESTRICT_CLASS { layout } } ; CELL cell1 { SWAP_CLASS { foo } } CELL cell2 { SWAP_CLASS { foo bar } } CELL cell3 { SWAP_CLASS { bar } } In a tool of doing physical synthesis, it may swap cell1 with cell2 during resynthesis, and then swap cell2 with cell3 during physical layout optimization. It turns out cell1 is swapped with cell3 in one run although cell1 and cell3 are not swappable by definition. I believe this must have been discussed by the committee long time ago. Do you know what was the concensus? I think "multi-value annotation" is quite general for handling different scenarios but it could easily be too general if not well-defined in the first place. Thanks, Sean- -- ************************************************************************* ** Sergei Sokolov E-mail: ssokolov@sequencedesign.com ** ** Sequence Design, Inc. Phone: +1-978-635-9080x317 ** ** www.sequencedesign.com Fax: +1-978-635-9575 ** ************************************************************************* ============================================================================== From owner-alf@eda.org Mon Jul 16 15:08:55 2001 Date: Mon, 16 Jul 2001 15:02:22 -0700 From: Kevin Grotjohn X-Accept-Language: en,pdf MIME-Version: 1.0 To: Sergei Sokolov CC: alf@eda.org, sean@sequencedesign.com Subject: Re: FWD: Question on SWAP/RESTRICT classes Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The original proposal the classes are defined such that the application implementation is if the cells are same swap class { if the cells are all known restrict class { swap cells } } ALF1.x allowed multiple restrict class, but it was worded such that only one class needed to be known for a match. This means that restrict classes can be ignored - however it is mandatory requirement that restrict classes not be ignored. Thus OLA it was reworded to require all restrict classes to match. Sections 6.1.5 and 6.1.6 are examples added in ALF2.0 - the sentences you point out are further semantic explanation that are actual further restriction of the semantic that appear in 6.1.3 and 6.1.4. I would rather leave it as swappable cells having all the known restrict classes - that ALF2.0 example interpretation is assuming that tools are single class only. I have asked Wolfgang to provide the record of discussion on these additions because I was only aware that ALF1.x and ALF2.0 difference would be the examples OLA clarified the restrict classes to mean tool operations - rather than tools themselves. Tools are belonging to multiple classes nowadays. In your example it should not matter not if the same tool is performing the operations or different tools within the same flow are performing the operations. The end result is the same. You point out that it swaps the cells defined as nonswappable was if it was a problem - but it did not swap the cells within the same operation so it is a legit swap. Maybe foo is for cells with diffusion inputs, and bar is for same size cells. Certainly this library example would work in both the phsycial synthesis tool and the synthesis/layout tool flow and get the desired swapping results. The problem with the ambigous semantics is with multiple valued restrict_class. ALF1.1 allows this because the cell is being used in either the synthesis OR layout operation. Whereas I originally proposed and as was finally accepted by OLA - this means it can only be used only in an tool operation that does synthesis AND layout. (LSI datapath tools consist of such multiply classed operations). The problem with ALF1.1 is that it allows an undefined restrict class to be ignored in the multiple class case - suppose cell2 also had "restrict_class = super_secret_usage" In ALF1.1 it will get used whenever the synthesis or layout operations are performed regardless the super_secret_usage status - this is a violation of the semantic intent that unknown restrict class is not used. With OLA reflecting the original proposal semantic intent this means that it can only be used for a tool operation that is classed as synthesis, layout, and super_secret_usage. I certainly see that it is desirable to define a cell useable in tool operations synthesis OR layout - even though I proposed a semantic that is synthesis AND layout - but this semantic is absolutely necessary to avoid unknowingly using restricted cells. I would argue that ALF inheritance solves this problem of OR already - the swap class itself is restricted in your final example - therefore the layout operation never sees the synthesis operations swap class, cell2 in fact is not multivalued restriction except for the tool operation that is classed as synthesis AND layout. So any argument of AND/OR/ANY/ONLY is not present moot in this example because inheritance was used to eliminate the possibility of multiple restrict class! There is an argument to be made only for an example cell that has RESTRICT_CLASS { layout synthesis} Certainly requiring the multivalued restrictions to be all matched means it has to be taken into account in the class design to enable the swapping operations desired. Such a multiply classed cell is only swappable in a multiple classed tool operation - which is not likely. ALF inheritance allows the common concept of using cells in synthesis or layout thru inheritance- even without inheritance you can still use a non standard class (synthesis_layout) to define the cellset common to both operations. This only requires a user/application restrict_class configuration to recognize this. On the application side it is very straightforward inplementation regardless of the library complexity. Moving the mulitply classed semantics from the standard definition to the application definition as Wolfgang proposed means it is not known how the multiple class cells are interpreted - thus the multiply classed cells cannot be designed. ------------------------------------------------------------------------------- Kevin R. Grotjohn LSI Logic Corporation Staff Design Engineer 15813 SE Rivershore Dr ARM Datapath Design Vancouver, WA 98683 Processor Cores Division Tel : (360) 891-5577 krag@lsil.com Fax : (360) 891-5959 ------------------------------------------------------------------------------- ============================================================================== From owner-alf@eda.org Mon Jul 16 15:33:16 2001 Date: Mon, 16 Jul 2001 15:28:20 -0700 (PDT) From: Wolfgang Roethig To: alf@eda.org Subject: Re: FWD: Question on SWAP/RESTRICT classes Cc: sean@sequencedesign.com, ssokolov@sequencedesign.com Sean and all, The restrict_class and swap_class have a long history. The main reason for ongoing discussion is the long latency time between formulation of the original concept and the effort of tool implementation. Therefore I distinguish between the following type of issues: Type 1 Issues related to the original concept and its formulation in ALF 1.1. Type 2 Issues related to amendments of the ALF 1.1 spec., formulated in ALF 2.0, eventually causing alteration of the original idea. Type 3 Issues related to interpretation of the ALF 1.1 and/or ALF 2.0 by the OLA work group and reformulation of the concept in OLA 1.14. Please find embedded comments on your mail with this distinction in mind. Regards Wolfgang > From the inner parts of Sequence: > > Hi Sergei, > > Steve passed your emails to me regarding the swap/restricted_class > in > ALF 2.0. After briefly read thru the doc, I have a question here - > > In Chapter 6.1.3, it says "Multi-value annotation can be used [in > SWAP_CLASS]." > > In Chapter 6.1.5, it reads "the set of cells that can be swapped > with > each other is the set of cells with a non-empty intersection of both > SWAP_CLASS and RESTRICT_CLASS." > There is a "Type 2" issue. It should say "non-empty intersection of SWAP_CLASS and usage authorization by RESTRICT_CLASS". > In Chapter 6.1.6, the first paragraph reads "Cells can only be > swapped > if the intersection of their SWAP_CLASS and the inherited RESTRICT_CLASS > is > non-empty." > This can also be better formulated by saying "if the intersection of their SWAP_CLASS is not empty, provided usage authorization by the inherited RESTRICT_CLASS". > So, for example, > > CLASS foo; > CLASS bar; > CELL cell1 { > SWAP_CLASS { foo } > RESTRICT_CLASS { layout } > } > CELL cell2 { > SWAP_CLASS { foo bar } > RESTRICT_CLASS { layout } > } > CELL cell3 { > SWAP_CLASS { bar } > RESTRICT_CLASS { layout } > } > > By definition, (cell1, cell2) and (cell2, cell3) are swappable sets > but > not (cell1, cell3). However once an instantiation of cell1 is swapped > with > cell2 (via foo), it becomes legal for swapping with cell3 (via bar). So > natually (cell1, cell2, cell3) is a swappable set. > This example is a poor usage of SWAP_CLASS and RESTRICT_CLASS. If all cells have the same RESTRICT_CLASS, it makes no sense to have multiple non-exclusive SWAP_CLASS values in a cell. > A similar scenario can go across RESTRICT_CLASS. Here is another > example, > > CLASS foo { RESTRICT_CLASS { synthesis } }; > CLASS bar { RESTRICT_CLASS { layout } } ; > CELL cell1 { > SWAP_CLASS { foo } > } > CELL cell2 { > SWAP_CLASS { foo bar } > } > CELL cell3 { > SWAP_CLASS { bar } > } > > In a tool of doing physical synthesis, it may swap cell1 with cell2 > during resynthesis, and then swap cell2 with cell3 during physical > layout > optimization. It turns out cell1 is swapped with cell3 in one run > although > cell1 and cell3 are not swappable by definition. > This is actually in line with the original idea: A tool can be set up so that cells can be swapped in a certain way during subsequent operations in the flow. In a meaningful scenario, there would be few cells used for inital synthesis (coarse set of drive strengths) and many cells used for layout (fine-tuned drive strengths). However, during "Type 1" and "Type 3" discussions, we figured that such a scenario can even be accomplished without the concept of inherited RESTRICT_CLASS. > I believe this must have been discussed by the committee long time > ago. > Do you know what was the concensus? I think "multi-value annotation" is > quite general for handling different scenarios but it could easily be > too > general if not well-defined in the first place. > > Thanks, > > Sean- > > -- > ************************************************************************* > ** Sergei Sokolov E-mail: ssokolov@sequencedesign.com ** > ** Sequence Design, Inc. Phone: +1-978-635-9080x317 ** > ** www.sequencedesign.com Fax: +1-978-635-9575 ** > ************************************************************************* > To summarize the consensus: 1. RESTRICT_CLASS and SWAP_CLASS should be orthogonal. Once the usage of a set of cells is authorized by the RESTRICT_CLASS values, cells with common SWAP_CLASS within that set can be swapped. 2. A tool may be configurable to recognize different sets of RESTRICT_CLASS values in order to utilize different sets of cells in different stages of the design flow. 3. A majority of users think in terms of predefined RESTRICT_CLASS values (synthesis, clock, layout ...). However, for flow control according to the original idea, customized RESTRICT_CLASS values are mandatory. 4. The original ALF 1.1 spec "if a cell has no or only unknown RESTRICT_CLASS values" needs to be amended. To summarize the points of discussion: 5. The OLA spec now says that the usage of a cell with any RESTRICT_CLASS value unknown to the application is not authorized. This clashes with the meaning of the predefined RESTRICT_CLASS values. For example, a buffer that can be used for logic synthesis or for clock tree synthesis would have RESTRICT_CLASS { synthesis clock }. However, neither a pure "synthesis" nor a pure "clock" tool could use that buffer. 6. The latest proposal from my side allows for a general formulation of usage authorization, which - hopefully - accomodates all the different usage models that people have in mind, without introducing ambiguity or making the system too complicated. Please see my previous email to the reflector. 7. In the context of a general usage model, we have to decide whether the concept of inherited RESTRICT_CLASS, introduced in ALF 2.0, is still useful. ============================================================================== From krag@lsil.com Mon Jul 16 16:46:48 2001 Date: Mon, 16 Jul 2001 16:47:13 -0700 From: Kevin Grotjohn X-Accept-Language: en,pdf MIME-Version: 1.0 To: Wolfgang Roethig CC: alf@eda.org, sean@sequencedesign.com, ssokolov@sequencedesign.com Subject: Re: FWD: Question on SWAP/RESTRICT classes Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Good breakdown of the issues Wolfgang - I do not disagree any of your bullets - except #6 summary. I agree that the intent of the predefined classes was to enable use of cellsets for different common tool operations. However it really never considered cellsets useable for multiple tool operations. If { synthesis clock} was to mean synthesis OR clock tools - then { synthesis clock fubar} would mean synthesis OR clock OR fubar tools. That means that restriction fubar is ignored in the synthesis or clock tool. Your interpretation is that this only defines another allowed tool usage defeats the purpose of it being a further restriction on cell usage. That interpretation goes against the underlying priniciple of unknown restrictions are not ignored (i.e. cells are used) - that is the mandatory requirement referred to in the minutes that any implementation must consider. Defining the tool operation as multiply classed synthesis AND clock solves the problem - but only if it really does both things or use both cellsets at once. Then synthesis tool can use synthesis cellsets, the clock tool can use clock cellsets, or there can be a tool that uses both synthesis and clock cellsets - including the overlap of the cellsets.. I see no problem with multiply classed tools like this, in fact this what the LSI datapath tools do and the restrict_class usage is even user configurable! However if the tool operation is not truly multiply classed then a class must be created for the cellset of cells that are usuable in both operations - i.e. {synthesis_clock}. This may not be as elegant as {synthesis clock} - but it is certainly possible with user/app restrict_class configuration. I would expect such unique classes in a library would be documented as part of library/tool vendor flow methodology - so I do not see this to be an issue as indicated in summary #3. I cannot support either the standard or application allowing the semantic to be a partial match of multiply classed cells - as this does not meet the mandatory requirement that unknown restrictions are not to be ignored! My issue is that ALF does not meet that requirement - even with the new proposal to put the semantic requirement on the application side not in the standard. I think inheritance is still a powerful solution - especially defining swap_classes as restricted as in the most recent example. This enables a different cellset for each operation as well as a cell supporting multiple operations- and avoids the inelegance of multiply classed cells requiring new combination classes. I think ALF already has the flexibility needed - we just need to close the hole that allows unknown restricted cells to be used. The solution of requiring a match of all multiple classes may lead to inelegant or more complex class definitions - but the alternative is usage of unknown cells. Your proposal is that restrict_class semantics be configurable - however it really only works if just the applications restrict_class known values are configurable. The library class design cannot be made independent of the application semantics - trying to generalize it makes it ambigous. I think the ALF concept of inheritance is what makes the idea general usage. ============================================================================== ------------------------------------------------------------------------------- Kevin R. Grotjohn LSI Logic Corporation Staff Design Engineer 15813 SE Rivershore Dr ARM Datapath Design Vancouver, WA 98683 Processor Cores Division Tel : (360) 891-5577 krag@lsil.com Fax : (360) 891-5959 ------------------------------------------------------------------------------- ============================================================================== From sean@sequencedesign.com Thu Jul 26 16:44:39 2001 Date: Thu, 26 Jul 2001 16:46:43 -0700 From: Sean Huang X-Accept-Language: zh-TW, en MIME-Version: 1.0 To: Wolfgang Roethig , Kevin Grotjohn , ssokolov@sequencedesign.com Subject: Re: FWD: Question on SWAP/RESTRICT classes Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Kevin & Wolfgang, Sorry for the late response. Things have been very busy here. After reading through all the emails that I received from you, here are my $0.02 - (1) I agreed with Wolfgang on my first example to be a poor usage of SWAP_CLASS and RESTRICT_CLASS (as I intented to make a bad one). But that also says, such a poor usage may cause confusions between library builder, designer, and application tools in the future. Maybe a clear statement that prohibits a cell to have multiple non-exclusive SWAP_CLASS/RESTRICT_CLASS values would help to reduce potential conflicts in the future. (2) I did not expect to see the divergence between the proposals from both of you. In short, I think both proposals are workable and look sound to me. It seems you just look at the same problem from different angles (w/ different philosophy?), I guess. ^_^ (a) What Kevin stands upon seems more in line with the definition of "RESTRICT_CLASS". (I like to think of Wolfgang's proposal as "AUTHORIZED_CLASS". ^_^) SWAP_CLASS has the OR relationship and RESTRICT_CLASS uses the AND. To achieve the OR relationships between RESTRICT_CLASS's, one can use inherited RESTRICT_CLASS to create multiple SWAP_CLASS's. For example, the SWAP_CLASS 'logic_nand' which has an inherited RESTRICT_CLASS 'synthesis' is for the nand gates tha are swappable in logic syntehsis tools, while the 'layout_nand' which has an inherited RESTRICT_CLASS 'layout' is for the nand gates that are swappable in layout tools. a nand cell may have both 'logic_nand' and 'layout_nand' in its SWAP_CLASS, which make the cell swappable in both synthesis and layout tools. (b) What Wolfgang proposed, however, is relatively more intuitive and easy-to-understand to me. Both SWAP_CLASS and RESTRICT_CLASS use the OR relationships. To achieve the AND relationship between RESTRICT_CLASS's, one can create a new RESTRICT_CLASS for the combination. For example, the RESTRICT_CLASS's {syntehsis layout} and { layout_synthesisi } are for the application tools that perform either or both layout and synthesis operations respectively. No matter it is (a) or (b), either one will do well, I believe. What I concerns more is we should try to reduce any potential poor usage (== potential conflicts) while we generalize the usage model. Again, just my $0.02. ^_^ Sean- ============================================================================== From krag@lsil.com Thu Jul 26 18:58:59 2001 Date: Thu, 26 Jul 2001 18:59:02 -0700 From: Kevin Grotjohn X-Accept-Language: en,pdf MIME-Version: 1.0 To: Wolfgang Roethig CC: alf@eda.org Subject: Re: FWD: Question on SWAP/RESTRICT classes Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If restrict_class is seen as an OR function it may be more intuitive - but this violates the basic principle of the concept that unknown restrictions mean do not use/touch! of course this is intuitive to think restrict_class { synthesis layout } means this cell is useable in synthesis or layout tools but you have to realize that interpretation restrict_class ( synthesis layout fubar } means this cell is useable in synthesis or layout or fubar tools. In other words fubar restriction is ignored in the synthesis tool! If fubar is a restricted class of cells unknown to the user or any tool - it is not acceptable that it be used in other classes of tools. This is the fundamental problem that has yet to be solved by any proposal except that it be an AND relationship. I realize that making it an AND relationship requires more combination restrict classes in apps/libs or swap classes restricted with inheritance to do the same thing as the intuitive version - but it is a concession to making it work in principle whereas the intuitive version does not. Personally I think inheritance is actually more intuitive for the typical problem that needs solved (expanded cell swapping in layout) rather than multiple classes. The proposal to configure the relationship on the application side is not a solution either - because it is not possible to configure a restriction that is unknown - simply because you do not know about it means you cannot configure it. Without the AND interpretation - it is not possible to make an custom restrict class (i.e fubar example) which can be used both in custom tools (because it is known)- and in standard flows using standard tools that know standard restrictions only (user configured to know custom restrict class). This is a need LSI has and why the proposal was made years ago. Assume I have a synthesis tool and layout tool that can be configured to use fubars synthesis cellset in synthesis tool and fubars expanded layout cellset in layout tool. IBM also proposed this need - LSI calls it mix and match synthesis. With this capability I just set restrict_class fubar once at the beginning of the flow. restricted cellsets are not just for specific tools or operations - sometimes they are used to distinguish different classes of cells - like good/bad small/big fast/slow high/low cellsets. While my AND solution may seem counter intuitive on the library side - it is extremely intuitive, useable and simple on the app/user side. There are a lot more chip designers than library designers - so I put the burden on the library design. ============================================================================== RESTRICT_CLASS definition update in IEEE work doc: see chapter 14, page 33 ff. http://www.eda.org/alf/homepage/alf_draft4jul2001.pdf (actually staged on Aug. 1 2001) ============================================================================== Conference call in September 2001: no discussion on RESTRICT_CLASS topic http://www.eda.org/alf/homepage/minutes/010919_ALF.txt ============================================================================== RESTRICT_CLASS definition update in IEEE work doc: see chapter 14, page 33 ff. http://www.eda.org/alf/homepage/alf_draft4oct2001.pdf (no substantial changes wrt previous version) ============================================================================== Face-to-face meeting in October 2001: no discussion on RESTRICT_CLASS topic http://www.eda.org/alf/homepage/minutes/011009_ALF.txt ============================================================================== RESTRICT_CLASS definition update in IEEE work doc: see chapter 14, page 33 ff. http://www.eda.org/alf/homepage/alf_draft4nov2001.pdf (no changes wrt previous version) ============================================================================== Face-to-face meeting in November 2001: Request to document the history of RESTRICT_CLASS http://www.eda.org/alf/homepage/minutes/011009_ALF.txt ==============================================================================