Transcript Deep Space Transponder ASIC for BepiColombo

DST ASIC
(Deep Space Transponder ASIC)
for BepiColombo
Template reference : 100181703F-EN
Microelectronics Presentation Days 2010
ESTEC - March 30, 2010
David J. Fiore
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST ASIC Presentation Overview
Page 2
 DST ASIC Project Overview

Overall and specific technical goals

SOC design strategies
 DST ASIC Architecture Overview

DST ASIC general information

DST ASIC block diagram

LEON2-FT Implementation

LEON2-FT Peripheral Implementation
 FPGA Prototyping
 Project Experiences

Achievements

main problems found

lessons learnt
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST ASIC Overall Technical Goals
Page 3
 The DST ASIC represents the signal processing core of the
new generation Deep Space Transponder equipment
whose first application will be in the frame of the
BepiColombo program.
 Operative threshold: down to -150 dBm
 Fully configurable telecomm. and telemetry (multistandard)
 Doppler shift up to 1 MHz
 Frequency band (up/down): S, X, Ka
 Accurate ranging (standard and regenerative): better
than 1 m
 Coherent and non-coherent operation
 Output power: up to +12 dBm
BepiColombo Deep Space Transponder (EM)
 The design includes all the functions needed for carrier recovery and data demodulation on
the receiver side, and advanced design schemes needed to support several modulation
formats in order to improve the space-to-earth link performance, on the transmitter side.
 The foreseen integration of the LEON2FT Microprocessor (ESA IP) within the DTS ASIC,
allows a full programmability and control of the TTC modem in the context of the most
advanced space applications and recently issued standards.
 The Leon2FT Microprocessor (ESA IP) implements a 32-bit processor conforming to
the IEEE-1754 (SPARC V8) architecture.
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST ASIC Specific Technical Goals
Page 4
 The DST ASIC includes a complete set of digital processing functions to cover all TT&C
standard (FM, PM, spread-spectrum, deep-space).
 Gated clocks (7) for each DSP function (AHB Slaves) are used to reduce power
consumption in the different configurations)
Demodulated Telecommand
DST ASIC
Carrier Demodulator
Processor
SpreadSpectrum
Receiver
From
ADC
Baseband
Processor
LEON2 RT
Command
Demodulator
Carrier Modulator
Processor
TLM Stream’s
Spread-Spectrum
Ranging
Processor
Standard
Receiver
(PM/FM)
Ancillary
Functions
Standard
Ranging
Processor
MUX
DDS
Modulator
To
DAC’s
Operational Mode
(Standard/Spread-spectrum)
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST ASIC SOC Design Strategies
Page 5

Keep as much of the ESA LEON2 IP package “as is” (try to utilize the same blocks and same
configurations - change as little as possible!).

This is very useful when using the supplied overall testbenches and for debugging in general. (there
is a “default” LEON platform to compare results against.)

Blocks that utilize the same clock frequency as the LEON2/AMBA, will be implemented as APB slaves.

Blocks that utilize clock frequencies different than the LEON2/AMBA, will be implemented as AHB slaves.



Utilize the wait states to hold the transaction until re-synchronization is complete.

This re-synchronization is completely decoupled from the AMBA bus and does not involve any handshaking – it is completely managed by a circuit using the same clock frequency as the LEON
configured with pre-determined number of wait states.
Design a standard AHB AMBA wrapper to be utilized by all designers. This creates a uniform and more
manageable design and eliminates the designer from dealing with the AMBA bus. Certain parameters
(such as wait states and number of sub-slaves are hard-configurable)

This wrapper divides each AHB slave into 1 to 4 “sub-slaves” to help in organizing design and
manage AHB slaves with different functions and different designers. These “sub-slaves” are
transparent to the AHB bus.

Certain rules were created for each designer to follow in order to keep overall uniformity and
facilitate the overall design flow.
LEON / AMBA clock frequency is 25.6MHz.
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST ASIC General information
Page 6
•
ATMEL MH1-332E Gate Array
•
MQFPT 352 Ceramic Quad Flat Package
 0.35  CMOS
 Gate Complexity: 1.64 million typical routable gates
 273 used I/O pins
 78 Power Pins
•
Operating Conditions




•
Temperature range for die (°C):-55, +145
Radiations (dose) : 200 Krads
Power supplies (V%) : 3.3V 10% (Core) 3.3V 10% (I/O)
Max frequency :76.8 MHz
Estimated power :
 5.0 W at 3.3V , load 20 pF and system clock frequency of 76.8 MHz
•
•
•
•
No internal RAM available in this technology
SEU hardened registers for critical blocks
Scan chain implemented yielding 95% fault coverage
Present status:
 Sign-off in April 2010
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST ASIC SOC configuration
PROM
Legend
RS232
ESA IP
TAS-I
ESA IP
Master
Page 7
Other IP
external
ASIC
APB
IF
APB used here only
for configurataion.
APB
IF
I/O
(FPGA)
SRAM
APB used here only
for configurataion.
LEON2FT
Serial Debug Interface
UART of AHB
(Debug Support Unit)
I-cache D-cache
Memory
Controller
(with EDAC)
AHB-Interface
AHB-Interface
AHB-Interface
AHB-Interface
AHB
integer unit
DSU
APB
IF
AHB
Arbiter/
decoder
gateclk3
gateclk4
AHB-Interface
AHB-Interface
AHB-Interface
AHB/AHP
DSP
DSP
Bridge
slv#3
slv#4
…
gateclk9
clk12MHz
AHB-Interface
AHB-Interface
DSP
1553
Slv #10
slv #9
APB-Interface
APB-Interface
APB-Interface
APB-Interface
APB-Interface
APB-Interface
APB-Interface
APB-Interface
APB-Interface
UART #1
Timers/
Watchdog
GPIO (16bit)
Interrupt#1
cntrl
Housekeeping
MLDS
LSSB
PLL Peregrine
SIPO/PISO
APB-Interface
APB-Interface
UART #2
RS232
Wr Protect
APB-Interface
APB-Interface
APB-Interface
APB-Interface
AHB Status
Interrupt #2
cntrl
Scratch Pad
(rad-hard)
CAN
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST ASIC LEON2-FT implementation
Page 8
LEON2-FT implementation:
• LEON2-FT version: the newest version of VHDL - LEON2-FT v1.0.9.16.2.
• LEON2-FT Cache (both data and instruction) : 1 set, direct mapped.
Implemented as a synchronous (register-based) memory and protected by 2
parity bits. This creates a 1 kbyte cache memory organized as 256x34 and a Tag
memory organized as: 32x32.
• LEON2-FT Register File : 8 windows. Implemented as a synchronous (registerbased) 3-port Regfile protected by 7-bit EDAC. Note that this block has been
modified from the original implementation choices.
• Multiplier, divider (radix2) and MAC
Memory Controller implementation:
• Memory Controller : 8 / 16 bit external bus capability
•
•
Note: BepiColombo project uses 8-bit memory
Memory Controller : 7-bit EDAC external protection (8-bit mode only)
•
Note: BepiColombo project disables this feature
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST ASIC LEON2-Ft platform main changes
Page 9
•
•
•
Reduced external 32-bit data bus to 16-bits and also various RAM/PROM
control due to pinout limitations.
Implemented the LEON Register File with a “new” synchronous (registerbased) 3-port Regfile to adapt to our non-RAM ASIC. This was not part of
the original LEON package. This reduces write banks from 2 to 1 bank and
can read 2 different locations simultaneously. (in the original RAM
versions, 2 RAM identical write banks are implemented)
Not implemented in the DST ASIC:
•
•
•
•
TMR clocks and registers.
FPU
Co-processor
SDRAM interface
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST ASIC AHB Slave Wrapper
Conceptual block diagram
Page 10
Other Clock
Domain
Configuration Generics
• # sub-slaves (1 to 4)
• # of total 32-bit words
• # write wait states
• # read wait states
• pulse width of Chip-select
• # slave ID information
Add
# sub-slaves (1 to 4)
CS sub-slv0
Re-synced
Chip-Select
Re-sync
pulse
Chip
Select (3-stage)
Ahbsi.
Green AMBA
Clock domain
AHB
Interface
(including
Frozen Address
.hready Wait
(already
Counter)
.hresp
scaled down)
“n” multicycle
Path
Ahbsi.data
amba_rd_en
Top 2 bits
Add
Chip
CS sub-slv1
Select
Sub-slave
Add
Decoder
(and delay) CS sub-slv2
Sub
Slave
en 0
“n” multicycle
Path
Sub
Slave
en 1
2 multicycle
Path
Sub
Slave
en 2
Ahbso
.data
CS sub-slv3
Reg
en
en
Data
Sync-up
Re-synced
Data
2 multicycle
Path
Sub
Slave
3
Top 2
Add bits
en
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST ASIC fault-tolerance approach
Page 11
•
•
•
•
•
External PROM:
•
Program runs in PROM only. PROM is rad-hard and SEU-immune.
External RAM:
•
RAM is rad-hard, but not SEU-immune. It is used only for non-critical data
which is periodically scrubbed. EDAC will not be used for Bepi Colombo
mission.
Internal Scratchpad is rad-hard. It is used for critical data.
Internal Cache is not rad-hard (too many gates) but does have a 2-bit parity
protection.
Internal Register-file is not rad-hard (too many gates) but does have a 7-bit
EDAC protection.
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST FPGA: Bread Board implementation
Page 12
•
•
•
•
The entire DST ASIC (using the same ASIC VHDL code) has been
successfully implemented in an Altera StratixII EP2S180 device.
Gaisler GRMON debugger used as general debugger and also to download
software into the “PROM”.
All tests performed using real software - C code (DST FPGA is in real
operational mode). This is the same software used in simulation.
Supplied LEON2 and peripheral validation software was run successfully on
the FPGA.
NOTE: simulations, ASIC synthesis and lab verifications (both FPGA and ASIC)
all use the same LEON2 configuration. The only exception is the target
technology.
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST ASIC Achievements
Page 13

A complete system has been included all in a single chip : from a
microprocessor, various DSP functions, standard BUS interfaces (MIL-STD-1553,
LSSB, MLDS16, CAN) and many other general purpose serial and parallel
interfaces.

Thus a ready, flexible, configurable and multi-standard platform has been
obtained, which is the core for our on-board TT&C equipment for several
mission profiles (Deep Space, Near Earth or Secure Communications).

Gated clocks : we achieved our goal for the different clock domains and thus
can reduce power consumption in the different configurations.
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST ASIC overall problems encountered
Page 14
General problems with the place and routing in MH1RT:
 Silicon Ensemble Router (previously called tangate) “failed” (aborted after several
days run) due to the high congestion without giving much indication to the cause.
Area density before P&R failing was around 55% :
•
•
•
•
•

The only recoverable information from the P&R tool was a map of the area
where the most severe congestion problems were found
This area was in the LEON2 placed gates region.
No solution found with timing driven Router tool First-Encounter
Typical area usage (Atmel source) for MH1RT technology is 70%.
Solutions to resolve the problem:
•
•
•
•
•
Optimization of certain code
Removal of certain blocks (some moved to software)
Added AHB slave data register to create multi-cycle paths for AMBA writes
More refined script files (multi-cycle paths etc.)
AMBA / LEON clock frequency reduced from 38.4MHz to 25.6MHz reduction

After above gate reduction (to 52%), we had success (using only Silicon Ensemble)
but we still had timing problems with 76.8MHz.
 More than 1 week required for every new run of the P&R tool
•
No incremental layout possible even if only minor parts of the ASIC changed
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
Problems encountered in
implementing the LEON2-FT
Page 15
1. LEON2-FT Manual : There were numerous errors and discrepancies in the manual
which took time to understand. Certain sections were not very clear or hard to
understand. This required simulation and code analysis for a better understanding.
2. The provided validation C code (used to validate the LEON2 and peripheral):
•
Certain (very minor) changes to the provided validation C code caused errors in
the cache-controller test when using a non-standard cache set-size (1 set).
3. RTL / Gate simulation mismatches : ‘X’s in gate level simulation (which propagate) due
to non-reset control registers (that are truly don’t care). Different results for each
synthesis.
•
TASI has resolved this problem utilizing the already existing internal SCAN chain
to initialize all control registers in the LEON environment
•
This “SCAN pre-initilization” is run at the beginning of each testbench and thus far
TASI has not encountered any problems.
•
WARNING: Utilizing the above SCAN pre-initialization introduces the risk that it
could hide true initialization problems.
4. Cache : trying to implement the cache as a latch-based memory caused difficulty in
routing / timing.
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
Problems encountered with Modelsim when
implementing the LEON2-FT
Page 16
Modelsim code coverage“bugs”:
1. Incorrect simulation: while performing code coverage, modelsim simulation
produced erroneous results – there was a wrongly evaluated combinatorial
expression in a variable assignment inside a combinatorial process within the
Memory Controller.
•
Solution: use a different version of modelsim, but be careful because this
problem has come and gone as versions evolve. For now, the version that
doesn’t seem to have problems is 6.5c
2. Modelsim code coverage ignores recursive constant assignments in the target /
device / config packages (the “passing” of constants from a lower level package
to a higher level package) – thus resulting in a much lower code coverage.
•
Solution (Only a “patch” for now): by hand (or script) modify the upper level
constants package (config.vhd).
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST ASIC lessons learnt (1 of 2)
Page 17






It is very difficult to understand if there will be routing problems with Technology
MH1RT (especially in high fan-out, intensive bus routing designs).
If there is space, implementing more Cache would be very useful.
For the cache, it is better to chose an ASIC that has RAM (or one that has enough
available space to implement the cache in registers)
8-bit data bus can be a “bottleneck”, and even more so with EDAC enabled.
Always perform a flush enabling the cache.
Be careful when using PIO[1:0] to configure data-bus width during a non-power-on
reset. Depending on the reset width, there may not be enough time for the pull-up
/down resisters to reach their value.
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space
DST ASIC lessons learnt (2 of 2)
Page 18
Some other observations…
 The modular AMBA bus is a very efficient/organized way to design SOC platforms.
It was also very easy to add and remove slaves from the bus in the beginning design
stages or for certain verifications.
 Designing a standard AHB wrapper helped in the debug and created a well ordered
and uniform design. It also helped when creating script files.
 If possible, keeping the top level (including I/O pins) and the “mcore” basic structure
as much the same as possible to the original design helps in general debug and
especially when using the provided validation C code to validate the LEON2 and
peripheral.
 Record types are very useful in organizing the design and also aid in debug.
 With today’s faster memories, the Memory Controller PROM wait states could be
changed to increments of 1. (presently 0, 2, 4 etc.)
Thales Alenia Space Italia SpA
All rights reserved, 2010, Thales Alenia Space