VITAL Working Group Meeting, Ottawa, April 1993 Steve Schultz - introduction Take version 2 VITAL and review the issues toward implementation of VITAL. What needs to be changed to make VITAL successful. Companies represented: NEC (development group, cad support) 5 Mentor (vhdl simulation) Toshiba (Vertex) National Semiconductor 2 Ikos 3 Genrad 2 Hewlett Packard (ASIC) Intergraph Simquest Racal Redac 2 Synopsys (library compiler group) 2 Vantage 3 TI semiconductor LMC 2 Cadence LSI Logic Ryan and Ryan Consulting Bill Billowitch: Purpose: Technical session to move VITAL forward! Presented VITAL VI technical committee there were several points made that will be presented today. VITAL objective is going to remove the word certified and shoot for VHDL ASIC Libraries. The VITAL proposal will be moved to the IEEE for standardization once the development process of the document is complete. Get it far along so that balloting can be accelerated. MODIFICATIONS Expected in 2.1 o Condense and simplify 2.0 thru 4.0 o Add a glossary of terms, clarify the term interface throughout o Appendix A 10.1, 10.4 becomes part of the standard o Requirements Document is out of date - remove references to it in the spec o Delete references to "the separation of timing & function" o Remove philosophic viewpoints regarding "golden" or "certified" simulators o Remove improper data from section 2.4 Any problems with above proposals in the group? Everyone agrees More Modifications for 2.1 o Define the version # and subset of SDF which will be used - Will use SDF that supports backannotation of timing and not use items that imply changes to function o Redraw 8-71 such that tool which currently produce SDF are not obligated to produce VHDL. Show SDF as the timing data value input to other tools. o Define all the SDF -> VHDL transformations in detail o Report SDF -> VHDL omissions & errors o Move all unessential reference to a discussion document (i.e. Wire Delays) o Restrict the statement of scope to Macrocells o Timing parameter prefix names must be further expanded/clarified o Glitch procedure will be built (see attached slide on Glitch/Hazard) Decision made to do glitch on detect or on event, rejection limit, and a flag for message/no message A great deal of discussion occurred and the outcome of the discussions are summarized below. Event or Detect: separate into two procedures - agreed Detect Glitch: Not needed - agreed Propagate X: switch on procedure - agreed Inertial or Transport: not needed - agreed Message upon detect: switch on procedure - agreed Pulse Rejection Limit - separate procedure (not hw accelerateable for x propagation, ok for messaging) - agreed LIST OF OPTIONS FOR MESSAGING AND X PROPAGATION: MSG +X MSG -X X -MSG No Detect o Eliminate the global signal restriction o "Primitives" to be implemented as procedures & functions instead of entity/architecture pairs -> easier to support & accelerate Everybody Agrees with areas of modification Under Consideration for Version 2.1 Under Tval implementation: o Resolve potential hierarchical naming conflicts for package names o Timing representations for array ports needs further consideration o Timing functions may require further work Rationale: Original assumption that a large number of generic parameters is less efficient than a small number of larger parameters is found to be untrue in talking with simulator vendors. Consideration of using Expanded generic lists vs. Tval o Eliminates the need to maintain corresponding packages o Make the model more readable o Eliminates the chance of overrunning array bounds o Removes the need for a VITAL attribute o Eliminates the hierarchical naming problem Discussion - Parameters possible for a model: tp01,tp10,tp0z,tp1z,tpz0,tpz1 tsetup(hi|lo), thold(hi|lo),tpwlo,tpwhi,tperiod Must set naming convention regardless, but is also needed to tie to SDF. The problem with naming needs to be re-engineered - Any opinions on Tval vs. Expanded Generic? Synopsys has problems with current deferred constant package. Problem is the explosion of constants if it does it named association. o Tvalpkg <- model (package per model basis) o Tvalpkg -> Xlate <- SDF (required to prevent mismatch) o Output of Xlate is Tval_ckt used by the configuration declaration Implementation may read SDF directly, but is not required - Also meets the needs of defense contractors that have a VHDL mandate. VITAL modeling must allow simulation in a pure VHDL environment. Someone will need to generate option A or option B to support this objective. o No requirement implied that the EDA vendor will need transform to option A or B to be VITAL compliant o Must have an SDF reader to be VITAL compliant Which option should be the recommendation A or B? A is Tval arrays in generic and B is expanded generic. The vote was inconclusive, but leaned toward B. Model robustness problem - how do you insure that you don't index beyond the end of the array. TABLE 1. A Pros: doesn't need to be filled in A Cons: simple potential pkg name conflicts B Pros: Easier to understand model B Cons: Larger list of generics Example Option A: Tval_pkg_AND: ( tp01_A_C: (5 6 7) tp10_A_C: (5 6 7) tp01_B_C: (5 6 7) tp10_B_C: (5 6 7) ); Example Option B: Generic tp01_A_C: MTM:= (5 6 7) tp01_B_C: MTM:= (5 6 7) tp10_A_C: MTM:= (5 6 7) tp10_B_C: MTM:= (5 6 7) The real issue is partial association with the remainder going to default is OK with B not with A. Remote: A or B -> option B wins! Comments and Presentations from the Group Dan Hafeman (Ikos Systems) How will you handle multidrive/multireceiver networks? The solution requires changes to the VHDL structure if the VHDL must describe the simulation completely. VITAL will not recommend how to accomplish this task. This model is not specified as part of VITAL, it will be removed. Accelerateable User Defined Function/Procedure - see attached slide DISCUSSION Is VITAL going to recommend a model standard or are you going to open up to entire VHDL. The group had a great deal of discussion. The consensus was that their are things specified that can be used in places other than where VITAL is intending like macrofunc- tions. How are vendors modeling? Primitive/Table? - Vendors HP - Table based approach because they can specify the behavior very accurately and facilitate functional simulation. LSI - Behavioral Modeling is preferred TI - Uses the structural approach currently in VHDL - We are having difficulty need a bus holder primitive - A table approach would be easier. LMC - Don't ASIC vendors want one library if possible: yes - one library across software and hardware simulators. HP - Presented some proposals for generating truth table for modeling: The proposal uses an if/else if structure to eliminate the lack of the don't care functionality inside tables to describe a D flip-flop. The model will be sent out on the reflector. A second proposal uses a CASE structure. The model will be sent out on the reflector. A third proposal adds a logic system that includes a rising and falling edge value. The model will be sent out on the reflector. A fourth proposal to simplify the truth table in the third proposal. The model will be sent out on the reflector. DISCUSSION Need to define what is needed not the implementation. Needs more work to refine in the specification. LMC - Randy Harr 6.2 Optimization/Table -> Unnecessary - VHDL semantics does not allow collapsible hierarchy - Pros/Cons not really correct 7.1 Tval pkg - requires instance specific package. package names global to library 7.2 SDF direct - SDF is slow also unless only delta included - need some info to timing calculator included. 8.0 Header Msg -either standardize or drop -if instance name, only mechanism is via generic o Setup/Hold/Timing -> collapse to single call. Only seen by model writer. Document to him/her how to do setup/hold/etc. with single call. o Period check -> seems very complex. Should simply check rise to rise or fall to fall. Use pulse_hi or pulse_lo seems swapped o Calcdelay - `W' - maximize uncertainty - minimize time to `x' and maximize time from `x' 11.0 Net delay not mentioned 16.0 Condition on timing - If not using SDF mechanism, need naming convention for con- dition based time specification GENERAL o Distinguish gate and behavior(megacell) modeling requirements o Bus holder In Out U W X W 0 L 1 H W Z L Z H Z Z Z - Z LSI Logic - Jeffery Vo SDF - enumeration type not supported in SDF - Glitch, X propagate... (no plan to extend SDF) Unconstrained or constrained array - SDF can't specify the entire array of timing for vec- tor inputs d (8 downto 0) Primitives - Multiple pin changes at the same time (how do you handle this?) - Which glitch algorithm for the primitives? (Don't put the scheduling in the primitive) DISCUSSION - HP likes separation of timing calc and function - helps state dependent PRIMITIVES will be functions or sequential procedure calls! DISCUSSION - Are the models behavior or structure? The consensus was behavior using sequential proce- dure calls or functions - as mentioned above in the PRIMITIVES item. Bill Billowitch - multiple pin change discussion There is no absolute rule. The consensus was that what you do should match what would happen if the events were a delta delay different in one direction or the other, don't invent a third result! One proposal to assure the same behavior if events are a delta delay apart or at the same time is to always generate the X. This means use the on detect mode defined or add another on event mode that generates the x regardless of where the second event is sched- uled (before or after ) the first scheduled event. No conclusion was reached and was left as an exercise for Bill to propose something in the next version of the spec. Glitch/Hazard o Provide two algorithms o Propagate X on hazard detect o Propagate X on event maturity X on event X on detect