RTS Version 3.9.20
21 March 2001
1.0 Overview
This document describes changes included within:
|
Module Name
|
Module Description
|
|
SysConf
|
System Configuration
|
|
TPS
|
TYX Programming Support
|
|
PORF
|
PAWS Output Report Formatter
|
|
Targetter
|
ATLAS Program Targetter
|
|
XUtil
|
TYX X-Window Utilities
|
|
WinUtil
|
TYX MS Windows Utilities
|
|
PLI
|
PAWS LAPS Interpreter
|
|
PTE
|
PAWS Test Executive
|
|
CEM
|
PAWS CIIL Emulation Module
|
Note: SysConf is used by TPS, PORF, Targetter, XUtil, WinUtil, PLI, PTE and CEM
TPS is used by PORF, Targetter, XUtil, WinUtil, PLI, PTE and CEM.
XUtil and WinUtil are used by PLI and PTE.
|
Module
|
Changes
|
Rebuilt
|
Current Version
|
|
SysConf
|
None
|
N/A
|
20000501
|
|
TPS
|
None
|
No
|
20000501
|
|
PORF
|
None
|
No
|
20000508
|
|
Targetter
|
None
|
No
|
20000508 3.8.3
|
|
Xutil
|
None
|
No
|
20000508
|
|
WinUtil
|
None
|
No
|
20000508
|
|
PLI
|
None
|
No
|
20000508 3.9.13
|
|
PTE
|
Minor
|
Yes
|
20010321 3.9.20
|
|
CEM
|
Minor
|
Yes
|
20010321 3.9.20
|
PTE means both the Run-Time System (RTS) and the Simulator (SIM).
PTE, RTS, CEM and SIM mean all Platforms.
UPTE, URTS, UCEM and USIM mean UNIX Platforms only.
WPTE, WRTS, WCEM and WSIM mean MS-Windows Platforms only.
XPTE, XRTS and XSIM mean X-Window Platforms only.
NOTICE TO CEM USERS
This version of the RTS is compatible with CEM Modules built with CEM Files distributed with RTS Version 19980714 3.9.7 and later. You may install this version of the RTS without rebuilding your CEM Module. However, in order to make use of the new CEM capabilities, you MUST install this version of the RTS, and then you MUST recompile and relink your CEM Module(s) with the TYX-supplied CEM Files distributed with this version of the RTS.
As time goes on, RTS/CEM testing to provide error-free backwards-compatibility becomes increasingly difficult. Therefore, TYX Corporation very strongly recommends that CEM Users recompile and relink their CEM Modules after installing a new version of the RTS.
1.1 Enhancements
CEM SubChannels Reset Capability
ATLAS Compilers, the Flow Analyzer and the Resource Allocator have designed within them the concept of Signal and Sub-Signal Objects. These Objects are generated and used by ATLAS Compilers upon detection of certain verbs and nouns. For example, REQUIRE, DIGITAL TEST Statements usually cause the generation of a Signal Object (which is used for DO, DIGITAL TEST Statements), a STIM Sub-Signal Object (which is used for SETUP, DIGITAL TEST Statements specifying Stimulate Modifiers) and a RESP Sub-Signal Object (which is used for SETUP, DIGITAL TEST Statements specifying Response Modifiers). However, the CEM Kernel has no knowledge of the Signal/Sub-Signal relationship between these Objects.
Prior to this release, the CEM Kernel was unable to perform reset operations for Sub-Signal Objects when the associated Signal Object was reset. For example, a REMOVE, DIGITAL TEST Statement would result in the CEM Kernel resetting CEM Kernel Modifier Data for the Signal Object but not for any of the associated Sub-Signal Objects. If the Device Database contains only one Channel (also called a Function) for the Device, this did not cause a problem. However, if the Device Database contains one Channel for the Signal (the Sub-Channel Parent) and one or more Channels for the Sub-Signal(s) (the Sub-Channel Children), the Device Driver was then responsible for determining what Sub-Channel Child Modifier Data was "fresh" or "stale".
With this release, the CEM Kernel allows a CEM Device Driver to specify any Device/Channel as a Sub-Channel Parent (the Signal) so that the CEM Kernel can find and perform reset processing for the Sub-Channel Children (the Sub-Signals). See the CEM Help Section below for detailed information about the new CEM Sub-Channel Functions SubChanParent(), SubChanResetEnable() and SubChanResetDisable().
1.2 Problem Reports.
None
CEM Help
The purpose of this Section is to describe changes made to the CEM User Interface that will eventually be added to the CEM On-Line Help.
Update to "Modifier Data in CEM Kernel" Section
Note:The following will be added to the end of the Section.
SubChanParent()
For those devices that have a "parent"/"child" relationship between the various "channels" (also known as "functions") defined within the Device Database, a driver can call this function to inform the CEM Kernel that such a relationship exists. This allows the CEM Kernel to remove any modifier data for a particular "child channel" when the "parent channel" is RESET
Update to Data Access CEM Macro Group
SubChanParent()
SubChanResetEnable()
SubChanResetDisable()
|
Name:
|
SubChanParent
|
|
Type:
|
Data Access
|
|
Usage:
|
char *pcParentDevChan;
int nStatus;
nStatus = SubChanParent( pcParentDevChan );
|
Description: This Function identifies the Device/Channel specified by the String pointed to by pcParentDevChan as the "parent" Channel for the Device. The format of the String is:
Device:CHChannel
|
where
|
is
|
|
Device
|
the Device Name.
|
|
:CH
|
a Literal.
|
|
Channel
|
the Device Channel Number.
|
Note:TYX strongly recommends that this Function be called within the User's Non-ATLAS Action CONNECT Function (which is called by the CEM Kernel just one time at the end of the CEM Kernel's initialization processing.)
This Function performs the following:
- Verifies that the specified Device/Channel String is valid.
- Marks the Device/Channel as a Sub-Channel Parent.
- For each Device/Channel with the same Device Name as the Sub-Channel Parent:
- Marks the Device/Channel as a Sub-Channel Child.
- Disables
the calling of the Device/Channel ATLAS Action RESET Function when the Sub-Channel Parent is RESET.
- Verifies that the Sub-Channel Parent has at lease one Sub-Channel Child.
Note When the CEM Kernel receives a Message from the RTS to RESET a Sub-Channel Parent, the CEM Kernel resets the Device by:
- Calling the Sub-Channel Parent ATLAS Action RESET Function (if defined).
- Removing all accumulated Sub-Channel Parent DATUM's (i.e., Modifier Data).
- Resetting each Sub-Channel Child of the Sub-Channel Parent by:
- Calling the Sub-Channel Child ATLAS Action RESET Function (if enabled and defined).
- Removing all accumulated Sub-Channel Child DATUM's (i.e., Modifier Data).
|
Returns:
|
Integer
|
= = OSRSERR
|
= Error detected.
|
|
 
|
 
|
= = OSRSOK
|
= No errors detected.
|
See Also: Data Access CEM Macros and CEM Functions SubChanResetEnable() and SubChanResetDisable().
Name: SubChanResetEnable
Type: Data Access
Usage: char *pcChildDevChan;
int nStatus;
nStatus = SubChanResetEnable( pcChildDevChan );
Description: This Function enables the ATLAS Action RESET Function for the Device/Channel specified by the String pointed to by pcChildDevChan. The format of the String is:
Device:CHChannel
where is
Device he Device Name.
:CH Literal.
Channel the Device Channel Number.
This Function performs the following:
- Verifies that the specified Device/Channel String is valid.
- Verifies that the specified Device/Channel is marked as a Sub-Channel Child.
- Enables the calling of the Device/Channel ATLAS Action RESET Function when the Sub-Channel Parent is RESET.
Returns: Integer == OSRSERR = Error detected.
== OSRSOK = No errors detected.
See Also: CEM Functions SubChanParent() and SubChanResetDisable().
Name: SubChanResetDisable
Type: Data Access
Usage: char *pcChildDevChan;
int nStatus;
nStatus = SubChanResetDisable( pcChildDevChan );
Description: This Function disables the ATLAS Action RESET Function for the Device/Channel specified by the String pointed to by pcChildDevChan. The format of the String is:
Device:CHChannel
where is
Device the Device Name.
:CH a Literal.
Channel the Device Channel Number.
This Function performs the following:
- Verifies that the specified Device/Channel String is valid.
- Verifies that the specified Device/Channel is marked as a Sub-Channel Child.
- Disables the calling of the Device/Channel ATLAS Action RESET Function when the Sub-Channel Parent is RESET.
Returns: Integer == OSRSERR = Error detected.
== OSRSOK = No errors detected.
See Also: CEM Functions SubChanParent() and SubChanResetEnable().
|