— Embedded microprocessor boards and any circuit needing I2C
peripherals
Features:
— Fully optimized for Actel FPGAs
DATA_IN[7:0]
ADDR_IN[6:0]
TWSI_CMD[2:0]
CFG[127:0]
START
ENABLE
STDFAST_N
INTERFACE
CONTROL
LOGIC
SYNCHRS
SHIFTLGC
SCL_OUT
SDA_OUT
SCL_IN
SDA_IN
AT TOP LEVEL
SCL
SDA
— I2C-compatible two-wire serial interface core; I2C is a trademark
of Philips, Inc.
— Multi-master operation with arbitration and clock synchronization
— Slave transmit and receive operation
— Support for reads, writes, burst reads, burst writes, and repeated
start
STATE MACHINE
SHIFT
REGISTER
DATA_OUT[7:0]
(HOST DATA)
STATUS[5:0]
DATA_VLD
REQ_DATA
FIRST_BYTE
— User-defined timing and clock frequency
— Fast mode and standard mode operation
RESET
CLK
Targeted Devices:
— ProASIC
®
3 Family
— Axcelerator
®
Family
— ProASIC
PLUS®
Family
Core Deliverables:
— Netlist Version
Block Diagram
> Netlist compatible with the Actel Designer place and route tool
> Compiled RTL simulation model, compliant with the Actel
Libero® environment
— RTL Version
> VHDL or Verilog RTL Source Code
The MC-ACT-TWSI is a “core” logic module specifically designed for Actel FPGAs that
emulates the functionality of the industry standard two-wire serial interface, I2C. This
core does not support 10-bit slave addressing or START byte data transfers. It
facilitates upgrading current systems by allowing the designer to incorporate the
TWSI function as well as other logic into a single, state of the art FPGA. This core is
designed such that it can be instantiated into a Actel design and “hooked up” to I/O
buffers and pads and then compiled to make a device that will “plug in” to a TWSI
application. The core can be configured to operate as either a Master-Slave, Master-
Only, or Slave-Only.
> Test Bench
— All
> User Guide
> Data Sheet
Synthesis and Simulation Support:
— Synthesis: Synplicity
— Simulation: ModelSim
— Other tools supported upon request
Verification:
— Test Bench
Functional Description
The diagram on the first page shows the Block Diagram of the MC-ACT-16550 Core. The core is partitioned into modules. These modules are described below.
INTERFACE CONTROL LOGIC
The core is configured via a configuration vector (CFG[127:0]). This vector contains information required for proper operation of the core. The command vector input
(TWSI_CMD[2:0]) is used to instruct the core what operation to perform. The contents of the input and output vectors are as follows:
Configuration Vector
Applicable to the following core configurations:
Master-Only
Yes
The bits of the Configuration Vector are defined as follows:
Configuration Bits
CFG[6:0]
CFG[7]
CFG[19:8]
CFG[31:20]
CFG[43:32]
CFG[45:44]
CFG[46]
CFG[47]
CFG[48]
CFG[60:49]
CFG[72:61]
CFG[84:73]
CFG[127:85]
Description
TWSI Slave’s Own Address
Reserved
SCL BusFree (arbitration) Timer Value for Standard Speed
SCL HI Timer Value for Standard Speed
SCL LO Timer Value for Standard Speed
TWSI Mode (Master-Only, Slave-Only, Master-Slave)
Enable the SCL Glitch Filters
Enable two extra CLK periods of hold time on SDA from the falling edge of SCL.
Enable General Call Addressing
SCL BusFree (arbitration) Timer Value for Fast Speed
SCL HI Timer Value for Fast Speed
SCL LO Timer Value for Fast Speed
Reserved
Table 1: Configuration Vector
Command Vector
Applicable to the following core configurations:
Master-Only
Yes
The bits in this vector are defined as follows:
2
RESTART
1
STOP
Figure 1: Command Vector
These three bits of the command vector control the operation performed on the serial interface. The READ bit determines if the operation will be a read (high) or a
write (low). The STOP bit will determine if the cycle will stop at the end of the data cycle, or continue on to a burst. The REPEATED START bit will cause the genera-
tion of a repeated start protocol.
0
READ
Master-Slave
Yes
Slave-Only
Undefined
Master-Slave
Yes
Slave-Only
Yes
Address Vector
Applicable to the following core configurations:
Master-Only
Yes
The bits in this vector are defined as follows:
Master-Slave
Yes
Slave-Only
Undefined
6
ADDR_IN[6]
5
ADDR_IN[5]
4
ADDR_IN[4]
3
ADDR_IN[3]
Figure 4: Address Vector
2
ADDR_IN[2]
1
ADDR_IN[1]
0
ADDR_IN[0]
The address vector (ADDR_IN[6:0]) is written with the 7-bit I2C address that will be transmitted during the address phase of the I2C bus transaction.
Data Input Vector
Applicable to the following core configurations:
Master-Only
Yes
The bits in this vector are defined as follows:
7
DATA_IN[7]
6
DATA_IN[6]
5
DATA_IN[5]
4
DATA_IN[4]
3
DATA_IN[3]
2
DATA_IN[2]
1
DATA_IN[1]
0
DATA_IN[0]
Master-Slave
Yes
Slave-Only
Yes
Figure 3: Data Input Vector
The data input vector (DATA_IN[7:0]) is written with a byte that will be transmitted during the data phase of the I2C bus transaction.
Status Vector
Applicable to the following core configurations:
Master-Only
Yes
The bits in this vector are defined as follows:
Master Only
5
Not
Implemented
Master Slave
5
HDWE_GC
4
GC_RST
3
GC_ADDR
2
GC_BUSY
1
BUSLOSS
0
SLAVE
TIMEOUT
4
Not
Implemented
3
Not
Implemented
2
Not
Implemented
1
BUSLOSS
0
SLAVE
TIMEOUT
Master-Slave
Yes
Slave-Only
Yes
Slave Only
5
HDWE_GC
4
GC_RST
3
GC_ADDR
2
GC_BUSY
1
Not
Implemented
0
Not
Implemented
Figure 4: Status Vector
Bit 5 - HDWE_GC: Indicates the core has received the Hardware General Call instruction.
Bit 4 - GC_RST: Indicates the core has received General Call instruction to reset and change its address.
Bit 3 - GC_ADDR: Indicates the core has received General Call instruction to change its address.
Bit 2 - GC_BUSY: Indicates the core is busy with a General Call access.
Bit 1 - BUSLOSS: Indicates that this master lost the bus to another master before completion of the cycle.
Bit 0 - SLAVE_TIMEOUT: Indicates that the addressed slave did not respond with a nack when required.
Data Output Vector
Applicable to the following core configurations:
Master-Only
Yes
The bits in this vector are defined as follows:
Master-Slave
Yes
Slave-Only
Yes
7
DATA_OUT[7]
6
DATA_OUT[6]
5
DATA_OUT[5]
4
DATA_OUT[4]
3
DATA_OUT[3]
2
DATA_OUT[2]
1
DATA_OUT[1]
0
DATA_OUT[0]
Figure 5: Data Output Vector
The data output vector (DATA_OUT[7:0]) contains the data from the receive shift register
SHIFT REGISTER
There is a single parallel-in, parallel-out, serial-in, serial-out shift register called NUPSHIFT, which performs the shifting of data for address cycles, write cycles, and
read cycles. The parallel output drives the core interface pins DATA_OUT, which are used to return read data to the host.
SYNCHRS
The SDA and SCL inputs are passed through the Synchrs module that performs a dual-rank synchronization and glitch filtering when enabled by bit 46 of the configu-
ration vector (CFG[46]).
The MC-TWSI core treats both the SDA and SCL lines as data lines. The SDA line is actually sampled some number of clocks after the rising edge of SCL is de-
tected. This allows for greater noise immunity and more robust operation.
STATE MACHINE
The control for the serial interface comes from the TWSI_SM_M, TWSI_SM_S, and GEN_CALL_SM state machines. These state machines control the loading and
enabling of all shift registers and counters, and are responsible for implementing the basic interface protocol.
Arbitration
Before the MC-TWSI initiates either a start or repeated start condition, it samples the synchronized versions of SDA and SCL for BUSFREE_COUNT x clock periods
of high values. If at any time either of these pins is detected in a low (driven) state, then the count starts over (it assumes that another master is on the bus). The
automatic retrying to obtain the serial bus only occurs until the start command is issued. After that, the responsibility of the retry is left to software, since cycles may
be of infinite length.
After a start is issued and while the address or data is being written to the slave, the macro samples the data on the SDA pin while SCL is high. If a data mismatch is
detected then the operation is aborted with an interrupt and a BUSLOSS status. This can also occur during burst reads whenever a NACK is intended to be issued
and an ACK is detected instead.
SHIFT LOGIC
The basic cycle on the TWSI serial interface consists of an address cycle followed by data cycle(s). The address consists of seven bits and the read/write bit (the
LSB). The MSB is always transmitted first on the SDA line. The data cycle can either be a read or a write. For a write operation, the core shifts the data from the
DATA_IN Register onto the SDA line. For a read operation, the core captures the data into the Shift Register. The host can read the Shift Register contents via the
DATA_OUT Register. The data cycle can end in three different ways:
1. A stop can be generated which terminates the current cycle
2. Another data cycle can take place (a burst)
3. A repeated start can be generated by the interface
For each byte read, DATA_VLD will be asserted for one clock to tell the host that valid data is on DATA_OUT. For each byte written, REQ_DATA will be asserted for
one clock to ask the host for another byte of data to send.
A repeated start is used to turn the bus around; when a read cycle must be followed directly by a write cycle without a stop in-between. Since the READ bit is a part
of the address, if a read followed by write is desired without a stop command, a second address must be issued following the data cycle. The sequence of events in a
repeated start cycle is: start, address cycle, data cycle, repeated start, address cycle, data cycle, stop. Each of the data cycles can be repeated if bursting is desired,
and the stop cycle could actually be another repeated start, if desired.
GENERAL CALL ADDRESSING
The General Call Address is used to address and send data to every node on the I2C bus and is enabled by bit 48 of the configuration vector (CFG[48]). Not all
devices are required to support General Call. Nodes not requiring the data sent within a General Call data transfer can ignore the transfer by not acknowledging the
address. If a node does require the data sent with a General Call it will acknowledge the address and behave as a slave receiver for the subsequent bytes. If any
given slave cannot process any of the subsequent bytes during the transfer, it must ignore the byte by not acknowledging. The behavior for a General Call transfer is
specified in the second byte, and is determined by the LSB.
When the LSB of the second byte is a ‘0’, the second byte can have the following definition:
“00000110” (H’06’) – Write the slave address (the third byte to be sent) and then reset. All devices receiving this two-byte sequence will treat the third byte to be sent
as their new I2C address and will then reset. Care must be taken by the slave nodes not to drive (pull down) the SDA or SCL lines while resetting to avoid blocking
the bus.
“00000100” (H’04’) – Write the slave address (the third byte to be sent) and do not reset. All devices receiving this two-byte sequence will treat the third byte to be
sent as their new I2C address. The node will not reset.
“00000000” (H’00’) – This byte is not allowed to be sent as the second byte.
All other bytes in the second byte of the transfer have not been specified and nodes are generally required (per the Philips I2C specification) to ignore them.
When the LSB of the second byte is a ‘0’, the second byte will be a ‘Hardware General Call’. This means that a master node on the I2C, which cannot be pro-
grammed to send a specific slave address, needs the attention of another node to facilitate a transfer. This is typical of embedded hardware nodes such as keyboard
scanners. Since a hardware master can’t be programmed to address a specific node to which it needs to transfer data, it can only initiate a General Call followed
by its own address to identify itself to the system. The seven upper bits of the second byte contain the address of the hardware master. An intelligent device then
recognizes this address on the I2C bus, which will direct the information from the hardware master.
京公网安备 11010802033920号
EEWORLD
