is set by the fact that the address must not cross a by 0co00L2

VIEWS: 4 PAGES: 72

									    Hardware /
Software Codesign
  Term Project :
   (1)AMBA BUS
  (2)Integration
  ARM and RTOS
•D90522024 劉志鵬
•F91522803   鍾書耘
                Agenda
• Why Need HW/SW Co-design?
  – What is our first step?
• AMBA BUS
• Conclusion 1
• ARM ADS and RTOS Integration
• Conclusion 2
   Why Need HW/SW Co-
         design?
• IC design has ushered in a new
 era – SoC
  – System on a Chip
   Why Need HW/SW Co-
         design?
• What is SoC?
    Why Need HW/SW Co-
          design?
• What is our first step?
  – Processor?
  – Memory?
  – Operating System?
  – Peripheral Interface?
  – CAD Tools?
  – What else?
      What is our first step?
• Core IP (Processor)
  – PC && Workstation
     • Intel Pentium
     • Ultra SPARC
     • MIPS
  – Micro-Controller
     • 8051
  – DSP
     • TI,
  – SoC
     • ARM
     • Power PC
     • Configurable Tensilica Processor
  – SOPC
     • Altera – Nios
     • Xillinx – Micro-Blaze
        What is our first step?
• Memories Design is our chance?
  – Process?
• Operating System is another opportunity?
  – PC & Workstation
    • Windows
    • Unix – Solaris, HP-Unix
    • Linux
  – RTOS
    •   eCos
    •   Micrium uC/OSII
    •   Shugyo Design  KROS
    •   Accelerated Technology  Nucleus Plus
    •   VxWork
  – Embedded System
    • Windows CE
    • uCLinux
    What is our first step?
• Peripheral IP Design is one way for
  us?
  – PrimeCell – ARM
  – Synopsys –
  – FPGA Vendor --
  – Open Core Web Site –
    www.opencores.org
  –. . .
• EDA CAD Tool?
  – Cadence
  – Synopsys
    What is our first step?
• Can We Find Our Way in SoC or HW/SW
  Co-design Era?
  – Master in applications
     • ASIC
     • SW
  – Time to Market is another important thing
     • Use Well-Design IP
     • Embedded Linux, RTOS
  – What else?
     • Integration
        – System is the keyword of SoC
        – How to transition from on-board design to on-chip
          design?
AMBA BUS
AMBA BUS
                 AMBA BUS
• AMBA Buses
  – Advanced System Bus (ASB)
  – Advanced High-Performance Bus (AHB)
    • Processors
    • On-Chip Memory
    • Off-Chip External Memory with low power peripheral
      macrocell
    • Bridge : to APB
    • High Speed ASIC – Your Design
    • …
  – Advanced Peripheral Bus (APB)
    • Peripheral Interface
       – UART
       – Timer
       – Low Speed ASIC – Your Design
           AMBA BUS
• Advanced High-Performance Bus :
  AHB
           AMBA BUS
• Advanced High-Performance Bus :
  AHB
         AMBA BUS  AHB
• Advanced High-Performance Bus : AHB
  – AHB master is able to initiate read and
    write operations by providing an address
    and control information. Only one bus
    master is allowed to actively use the bus at
    any one time.(max. 16)
  – AHB slave responds to a read or write
    operation within a given address-space
    range. The bus slave signals back to the
    active master the success, failure or
    waiting of the data transfer.
  – AHB arbiter ensures that only one bus
    master at a time is allowed to initiate data
    transfers.
AMBA BUS  AHB
AMBA BUS  AHB
        AMBA BUS  AHB
• Basic Transfer of AHB
       AMBA BUS  AHB
• Transfer Types of AHB
       AMBA BUS  AHB
• Burst Operation of AHB
             AMBA BUS  AHB
• Incrementing bursts access sequential locations and
  the address of each transfer in the burst is just an
  increment of the previous address.
   – An incrementing burst can be of any length, but the upper
     limit is set by the fact that the address must not cross a 1kB
     boundary
• For wrapping bursts, if the start address of the
  transfer is not aligned to the total number of bytes in
  the burst (size x beats) then the address of the
  transfers in the burst will wrap when the boundary is
  reached. For example, a four-beat wrapping burst of
  word (4-byte) accesses will wrap at 16-byte
           AMBA BUS  AHB
• There are certain circumstances when a burst
  will not be allowed to complete and therefore
  it is important that any slave design which
  makes use of the burst information can take the
  correct course of action if the burst is
  terminated early. The slave can determine
  when a burst has terminated early by
  monitoring the HTRANS signals and ensuring
  that after the start of the burst every transfer is
  labelled as SEQUENTIAL or BUSY. If a
  NONSEQUENTIAL or IDLE transfer occurs
  then this indicates that a new burst has started
AMBA BUS  AHB
AMBA BUS  AHB
       AMBA BUS  AHB
• HSIZE[2:0] of AHB
         AMBA BUS  AHB
• The protection control signals, HPROT[3:0]
  of AHB
       AMBA BUS  AHB
• AHB Bus Slave
       AMBA BUS  AHB
• AHB Bus Master
       AMBA BUS  AHB
• AHB Arbiter
       AMBA BUS  AHB
• AHB Decoder
          AMBA BUS  APB
• Advanced Peripheral Bus : APB
  – The AMBA APB should be used to interface to
    any peripherals which are lowbandwidth and do
    not require the high performance of a pipelined bus
    interface.
AMBA BUS  APB
            AMBA BUS  APB
• IDLE
  – The default state for the peripheral bus.
• SETUP
  – When a transfer is required the bus moves into the SETUP
    state, where the appropriate select signal, PSELx, is
    asserted. The bus only remains in the SETUP state for one
    clock cycle and will always move to the ENABLE state on
    the next rising edge of the clock.
• ENABLE
  – In the ENABLE state the enable signal, PENABLE is
    asserted. The address, write and select signals all remain
    stable during the transition from the SETUP to ENABLE
    state. The ENABLE state also only lasts for a single clock
    cycle and after this state the bus will return to the IDLE
        AMBA BUS  APB
• Write Transfer of APB
        AMBA BUS  APB
• Read Transfer of APB
       AMBA BUS  APB
• APB Bridge
       AMBA BUS  APB
• APB Slave
           Conclusion
• What do you want in SoC era?
 (2)Integrate uC/OS-II into
ARM Development Suite (ADS)

       D90522024 劉志鵬
       F91522803 鍾書耘
• Introduction to ADS
• Experiment 1
  – Analysis of ARM and Thumb instruction
• Experiment 2
  – Integrate UC/OSII into ADS
   ARM Development Suite
         (ADS)
• Project management
• Configuring the settings of build
  targets for project
The Structure of ARM Tools
    Main components of ADS
•   ANSI C compilers- armcc, tcc
•   ISO/Embedded C++ compilers – armcpp, tcpp
•   ARM/Thumb assembler- armasm
•   Linker – armlink
•   Project management tool – CodeWarrior
•   Instruction set simulator – ARMulator
•   Debuggers – AXD, ADW, ADU and armsd
•   Format converter – fromelf
•   Libarian – armar
•   ARM profiler – armprof
           CodeWarrier
• Provides a simple, versatile graphical
  user interface for managing your
  software development projects
• Develop C,C++, and ARM assembly
  language code
• Targeted at ARM and Thumb
  processors
Create New Project   Project File View




   Target Setting     Editor Window
                AXD
• Various views allow you to examine
  and control the processes you are
  debugging
                  ARMulator
• A suite of programs that models the behavior of
  various ARM processor cores and system
  architecture in software on a host system
• Can be operates at various levels of accuracy
  – Instruction accurate
  – Cycle accurate
  – Timing accurate
• Benchmarking before hardware is available
• Introduction to ADS
• Experiment 1
  – Analysis of ARM and Thumb instruction
• Experiment 2
  – Integrate UC/OSII into ADS
  Analysis of ARM and Thumb
        instruction(1/8)
ARM and Thumb code size
 Analysis of ARM and Thumb
      instruction(2/8)
The need for interworking

The code density of Thumb and its performance from narrow
memory make it ideal for the bulk of C code in many
systems. However there is still a need to change between
ARM and Thumb state within most applications:
•ARM code provides better performance from wide memory
•Some functions can be performed with ARM instructions
•Thumb programs will also need an ARM assembler header
to change state and call the Thumb routine
 Analysis of ARM and Thumb
      instruction(3/8)
 ARM/Thumb Interworking using ASM (no Veneer)

 1   AREA AddReg,CODE,READONLY ;Name this block of code.
 2   ENTRY                      ;Mark first instruction to call.
 3   Main
 4   ADR    r0,ThumbProg +1     ;Generate branch target address    ARM State
 5                              ;and set bit 0,hence arrive
 6                              ;at target in Thumb state.
 7   BX     r0                  ;Branch exchange to ThumbProg.
 8   CODE16           ;Subsequent instructions are Thumb code.
 9   ThumbProg
10   MOV    r2,#2               ;Load r2 with value 2.
11   MOV    r3,#3               ;Load r3 with value 3.             Thumb State
12   ADD    r2,r2,r3            ;r2 =r2 +r3
13   ADR    r0,ARMProg
14   BX     r0
15   CODE32           ;Subsequent instructions are ARM code.
16   ARMProg
17   MOV    r4,#4
18   MOV    r5,#5
19   ADD    r4,r4,r5
20   Stop                                                          ARM State
21          MOV       r0,#0x18 ;angel_SWIreason_ReportException
22   LDR    r1,=0x20026         ;ADP_Stopped_ApplicationExit
23   SWI    0x123456            ;ARM semihosting SWI
24   END                        ;Mark end of this file.
 Analysis of ARM and Thumb
      instruction(4/8)
ARM/Thumb interworking using ASM (using Veneer)
  Arm.s
   1       AREA    Arm,CODE,READONLY     ;Name this block of code.
   2       IMPORT ThumbProg
   3       ENTRY                         ;Mark 1st instruction to call.
   4   ARMProg
   5       MOV r0,#1                     ;Set r0 to show in ARM code.
   6       BL ThumbProg                  ;Call Thumb subroutine.
   7       MOV r2,#3                     ;Set r2 to show returned to ARM.
   8                                     ;Terminate execution.
   9        MOV r0,#0x18                 ;angel_SWIreason_ReportException
  10        LDR r1,=0x20026              ;ADP_Stopped_ApplicationExit
  11        SWI 0x123456                 ;ARM semihosting SWI
  12        END




 Thumb.s
  1    AREA Thumb,CODE,READONLY        ;Name this block of code.
  2    CODE16                          ;Subsequent instructions are Thumb.
  3    EXPORT ThumbProg
  4    ThumbProg
  5     MOV r1,#2                      ;Set r1 to show reached Thumb code.
  6      BX lr                         ;Return to ARM subroutine.
  7     END                            ;Mark end of this file.
 Analysis of ARM and Thumb
      instruction(5/8)
ARM/Thumb interworking using ASM (using Veneer)

 armsd: list 0x8000
 ArmProg
 0x00008000: 0xe3a00001      .... : >    mov        r0,#1
 0x00008004: 0xeb000005      .... :      bl         $Ven$AT$$ThumbProg
 0x00008008: 0xe3a02003      . .. :      mov        r2,#3
 0x0000800c: 0xe3a00018      .... :      mov        r0,#0x18
 0x00008010: 0xe59f1000      .... :      ldr        r1,0x00008018 ; = #0x00020026
 0x00008014: 0xef123456      V4..:       swi        0x123456
 0x00008018: 0x00020026 &... :           dcd        0x00020026 &...
 ThumbProg
 +0000          0x0000801c: 0x2102                  .! :         mov          r1,#2
 +0002          0x0000801e: 0x4770                  pG :         bx           r14
 $Ven$AT$$ThumbProg
 +0000          0x00008020: 0xe59fc000   .... :     ldr          r12,0x00008028 ; = #0x0000801d
 +0004          0x00008024: 0xe12fff1c              ../. :       bx           r12
 +0008          0x00008028: 0x0000801d   ....   :   dcd          0x0000801d ....
 +000c          0x0000802c: 0xe800e800   ....   :   dcd          0xe800e800 ....
 +0010          0x00008030: 0xe7ff0010   ....   :   dcd          0xe7ff0010 ....
 +0014          0x00008034: 0xe800e800   ....   :   dcd          0xe800e800 ....
 +0018          0x00008038: 0xe7ff0010   ....   :   dcd          0xe7ff0010 ....
 Analysis of ARM and Thumb
      instruction(6/8)
ARM/Thumb interworking using C/C++

     armmain.c
 1   #include <stdio.h>
 2   extern void thumb_function(void);
 3   int main(void)
 4   {
 5        printf("Hello from ARM\n");
 6        thumb_function();
 7        printf("And goodbye from ARM\n");
 8        return (0);
 9   }
10



     thumbsub.c
1    #include <stdio.h>
2    void thumb_function(void)
3    {
4        printf("Hello and goodbye from Thumb\n");
5    }
 Analysis of ARM and Thumb
      instruction(7/8)
                      Timing
Analysis Tool




    Code Size
                       Profiling
Analysis of ARM and Thumb
     instruction(8/8)
Performance
                   FDCT          FDCT
                 (ARM Code)   (Thumb Code)


Total ROM Size    25.46kB       22.13kB


  Total Cycle      592782        709741

Main program       9.46%         9.60%
  profiling



FDCT(ARM) : 執行速度快,大小適中。
FDCT(Thumb): 程式碼小,執行速度適中。
• Introduction to ADS
• Experiment 1
  – Analysis of ARM and Thumb instruction
• Experiment 2
  – Integrate UC/OSII into ADS
                 μC /OS-II
• Written by Jean J. Labrosse in ANSI C
• A portable, ROMable, scalable, preemptive, real-
  time, multitasking kernel
• shipped with ARM Firmware Suite (AFS).
• Portable 8 bit~64 bit
• ROMable small memory footprint
• Scalable select feature at compile time
• Multitasking preemptive scheduling, up to 64 tasks
 Integrate μC /OS-II into ARM
• uHAL is shipped in ARM Firmware Suite
• uHAL is a basic library that enables simple application to
  run on a variety of ARM-based development systems
• uC/OS-II use uHAL to access ARM-based hardware


   uC/OS-II & user application AFS Utilities


      uHAL routines / AFS support routines


                ARM-based hardware
      Resource management
To use a shared resource such as I/O port, hardware device or global
variable, you must request the semaphore from OS and release the
semaphore after access
Inter-Process Communication
        using Mailbox
In μC/OS-II, tasks are not allowed to communicate to each other
directly. The communication must be done under control of OS
through Mailbox
           Memory Management
In μC/OS-II, memory allocation is semi-dynamic. Programmer must
statically allocate a memory and partition the region using μC/OS-II
Kernel API. Tasks can only request pre-partitioned fixed-size memory
space from μC/OS-II
Setting up the ARMulator
The ARMulator can function as virtual
prototype to various ARM core and
development boards. However, the
original configuration of ARMulator
does not match that of ARM
Integrator/AP
            Building μC/OS-II
1.   Edit OS_CFG.C/ OS_CFG.H to customize μC/OS-II.

2.   Adding access path for ARMuHAL library
          Building μC/OS-II
3. Include uC/OS-II project and library

4. Include ARMuHAL project and library




                           ARMuHAL
                           uC/OS-II
      Building Program with
             μC/OS-II
•Create two tasks to perform inter-Process communication (IPC)
•Deliver the counting number by mailbox



  0                                                  <----Task1
  1                                                  <----Task2
  2                                                  <----Task1
  3                                                  <----Task2
  4                                                  <----Task1
  5                                                  ----Task2
  6                                                  ----Task1
    Main function
/* main function */
int main(int argc, char *argv[])
{
   /* do target (uHAL based ARM system) initialisation */
   ARMTargetInit();

    /* needed by uC/OS */
    OSInit();

    /* create message mailbox */
    Mbox12 = OSMboxCreate((void*) NULL);                    // initially, no message from task1 to task2
    Mbox21 = OSMboxCreate((void*) &token);                  // initially, a token is in mailbox so that


    /* create the tasks in uC/OS */
    OSTaskCreate(Task1, (void *)0, (void*)&Stack1[STACKSIZE - 1], 4);
    OSTaskCreate(Task2, (void *)0, (void*)&Stack2[STACKSIZE - 1], 3);

    /* Start the (uHAL based ARM system) system running */
    ARMTargetStart();

    /* start the game */
    OSStart();

    /* never reached */
    return(0);
}
void Task1(void *pata)
{
    INT8U err;
    int* info;                                                        Task1
    for(;;)
   {
       info = (int*) OSMboxPend(Mbox21, 0, &err); // wait for task2 to complete
       printf("Task1 called        %s\n",smile[*info]);
       count++;
       if(count>6)
       {
             printf("Task1 waiting...... ");
             scanf("%d",&stop );      // let the task1 wait for user information
       }
       OSMboxPost(Mbox12, (void*) &count);
   }
}



void Task2(void *pdata)
{
    INT8U err;                                                         Task2
    int* info;
    for(;;)
    {
             info = (int*) OSMboxPend(Mbox12, 0, &err); // wait message from task1
             printf("Task2 called  %s\n",smile[*info]);
             count++;
             OSMboxPost(Mbox21, (void*) &count);
    }
}
Result
            Conclusion
• As applications of the embedded
  systems become more complex, the
  operating system support and
  development environment became
  crucial. It can shorten the period of
  development. That is why we design
  the simple experiment for the project

								
To top