eXpress DSP Components (XDC) is a standard for reusable software
components, optimized for real-time embedded systems. XDC components
have hardware-neutral formal interfaces, are configurable offline to
optimize memory and performance, and support custom automation in the
development environment via a scripting language.
XDC 2.93 includes the following sets of packages:
XDC core (xdc.*) - the xdc and
xs command line utilities for building packages
and execting scripts, together with the packages that implement
XDC itself;
User tools (xdc.tools.*) - command-line
and graphical utilities for working with packages and repositories;
Targets (*.targets.*) - definitions for using
various TI and third-party compiler tool chains with XDC;
Platforms (ti.platforms.*) - definitions for
linking and running code on various TI board-level hardware and
simulator products using XDC.
The following significant changes have been made since 2.92
Additions to the XDC Spec language
Additions to XDC runtime: Gate and TimeStamp
Enhanced ROM-ability of XDC content
Configuro build support added to Code Composer Studio v3.3
2.93 (This Release)
XDC Spec Language
added ability to generate a custom header from a template.
The @CustomHeader attribute now accepts an optional argument.
If an argument is supplied it is interpreted as a template
that should be used (in lieu of the standard RTSC header
file generation) to create the module's header.
@CustomHeader is now interpreted for metaonly modules; this
can be used to generate headers from metaonly modules used
for config.
module-wide configs defined in abstract interfaces can no
longer be accessed via proxies; in general, there was no way
to access these given an abstract module anyway. in cases
where runtime access to an underlying module config is required
via such an abstraction, a getter should then be explicitly
spec'd in the interface.
added the @TargetHeader attribute for metaonly units, allowing
them to supply a template for generating a target-domain .h
file. this feature is currently used by various ITarget.xdc to
invoke a common template used to generate various #define's
previously passed on the command-line
proxy declarations can now appear in the 'internal' section of
an .xdc module spec, just like most other module-wide features.
since these proxies are (in principle) not seen by the client,
their binding is the reponsibility of the module supplier in
their Mod.xs file; usage in both the meta- and target-domains
is otherwise the same
abstract const declarations (without initializers) appearing
in interfaces can now be overriden in units that inherit this
interface. by definition, a const with an initializer is
effectively 'final'. any const that has not been initialized
in a concrete module implies a @CustomHeader
XDC Script
added the built-in xdc-script operators $externFxn() and
$externPtr(), both of which take a string-valued argument that
denotes an external symbol. these operators should be used
when assigning legacy code/data pointers to config params of
type I/UArg. this approach is preferred over the current
'&myFxn' style of values, which would now be denoted as
$externFxn('myFxn')
change all examples to use the new $externFxn('myFxn') operator
in lieu of '&myFxn'; see idioms/i302 for an illustration
extended support for $logError functions to cfg model
initialization so that the platform instantiation code can use
that support; as a result, the function setExecutable() now
returns a String which contains errors and warnings, if any
Boot
if Program.system is null, two symbols from xdc.runtime.Startup
are added to the linker command file, and set to 0; these
symbols are function names, and the purpose of setting these
symbols to 0 in tha case when the functions are not linked in
is to support new boot files; new boot files will always look
for those symbols, but will call functions only if symbols are
not equal to 0
Added calls to Startup_reset & Startup_exec in boot files; added
--args option and removed alloc in SECTIONS in linkcmd.xdt in
ti.targets
Added autoinit to rts5500 and rts6000
Fixed the way we're calling the reset/exec functions in the boot
file for Arm9
Runtime
removed __PLAT__ from xdc/runtime/std.h
renamed the xdc_target__profile symbols to be xdc_bld__profile
to distinguish this symbol from the symbols xdc_target_*
symbols defined by std.h
the type xdc.runtime.Gate.Ref is now @Encoded as a
IGateProvider.Handle, enabling config-time assignment to state
variables of this type by simply assigning the result of
creating an IGateProvider instance object. this type continues
to be represented as an opaque pointer on the target, subject
to manipulation by the Gate_{alloc,enter,leave,free} macros.
added the getFreq into xdc.runtime.ITimeStamp and related
modules
removed 'name' from IHeap interface
Added new type xdc.runtime.Types.FreqHz to represent ferquency
in Hz. Used xdc.runtime.Types.FreqHz in
xdc.runtime.ITimestampSupport and xdc.runtime.Timestamp modules.
made SysMin and HeapMin thread-safe (using GATE_enterSystem),
and made a couple of name tweaks to Gate files
flushFull set to 'true' in SysMin.xdc
SysMin changes:
HOSTwrite 256 max problem fixed. On TI targets,
SysMin.bufSize greater than 256 was truncated to just 256.
Default flushFull to false. This might impact regression
tests with large amount of output via System_printf and
using SysMin.
bufSize default to 1024 chars instead of 256
Gate-protected the insertion/removal of created/deleted
instances from their module's master linked list within
xdc.runtime.Core, using the System gate
added 4 IArg fields to the end of the (opaque) Error_Block
struct for future expansion
reworked the (recursive) implementation of Text_putRope to
prevent "INLINE Recursion" warnings from occuring when
Text_NOLOAD is true; this also helps reduce code size
changed the signature of System_fail to take only a msg,
rather than a msg + vargs; this enables a more efficient
implementation in that only putch is called internally.
the two known call sites for this API (Error_raise and
Startup_exec) have been altered accordingly
changed the signature of Log_doPrint to take a single arg of
type Log_EventRec*, where the latter contains the log event,
args, timestamp, and serial number. modified LoggerSys to use
this feature, while also adding a config param to control
whether a timestamp is reported
the special format specifiers %$R, %$M, and %$S have been
removed from System_printf; current usage in xdc.runtime is
replaced with direct calls to routines in Text. the %$L
specifier remains, and is used to print the label associated
with a Handle-valued arg
XDC Module Binary Contract
arrays generated in package/cfg/*.c now are external symbols
with a '__A' suffix in their name; this helps in understanding
footprint issues when looking at a link map, but otherwise has
no impact on performance
Targets
added default platform for ti.targets.TMS470* targets
added a parameter to Win32 target to contain the path to an
installation of Platform SDK; Platform SDK is installed
separately from Visual Studio, so the installation path is not
fixed
Platforms
added a new parameter renameMap to xdc.platform.IPlatform; the
puprose of this parameter is to allow a simple way of changing
the names of memory objects without redefining the whole memory
map with 'customMemoryMap'
added assembleMemoryMap() to xdc.platform.Utils; the function
gathers cpu's and board's memory into a memory map and applies
any renaming requests passed through 'renameMap'
ROM Support
fixed a bug in the handling of object-offset accessors within
the ROM flow, but treating the underlying const offset value
not unlike any other module-wide config
fixed a bug in the handling of proxies within the ROM flow
Added .bss fix for ROM, plus NOLOAD change, to
ti/targets/linkcmd.xdt
fixed a bug in the generation of makefiles for ROM assemblies.
the ITarget link method now receives the reflected value of the
'isRom' attr in is 'goal' argument. ti/targets/ITarget.xs
factors this in when deciding to apply the "sed" hack
changed the use of 'DSECT' to 'NOLOAD' in
ti/targets/linkcmd.xdt when specifying the .fixedCode section
in the final link
fixed a ROM bug resulting from module-wide configs defined in
interfaces that are in turn inherited by a proxy
Build
removed most command line -D options added by xdc.bld; they
are now statically defined in headers included (indirectly)
by xdc/std.h. Clients that build source that include
xdc/std.h must only need to define two symbols:
xdc_target_types__ - the package qualified path to the
target's standard types header; e.g.,
ti/targets/std.h
xdc_target_name__ - the name of the target without the
package name
fixed xdc/bld/build.dtd, and xdc/bld/release.dtd to be
consistent with what is currently being generated
added a timestamp to the end of each package's .$vers array;
it previously contained only the compatibility key values from
package.xdc. With the addition of the package's release date
timestamp, this array can now be used as a version number;
i.e., different releases have unique $vers arrays
code in xdc.cfg.Main.xs that determines the order in which the
packages add their libraries to the linker command file is
changes, so that the package being built gets always on the top
of the list in the linker command file
fixed release processing to not complain about require
statements that exist solely to create a bundle
Configuro Build
Simplified the makefile usage for
non-TI targets. The generated linker.cmd file is now a linker
script with the correct syntax for the target. Previously some
special processing was needed in the makefile to convert syntax
for non-TI targets. Updated configuro examples.
Added new configuro command-line options to support
integration into CCS via BTI DLL.
Changed the command line syntax for using configuro with a
TCONF script. Previously the name of the .tcf file was given,
and the .cfg file was inferred. Now the name of the .cfg file
is given, and an additional "--tcf" option is used.
Modified configuro to use an XDC assembly only when the profile
is "whole_program" and the target is a TI target.
Code Composer Studio Support
Added support for XDC build using Configuro to Code Composer
Studio v3.3. This shows up as an "XDC" tab in the project
Build Settings. Configuro build is enabled by adding a .cfg
file to the CCS project.
Coverity Support
change -fs and -fr options to use -fs= and -fr= variants to
work around Coverity Prevent defect number 6979
fixed tisb.coverity.filters compiler config to work with
C++ code
Tools
In xdc.tools.Cmdr, updated command-line argument processing
with support for long and short option names. Also if the
config param is an array, then the option can be used multiple
times on the command line, as in -I... .
Assemblies
changed condition that determines if __PLAT__ and other symbols
in Program.xdt are included; now, Program checks for assemblies
by checking the length of the array $$asmvec, which gets
populated if Program imported any assemblies. If assemblies are
imported, at least one of them included symbols. However, this
solution does not solve the problem if Program imports more
than one assembly, where each one of them included symbols.
added two additional commands for a compilation goal where an
assembly is built in 'whole_program' profile. In that case,
the linker creates non-relocatable partially linked file, and
depending on the section order, linking such a file in the
final linker step can generate errors. The implemented solution
uses the optimized assembly file that the linker also generates
and compiles that assembly file to create a relocatable object
file, with all optimizations we need. Then, the compiled file
replaces the file that the linker initially generated.
XGCONF Graphical Configuration
Added checks for script text lines that the xgconf
parser does not support. If found the script is
marked as non-parsable. If the user performs an
edit action a golden watermark is appended to the
file and it is reparsed prior to executing the action.
Enhancements
The following minor enhancements were resolved:
ID
Headline
Defects
The following defects were resolved:
ID
Headline
SDSCM00006912
need to standardize std.h architecture symbols
SDSCM00012058
XGCONF "optimize script" corrupts some hand-written config
scripts
ti.targets - This package is compatible with the
previous release. (Compatibility key: 1,0,0,0 -> 1,0,0,1)
gnu.targets - This package is compatible with the
previous release. (Compatibility key: 1,0,0,0 -> 1,0,0,1)
Warning: Beginning with xdc-o02, internal C files generated when
building package schemas are
named package_<package name>.c instead of <package_name>.c.
This may introduce incompatibilities with older xdc-n and xdc-o trees
(XDC 2.X products).
The compatibility with metaonly xdc-m packages (XDC 1.X products) is still maintained.
Compatibility Key Definitions
Compatibility keys are intentionally independent of Marketing product numbers
and are intended to:
Enable tooling to identify incompatibilities between components, and
Convey a level of compatibility between different releases to set end user
expectations.
Compatibility keys are composed of 3 comma-delimited numbers - M,S,R - where:
M = Major. A difference in M indicates a break in compatibility.
S = Source. A difference in S indicates source compability. That
is, the user's source doesn't require change, but does require
rebuilding.
R = Radix. A difference in R indicates an introduction of new
features, but compatibility with previous interfaces has not broken. If
libraries are provided by the package, an application must re-link with the
new libraries, but not rebuild from source.
This product's version follows a version format, M.mm.pp.bb, where
M is a single digit Major number, mm is 2 digit minor number,
pp is a 2 digit patch number, and b is an unrestricted set of
digits used as an incrementing build counter.
To support multiple side-by-side installations of the product, the product
version is encoded in the top level directory, e.g.
xdc_2_93.
Subsequent releases of patch upgrades will be identified by the patch number,
ex. XDC 2.93.01 with directory xdc_2_93_01. Typically,
these patches only include critical bug fixes.
Please note that version numbers and compatibility keys are NOT the same. For
an explanation of compatibility keys, please refer to the 'Upgrade and
Compatibility Information' section.
