ESA 13345 : Building Blocks for System on a chipcontract
ESA 13345/#1 : Design of a VME Interface (EVI32)Final Presentation
Marc SOUYRI - Salvatore CATALANO – ASTRIUM SAS Velizy [email protected]
© Astrium2 ESTEC, 6 March 2001
l Study objectives- Contract History- Management objective of the study- Technical objective of the study
l Brief description of EVI32- Technical solutions used- EVI32 ERC Block Diagram and Interfaces- EVI32 timing performances
l EVI32 Development specificities- EVI32 Verification Strategy- EVI32 simulation with ERC32 SC microprocessor
l EVI32 project deliverables
Summary
THE OBJECTIVES OF EVI32 CONTRACT
© Astrium4 ESTEC, 6 March 2001
l EVI32 was developed in the frame of ESA 13345 contract called “BuildingBlocks for System on a Chip”.
l ESA 13345 contract is managed by Sandi Habinc at ESTEC. It includes :- #1 : development and Industrialization of an ERC32 VMEbus Interface Device- #2 : Initial Analysis of the Development of a System-On-a-Chip device- #3 : Development of a System-On-a-Chip device
l It was initially foreseen to use a VME interface within System-On-a-Chipbut this interface has been replaced by a PCI interface. Thus only thedesign of a packaged component remains from the initial project.
Contract history
© Astrium5 ESTEC, 6 March 2001
l Design and manufacture a first-time-right radiation tolerant ERC32VMEbus Interface for on-board application
l Ensure that the device is unrestrictedly available from the design house toEuropean industry at fair and reasonable pricing
l Ensure that the manufacturing foundry makes available and supports thedeveloped EVI32 device as an ASSP with a comprehensive data sheet
l Preferably use a European technology for foundry, with a process havingbeen approved or being considered for ESA/SCC Capability Approval
l EVI32 shall be based on the VHDL code provided by ESAl ESA shall have full ownership of the updated VHDL codel No validation of EVI32 at board level is performed in this study.
Management objective of the study
© Astrium6 ESTEC, 6 March 2001
l EVI32 shall fully adhere to IEEE 1014-1987 VMEbus standard- A32/A24/D32/D16/D8 master interface;- A24/D32/D16/D8 slave interface;- Interrupt handler;- Interrupter;- Single level arbiter (SGL);- VME bus timer;- Optimised D16 interface;- Four mailboxes for multi-processor communication;- On-chip error-detection.
l EVI32 shall be made compatible with :- ATMEL ERC32 3 chip microprocessor (TSC691E, TSC692E, TSC693E)- ATMEL ERC32 single chip microprocessor (TSC695E)- ATMEL 21020 DSP (TSC21020E)
l Radiation Tolerance shall be greater that 50 krads TD with a goodimmunity to SEU
Technical objective of the study
BRIEF DESCRIPTION OF EVI32
© Astrium8 ESTEC, 6 March 2001
l MG2RTP process of ATMEL was selectedl MG2RTP-142 matrix used - MQFPF 256 package
- 23138 gates used for 122128 available gates = 16.28 %- 256 pin used for 256 available pins- 224 signals, 4 power pins for core, 28 power pins for buffers
l All the functional D flip-flop are HDFF “SEU hardened D flip-flop”l Total Dose tolerance of EVI32 is over 100 krads and SEU immunity very
high
l No scan used, functional vectors + random vectors allows a faultcoverage over 100 %.
l JTAG Boundary Scan is implemented for board level testing
Technical solutions for process/matrix
EVI32 BLOCK DIAGRAM
JTAG
NOPARN
MASTER
CONF(1:0)
static pins to
configure
SEL16SCON
TDI
TRSTN
JtagTMSTDO
TCK
VME BUS
ERC/DSP Interface
VME Interface
MasterMode
Controller
Slave ModeController
MailboxManagement
Interrupthandler
/Interrupter
Arbiter/
VMETimer
Clock/
Resetmanagement
addata controls I/T
register
BUFFERS
EVI32 ERC SC INTERFACE
ERC32SC
EVI32
DMAGNTNDMAREQN
DM
AG
NT
*
VME BUS
NOPARN
CONF(1:0)
LOCK
RA
SI
LO
CK
WRTW
RT
LDSTO
DXFER
DX
FER
RL
DST
O
WEN
DRDYN
MEXC
WE
*D
RD
Y*
ME
XC
*
LA(31:0) LD(31:0)DPAR
DD
IR
BU
FFE
N*
DRA
oe*tr oe*tr
static pins to
configure
SEL16SCONMRSTIN
MRSTOUT
PRSTNSYSCLK
RE
SET
*SY
SRE
SET
*SY
SCL
K
power on resetR
SIZ
ER
DIO
SEL
(1)
INU
LL
EX
TIN
T
ASI
(3:0
)SI
ZE
(1:0
)
SYSAV
SYSA
V
DM
AA
DT
R
DM
AR
EQ
*R
APA
RR
ASP
AR
CPA
R
APARASPAR
IMPAR
RD
RSE
LN
INU
LL
LIR
Q(1
:0)
BU
SER
R*
BU
SRD
Y*
BU
SER
RN
BU
SRD
YN
addressbus
RAMmemory data
bus (0 ws)
DMAAS
DM
AA
S
TDI
TRSTN
JtagTMSTDO
TCK
IO andXtd data
bus
DD
IRIN
DD
IRO
UT
IOB
EN
IN
IOB
EN
OU
T
ALEN
AL
E*
DM
AA
DE
N
EVI32 VME INTERFACE
EVI32
VM
E B
US
DTACKINBERRINBBSYIN
BR3INSYSRESETIN
opencollector
buffer(xx621)
DTACKBERRBBSY
BR3SYSRESET
VIRQOUT[3:0]
DTACK*BERR*BBSY*BR3*SYSRESET*IRQ1*-IRQ7*
VIRQIN[7:1]
4
7
Bidirtristatebuffer
(xx245)
VA[31:1]
4
ABENABDIR
oe*tr
LWORDIACK
WRITE
VD[15:0DBLENDBDIR
Bidirtristatebuffer
(xx245)
16
oe*tr
VD[31:16DBHENDBDIR
IACKINIACKOUTBG3IN*BG3OUT*SCONACFAIL*SYSFAIL*
DSIN[1:0]VASIN
Bidirtristatebuffer
(xx245)
oe*tr
tristatebuffer
(xx244)oe*
DSOUT[1:0]
VASOUTASDSEN
2
tristatebuffer
(xx244)oe*ASDSEN
2
2 2DS0*-DS1*
AS*
AM01-AM05
31
LWORD*IACK*WRITE
D00-D15
D16-D31
IACKINIACKOUT
BG3INBG3OUT
SCONACFAIL
SYSFAIL
AM[5:0] 5 531
16
A01-A31
option for AS and DSsignals
allowing to reduce bufferbut not compliant with
VME standard
© Astrium12 ESTEC, 6 March 2001
l EVI32 can interface TSC21020 DSP
l DSP concept does not fit very well with VME :- Byte or 16 bit accesses are not implemented in DSP
- Data bus are 40 bit or 48 bit wide
- Address bus are only 25 bit wide for data and 20 bit wide for address
- Instructions and data paths are separated
l Limitations to VME interface have been performed in DSP mode :- In A32 and A24 addressing modes MSB bits are generated by EVI registers
- D8 and D16 accesses are controlled by decoding DMA[|21:19] and IOSEL_N
- Master accesses are mapped in DSP Data Space
- Slave accesses are mapped in Program Data Space
DSP Interface
© Astrium13 ESTEC, 6 March 2001
l in ERC32 3C mode, EVI32 speed is limited only by the speed of the uP(about 15 MHz)
l in ERC32 3C mode :- in master mode EVI32 runs at 25 MHz
- in slave mode EVI32 runs at about 20 MHz. Critical paths comes from theDMAAS signal that has the following characteristics :
- Setup time min 12 ns – setup time max ½ SYSCLK Period
l in DSP mode EVI32 runs at 15 MHz.
EVI32 timing performances
EVI32 DEVELOPMENT SPECIFICITIES
© Astrium15 ESTEC, 6 March 2001
l EVI32 development was based on ESA provided VHDL core
l EVI32 development method based on ESA requirement, butmodified to take into account that the core of the development wasnot performed by Astrium.
EVI32 development specificities
Obviously this is not a recommended design flow
=> Astrium put a large effort on model verification
© Astrium16 ESTEC, 6 March 2001
l An analysis of the code provided was done- By reading the VHDL model- By running checkers (as DC compiler, Prime Time, Star) on the synthetized
netlist to analyze paths between IO and registers, between IO and IO, andbetween registers, or design rule violations
l Comments were asked to ESA concerning specification and coding ofEVI32
l A writing of the Architectural report from the VHDL code was made
l Improvement of the model was made concerning VHDL coding rules, andthen modification of the model done.
EVI32 Verification of the model
© Astrium17 ESTEC, 6 March 2001
l A test plan was derived from EVI32 specification, VME standard, andprevious FPGA developed by ASTRIUM.
l A very large number of case has to be taken into account for the 3configurations :
- EVI32 master / slave- A32/A24/D32/D16/D8 type of exchange- Block transfer activated/or not- D16 interface activated / not- EVI32 interrupter / interrupt handler- EVI32 Arbiter / not- EVI32 in charge of VME timer function/ or not- EVI32 in slot1 , intermediate slot , end slot- plus error cases : non-response...
EVI32 Verification by Simulation (I)
© Astrium18 ESTEC, 6 March 2001
l For each of the 3 configurations (ERC 3C, ERC SC, DSP) EVI32 wassimulated with accurate models of the processors :
- ERC32 3 chip VHDL RTL model- ERC32 SC gate level model with its associated SDF file- TSC21020 gate level model and DPC companion ASIC VHDL model
l a VME checker written in VHDL and issued from our previous FPGAallows to check violations of the VME standard on the bus
l a VME spy written in VHDL allow to monitor trafic on the bus duringsimulations
l a VME remote slave written in VHDL is used to dialog with EVI32 in mastermode
l a VME remote master written in VHDL is used to dialog with EVI32 in slavemode
EVI32 Verification by Simulation (II)
© Astrium19 ESTEC, 6 March 2001
l 3 different configurations for ERC were coded in VHDL (in addition to ESAprovided testbench) :
l Conf M :- Slot 1 : ERC 3C or SC, RAM, ROM… + EVI32 acting mainly as master- Slot2 : VHDL remote slave- VME bus : VME checker, VME spy
l Conf S :- Slot 1 : ERC 3C or SC, RAM, ROM… + EVI32 acting mainly as slave- Slot2 : VHDL remote master- VME bus : VME checker, VME spy
l Conf 4EVI : test of IACK and Arbitration daisy chains- - Slot 1 : ERC 3C, RAM, ROM, + EVI32- - Slot 2 : ERC 3C, RAM, ROM, + EVI32- - Slot 3 : ERC 3C, RAM, ROM, + EVI32- - Slot 4 : ERC 3C, RAM, ROM, + EVI32
EVI32 Verification by Simulation (III)
© Astrium20 ESTEC, 6 March 2001
l About 12 complex sequences have been coded to test each mode. Eachsequence is composed of an Assembly program for ERC32 (or a Cprogram for DSP) and in case of slave test of a command file for theremote master.
l Testbench includes auto-check functions that verifies automatically mostof the functionality of EVI32
l Modelsim VHDL coverage tool was used to ensure that 100% of the modelinstructions are tested
EVI32 Verification by Simulation (IV)
© Astrium21 ESTEC, 6 March 2001
l Thanks to ATMEL Nantes a model of ERC32 SC has been delivered toAstrium to allow simulation. This model is a gate level model associatedwith its SDF file. It is compiled with a -nodebug option for Modelsim.
l ERC32SC model is very accurate, but long to simulate. Internal registersof EVI32 cannot be viewed during simulation.
l ERC32SC model generate a continuous flow of messages related tointernal violations in the model. These messages have to be filteredbefore checking Modelsim outputs.
l EVI32 functionality was first debugged with ERC32 3C model, and thentested with ERC32 SC model in order to save time
EVI32 simulation with ERC32 SC model
EVI32 DELIVERABLE STATUS
© Astrium23 ESTEC, 6 March 2001
l Timing have been added to EVI32 model following ESA recommendation
l EVI32 board level model has the same functionality as the component(except JTAG that is not included in the VHDL model), but has a limitedaccuracy in terms of timing
l A board level model of EVI32 is available upon request from ESA
l Warning : ERC32 SC model is delivered by ATMEL under specificconditions
EVI32 board simulation model
© Astrium24 ESTEC, 6 March 2001
l Delivery of prototypes planned for week 10
l Delivery of 5 EM planned in week 18
l Draft data sheet available from Astrium, will be put into ATMEL format
l Model available from ESA
EVI32 delivery schedule
© Astrium25 ESTEC, 6 March 2001
l EVI32 is manufactured, and will be available from ATMEL-WM
l EVI32 validation at board level has still to be made
l EVI32 study put in evidence the difficulty to base a space ASIC design ona code that has not been designed by the company.
l The ASIC methodology has to be modified and focused on verification :
- Specification review
- VHDL code analysis : by reading , with CAD tools
- Extraction of the Architecture from the VHDL code and analysis
- Generation of a simulation plan
- Simulation , code coverage
- Etc…
Conclusion