The Future of Software Development - Devin AI Innovative Approach.pdf
IEEE Paper A SystemC AMS Model of an I2C Bus Controller
1. A SystemC AMS Model
of an I2C Bus Controller
M. Alassir, J. Denoulet, O. Romain & P. Garda
Groupe SYEL - Laboratoire des Instruments et Systèmes d’Ile-de-France, LISIF
Université Pierre et Marie Curie, UPMC, Paris 6
3 Rue Galilée, BC252 - 94200 Ivry sur Seine, France
mdibassir@hotmail.com, Denoulet@lisif.jussieu.fr, Romain | Garda@lis.jussieu.fr
Abstract— We present the design of an Intellectual Property
(IP) modeling the interface controller for an inter-integrated
controller channel (I2C) bus. AMS IPs such as bus interfaces,
whose behaviour follows the bus protocols in terms of packet
structure, timing constraints or control modes can offer solutions
for the issue of communications between a System on a Chip and
its external environment. The model of our controller is written
in SystemC in association with a SystemC-AMS description of
the analog block. Simulation results are presented.
Keywords—model, simulation, SystemC-AMS, I2C controller
T
I. INTRODUCTION
HE recent technological advances have allowed the
development of complex Systems on a Chip (SoC) for
such diverse applications as smart sensors [1],
telecommunications or multimedia [2]. Most of these systems
integrate heterogeneous blocks such as micro processors
cores, digital signal processors, RAM/ROM memories, analog
to digital converters… Furthermore, communications between
a SoC and its environment often require the design of mixedsignal IPs (Intellectual Properties) such as bus interfaces
(IEEE1394, USB,…) or wireless transceivers [3] [4]
(IEEE802.11b, Bluetooth,…). However, few studies so far
have tackled the issue of the design and the modelling of bus
interfaces.
In order to bring solutions to the general problem of
external communications of a SoC, we first explored the
design of mixed IPs in SystemC 1.0 and VHDL-AMS. In
conjunction with our contribution to French national project
SOCLIB [5], consisting in an open-source library of digital
IPs in SystemC (CABA and TLM models), we now intend to
model mixed-signal IPs by using languages sharing a common
core. This paper introduces our approach with a model of an
I2C controller, where the digital part of the system is written
in SystemC 2.0.1 and the analog part in SystemC-AMS. The
choice of an I2C interface provides a number of advantages.
First of all, it features a simple example of a mixed-signal
interface, unlike other busses such as USB or IEEE1394.
Also, it is still often used in the embedded systems. We first
present the characteristics of the I2C protocol and the
controller, then focus on the modelling of the IP and show
simulation results.
II. I2C PROTOCOL & IP SPECIFICATION
A. Introduction
Historically, the first I2C controllers were designed in the
same time that the protocol by Philips at the beginning of the
nineties [6]. The I2C bus was designed to provide
communication on a two-wire bi-directional bus, a serial data
(SDA) and clock (SCL), between of small number of devices
(sensors, LCD, micro-controller,…). Each I2C device
integrates a controller typically composed of two distinct
blocks (Figure1); a digital block managing the protocol,
timing and control of specific sequences while an analog
block ensures the access to the I2C bus.
I2C Controller IP
SCL
Controller
Interface
Digital Block
µP
Analog Block
SDA
Fig. 1. I2C bus controller IP
B. Digital Block Specifications
1) Main Features: The technical characteristics of an I2C
bus controller IP are summarized in the following items:
• Compatible with Philips I2C standard
• Emulates the PCF8584 Philips component [PHIL]
• The controller bus interface is composed of two wires for
the bus: a data line SDA and a clock signal SCL.
• The parallel interface must be compatible with standard
micro-controllers / micro-processors (8051, Z80)
• Transfer frequency is up to 100 kbits/s for standard mode
• 7 bits addressing mode
2. • Start/Stop/Acknowledge generation and detection
• Arbitration management in multi-master mode, with
automatic transfer cancellation when arbitration is lost.
• Bus busy detection
2) Data Transfer Protocol and Data Frame: The data
transfer and frame generated by the IP designed respects the
following conditions:
• Transfers are initiated by a START condition It happens
when a falling transition occurs on the SDA line while
SCL is high.
• Transfers end with a STOP condition It happens when a
rising transition occurs on the SDA line while SCL is
high.
the clock on the data line.
• Electrical levels are compatible with MOS, CMOS or
bipolar technologies; for SDA and SCL, they are Vil max
= 1.5V, Vih min = 3V under 5V and Vol max = 0.4V
with 3 mA
III. DESIGN AND MODELLING OF THE IP
One of the issues in SoC design has been the multiplicity of
environments and modelling languages used to describe the
software and the hardware parts of the system but also its
digital and analog elements [7]. The emergence of SystemC
has provided an answer which is now being completed by the
development of a SystemC-AMS library [8]. With a
combination of both languages we will be able to design an
entire mixed-signal IP of the I2C bus interface with a common
language. As a result we chose SystemC 2.0.1 for the digital
block and SystemC-AMS for the analog block.
SCL
SDA
Start
Condition
Stop
Condition
Fig 2 : Start and Stop conditions
• Every transfer on the SDA line is a byte. MSBs are
transferred first.
• Data is considered valid during the high state of SCL. So
the SDA signal must remain stable during this period.
Data
valid
Data
valid
SCL
SDA
Fig 3 : Data validity period
A. SystemC model of the digital block
1) Architecture of the controller: Our model emulates the
behaviour of the PCF8584 Philips component [9]. We have
organised our design so that three major blocks appear (Fig 5).
• A micro-controller interface handles all data transfers
between the master and the I2C controller. It also
interprets the requests from the master (read data, write
data, controller configuration…) for the following blocks
of the architecture
• The core of the system is a sequencer which translates a
simple order coming from the master into a detailed
sequence respecting the I2C protocol (start bit, address
transmission, byte transmission or reception, etc…). It is
composed of a set of finite state machines.
• Finally, a signal generator module handles the behavior
of the SCL and SDA lines, according to the sequencer
commands.
• Data frame for the standard mode (transfer rate at 100
kbits/s) is composed of a start bit, 7 bits length of
address, a Read/Write bit, an acknowledge bit (ACK)
and data bits. A stop bit finalizes the transmission (Figure
2). Each bit is transmitted in conjunction with a clock
Start
Adress
R/W Ack
Data
Ack
Data
Ack Stop
Fig 4 : I2C data frame
C. Analog Block Specifications
The analog block’s main purpose is to perform a physical
access to the I2C bus for the digital signals. Its specifications
are as follows:
• AND logical function between the levels given by the
connected components on the bus
• Limitations function of electromagnetic field induced by
Fig 5 : Controller architecture
2) Digital model behavior: The micro-controller interface is
adapted to the 80C51 address/data multiplexed bus (Figure 6).
According to the ALE, RD, WR control signals, it stores
information in the address or data registers. Start and RW
signals are transferred to the sequencer to initiate a new I2C
communication.
3. Fig 8-b : Simulation results
Fig 6 : Micro-controller interface
B. SystemC-AMS model of the analog block
1) General architecture: The I2C protocol specifies that the
output stages of the devices must have open-drain or opencollector (depending on technology) in order to perform a
wired-AND function to manage a multi-master mode. Both
lines feature a pull-up resistor to VCC. Connections should be
made according to this electrical scheme in CMOS technology
(Figure 9):
Fig 7 : SDA line manager
The signal generator module performs the Start/Stop
condition and manages the Acknowledge generation/detection
depending on the operating mode (transmitter or receiver). A
shift register serializes data to be sent to the SDA line or
collects information from the bus in reception mode (Fig 7).
The module also manages the SCL line and generates a clock
signal by dividing the system clock by a user defined constant
that sets the transmission frequency.
3) Simulation results: The controller has been modelled in
SystemC 2.0.1. The simulation chronograms shown below
represent a reading of a slave peripheral. We first see the
emission of an 11-bit address add 12Dh (Figure 8-a). After a
new Start, the controller collects the data from the SDA line.
When the transmission is finished, the data (18h) is available
on the P0 port of the microcontroller (Figure 8-b).
Figure 9: Electrical scheme
In the sleep state, when transistors are not conductors, the
bus is not busy and both lines are released at the high level.
2) Model behavior: In the literature [10], there are a lot of
electrical circuits whose behaviour follow the above
characteristics. The choice depends essentially on some
parameters such as the bus rate, the distance between emitter
and receiver, the Electro Magnetic Compatibility…
We chose to model the analog block by using the following
electrical scheme (Figure 10) with the SystemC-AMS 0.13
library. Similar models are used for both SDA and SCL lines.
Fig 10: Electrical model used
Fig 8-a : Simulation results
4. This montage translates the signals SDA and SCL coming
from the digital block to voltages across the bus lines.
In this model, the transistor is represented with an
interrupter and resistor whose value depends on the voltage
across the SDA (SCL) line. A resistor and a 20pF capacitor
are used to manage the rising and falling times of the SDA
and SCL signals. Finally, a pull-up resistor sets the line at a
high state when no command is applied on the bus.
To read a value coming from the bus, a threshold detection
is applied to the SDA (SCL) line signal and provides a logical
value to the digital block.
3) Code Overview: There we present the code overview of
the part analogue which is shown in the Fig.10.
#include "systemc-ams.h"
data_conv1=new data_conv("data_conv1");
data_conv1->portin(sig_sdf);
data_conv1->portout(r_value);
c1=new sca_c("c1");
c1->value = 20.0e-12;
c1->p(out); c1->n(mass);
};
}
SC_MODULE (Part_Analog){
sc_in<bool> SDAout, SCLout;
sc_out<bool> SDAin, SCLin;
sca_elec_port SDA_out, SCL_out;
sca_elec_port mass;
SigConv
SigConv
SCA_SDF_MODULE(can){
sca_sdf_in<double> in;
sc_out<bool> out;
SCA_CTOR(can){}
void init(){ portout = 1.0e3;}
void sig_proc(){
portout_ = portin.read();
portout = portout_ * 3.0e2;}
SCA_CTOR(data_conv){}
SC_MODULE(SigConv){
sc_in<bool> sig_in;
sc_out<bool> sig_out;
sca_sdf_signal<double> sig_sdf;
sc_signal<double> r_value;
sc_signal<bool> sig_;
sca_elec_port out; //electrical node
sca_elec_port mass;
//reference node
sca_elec_node y;
//electrical node
sca_sc2r *r1;
sca_rswitch *sw1;
data_conv *data_conv1;
*GenSDA;
*GenSCL;
//SDA Signal Generation
GenSDA=new SigConv("GenSDA");
GenSDA->out(SDA_out);
GenSDA->mass(mass);
GenSDA->sig_in(SDAout);
GenSDA->sig_out(SDAin);
SCA_SDF_MODULE(data_conv){
sca_sdf_in<double> portin;
sc_out<double> portout;
double portout_;
};
//Elec Node
//Ref Node
SC_CTOR(Part_Analog){
void init(){}
void sig_proc(){
if(in.read() > 6.0) out = 1;
else out = 0;}
};
conv1=new sca_vd2sdf("conv1");
conv1->p(out); conv1->n(mass);
conv1->sdf_voltage(sig_sdf);
};
}
//SCL Signal Generation
GenSCL=new SigConv("GenSCL");
GenSCL->out(SCL_out);
GenSCL->mass(mass);
GenSCL->sig_in(SCLout);
GenSCL->sig_out(SCLin);
4) Simulation results: The chronogram below (Fig.11)
represents the behaviour of the analog SCL line according to
the command provided by the digital block of the IP. Visible
in this simulation are the rising and falling times of the I2C
signal due to the capacitor.
Analog
Value
sca_c
*c1;
sca_vd2sdf *conv1;
can
*can1;
SC_CTOR(SigConv){
Digital
Command
can1=new can("can1");
can1->in(sig_sdf); can1->out(sig_out);
sw1=new sca_rswitch("sw1");
sw1->off_val = true; sw1->p(y);
sw1->n(mass);
sw1->ctrl(sig_in);
r1=new sca_sc2r("r1");
r1->ctrl(r_value); r1->p(out); r1->n(y);
Fig 11: SCL Line Simulation
5. This next chronogram (Fig.12) represents the behaviour of
our controller (featuring the digital and the analog models)
during a data writing operation in a slave component. The
SCL and SDA lines are set according to the digital core
commands (see Fig. 8.a & 8.b).
The acknowledge bit is generated by a basic SystemC-AMS
slave model who handles the acknowledge phase of the
protocol and provides a sample data for reading operations.
Fig 12: Example of Simulation “Write byte to slave”
IV. CONCLUSION
We presented in this paper a model of a mixed-signal IP of
an I2C bus controller. Starting from the specifications of the
I2C protocol, we showed the design of the IP in SystemC and
SystemC AMS. Our simulation results show that the signals
generated are conform with the I2C protocol. We now intend
to add our model to the SOCLIB library in order to simulate it
as part of a much wider SoC architecture (including
microprocessors cores, memory, etc…) to certify its
reusability by other developers. Also, we are planning a
VHDL transcription of our controller to validate an
implementation of our structure.
The use of the SystemC-AMS library in our model
represents a first step to describe with a common language a
complete model of a mixed IP, in order to perform a full
system simulation. It also helps us to stress the interest of this
particular language, which could lead us in the direction of a
unique tool from the specification phase to the verification
phase of a mixed system.
REFERENCES
[1]
[2]
C.L. Britton et al.: MEMS Sensors and Wireless Telemetry for
Distributed Systems, Proc of The SPIE Fifth International Symposium
on Smart Materials and Structures, San Diego, CA, March 2, 1998
O. Pelc: An integrative Approach To Image Processing ang Control in a
Processor for Mobile Devices, in proc. of Global Signal Processing
GSPx, Santa Clara, CA, September 27-30, 2004
[3]
J. Oudinot, J. Ravatin and S. Scotti: Full transceiver circuit simulation
using VHDl-AMS, in proc. FDL'02, Esim, Marseille, France, Sept. 2427, 2002
[4] F. Op't Eynde and al.: A fully-integrated single chip SoC for Bluetooth,
in proc. of IEEE Int. Solid-State Circuits Conference - ISSCC 2001, Feb.
2001, pp. 196-197
[5] A.
Greiner
and
E.
Martin,
AS-SOCLIB
project,
http://www.comelec.enst.fr/rtp_soc/SOCLIB/fiche.html
[6] Philips Semiconductors: The I2C-Bus Protocol Specification, Document
Order
Number:
9398
393
40011,
January
2000,
http://www.semiconductors.philips.com/acrobat/literature/9398/3934001
1.pdf
[7] International Technology Roadmap for Semiconductors – Design, 2005
Edition, http://public.itrs.net
[8] C. Grimm, K. Einwich, A. Vachoux: Analog and Mixed and MixedSignal System Design Signal System Design with SystemC, FDL'04,
Lille, France, Sept. 13-17, 2004
[9] Philips Semiconductors: PCF 8584, I2C bus controller datasheet,
http://www.semiconductors.philips.com/acrobat/datasheets/PCF8584_4.
pdf
[10] D. Paret: Le bus I2C, de la théorie à la pratique, ISBN2100017179, ed.
DUNOD, Paris, 1993