A Methodology to Develop the Application Faster in Automotive Field

Shaila Ramreddy1, prof.Shantharam Nayak2

1 M.Tech (IT) 4th SEM, ISE dept, RVCE, Bangalore - 560059

2Professor, ISE dept, RVCE, Bangalore - 560059

1 ,

ABSTRACT- Today’s system design is much more complex and challenging. Verification of such complex designs results in increasing the verification effort at different cycles and the simulation time. The deployment for early development usage of virtual platform on the verification and architectural exploration are in place and the challenges on the early software development. This problem still persist on the automotive applications with respect to time to market and complete use case solutions. This paper deals with the sub-system based solution, was proposed at the verification and also for the software/application development with the help of existing stimulus of clock and reset, interrupt handling and register based mechanism. This brings faster solution with the help of specific system with the integration for the early use case algorithm development.

Keywords-Virtual System Prototype, TLM, Bus Functional Module, Bus, Reuse, sub-system.

I.  Introduction

Time-to-market pressure and productivity gap are two factors that encourage the Electronic Design Automation (EDA) industry and researcher of embedded system to enhance embedded system design method [1]. The Register Transfer Level (RTL) abstraction layer is accepted as the abstraction layer for describing hardware designs [2]. However, the vendor and researcher community is again pushing the abstraction layer a notch higher by promoting the electronic system level (ESL) [3] layer for addressing the lack of scalable tools and design methods. SystemC Transaction Level Modeling (TLM) is a way defining above RTL for modeling and simulation of embedded software systems [4]. The growing consumer demands for various complex applications led to pressure on vendor to design, implement embedded system in short time frame. The late entry to market means cost or opportunity loss. This condition is called time-to-market pressure for embedded system vendor. It needs shorter design process approach. Today for any product time-to-market plays an important role in the economy; it can be reduced by reuse techniques at various levels in the chip design flow.

In parallel to RTL development, before the actual start of verification cycle, the fully verified virtual prototype (transaction-level model) is available for architecture exploration and early software development. Depending on the given use case and specific requirements virtual prototype is developed.

The challenges at the complete design cycle are architectural exploration, verification at different level (pre-silicon and post-silicon) and the software development for the system along with different applications. However the first two challenges are taking into account. Even though VSP is present for early software development, but when we consider a software guy for him/her it is not possible to start the software application development until the complete system proof is accepted. This methodology mainly focused on this challenge.

This paper is proposed for the automotive application platforms with the usage of virtual platform. The virtual platform was used for the software development once the complete system is ready approximately 6 months before the silicon. Currently the platform helps in brining the software, development was application and OS. But still the concept of application bring-up needs still early development at the software level than HW-SW architecture exploration. This methodology brings the concept proven at the early stage when the use case based IP was already implemented and before it ready for the virtual platform integration. This methodology also helps in verifying the IP at the early stage if there are use case related issues.

The development and the verification activities are:

1) Bus functional model – without core and use the register mechanism.

2) Bus arbitration and Decoding.

3) Clock, Register Interface and Interrupt handling for the sub-system IP’s.

4) Specific protection mechanism.

The organization of the paper is as follows; Section II provides some basic definitions. Section III discuses on methodology implementation, in which BFM, Bus modeling and about specific protection mechanism are explained. Section IV discusses about conclusion. Finally section V provides the future work.

II.  basic definitions

·  Virtual System Prototype

Today’s complex designs, especially those targeted to deep submicron technologies, demand a good methodology at all stages of the design cycle in order to meet the quick turnaround requirements. The concept of VSP is based on creating a software model of the entire hardware system including external components. This model can be used to explore and analyze different architectures. Once an optimal architecture has been chosen, the same model can be used as an executable specification. HW design teams can use the VSP as a golden reference model against which they can verify the functionality of different modules and/or subsystems in the design. SW teams can use VSP to start their development work, as soon as the architecture is defined and the corresponding VSP is available[5]. VSP is one of the methods that can help in improving the product development time as shown in figure 1.Lines in this figure represent the possible redesign feedback paths, with dashed lines representing rare paths. With the VSP based flow, one can get system validation capabilities much early in the development cycle. These capabilities include:

1)  Identifying system issues up-front in the cycle by performing system simulations even before the Silicon is made available.

2)  As it is still a soft model, debug capabilities of the test framework will be much more powerful than the test framework with the actual Silicon.

3)  One can use a combination of different abstractions during the development phase.

Figure1: VSP Concurrent Execution

·  Transaction Level Modeling (TLM) using SystemC

Transaction-level Models fill the gap between purely functional descriptions and Register Transfer Level (RTL). They are created after hardware/software partitioning. The main application of Transaction Level Modelling (TLM) is to serve as a virtual chip (or virtual platform) on which the embedded software can be run. The main idea of TLM is to abstract away communication on the buses by so-called transactions. Instead of modeling all the bus wires and their state change, only the logical operations (reading, writing etc) carried out by the buses are considered in the model as shown in Figure 2. There are several TLM standards [5], for instance, loosely-timed- coding style is appropriate for software development, approximately-time- coding style is appropriate for architectural exploration and performance analysis and many other level of accuracy are mentioned.

VSP based on Transaction Level Modeling (TLM) has become a de-facto standard in today’s complex SoC designs [6]. A Transaction is defined as the Communication between concurrent processes using function calls. In Register Transfer Level (RTL) the communication happens by the signal protocol, here while communicating between two processes all the signals communicates separately [3]. The main idea of TLM is to abstract away communication on the buses by so-called transactions. Instead of modeling all the bus wires and their state change, only the logical operations (reading, writing etc) carried out by the buses are considered in the model as shown in Figure 1. In contrary to the RTL, where everything is synchronized on one or more clocks (synchronous description), Transaction Level (TL) models do not use clocks. They are asynchronous by nature, with synchronization occurring during the communication between components. These abstractions allow simulations multiple orders of magnitude faster than RTL. The other advantage of TL models is that they require far less modeling effort than RTL or than Cycle Accurate model. This modeling effort is further reduced when there already exists a C/C++ functional code for the processing done by the hardware block to model. For instance, one can reuse the reference code for a video decoder or for a digital signal processing chain to produce a TL model. Unlike a Cycle Accurate model, which is no longer the reference after RTL is created, TLM is by this means an executable, “golden model” for the hardware.

Figure 2: Communication in TLM and RTL

A transaction term is an atomic data exchange between an initiator and target. The initiator has the initiative to do the transaction whereas the target is considered as always able to receive it (at least, to indicate to the initiator that it is busy). This corresponds to classical concepts in bus protocols. The initiator issues transactions through an initiator port and a target receives them by a target port. Some components only have initiator ports some have only targets ports. Also, some components contain both initiator and target ports.

III.  Methodology

The architecture of the proposed sub-sytem is as shown in figure 3.

Figure 3: SubSystem Architecture

A.  Bus Functional Module

A bus functional module is a model that provides a task or procedural interface to specify certain bus operations for a defined bus protocol. The transactions usually take the form of read and write operations on the bus. BFMs are often used as reusable building blocks to create simulation test benches. Bus functional models are easy to use and provide good performance. Purpose of BFM is to gain simulation speed, ease of use, and ease of creation.

B.  Bus modeling

The Peripheral Bus (PB) connects the bus functional module to the medium and low bandwidth peripherals. OSCI Transaction Level Modeling (TLM) library has been used for standard bus communication between the peripherals modules in order to maintain interoperability between different bus models. The bus supports non-blocking read/write transactions. Bus model normally does the address decoding and the arbitration according to the actual application (means the system architecture)

The process is made active at falling clock edge. Handling of the requests: A request can result in different requests to slaves. A slave can take several cycles to complete: each time the request has to be re-issued to the slave. Once the slave transaction is completed, the current request is cleared, and the request form is update.

When current request is clear, the next request is selected. This can be the same one, if the transfer is not completed (burst-mode), or it can be a request with a higher priority. Intrusion to a non-locked burst-mode transaction is possible.

When a transaction sets a lock, then the corresponding field in the request is set to BUS_LOCK_SET. If the locked transaction is granted by the arbiter for the first time, the lock is set to BUS_LOCK_GRANTED. At the end of the transaction, the lock is set to BUS_LOCK_SET. If now a new locked request is made with the same priority, the status of the lock is set to BUS_LOCK_GRANTED, and the arbiter will pick this transaction to be the best. If the locked trans-action was not selected by the arbiter in the first round (request with higher priority preceded), then the lock is not set. After the completion of the transaction, the lock is set from BUS_LOCK_SET (set during the bus-interface function), to BUS_LOCK_NO.

C.  Specific protection mechanism

The value written into module registers should be written by either application or driver, some of the registers do not allow the application to write. All these protections are taken into care as like actual system architecture. The mainly used protection mechanisms are supervisory mode, user mode, master tag id, safe-endinit mode and endinit mode.

IV.  CONCLUSION

While designing a system, in order to reduce the system design cycle and simulation time bus functional model is used instead of core (Tricore, Infineon product) and only application specific peripheral devices are used like pulse width modulation and analog to digital converter.

By using this methodology at the end we will be able to 1) creating an infrastructure for early application development while the product development is on-going and can be reusable across the system. 2) Obtaining an easily pluggable application code while Core and other IPs or Peripherals are not available and to have a similar frame work in developing the application with specific use case. 3) Interoperability and 4) Design feedback at very early stage before the system proof is accepted.

V. FUTURE WORK

Presently the developed software package is tested with specific peripheral devices (ADC and PWM) which are used in motor applications. In future this software package will be enhanced further to support any number of peripheral devices and more applications.

ACKNOWLEDGEMENT

We would like to thank Prasanth Sasidharan (IFIN ATV C-MODEL), Prasanna Kesavan (IFIN ATV C-MODEL) for their technical support.

REFERENCES

[1]  Avss, P.; Prasant, S.; Jain, R.; “Virtual prototyping increases productivity - A case study” Proc. Int’l Sypm VLSI Design Automation and Test, 2009 (VLSI – DAT”09), PP, 96-101. DOI-10.1109/VDAT.2009.5158104

[2]  “ITRS 2011 Roadmap (System Drivers) “

[3]  Stehr G.,Eckmuller J., “Transaction level modeling in practice: motivation and introduction”, proc., Computer-aided design (iccad), 2010 IEEE/acm International conference, pp 324-331

[4]  Maman Abdurohman et al., “Transaction Level Modeling for Early Verification on Embedded System Design” 2009 Eight IEEE/ACIS International Conference on Computer and Information Science, DOI 10.1109/ICIS.2009.41

[5]  OSCI Standard, OSCI TLM-2.0 Language Reference Manual. Open SystemC Initiative, 2009.

[6]  Wolfgang Ecker, Volkan Esen, Michael Velten.” TLM+ Modeling of Embedded HW/SW Systems” Infineon Technologies AG, Germany. EDAA-2010 /978-3-9810801-6-2/DATE10

[7]  http://www.itrs.net/

[8]  http://www.design-reuse.com