Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "DSDP/RTSC - xdc.platform.ICpuDataSheet"

m
Line 70: Line 70:
 
*a instance of the named module
 
*a instance of the named module
  
The keys of the peripheral map might be the device-specific names for the peripherials.  
+
The keys of the peripheral map might be the device-specific names for the peripherals.  
  
 
Since each peripheral is an instance of a module, it can maintain "ownership" information and enforce the constraint that only one package may claim control of the peripheral.  This will prevent applications from trying to use HW already managed by high-level packages.
 
Since each peripheral is an instance of a module, it can maintain "ownership" information and enforce the constraint that only one package may claim control of the peripheral.  This will prevent applications from trying to use HW already managed by high-level packages.
 +
 +
The structure proposed above would look like this:
 +
{{codeblock|
 +
    struct Peripheral {
 +
        string name; //"Timer", "Cache", "Interrupts"
 +
        UInt baseAddr;
 +
        Peripheral.Attrs attrs {intNum, ...};
 +
        Peripheral.Instance inst; // Timer.Instance
 +
    }
 +
}}
 +
(Peripheral wouldn't be an actual struct, but an interface.)
 +
 +
The config parameter <tt>Program.cpu.attrs.peripherals</tt> would be defined as:
 +
{{codeblock|config Peripheral[string]}}.
 +
The device-specific peripheral names would be used as keys.
 +
 +
Do we need any functions (<tt>Program.cpu.attrs.getPeripherals(some search params)</tt>?
  
 
The interface ILM3Sx9xx in ti.catalog.arm package defines timers using the following structure:
 
The interface ILM3Sx9xx in ti.catalog.arm package defines timers using the following structure:
Line 87: Line 104:
 
{{codeblock|<pre>config Timer timers[4] = [...];</pre>}}
 
{{codeblock|<pre>config Timer timers[4] = [...];</pre>}}
  
The users access the array through <tt>Program.cpu.attrs.$orig.timers</tt>.
+
The users access the array through <tt>Program.cpu.attrs.$orig.timers</tt>. <tt>ICpuDataSheetInstance attrs</tt> already exposes some of the information provided by the datasheet for the device, so the peripherals could fit here as well.
 +
<tt>Program.cpu.attrs</tt> should be <tt>$orig</tt> already, so the users do not need to know about that detail. Then, we could have a map <tt>Program.cpu.attrs.peripherals</tt>.
 +
 
 +
 
  
 
== Resources  ==
 
== Resources  ==

Revision as of 15:50, 17 December 2009


Introduction

The current RTSC platform model contains a description of the hardware (HW) as a part of the configuration model.  This part of the model - accessible via Program.cpu - allows portable XDCscript code to reflect on the specific HW and conditionally generate results that are platform-specific.

Although the current HW model provides specific device information and a complete memory map as seen by executing applications, it does not currently provide a way to identify peripherals that are part of the device; e.g., what types of peripherals (timers, serial ports, ADCs, etc.) are present, how many exist, their base addresses, and any device specific attributes associated with these peripherals).

Goals

Extend the platform model to include a notion of a "peripheral" and augment the existing platform packages to include sufficient information to enable "automatic" configuration of peripheral drivers.  Automatic configuration implies:

  • user rarely needs to add device specific configuration statements
  • peripheral drivers can get information from the platform model (that is "implied" by the HW platform) sufficient to eliminate the need for internal tables of specific devices
  • the ability to detect conflicting/overlapping "ownership" of peripherals by separate runtime packages ensuring all software drivers operate properly without conflict

Requirements

Automatic configuration of

  • ti.sysbios timers and
  • ti.sdo.ipc.Sem

Example

PSP drivers maintain this monster table which is referenced in the Mod.xs files. All this information probably belongs in the catalog.

Here is an example from Uart.xs (Soc.zip - soc.xs)

var soc = xdc.loadCapsule("ti/psp/cslr/soc.xs");

/*
 *  ======== module$use ========
 */
function module$use()
{
    Uart = this;
    IDriver = xdc.module("ti.sdo.io.IDriver");
    DriverTypes = xdc.useModule("ti.sdo.io.DriverTypes");
    Semaphore = xdc.useModule("ti.sysbios.ipc.Semaphore");
        
    if (!(Program.cpu.deviceName in soc.deviceTable)) {

        Uart.$logError("Unsupported device",this, Program.cpu.deviceName);
    }
    else {
        var uarts = soc.deviceTable[Program.cpu.deviceName].uarts;
                   
        Uart.numInstances = uarts.length;
        Uart.defaultDeviceInfo.length = uarts.length;

        for (var i = 0; i < Uart.numInstances; i++) {   
            Uart.defaultDeviceInfo[i].baseAddress = uarts[i].baseAddress;
            Uart.defaultDeviceInfo[i].cpuEventNumber = uarts[i].cpuEventNumber;
            Uart.defaultDeviceInfo[i].rxDmaEventNumber = uarts[i].rxDmaEventNumber;
            Uart.defaultDeviceInfo[i].txDmaEventNumber = uarts[i].txDmaEventNumber;
            Uart.defaultDeviceInfo[i].inputFrequency =  uarts[i].inputFrequency;
        }
    }
}

Sketch

The following notes sketch the current thinking.

ICpuDataSheet would include a map of peripherals, say xdc.platform.IPlatform.Peripheral, were each peripheral would be a structure containing a name, base address, and an arbitrary hash of device specific attributes.

  • name would name a RTSC module that identifies the HW peripheral
  • the base address would be a device
  • the attrs hash would contain attributes such as interrupt id
  • a instance of the named module

The keys of the peripheral map might be the device-specific names for the peripherals.

Since each peripheral is an instance of a module, it can maintain "ownership" information and enforce the constraint that only one package may claim control of the peripheral.  This will prevent applications from trying to use HW already managed by high-level packages.

The structure proposed above would look like this:

   struct Peripheral {
       string name; //"Timer", "Cache", "Interrupts"
       UInt baseAddr;
       Peripheral.Attrs attrs {intNum, ...};
       Peripheral.Instance inst; // Timer.Instance
   }

(Peripheral wouldn't be an actual struct, but an interface.)

The config parameter Program.cpu.attrs.peripherals would be defined as:

config Peripheral[string]
.

The device-specific peripheral names would be used as keys.

Do we need any functions (Program.cpu.attrs.getPeripherals(some search params)?

The interface ILM3Sx9xx in ti.catalog.arm package defines timers using the following structure:

   struct Timer {
   	string	name;
       UInt	baseAddr;
       UInt	intNum;
   };

and then an array of such objects is defined in the interface:

config Timer timers[4] = [...];

The users access the array through Program.cpu.attrs.$orig.timers. ICpuDataSheetInstance attrs already exposes some of the information provided by the datasheet for the device, so the peripherals could fit here as well. Program.cpu.attrs should be $orig already, so the users do not need to know about that detail. Then, we could have a map Program.cpu.attrs.peripherals.


Resources

RTSC Platform Model Reference - the reference API for the current platform model

Soc.zip - full PSP example text



Back to the top