Electronic System Level Design Basics

1. Electronic System Level Design
Basics
蘇文鈺
成大資訊

2. Why learn ESL
• if you are an undergraduate student, and/or
• if you are a C.S. student, and/or
• if you still do not know in which areas you are
really interested,
• when you still do not know what ESL is?

3. Because
• This is one of the best ways to start your
learning of C++,
• This is the best way for a C.S. student to study
SoC design,
• This is the biggest advantage C.S. students can
take over E.E. students in SoC related areas,
• This is one of the best ways to learn lots of
tools and languages in HW/SW designs.

4. What is ESL?
• ESL = Electronic System Level
• ESL doesn’t specify which levels of design should
be employed. It focuses on the concepts of
designing a system, instead of specific
components.
• Then, what is Electronic System Level design flow?
• Design, debug, verify the system using ESL
methodologies, languages, tools and CONCEPTS.

5. What does level mean?
• In HW design, level means the degree of the
design details, or the level of abstraction, of the
model of the target design. For example,
–
–
–
–
–
–
–
–
Transistor level
Gate level
Register transfer level (RTL)
Transaction level
Behavior level
Architecture level
Algorithmic level
…. And so on.

6. Before the answer is made
• Let’s ask “Why ESL design flow is needed?”
–
–
–
–
–
–
–
–
–
Huge system
Extraordinarily high complexity
Design reuse
Slow simulation speed
Difficulty in integration
Mixed/multiple disciplines
HW/SW co-design/co-simulation/co-….
And so on.
Most importantly, time-to-market

7. Design Complexity from Different Design
Generation
David C. Black
Jack Donovan

8. These are not reasons
• They are just problems. Imagine
– You have a system with 10 processor cores, each
having its own memory system. There are shared
memory spaces for the cores. 20 different peripherals
to control. There are 20 programmers using 8 different
languages to develop 30 different applications on this
system which needs to support 2 different OS. And the
biggest problem is
• To cope with these problems, what do we need?

9. We need
• A super fast simulator
• A simulator supports mixed abstraction level
designs
• An integrated HW/SW co-development
environment
• A super fast simulation environment
• … and so on.
• To do this, what are the first few steps?

10. How about …
• New modeling languages instead of HDL
– SystemC, an open standard adopted by OSCI and
IEEE. Since programming using SystemC is the
main subject of this course, we will leave the
introduction of SystemC later in this course.
• New Modeling methods instead of RTL
– TLM, Transaction Level Modeling
– New languages do not give you speed. New
Modeling methods do.

11. Various Abstraction Levels
are new levels good
Transistor Level
for ?
Gate Level
Register Transfer Level
Transaction Level
What else?
should they be used?
it worth the effort to
write models for another
new level?

12. Why Abstraction MAY give you more
speed?
• Detail implementation is skipped
• High level programming languages can
be used
•
•
•
•
Powerful multi-CPU computers can be used
Faster model implementation
Reusing existing models
…

13. Instead of modeling all the details,
• For example, just Modeling Transaction may be
enough. If this is the case, we call it TLM
(Transaction Level Modeling)
• Transaction means “Communication”, “Exchange”,
“Interaction”, …, and so on.
• Transaction between/among functional blocks,
components, models, ….
• What we care about are: the content of each
transaction and probably the timing of each
transaction.
• What we do not care about are: ……

14. Why only focus on Modeling
Transaction?
• Higher abstraction level (This is not really the purpose)
• Separate the implementation of communication and
computation
• Simplify the model implementation
• Focus on System integration
• Design reuse
• One can adopt CBSD (Component Based Software
Development) methodologies. (This is not really the
purpose, either)
• …

15. What may be sacrificed if higher
abstraction level is used?
• Accuracy
– Time accuracy, for example, not cycle accurate
– Circuit-wise accuracy, for example, not pin
accurate
– Information accuracy, such as performance related
instead of functionality related, for example,
amount of bits transferred in a certain time frame.
– The more abstract, the less accurate.

16. Abstraction Levels in SoC design
David C. Black
Jack Donovan

17. Model referred in this course
• When “model” is referred, we usually talk
about the correspondent form existing in a
computer the model wants to describe.
Usually, it is implemented with a certain
programming language in this course.
• Model can be model of the system or model
of one of the components of the system

18. Time Accuracy of Model
• Un-timed (UT): no timing information is included
in the models. Only functionality is implemented.
• Approximately-Timed (AT): usually a quantum is
used to describe the time information of the
model. A quantum may be a certain number of
cycles which may derived from estimation or
actual implementation. Time annotation is
usually required.
• Cycle-Timed (CT): also called cycle-accurate (CA).

19. Cycle Accurate and Cycle
Approximated

20. What is TLM?
• There is no clear definition except that ..
– Abstracts the expected behavior of a given system.
– Using function calls and events for data exchange,
and synchronization instead of using signals and
registers.
– Providing set of Application Programming Interfaces
(APIs) to facilitating architectural exploration, efficient
modeling of complex given system.
– No consideration of any implementation details - such
as architecture address mapping information.
– Now we have standard TLM library in SystemC to use.

21. Principles of TLM
• Independent of programming languages
• Separation of the modeling of computation and
communication.
• Modeling of components as modules.
• Communication structure by means of channels.
• Modules and channels are bound to each other by
communication ports.
• A set of data is exchanged by a transaction.
• System synchronization is an explicit action between modules.

22. Why is TLM so interesting ?
•
•
•
•
•
Fast and compact
Integrate SW and HW models
Early platform for SW development
Early system exploration and verification
Function verification reuse
2005 Cadence Design Systems

23. Keys
•
•
•
•
•
•
•
•
•
Model only what you need
Get the result early
Get the transaction behavior right first
Less code can lead to higher simulation speed
Use Increment design process
Build verification model in the process
Consider mixed-level modeling
Do not use slow C constructs
Avoid clock threads if possible

24. Be Careful
• What you see may not be what you get. Good
interpretation is always needed.
• Timing requirement may not be always
achievable
• Model consistency
• Data/memory consistency unless TLM library
is used
• Not to go into too many details too early as
most logic designers will do

25. Different Stages of TLM
Dan Gajsky, Lukai Cai
CODES 2003

26. What are not TLM?
• RTL: cycle accurate, pin accurate, and so on. Too
detailed, especially the computation part. This makes
the simulation very slow.
• SM (Specification Model): Only functionality
specification is ready. There is not even the
specification for the architecture.
• SAM(System Architecture Model): without any
timing annotation. Though too rough for HW
implementation, it is still valuable for system
modeling. It can be considered as the one close step
toward TLM.

27. TLM Model Terminologies
• module: each component, including computation and
communication ones, are called a module.
• channel/interconnect: an interface structure that
establish the communication among the modules.
• port: the binding between a module and the channel
associated with it.
• transaction: a data set to be exchanged among
modules.
• master/initiator: a module that requests a transaction.
• slave/target: a module that receive a transaction from
a master or is responsible for a transaction request.

28. TLM Implementation Terminologies
• processes/threads: a mechanism that allows one
to implement modules which are executed in
parallel using a simulator (or computer).
• synchronization: a mechanism that allows
modules to cooperate on common jobs over
time.
• timed/un-timed TLMs: the transaction level
models with or without timing annotations.
• channel cycle accurate (CCA): the
implementation is cycle accurate only for the
channels within the target system.

29. Rules To-be or Not-to-be
• Implementation details of the overall system
should not be included. Said too many times.
• synchronization is required to build up the
dependencies among modules which run in
parallel using processes or threads.
• modules must be bit-true
• component interfaces must be register
accurate
• communication must be bit-true

30. Bus Component Model (BCM)
• Abstract bus channels: pin assignment and
bus protocol be omitted
• Transaction count is available, but exact cycle
count for the transaction is not known.
• No timing annotation for the computation
modules
• Close to system architecture model (SAM)

31. Component Assembly Model (CAM)
• Similar to BCM, but
– timing annotation is available in computation
modules, instead of communication modules.
• Computation module is regarded as a
processing element (PE)
– An ISS (Instruction Set Simulator) based module.
Not cycle accurate, but provide instruction counts
for a job.
– A simple combinational and/or sequential logic
with I/O ports

32. Bus Arbitration Model (BAM)
• One step further from either BCM or ATCM
• Bus arbiter is included
• Bus protocol is implemented though not to
the cycle accurate level

33. Bus Functional Model (BFM)
• Cycle accuracy is required for communication
modules, but not computation modules.
• Bus protocol be implemented in full details
with respect to the master clock signal
• Pin accurate: virtual wires of the bus are
implemented with variables/signals.
• Good approximation of true system
performance

34. Cycle Accurate Computation Model
(CACM)
• Pin accurate
• Communication among modules goes through
abstract channels
• Suitable when some modules have finished
their designs and there are existing IPs which
include ESL simulation models.

35. Cycle Accurate Implementation Model
(CAIM)
• Cycle-accurate implementation of all
computation and communication
modules/components
• Slow in simulation speed
• Close to RTL
• Not a TLM

36. Design Stages of TLM
RTL in HDL
Target
Communication
CT
BFM
CAIM
CACM
AT
BCM
BAM
UT
SAM
CAM
SM
: TLM
UT
AT
Computation
CT
Others: Not TLM

37. Example used by Gajski
Specification Model (SM) or
System Architecture Model (SAM)

38. Example used by Gajski
Component Assembly Model (CAM)

39. Example used by Gajski
Bus Assembly Model (BAM)

40. Example used by Gajski
Set up the Timing Spec.

41. Example used by Gajski
Bus Functional Model (BFM)

42. Example used by Gajski
Cycle-Accurate Computation Model (CACM)

43. Example used by Gajski
CAIM

44. Incremental Design Flow using TLM
RTL in HDL
Communication
CT
BFM
CAIM
CACM
AT
BCM
BAM
UT
SAM
CAM
: TLM
Others: Not TLM
SM
UT
AT
Computation
CT

45. Characteristics of TLM models
By Gajski’s definition

46. Characteristics of TLM models
Models
Communication Computation
Time
Time
Communication PE interface
Scheme
SAM
no
no
Not specified
No PE or Rough
PE
BCM
appro.
no
Abstract bus
model
abstract
CAM
no
approx.
Message
passing channel
abstract
BAM
approx.
approx.
Abstract bus
model
abstract
BFM
Cycle accurate
approx.
Detail bus
model
abstract
CACM
approx.
Cycle accurate
Abstract bus
model
Pin accurate
CAIM
Cycle accurate
Cycle accurate
wire
Pin accurate
By this course

47. Basic SoC Design Flow

48. How TLM is used in ESL design flow?
Requirement Development
SM/SAM
Transaction Level Model
Development
TLM
SW
design,
Development
and
Profiling
HW Design/Refinement
RTL
HW
Verification,
Emulation
and
Profiling

49. Why simulation model is useful?
System
Requirement
System
Spec.
Executable
System Spec.
PIM
Simulation Model as the
Executable System Spec.
DSE
HW Spec.
SW Spec.
HW
Implementation
SW
Implementation
PSM
PIM: Platform Independent Model
PSM: Platform Specified Model

50. Speed Comparison of Different ESL/EDA
approaches
Modified from ARM
Chris Lennard, Davorin Mista
FPGA Based
Developers
50

51. Why ESL design flow is needed?
• Obviously, simulation speed.
• IP-based design flow
• Early HW/SW Co-design for parallel
development
• HW/SW development around a common
environment
• Mixed level simulation
• Save development time

52. However
• High abstraction level gives you speed, not
language,
– even when you use SystemC. Modeling methodology
determine the level, not the language.
– If your simulator does not give you speed, do not use
it.
– If you are modeling at a much higher level but get not
much speedup, something is wrong.
– Carefully choose timing accuracy. CA may slow down
simulation very much. Cycle accuracy may sometimes
be a myth.

53. Why IP-based design?
• Why use ESL if building a system from ground?
– You need an extra ESL platform.
– You usually have to spend lots of time on building
ESL models.
– You need a strong ESL team.
– Unless you have good roadmap toward develop
IP-based design flow.

54. HW/SW Co-design
• ESL is useful when you need to run SW on HW.
– Early system performance profiling
– Find HW bottleneck
– Parallel development
– Find bugs earlier
– Working on the same platform help
communication between HW and SW people
• ESL is still encouraged when no SW is present.

55. Mixed level simulation
• A very important feature to allow people of
different skills and levels to work on the same
project.
– Mixing models of gate-level, RTL, TLM, or even
algorithmic level
– Even Matlab and FPGA models
– Provide progressive design path

56. Development time
• If development time is not saved
– Do not use ESL, or
– There must be something wrong

57. Co-Design Environment
Eclipse IDE
Appilication
Hardware Models
(Simulator)
Software gdb
Simulator gdb
Native System (x86)

58. SW Tool Chain
Compiler
Eclipse Integrated
Developed Environment
Assembler
CDT plug-in
GDB/MI interface
GDB/MI interface
User interface
Debugger
Target side
RSP
RSP
Debugging Stub
Simulator
(SyetemC)
Linker

59. Progressive Design Flow
Three stage pipeline design：
A. SW model: high abstraction level model
B. TLM model：very close to architecture
C. HW model ：HDL
交互驗證

60. Detailed Flow: Early stage

61. TLM/ESL Modeling stage

62. Final Integration Stage

63. Verification and Debugging

64. Impact of Development Cycle Change
• Traditional Design Procedure
SW Development
Specification
HW development
System testing
Integration & Debug
• New ESL Design Procedure
SW
HW/SW
development early integration
Specification
Modeling
Environment
Simulation
HW development
Integration
&
Debug
CoWare Inc. 2006
Virtual Platform
System testing
Time saving

65. Commercial tool: SOC Designer
Work Space
Cache Profiling window
Waveform Viewer
Assembly code window
Memory maps

66. Commercial tool: CoWare

67. Open Source: GreenSoc (not so open)
GreenScript
Config PlugIn
GreenAV PlugIn
GreenControl Core
ESL
Tools
Config User I/F
User IP 1 GreenBus I/F
GreenAV User I/F
Config User I/F
User IP 2 GreenBus I/F
Config User I/F
Specific PlugIn
User IP 3 GreenBus I/F
Specific User I/F
SystemC

68. SCREAM Lab OpenESL

69. SCREAM Lab OpenESL

70. FPGA tool:
Berkeley BEE2

71. FPGA tool: NCKU Multicore

72. FPGA tool: SMIMS

73. Where are we going?

74. The rest of related topics
• SystemC
– Some C++ review
– Threads and Processes
– SystemC programming
• Logic Design
– Simple digital design using Verilog at RTL
– HDL simulator
– FPGA
• Computer architecture
– Bus based
– NoC based
• OpenESL
– Start a SoC project
– Heterogeneous tools: SystemC, FPGA, Matlab, …..

75. Let’s kick off