Microprocessor Library Definition (MLD)
Microprocessor Library Definition Overview
This section describes the Microprocessor Library Definition (MLD) format, Platform Specification Format 2.1.0. An MLD file contains directives for customizing software libraries and generating Board Support Packages (BSP) for Operating Systems (OS). This document describes the MLD format and the parameters that can be used to customize libraries and OSs.
Requirements
Each OS and library has an MLD file and a Tcl (Tool Command Language) file associated with it. The MLD file is used by the Tcl file to customize the OS or library, depending on different options in the MSS file. For more information on the MSS file format, see Microprocessor Software Specification (MSS). The OS and library source files and the MLD file for each OS and library must be located at specific directories to find the files and libraries.
MLD Library Definition Files
Library Definition involves defining Data Definition (MLD) and a Data Generation (Tcl) files.
Data Definition File
The MLD file (named as <library_name>.mld or <os_name>.mld ) contains the configurable parameters. A detailed description of the various parameters and the MLD format is described in MLD Parameter Descriptions.
Data Generation File
The second file (named as <library_name>.tcl or <os_name>.tcl, with the filename being the same as the MLD filename) uses the parameters configured in the MSS file for the OS or library to generate data. Data generated includes, but is not limited to, header files, C files, DRCs for the OS or library, and executables. The Tcl file includes procedures that are called by the tool at various stages of its execution. Various procedures in a Tcl file include the following:
- DRC (the name of the DRC given in the MLD file)
- generate (tool defined procedure) called after OS and library files are copied
- post_generate (tool defined procedure) called after generate has been called on all OSs, drivers, and libraries
- execs_generate (a tool-defined procedure) called after the BSPs, libraries, and drivers have been generated
MLD Format Specification
The MLD format specification involves the MLD file format specification and the Tcl file format specification. The following subsections describe the MLD.
MLD File Format Specification
The MLD file format specification involves the description of configurable parameters in an OS or a library. The format used to describe this section is discussed in MLD Parameter Descriptions.
TCL File Format Specification
Each OS and library has a Tcl file associated with the MLD file. This Tcl file has the following:
- DRC Section
- This section contains Tcl routines that validate your OS and library parameters for consistency.
- Generation Section
- This section contains Tcl routines that generate the configuration header and C files based on the library parameters.
MLD Design Rule Check Section
proc mydrc { handle } { }
The DRC function could be any Tcl code that checks your parameters for correctness. The DRC procedures can access (read-only) the Platform Specification Format database (which the tool builds using the hardware (XSA) and software (MSS) database files) to read the parameter values that you set. The handle is associated with the current library in the database. The DRC procedure can get the OS and library parameters from this handle. It can also get any other parameter from the database by first requesting a handle and using the handle to get the parameters.
For errors, DRC procedures call the Tcl error command error "error msg" that displays in an error page.
For warnings, DRC procedures return a string value that can be printed on the console.
On success, DRC procedures return without any value.
MLD Format Examples
This section explains the MLD format through an example MLD file and its corresponding Tcl file.
Following is an example of an MLD file for the xilmfs library.
option psf_version = 2.1.0 ;
option is a keyword identified by the tool.
The option name following the option keyword is a
directive to the tool to do a specific action.
The psf_version of the MLD file is defined to
be 2.1 in this example. This is the only option that can occur before a BEGIN
LIBRARY construct now.
BEGIN LIBRARY xilmfs
The BEGIN LIBRARY construct defines the start of a library named
xilmfs.
option DESC = "Xilinx Memory File System" ;
option drc = mfs_drc ;
option copyfiles = all;
option REQUIRES_OS = (standalone xilkernel freertos_zynq);
option VERSION = 2.0;
option NAME = xilmfs;
The NAME option indicates the name of the
driver. The VERSION option indicates the version of
the driver.
The COPYFILES option indicates the files to
be copied for the library. The DRC option specifies the name of the Tcl procedure
that the tool invokes while processing this library. The mfs_drc is the Tcl procedure in the xilmfs.tcl file that would be invoked while processing the xilmfs
library.
PARAM name = numbytes, desc = "Number of Bytes", type = int, default =
100000, drc = drc_numbytes ;
PARAM name = base_address, desc = "Base Address", type = int, default =
0x10000, drc = drc_base_address ;
PARAM name = init_type, desc = "Init Type", type = enum, values = ("New
file system"=MFSINIT_NEW,
"MFS Image"=MFSINIT_IMAGE, "ROM Image"=MFSINIT_ROM_IMAGE), default =
MFSINIT_NEW ;
PARAM name = need_utils, desc = "Need additional Utilities?", type =
bool, default = false ;
PARAM defines a library parameter that can be configured. Each
PARAM has the following properties associated with it, whose
meaning is self-explanatory: NAME, DESC, TYPE, DEFAULT, RANGE, DRC.
The property VALUES defines the list of possible values associated
with an ENUM type.
BEGIN INTERFACE file
PROPERTY HEADER="xilmfs.h" ;
FUNCTION NAME=open, VALUE=mfs_file_open ;
FUNCTION NAME=close, VALUE=mfs_file_close ;
FUNCTION NAME=read, VALUE=mfs_file_read ;
FUNCTION NAME=write, VALUE=mfs_file_write ;
FUNCTION NAME=lseek, VALUE=mfs_file_lseek ;
END INTERFACE
An Interface contains a list of standard functions. A library defining an interface should have values for the list of standard functions. It must also specify a header file where all the function prototypes are defined.
PROPERTY defines the properties associated
with the construct defined in the BEGIN construct.
Here HEADER is a property with value xilmfs.h, defined by the file interface. FUNCTION defines a function supported by the
interface.
The open, close, read,
write, and lseek functions of the file
interface have the values mfs_file_open,
mfs_file_close, mfs_file_read, mfs_file_write,
and mfs_file_lseek. These functions are defined in the header file
xilmfs.h.
BEGIN INTERFACE filesystem
BEGIN INTERFACE defines an interface the library supports. Here,
file is the name of the interface.
PROPERTY HEADER="xilmfs.h" ;
FUNCTION NAME=cd, VALUE=mfs_change_dir ;
FUNCTION NAME=opendir, VALUE=mfs_dir_open ;
FUNCTION NAME=closedir, VALUE=mfs_dir_close ;
FUNCTION NAME=readdir, VALUE=mfs_dir_read ;
FUNCTION NAME=deletedir, VALUE=mfs_delete_dir ;
FUNCTION NAME=pwd, VALUE=mfs_get_current_dir_name ;
FUNCTION NAME=rename, VALUE=mfs_rename_file ;
FUNCTION NAME=exists, VALUE=mfs_exists_file ;
FUNCTION NAME=delete, VALUE=mfs_delete_file ;
END INTERFACE
END LIBRARY
END is used with the construct name that was used in the
BEGIN statement. Here, END is used with
INTERFACE and LIBRARY constructs to indicate
the end of each of INTERFACE and LIBRARY
constructs.
The following is the xilmfs.tcl file corresponding the
xilmfs.mld file described in the previous section. The
mfs_drc procedure would be invoked for the
xilmfs library while running DRCs for libraries. The
generate routine generates constants in a header file and a c file for the
xilmfs library based on the library definition segment in
the MSS file.
proc mfs_drc {lib_handle} {
puts "MFS DRC ..."
}
proc mfs_open_include_file {file_name} {
set filename [file join "../../include/" $file_name]
if {[file exists $filename]} {
set config_inc [open $filename a]
} else {
set config_inc [open $filename a]
::hsi::utils::write_c_header $config_inc "MFS Parameters"
}
return $config_inc
}
proc generate {lib_handle} {
puts "MFS generate ..."
file copy "src/xilmfs.h" "../../include/xilmfs.h"
set conffile [mfs_open_include_file "mfs_config.h"]
puts $conffile "#ifndef _MFS_CONFIG_H"
puts $conffile "#define _MFS_CONFIG_H"
set need_utils [common::get_property CONFIG.need_utils $lib_handle]
if {$need_utils} {
# tell libgen or xps that the hardware platform needs to provide
stdio functions
# inbyte and outbyte to support utils
puts $conffile "#include <stdio.h>"
}
puts $conffile "#include <xilmfs.h>"
set value [common::get_property CONFIG.numbytes $lib_handle]
puts $conffile "#define MFS_NUMBYTES $value"
set value [common::get_property CONFIG.base_address $lib_handle]
puts $conffile "#define MFS_BASE_ADDRESS $value"
set value [common::get_property CONFIG.init_type $lib_handle]
puts $conffile "#define MFS_INIT_TYPE $value"
puts $conffile "#endif"
close $conffile
}
An example of an MLD file for the standalone OS is given below:
option psf_version = 2.1.0 ;
option is a keyword identified by the tool.
The option name following the option keyword is a
directive to the tool to do a specific action. Here the psf_version of the MLD file
is defined to be 2.1. This is the only option that can occur before a BEGIN OS construct at this time.
BEGIN OS standalone
The BEGIN OS construct defines the start of an OS named
standalone.
option DESC = "Generate standalone BSP";
option COPYFILES = all;
The DESC option gives a description of the
MLD. The COPYFILES option indicates the files to be
copied for the OS.
PARAM NAME = stdin, DESC = "stdin peripheral ", TYPE =
peripheral_instance, REQUIRES_INTERFACE = stdin, DEFAULT = none; PARAM
NAME = stdout, DESC = "stdout peripheral ", TYPE = peripheral_instance,
REQUIRES_INTERFACE = stdout, DEFAULT = none ; PARAM NAME = need_xilmalloc,
DESC = "Need xil_malloc?", TYPE = bool, DEFAULT = false ;
PARAM defines an OS parameter that can be configured. Each
PARAM has the following, associated properties:
NAME, DESC, TYPE,
DEFAULT, RANGE, DRC. The
property VALUES defines the list of possible values associated with
an ENUM type.
END OS
END is used with the construct name that was used in the
BEGIN statement. Here END is used with OS to
indicate the end of OS construct.
The following is the standalone.tcl file corresponding to the standalone.mld file described in the previous section. The generate routine generates constants in a header file and a c file for the xilmfs library based on the library definition segment in the MSS file.
proc generate {os_handle} {
global env
set need_config_file "false"
# Copy over the right set of files as src based on processor type
set sw_proc_handle [get_sw_processor]
set hw_proc_handle [get_cells [get_property HW_INSTANCE
$sw_proc_handle] ]
set proctype [get_property IP_NAME $hw_proc_handle]
set procname [get_property NAME $hw_proc_handle]
set enable_sw_profile [get_property
CONFIG.enable_sw_intrusive_profiling $os_handle]
set mb_exceptions false
switch $proctype {
"microblaze" {
foreach entry [glob -nocomplain [file join $mbsrcdir *]] {
# Copy over only files that are not related to exception
handling.
# All such files have exception in their names.
file copy -force $entry "./src/"
}
set need_config_file "true"
set mb_exceptions [mb_has_exceptions $hw_proc_handle]
}
"ps7_cortexa9" {
set procdrv [get_sw_processor]
set compiler [get_property CONFIG.compiler $procdrv]
if {[string compare -nocase $compiler "armcc"] == 0} {
set ccdir "./src/cortexa9/armcc"
} else {
set ccdir "./src/cortexa9/gcc"
}
foreach entry [glob -nocomplain [file join
$cortexa9srcdir *]] {
file copy -force $entry "./src/"
}
foreach entry [glob -nocomplain [file join $ccdir *]] {
file copy -force $entry "./src/"
}
file delete -force "./src/armcc"
file delete -force "./src/gcc"
if {[string compare -nocase $compiler "armcc"] == 0} {
file delete -force "./src/profile"
set enable_sw_profile "false"
}
set file_handle [xopen_include_file "xparameters.h"]
puts $file_handle "#include \"xparameters_ps.h\""
puts $file_handle ""
close $file_handle
}
"default" {puts "unknown processor type $proctype\n"}
}
MLD Parameter Descriptions
MLD Parameter Description Section
This section gives a detailed description of the constructs used in the MLD file.
Conventions
[ ] Denotes optional values.
< > Value substituted by the MLD writer.
Comments
Comments can be specified anywhere in the file. A “#” character denotes the beginning of a comment and all characters after the “#” right up to the end of the line are ignored. All white spaces are also ignored and semi-colons with carriage returns act as sentence delimiters.
OS or Library Definition
The OS or library section includes the OS or library name, options, dependencies, and other global parameters, using the following syntax:
option psf_version = <psf version number> BEGIN LIBRARY/OS <library/os
name> [option drc = <global drc name>] [option depends = <list of
directories>] [option help = <help file>] [option requires_interface =
<list of interface names>] PARAM <parameter description> [BEGIN CATEGORY
<name of category> <category description> END CATEGORY] BEGIN INTERFACE
<interface name> ....... END INTERFACE] END LIBRARY/OS
MLD Keywords
The keywords that are used in an MLD file are as follows:
BEGIN
The BEGIN keyword begins one of the
following: os, library, driver, block, category,
interface, and array.
END
The END keyword signifies the end of
a definition block.
PSF_VERSION
Specifies the PSF version of the library.
DRC
Specifies the DRC function name. This is the global DRC function, which is called by the GUI configuration tool or the command-line tool. This DRC function is called once you enter all the parameters and MLD or MDD writers can verify that a valid OS, library, or driver can be generated with the given parameters.
Option
Specifies that the name following the keyword option is an option to the GUI tools.
OS
Specifies the type of OS. If it is not specified, then OS is assumed as standalone type of OS.
COPYFILES
Specifies the files to be copied for the OS, library, or driver. If
ALL is used, then the tool copies all the OS,
library, or driver files.
DEPENDS
Specifies the list of directories that needs to be compiled before the OS or library is built.
SUPPORTED_PERIPHERALS
Specifies the list of peripherals supported by the OS. The values of this option can be specified as a list, or as a regular expression. For example:
option supported_peripherals = (microblaze)
Indicates that the OS supports all versions of MicroBlaze. Regular expressions can be used in specifying the peripherals and versions. The regular expression (RE) is constructed as follows:
- Single-Character REs:
- Any character that is not a special character (to be defined) matches itself.
- A backslash (followed by any special character) matches the literal character itself. That is, this “escapes” the special character.
- The special characters are: + * ? . [ ] ^ $
- The period (.) matches any character except the new line. For example, .umpty matches both Humpty and Dumpty.
- A set of characters enclosed in brackets ([]) is a one-character RE that matches any of the characters in that set. For example, [akm] matches either an "a", "k", or "m".
- A range of characters can be indicated with a dash. For example, [a-z] matches any lowercase letter. However, if the first character of the set is the caret (^), then the RE matches any character except those in the set. It does not match the empty string. Example: [^akm] matches any character except "a", "k", or "m". The caret loses its special meaning if it is not the first character of the set.
- Multi-Character REs:
- A single-character RE followed by an asterisk (*) matches zero or more occurrences of the RE. Thus, [a-z]* matches zero or more lower-case characters.
- A single-character RE followed by a plus (+) matches one or more occurrences of the RE. Thus, [a-z]+ matches one or more lower-case characters.
- A question mark (?) is an optional element. The preceeding RE can occur zero or once in the string, no more. Thus, xy?z matches either xyz or xz.
- The concatenation of REs is a RE that matches the corresponding concatenation of strings. For example, [A-Z][a-z]* matches any capitalized word.
- For example, the following matches a version of the
axidma:
option supported_peripherals = (axi_dma_v[3-9]_[0-9][0-9]_[a-z] axi_dma_v[3-9]_[0-9]);
LIBRARY_STATE
Specifies the state of the library. Following is the list of values that can be assigned to LIBRARY_STATE:
- ACTIVE
- An active library. By default the value of LIBRARY_STATE is ACTIVE.
- DEPRECATED
- This library is deprecated
- OBSOLETE
- This library is obsolete and will not be recognized by any tools. Tools error out on an obsolete library and a new library should be used instead.
APP_COMPILER_FLAGS
This option specifies what compiler flags must be added to the application when using this library. For example:
option APP_COMPILER_FLAGS = “-D MYLIBRARY”
The GUI tools can use this option value to automatically set compiler flags automatically for an application.
APP_LINKER_FLAGS
This option specifies that linker flags must be added to the application when using a particular library or OS. For example:
option APP_LINKER_FLAGS = “-lxilkernel”
The GUI tools can use this value to set linker flags automatically for an application.
BSP
Specifies a boolean keyword option that can be provided in the MLD file to identify when an OS component is to be treated as a third party BSP. For example:
option BSP = true;
This indicates that the Vitis tools will offer this OS component as a board support package. If set to false, the component is handled as a native embedded software platform.
OS_STATE
- ACTIVE
- This is an active OS. By default the value of OS_STATE is ACTIVE.
- DEPRECATED
- This OS is deprecated.
- OBSOLETE
- This OS is obsolete and will not be recognized by the tools. Tools error out on an obsolete OS and a new OS must be specified.
- OS_TYPE
- Specifies the type of OS. This value is matched with SUPPORTED_OS_TYPES of the driver MDD file for assigning the driver. Default is standalone.
- REQUIRES_INTERFACE
- Specifies the interfaces that must be provided by other OSs, libraries, or drivers in the system.
- REQUIRES_OS
- Specifies the list of OSs with which the specified
library will work. For
example:
option REQUIRES_OS = (standalone xilkernel_v4_[0-9][0-9])The GUI tools use this option value to determine which libraries are offered for a given operating system choice. The values in the list can be regular expressions as shown in the example.
Note: This option must be used on libraries only. - HELP
- Specifies the HELP file that describes the OS, library, or driver.
- DEP
- Specifies the condition that must be satisfied before processing an entity. For example to include a parameter that is dependent on another parameter (defined as a DEP, for dependent, condition), the DEP condition should be satisfied. Conditions of the form (operand1 OP operand2) are the only supported conditions.
- INTERFACE
- Specifies the interfaces implemented by this OS,
library, or driver. It describes the interface functions and header
files used by the
library/driver.
BEGIN INTERFACE <interface name> option DEP=;<list of dependencies>; PROPERTY HEADER=<name of header file where the function is declared>; FUNCTION NAME=<name of the interface function>, VALUE=<function name of library/driver implementation> ; END INTERFACE - HEADER
- Specifies the HEADER file in which the interface functions would be defined.
- FUNCTION
- Specifies the FUNCTION implemented by the interface. This is a name-value pair in which name is the interface function name and value is the name of the function implemented by the OS, library, or driver.
- CATEGORY
- Defines an unconditional block. This block gets
included based on the default value of the category or if included in
the MSS
file.
BEGIN CATEGORY <category name> PARAM name = <category name>, DESC=<param description>, TYPE=<category type>, DEFAULT=<default>, GUI_PERMIT=<value>, DEP = <condition> option DEPENDS=<list of dependencies>, DRC=<drc name>, HELP=<help file>; <parameters or categories description> END CATEGORYNested categories are not supported through the syntax that specifies them. A category is selected in a MSS file by specifying the category name as a parameter with a boolean value
TRUE. A category must have a PARAM with category name. - PARAM
- The MLD file has a simple <name = value> format
for most statements. The PARAM keyword is required before every such
NAME,VALUEpair. The format for assigning a value to a parameter isparam name = <name>, default = value. ThePARAMkeyword specifies that the parameter can be overwritten in the MSS file. - PROPERTY
- Specifies the various properties of the entity defined
with a
BEGINstatement. - NAME
- Specifies the name of the entity in which it was
defined. (Examples:
paramandproperty.) It also specifies the name of the library if it is specified with option. - VERSION
- Specifies the version of the library.
- DESC
- Describes the entity in which it was defined.
(Examples:
paramandproperty.) - TYPE
- Specifies the type for the entity in which it was
defined. (Example: param) The following types are supported:
- bool
- Boolean (true or false)
- int
- integer
- string
- String value within “ " (quotes)
- enum
- List of possible values that a parameter can take
- library
- Specify other library that is needed for building the library/driver
- peripheral_instance
- Specify other hardware drivers that is needed for building the library
- DEFAULT
- Specifies the default value for the entity in which it was defined.
- GUI_PERMIT
- Specifies the permissions for modification of values.
The following permissions exist:
- NONE
- The value cannot be modified at all.
- ADVANCED_USER
- The value can be modified by all. The Vitis IDE does not display this value by default. This is displayed only for the advanced option in the GUI.
- ALL_USERS
- The value can be modified by all. The Vitis IDE displays this value by default. This is the default value for all the values. If GUI_PERMIT = NONE, the category is always active.
- ARRAY
- ARRAY can have any number of PARAMs, and only PARAMs.
It cannot have
CATEGORYas one of the fields of an array element. The size of the array can be defined as one of the properties of the array. An array with default values specified in the default property leads to its size property being initialized to the number of values. If there is no size property defined, a size property is created before initializing it with the default number of elements. Each parameter in the array can have a default value. In cases in which size is defined with an integer value, an array of size elements would be created wherein the value of each element would be the default value of each of the parameters.BEGIN ARRAY <array name> PROPERTY desc = <array description> ; PROPERTY size = <size of the array>; PROPERTY default = <List of Values for each element based on the size of the array> # array field description as parameters PARAM name = <name of parameter>, desc = "description of param”, type = <type of param>, default = <default value> ..... END ARRAY
MLD Design Rule Check Section
proc mydrc { handle } { }
The DRC function could be any Tcl code that checks your parameters for correctness. The DRC procedures can access (read-only) the Platform Specification Format database (which the tool builds using the hardware (XSA) and software (MSS) database files) to read the parameter values that you set. The handle is associated with the current library in the database. The DRC procedure can get the OS and library parameters from this handle. It can also get any other parameter from the database by first requesting a handle and using the handle to get the parameters.
For errors, DRC procedures call the Tcl error command error "error msg" that displays in an error page.
For warnings, DRC procedures return a string value that can be printed on the console.
On success, DRC procedures return without any value.
MLD Tool Generation (Generate) Section
proc mygenerate { handle } {
}
Generate could be any Tcl code that reads your parameters and generates
configuration files for the OS or library. The configuration files can be C files,
Header files, Makefiles, etc. The generate procedures can access (read-only) the
Platform Specification Format database (which the tool builds using the MSS files) to
read the parameter values of the OS or library that you set. The handle
is a handle to the current OS or library in the database. The generate procedure can get
the OS or library parameters from this handle. It can also get any other parameter from
the database by first requesting a handle and using the handle to get the parameter.