****************************************************************************** ********************* IBIS GOLDEN PARSER BUG REPORT FORM ********************* ****************************************************************************** INSTRUCTIONS To report a bug in the IBIS golden parser. Please fill out the top part of the following form and send the complete form to ibis-bug@eda.org. A list of reported bugs will be maintained on eda.org. ****************************************************************************** PARSER VERSION NUMBER: 6.0.0 PLATFORM (SPARC, HP700, PC, etc.): PC OS AND VERSION: Linux,Win8 REPORTED BY: Mike LaBonte, SiSoft, Bob Ross, Teraspeed Labs DATE: September 16, 2014 DESCRIPTION OF BUG: Disable undocumented -etc flag inserted during the ibischk4 development by setting Boolean to False. The tests which are turned on are not clear and may not be valid. The orginal developer does not recall the details related to these tests. Since an undocumented flag is required, the removal of these tests should not have any impact. A more detailed writeup is below: In ibischk the -etc flag sets an internal global flag (gbEtcFlag) to TRUE. This flag enables the following checks in circuit.c:CCALL_checkNodes(): {CIRCUIT_ERR_29, "Component <%s> Node: <%s> has no defined drivers%s"}, {CIRCUIT_ERR_30, "Component <%s> Node: <%s> has a analog receiver but no analog driver%s"}, {CIRCUIT_ERR_31, "Component <%s> Node: <%s> has a analog receiver but no obvious analog driver\n\ This indicates connection to a AMS port that 'may' be analog %s"}, {CIRCUIT_ERR_32, "Component <%s> Node: <%s> has a analog driver but no analog receiver%s"}, {CIRCUIT_ERR_33, "Component <%s> Node: <%s> has a analog driver but no obvious analog receiver\n\ This indicates connection to a AMS port that 'may' be analog %s"}, These are mostly ERRORs, but CIRCUIT_ERR_31 and CIRCUIT_ERR_33 are WARNINGs. Section 6.3 of the IBIS 6.0 specification does say that both digital and analog signal ports must be present. But I can't find anything in section 6.3 relating to combinations of drivers and receivers, and it's not clear to me from the code that for example CIRCUIT_ERR_30 would be issued only where a driver and receiver would be expected. Not using the flag enables a special error message in mdl.c:s_SetExtMdlSubParms(): case PORT_TYPE: if (gbEtcFlag) /* this is only turned on by Explicit Type Check flag JNP NON-SPEC*/ { if (Args.iCount != 3) { /* ERRLOG_LineError("Wrong number of args in PORT_TYPE"); */ ERRLOG_LineErrorNew(MDL_ERR_42); break; } s_MDL_AddPortType(pMdl,Args.arg[1],Args.arg[2]); } else { /* ERRLOG_LineError("Port_type not allowed without -etc flag"); */ ERRLOG_LineErrorNew(MDL_ERR_43); } break; So having a "Port_Type" parameter in an [External Model] will trigger MDL_ERR_43 with no -etc, and will trigger MDL_ERR_42 with -etc if there are not 3 arguments. The comment in the source code from Jon Powell is significant, saying that there is no such parameter in IBIS. No regular IBIS user will run into this. The suggestions would be to: 1. Comment out all mdl.c and ibis_chk.c code related to -etc 2. Mark messages MDL_ERR_42 and MDL_ERR_43 as "Unused" in the spreadsheet. 3. Comment out checks CIRCUIT_ERR_29 through 33 in circuit.c The proposed resolution is to disable the -etc flag by permanently setting the Boolean to False (but to leave in the checks for historical reference). INSERT IBIS FILE DEMONSTRATING THE BUG: None ****************************************************************************** ******************** BELOW FOR ADMINISTRATION AND TRACKING ******************* ****************************************************************************** BUG NUMBER: 158 SEVERITY: [FATAL, SEVERE, MODERATE, ANNOYING, ENHANCEMENT] ANNOYING PRIORITY: [HIGH, MEDIUM, LOW] LOW STATUS: [OPEN, CLOSED, WILL NOT FIX, NOT A BUG] CLOSED FIXED VERSION: 6.0.1 FIXED DATE: November 3, 2014 NOTES ON BUG FIX: Classified at the October 3, 2014 IBIS Teleconference meeting. The proposed resolution is (1) disable or comment out the -etc flag, (2) set the Boolean associated with it to false, and (3) clearly put in comments in the portions of code that the -etc flag enabled for future code reference to indicate that the code was activated only by an undocumented -etc flag. ****************************************************************************** ******************************************************************************