System-on-Chip Data Processing and Data Handling Spaceflight Electronics

8 Pages·1999·0.58 MB·English

by  Kleyner, I.

System-On-Chip Data Processing and Data Handling Spaceflight Electronics
I. Kleyner _,R. Katz 2and H. Tiggeler 3
1Orbital Sciences Corp.
2NASA/Goddard Space Flight Center
3University of Surrey
Abstract flight hardware design due to the limitation
of resources available in radiation-hardened
This paper presents a methodology and a
tool set which implements automated devices and reliability issues, particularly for
the radiation environment.
generation of moderate-size blocks of
customized intellectual property (IP), thus The objective of our research is to
effectively reusing prior work and develop, demonstrate, and refine
minimizing the labor intensive, error-prone architectural techniques and tools for FPGA
parts of the design process. Customization designers to permit rapid, reliable
of components allows for optimization for development of high-speed processing and
smaller area and lower power consumption, data handling functions, integrated onto a
which is an important factor given the single chip.
limitations of resources available in
radiation-hardened devices. The effects of II. IP GENERATION ENVIRONMENT
variations in HDL coding style on the
efficiency of synthesized code for various Development of an integrated IP
commercial synthesis tools are also generation environment was the first phase
discussed. of the project. As shown in Figure 1,
Kompiler combines customized VHDL
I. INTRODUCTION code-writing capabilities with built-in test
vector generation, synthesis execution, and
Performance requirements for simulation for verification.
spaceflight electronics have been increasing
as detectors produce greater amounts of data
at higher resolutions. Concurrently, there is
an increasing need to produce spacecraft
electronics in shorter periods of time using
less spacecraft resources.
It is a common occurrence that similar or
identical spaceflight data handling and
processing hardware functions tend to be
redesigned repeatedly by independent teams
of engineers or even within the same team.
This obviously is inefficient and costly in
both development and verification time.
AltemativeIy, commercial IP cores are Figure 1.Kompiler 1P Generation Flow.
available for many functions required for
spaceflight hardware design; however, these Generation of VHDL code for a
cores tend to be ill suited for the specifics of component is performed by utilizing a
previously coded generic "template," the If more than one coding style for the
contentsof which are embeddedin the component can be utilized or different
sourcecodeof Kompiler. The front end synthesis tools are available, the code
userinterfaceprovidesselectionof various creation/synthesis loop can be repeated for
options to satisfy the requirementsof the all available combinations. In this fashion,
particular application for which the the optimal solution may be obtained with
componentis intendedto be used,while minimal effort from the design engineer. In
allowing a trade-offbetweenresourcesand case of FPGA space applications, this is
features.Foradata-heavycomponent(such often the one consuming the least amount of
as a ROM) input data is provided as a resources and power.
specially formatted ASCII text file. After completing the code
Additionally, a synthesis tool selection creation/synthesis phase, the component's
option is providedto optimize the created implementation is automatically verified.
codefor knownspecificsof aparticulartool The Kompiler calls the gate-level simulator
to beusedfor synthesizingthe component. via its command line interface, with the
Furthermorem, orethanonecodingstylefor previously generated stimulus/checking file
a block may be available. As a result, a as a parameter. Design verification is a
customized version of a generic labor-intensive, error-prone phase of the
component'sVHDL codeisproduced. design process, often being larger than the
detailed circuit design. Utilizing test vectors
Kompiler llll_I l algorithmically generated by the Kompiler
saves considerable time and effort, as does
W,_eVHDLCode| C_ I _r_'ea_dS_ I
Kompiler's automated processing of the
simulation results.
_i_ C:',.USER'_omplerkRAM vhd __
' M_Lr_eL_gth I Simula_c_" ,
III. COMBINATIONAL IP BLOCKS
;,o1_-'_,_,............................I.....I.v.."._.." -'-I_'
AND CODING STYLES
As was mentioned above, System-on-
Chip (SoC) building blocks to be
implemented in the Kompiler environment
include a variety of universal and commonly
used components such as ROM, RAM,
::.._-_-_--j LIFOIU_T,_]UART,K_PLl MKSI FIFO, LIFO, and Register File. More
complex and specific structures such as
UART Receiver, UART Transmitter, Timer,
and Data Encoder/Decoder can also be
Figure 2. Kompiler User Interface.
developed into Kompiler blocks. In addition
Creation of customized VHDL code for to these data handling functions, arithmetic
a component is a useful feature by itself, but cores such as an array multiplier, CORDIC
it can be even more powerful if used in functions, and DSP cores (FIR filter, IIR
conjunction with other Kompiler features. filter, Correlator) are prime candidates.
During the next step, the VHDL code The generation of combinational logic
generated by Kompiler is synthesized from blocks (ROM component) was chosen as the
within the Kompiler environment, using the first Kompiler application for a variety of
command line interface of the synthesis tool. reasons. Such a component is described
functionallyby definingthevalueof output Additionally, we have developed two
for every combinationof inputs. This is more styles of coding for combinational
rather laborious and error-proneto code logic blocks. By viewing the ROM as a set
manually, but the task can easily be of functions, the minterms can be selected
automated. In addition, the ROM and written as logic equations in a
component represents a convenient sum-of-product format. Either the "ones"
opportunity to study the advantagesand may be grouped and the minterms written
disadvantagesof different coding styles, directly or the "zeros" may be written and
since automatedcode creation allows for
the resulting function complemented.
fast and efficient implementation of
differentcodingtechniques. When selecting "ones" we have
The moststraightforwardstyle for the generated code segments that look like this:
ROM component,named"Word-Case"is
themostnaturalfor "human"coding. One ZData (2) <= '0' or (ZA(0)
and not ZA(1)
long VHDL Case statementis used to
and not ZA(2)
implementthe structurewith the address and not ZA(3)
usedastheevaluatedexpression.Thelist of and not ZA(4)
and not ZA(5)
choicesrepresentsall possiblecombinations
and not ZA(6)
of inputs and correspondingvalues for or (ZA(0) and ZA (1)
outputsbasedon the contentsof the input and not ZA(2)
and not ZA(3)
data file, which contains the functional
and not ZA(4)
descriptionoftheblock. and not ZA(5)
and not ZA(6)
or ...
When "000001010" => ZData <= "i00101";
When "000001011" => ZData <= "iiii00";
When "000001100" => ZData <= "i01101"; When selecting "zeros" the generated
code is structured in this manner:
ZData(2) <= not ( '0' or ( not ZA(0)
Alternatively, each bit of the output can
and not ZA(1)
be coded using separate Case statements and not ZA(2)
("Bit-Case" style) and not ZA(3)
and not ZA(4)
and not ZA(5)
When "0000000" [ and not ZA(6)
"0000100" I or ( not ZA(0)
"1111110" => ZData(0) <= '0'; and ZA(1)
and not ZA(2)
and not ZA(3)
and not ZA(4)
or input data can be represented by an and not ZA(5)
and not ZA(6)
array of constants ("Hans-Array" style)
or ...
constant ROM : rom_array := (
Obviously, writing the "logic equations"
"0000000000000001",
"1110001001100001", code manually is not a task that can be
"1101000100110001" , accomplished reasonably for a logic block of
"1110001101001001",
any significant size. However, the algorithm
for automating such task was rather
straightforward to code into the Kompiler.
The resulting VHDL code is often somewhat
bulkyandquiteunreadableforahumaneye,
but, as was discoveredlater, sometimes
preferredby certainsynthesistools.
Besides the usefulnessof the ROM
componentfortheKompilerasausefulSoC
building block, it enabledus to study the
efficiencyof differentsynthesistools. This
included the effects of processingVHDL
descriptionsofblocksof logicwrittenusing
differentcodingstyles. Additionally, for a
L_c I L_ico _I ell, word _ HI.* A_y
fixed description, the targeting of the Codln6 _)-II
Figure 3a. Sine Wave Synthesis Results for Actel
generatednetlistinto differenttechnologies
Act 3Target Technology
was studied. Among the synthesistools
available for us during this study are
The next selected test case was identical
Actmap from Actel, Synplify from
to the one above with the only exception of
Synplicity,DesignCompilerfromSynopsys
a different target technology; Act 3 was
and Leonardo from Exemplar. A few
replaced with Actel SX. In some aspects the
real-life input data sets were randomly
results (represented by the chart in Figure
selectedandall five aforementionedcoding
3b) were similar to the ones in the previous
styles were utilized to generateVHDL
example. For instance, the Synplify tool
blocks, which were then synthesizedfor
was most efficient for synthesizing
variousActel FPGA devices. Someof the
"Logic 1/Logic0"-style code, Synopsys
resultsareillustratedinFigure3.
"preferred" code written in "Bit-Case" style,
Thefirst testcase(Figure3a)represents
and Actmap was most compatible with
results (in terms of module count) of
"Word-Case" and "Hans-Array" styles.
implementinga 128x16bit sinewaveLUT
Some results, however, were quite
targetingActel Act 3 technology. As can
surprising. For example, Actmap synthesis
easilybeseenfromthechart,thesizeof the
for SX technology required a factor of two
synthesizedblockfor thesamedatacontent
or more increase in the number of modules
variessignificantlydependingonthecoding
(from 108 to 216 for "Word-Case," from
styleaswell asthesynthesistool used.For
103 to 270 for "Hans-Array") as compared
example,Actmapsynthesized"Word-Case"
to Act 3 technology. It is noted that the SX
and "Hans-Array" style code most
C-Cell is a superset of the Act 3 C-Module
efficiently,producingamodulecountof 108
and should have been more efficient [1]. In
and 103 modulesrespectively. However,
fact, out of all synthesis tools utilized in the
the Synplify synthesizerproducedits best
study, only Synplify was able to take
resultsof 199 and201 modulesfor code
advantage of the improvement in the SX
written in "Logic 0" and"Logic t" styles,
logic module relative to the Act 3 module,
while doing somewhat worse with
resulting in lowering of the total module
case/arraystyled code. Other interesting
count. The relative lack of performance in
trendsmay beobserved. Forexample,the
Actmap for SX in comparison to Act 3
factthat the "Bit-Case"style producedthe
technology can partially be explained by the
most efficient resource consumption in
fact that the version of the tool available at
conjunction with Synopsys Design
the time of study did not have all of the
Compiler,butwastheleastefficientwith the
optimization algorithms implemented. The
ExemplarandSynplifytools.
next revision of the Actmap software did
showimprovementby bringing themodule
countfor SX ("Word-Case"style)downto
136. However,themodulecountforAct 3
technologyin the newerrevisionalsowas
136,upfrom108forthepreviousrelease! i
'...*.°.'l.. I
ISynp)ify !
liExa_nar
I Dsynoply_ I
¢°a_0In..
Figure 3c. Correlator LUT Synthesis Results for
Actel SX Target Technology
A few more input data sets of various
contents were tested in a similar fashion.
e°dl.t rafts, Some quite consistent trends were detected;
Figure 3b. Sine Wave Synthesis Results for Actel i.e. certain synthesis tools were more
SX Target Technology
efficient with certain coding styles. The
most obvious result of the study was the fact
The chart in Figure 3c also represents
that for any synthesis tool used the resource-
synthesis results targeted for SX technology,
effectiveness of implementing a
but for a very different data pattern or ROM
combinational block was highly dependant
content - a look-up table for a correlator.
on the content of data, coding style, target
This particular data set contains a certain
technology and sometimes even the tool
number of "don't care" values in the address
software revision level.
field. This can be efficiently utilized in
"Logicl/0" style code which selects
IV. SEQUENTIAL IP BLOCKS
minterms to write logic equations but not in
the "Case" style, since VHDL syntax does
Given the relative successfulness of the
not allow "don't care" values in the choice
experiment with the ROM component for
field of Case statement. In this test case
the Kompiler, additional relatively simple
both Synplify and Actmap were most
blocks, which include sequential elements,
effective with the "Logic 1" coding style,
were developed into Kompiler features.
apparently being able to take advantage of
These included RAM, LIFO, and UART
"don't care" values in the address field.
receivers and transmitters. The development
This data set had a prevalence of "0"s for
effort for these blocks concentrated on
the output values with no more than 2 out of
making them highly customizable. This
8 output bits containing "l"s for any address
allows a user, for example, to select the
value. This was not the case with the
active level of logic,
Synopsys Design Compiler tool, as the
synchronous/asynchronous, single/dual port
"best" results (lowest module count) were
configuration, active edge for clock, and
achieved synthesizing with the
exact depth and width of memory. UART
"Word-Case"-style code.
IP cores are readily available on the
commercial market, but usually they are
very comprehensive and carry many features
that may not be needed for a particular
v
application. For example, the simplest controllers). For space flight applications,
version of the UART IP core available from the commercial part was not acceptable
Actel requires 180 Actel SX modules. On because of radiation and power consumption
the other hand, the Kompiler offers separate concerns. For example, testing by JPL
receiver and transmitter blocks that can be showed that the device was susceptible to
stripped-down to only needed level of Single Event Latchup (SEL) [2]. The
functionality. This provides the benefit of Kompiler-integrated version of the part,
significant resource savings and frequently called the 29KPL154, inherited all features
lower power dissipation, a goal of most of the original controller including
space-borne designs. Additionally, some compatibility with the native assembler and
sub-blocks of both the receiver and simulator. Following our development
transmitter can be optionally utilized by philosophy, we required that it be fully
other components of a SoC design or can be customizable to fit exactly the requirements
shared between the receiver and transmitter of a particular application and be fully
modules. As a result, simple but fully integrated into Kompiler environment. An
functional double-buffered versions of both additional goal was to analyze the processor
transmitter and receiver were synthesized and its instruction set architecture to explore
utilizing less than 40 modules for each possible optimizations for implementing
block, which represents significant resource small processors.
savings. The Kompiler also offers single AM29CPL154 original features (all
buffer version for minimal resource preserved in 29KPL154 component) include
utilization. a 512x36-bit external program ROM, 8 test
Kompiler generated blocks like ROM, inputs, 16 user outputs, 28 instructions, and
RAM, and LIFO, even though very often a 17x9-bit stack [3]. Developing the
useful by themselves and able to save a 29KPL154 as a Kompiler block required not
designer a significant amount of time and/or just copying and implementing the
resources are relatively primitive in their architecture of the original device, but
nature. Building "manually" a whole allowing for customization and optimization
system-on-chip with any meaningful of the component as well. Among the
functionality out of such basic components user-configurable options for the 29KPL154
can be a very labor-intensive and error- are program memory internal, external or a
prone task. For the next phase of the combination, custom sizing of stack depth (0
Kompiler development, the emphasis was on to 17) and additional test inputs (up to 8)
creating a more complex component with and user outputs (up to 16). If internal
functionality sufficient to become a program memory is desired, the contents of
foundation for a potential complete system microprogram are synthesized as a ROM
capable of performing a useful task. block with the implementation utilizing the
Additionally, we set the goal of complete optimal style of coding. The user program
automation of this task. is analyzed by the Kompiler and only
As a prototype for such a component, the utilized instructions and test conditions are
AM29CPL 154, an obsolete single-chip Field implemented in hardware; the decoder,
Programmable Controller by AMD, was execution hardware, registers, etc. for
selected. In the past this part was used instructions not used for an application are
extensively by many engineers for not included in the final synthesized design.
implementing complex state machines and Additionally, instruction encoding may be
controllers (i.e. focal plane array optionally optimized by inserting "don't
care's into unused fields of certain controller for a spaceflight mission. The
instruction. An assemblertypically assigns 29KPL154 component was generated for
eithera '1'or a'0'to anunusedfield in the three different levels of customization -
instruction. The Kompiler, when unoptimized 29CPL154-1ike, optimized
post-processing the assembler's output, program ROM only, and a fully customized
replacesthe assignedvalueswith a "don't version with custom-tailored stack,
care,"givingtheoptimizermorefreedomto instruction decoder, and optimized
produceamorecompactdesign. instruction encoding. The results of
The AM29CPL154 assembleris fully synthesis using Actmap and Synplify tools
integrated into the Kompiler platform for Act 3 as a target technology are shown
allowingfor "one-click"generationprocess. on the chart (Figure 5).
Theuseronlyneedstoselectdesiredoptions
and configurationsand supply a file with
assemblycode (Figure 4). Two of the
building blocks for 29KPLI54 were
implementedusing previously developed |
components- programmemoryis basedon
the ROM componentandthe stackutilizes
theLIFOcomponent.
FullyC_lom_z*d Opl]mlzed Proonim ROM "29GPL 1544i_l*
Level of Opllmlz_io_
'+,',_eVHDLCoIde C_ [ "_,e_dS_ [ Figure 5. Controller Implementation with
29KPL 154 utilizing various levels of
__2_C:\U SER\NewKomplekto_ vhd ...... -± customization.
ibl_ LineLer,g_h _ :I__:............._... l S_alol
The chart clearly shows that the
, _lActMap _ C,e_eStrr_FJ_lPeu_i
-- ............................... implementation of a customized processor
has significant gain for the user. In this
example, we see that the optimized
29KPL154 brings about approximately 40%
savings in resource consumption for this
particular design, while still maintaining full
compatibility with the original device.
V. CONCLUSIONS
Figure 4.29KPL 154 Generation. The Kompiler development is still very
much a work in progress, as the verification
To evaluate the potential benefits of
effort for 29KPL154 is under way and
customization and optimization for the
additional components are incorporated into
29KPL154 a program used in a previous
Kompiler environment. Indeed, the
29CPL154 application was utilized to
extensible design of the Kompiler is geared
generate a customized processor. The
towards continuously adding new
sample program occupies approximately one
components and features, while presenting
quarter of the maximum allowable 512 word
the user with a consistent, easy-to-use
program memory and was originally used interface.
for prototyping a Focal Plane Array
v
Nevertheless, the concept of generating depending on the style of coding, the
small and moderately sized specific data content, and the software
custom-configured blocks of IP using an revision level of the tool.
integrated environment such as Kompiler
seems to be proven as a realistic task. It is REFERENCES
also quite obvious that at the very least using
automated generation of IP blocks shortens [1] Actel Corporation. Actel 54SX Family
the development time and helps avoid FPGA, 1999.
simple coding errors. For certain tasks, like
generating a large block of combinational [2] JPL/NASA Radiation Effects
logic the manual coding approach is Database.
extremely labor-intensive and error-prone, http://radnet.jpl.nasa.gov/SEE/1188.txt
and utilizing Kompiler code-generating
capabilities allows for tremendous savings [3] Advanced Micro Devices.
in engineering time and optimization Am29CPL 154 Field-Programmable
sometimes unattainable with traditional Controller, 1990.
methods. The rapid generation of HDL
using different coding styles makes
optimization of large logic blocks feasible,
practical, and effective.
It was also shown that along with small
and simple blocks, more complex and
comprehensive cores capable of substantial
functionality can be integrated into fully
automated IP-generating environment such
as Kompiler. The 29KPL154 has the
capability to be a cornerstone of SoC
implementation using a small processor for a
spaceflight application, yet it can be
customized to fit in a small, radiation-
hardened FPGA.
We have also determined that combining
HLL-based software equipped with a simple
user interface with VHDL permits a
convenient and flexible approach to
hardware design. The resulting environment
is suitable for implementing components
ranging from very simple and universal to
more complex and specialized; however, the
task of embedding and customizing a
component as well as designing a suitable
user interface escalates greatly with block's
increasing complexity.
Additionally, it was shown conclusively
that various synthesis tools perform identical
tasks with various degree of efficiency