Framework Components 1.20 Release Notes
General Info,
Documentation,
What's New,
Compatibility Information,
Validation Info,
Known Issues,
Device Support,
Examples,
Version Information,
Technical Support.
The Framework Components are a collection of framework-independent utility
libraries which other software frameworks can build upon.
This Framework Components release consists of the following packages:
-
ti.sdo.fc.dskt2 - xDAIS utility library for instantiating xDAIS
algorithms, and managing their memory resources.
-
ti.sdo.fc.dman3 - DMA Manager library (Joule
specific). A library for managing DMA hardware resources for xDAIS
algorithms. This includes the IDMA3 interface (Joule specific),
which xDAIS algorithms must implement to enable DMAN3 to manage their
DMA resources.
-
ti.sdo.fc.acpy3 - High-Performance Functional DMA Interface and
Common Library for EDMA3-based devices.
-
ti.sdo.fc.utils - Utilities which frameworks can built upon,
including Design By Contract (DBC) and Debug tracing tools
(DBG).
The Framework Components are provided as libraries, without sources.
Additionally, some distributions of this release include an "fctools" directory
containing xDAIS interface headers for convenience. These headers are
identical to the xDAIS 5.10 Release.
The following documentation is available:
-
Framework Components Reference Guide (HTML | CHM)
-
Configuration Reference Guide
-
Using DMA with Framework Components for 'C64x+ Application Note
-
DSKT2 User's Guide
Release notes from previous releases are also available in the relnotes_archive directory.
The following significant changes have been made since 1.00
1.20 (This Release)
- C64+ libraries built with CG 6.0.8
- Updated fctools to xDAIS 5.20 release
- ACPY3_complete() inline support added.
- fastcopy example cleanup
- And the following MRs were resolved:
ID |
Headline |
SDSCM00002823 |
Remove dependency on BIOS types |
SDSCM00012024 |
DSKT2 User Guide documentation collateral should be provided for
Framework Components |
SDSCM00013086 |
FC DMAN3 example builds have poor out of box experience |
SDSCM00013781 |
Require instrumentation in ACPY3 library to support
DGT logging or any other kind of generic logging |
SDSCM00014395 |
DSKT2 scratch memory allocation & sharing is not optimal when
alignment is required |
SDSCM00014454 |
Hardlimit of DMAN3_MAXDMARECS to 32 not required in the dman3
library. Should be removed as a config option for DMAN3 |
SDSCM00014931 |
DMAN3_createChannels(), DMAN3_grantDMAChannels() memory overwrite
for non-ACPY3 channels |
1.10
- All libraries are built with CG 6.0.7
- Updated fctools to xDAIS 5.10 release
- And the following MRs were resolved:
ID |
Headline |
SDSCM00013041 |
ACPY3 susceptible to SDSCM00012367 (Silicon Errata) |
SDSCM00006288 |
Need to update the Joule DMA design guide |
SDSCM00012532 |
Source code does not line up when stepping through
debug libraries |
SDSCM00012770 |
ACPY3 specification changes are needed for
clarification and to match design and implementation changes |
SDSCM00012773 |
DMAN3 RTSC Configuration requires custom non-public
initialization call to configure DMAN3 heaps |
1.03
- All libraries are built with CG6x 6.0.5
1.02
- OMAPS00082651 - Allow IDMA3 channel env to be allocated in DSKT2
scratch memory
- Also tracked as SDSCM00005723 - FC ACPY3 needs to support scratch
environment memory for IDMA3 channel objects
- SDSCM00010132 - ACPY3 Changes Needed for Interoperability with Codecs
using QDMA Library
- SDSCM00010205 - DMAN3 uses wrong QCHMAP offsets
1.01
- OMAPS00081737 - Race condition can happen in DSKT2_freeAlg
- Also tracked as SDSCM00007366 - DSKT2_freeAlg and lazy
deactivate race condition
- OMAPS00079468 - ACPY3_activate causing DMA transfer when built
with -o3
- OMAPS00078941 - ACPY3_wait() inline version not inlining
- OMAPS00078784 - DSKT2 needs an API to deactivate all algs that have
been lazily deactivated
- Also tracked as SDSCM00006538 - DSKT2's lazy deactivate can cause
problems when power management is introduced
- This was satisfied with the introduction of
DSKT2_deactivateAll()
- OMAPS00079710 - DSKT2 should not try to deactivate an codec instance
that does not provide algDeactivate()
- OMAPS00076836 - DSKT2 can introduce some cache coherence issues
- Also tracked as SDSCM00005847 - DSKT2 doesn't BCACHE_flush
MEM_calloc initialized external, persistant data
- OMAPS00074261 - Support Visual Studio builds of dman3 and acpy3
libraries
- OMAPS00074262 - Fix CPU copy version of ACPY3 library
- Added DSKT2 documentation to the configuration reference guide
This release supports and has been tested on the following devices:
-
DaVinci EVM
-
OMAP2430 EVM
-
OMAP3430 EVM
-
Joule simulators
DMAN3 and ACPY3 can be configured to run on other Joule devices,
(e.g. Himalaya), by configuring DMAN3.qdmaPaRamBase via RTSC or
at runtime by setting DMAN3_PARAMS.qdmaPaRamBase.
Additionally, when DMAN3 is not configured as a RTSC package the
application must set the _DMAN3_EDMA3BASE in the linker cmd file
as shown in the DMAN3 fastcopytest example.
Applications which use ACPY3 but don't consume DMAN3 as a RTSC package
will need to define DMAN3_EDMA3BASE symbol in their application linker
command file. For Davinci and 2430 this should be set as:
_DMAN3_EDMA3BASE = 0x01C00000;
An example of this usage is shown in
ti/sdo/fc/dman3/examples/davincisim_bios/fastcopytest.cmd
-
ti.sdo.fc.acpy2 - This package is compatible with the
previous release. (Compatibility key: undefined ->
1,0,0,0)
-
ti.sdo.fc.acpy3 - This package is compatible with the
previous release. (Compatibility key: 1,0,0 ->
1,0,1,0)
-
ti.sdo.fc.dman - This package is compatible with the
previous release. (Compatibility key: undefined ->
1,0,0,0)
-
ti.sdo.fc.dman3 - This package is compatible with the
previous release. (Compatibility key: 1,0,1 ->
1,0,2,0)
-
ti.sdo.fc.dskt2 - This package is compatible with the
previous release. (Compatibility key: 1,0,1 ->
1,0,2,0)
-
ti.sdo.fc.utils - This package is compatible with the
previous release. (Compatibility key: 1,0,0 ->
1,0,1,0)
-
Compatibility with previous releases is not currently managed in
the examples.
If migrating from a release prior to FC 1.10, consult previous
releases available in the relnotes_archive directory.
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 4 comma-delimited numbers - M,S,R,P
- 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.
- P = Patch. A difference in P simply indicates a
different release of the package (larger is newer). The package is
compatible.
This release was built and validated against using the following components:
-
DSP/BIOS-5.31
-
C6x Code Generation Tools version 6.0.8.
-
C55 Code Generation Tools version 3.2.2.
C64+
-
DaVinci EVM
-
OMAP2430 EVM
-
OMAP3430 EVM
-
Limited sanity testing using CCS C64+ Simulator
C55
ACPY3
-
ACPY3 usage of IDMA0 does not provide any software workaround for
DaVinci silicon defect BTS_DAV_SIBUGS 75, titled:
"GEM IDMA can hang dependent on chip level implementation."
The defect only exists on Davinci Pg1.x silicon. (Fixed for
future Davinci Pg2.x, OMAP 2430 and 3430 silicon releases.)
There is no plan to address this issue in Framework Components.
-
3D DMA transfers using Joule CCNT > 1 (i.e. numFrames > 1) are
not supported. There is no plan to address this limitation.
DMAN3 Example
-
The DMAN3 example .pjt files support only the DaVinci DM644x platform.
xDAIS examples and instructions are located in the
"examples" directory.
- Example Build Instructions
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,
ex. framework_components_1_20.
Subsequent releases of patch upgrades will be identified by the patch
number, ex. FC 1.20.01 with directory framework_components_1_20_01.
Typically, these patches only include critical bug fixes.
For technical support, contact softwaresupport@ti.com
Check the following web site for updates: https://www-a.ti.com/downloads/sds_support/targetcontent/FC/index.html
Last updated: February 20, 2007