Esl basics


Published on

Electronic System Level Design Basics

Published in: Technology, Design
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Esl basics

  1. 1. Electronic System Level Design Basics 蘇文鈺 成大資訊
  2. 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. 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. 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. 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. 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. 7. Design Complexity from Different Design Generation David C. Black Jack Donovan
  8. 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. 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. 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. 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. 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. 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. 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. 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. 16. Abstraction Levels in SoC design David C. Black Jack Donovan
  17. 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. 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. 19. Cycle Accurate and Cycle Approximated
  20. 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. 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. 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. 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. 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. 25. Different Stages of TLM Dan Gajsky, Lukai Cai CODES 2003
  26. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 37. Example used by Gajski Specification Model (SM) or System Architecture Model (SAM)
  38. 38. Example used by Gajski Component Assembly Model (CAM)
  39. 39. Example used by Gajski Bus Assembly Model (BAM)
  40. 40. Example used by Gajski Set up the Timing Spec.
  41. 41. Example used by Gajski Bus Functional Model (BFM)
  42. 42. Example used by Gajski Cycle-Accurate Computation Model (CACM)
  43. 43. Example used by Gajski CAIM
  44. 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. 45. Characteristics of TLM models By Gajski’s definition
  46. 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. 47. Basic SoC Design Flow
  48. 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. 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. 50. Speed Comparison of Different ESL/EDA approaches Modified from ARM Chris Lennard, Davorin Mista FPGA Based Developers 50
  51. 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. 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. 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. 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. 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. 56. Development time • If development time is not saved – Do not use ESL, or – There must be something wrong
  57. 57. Co-Design Environment Eclipse IDE Appilication Hardware Models (Simulator) Software gdb Simulator gdb Native System (x86)
  58. 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. 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. 60. Detailed Flow: Early stage
  61. 61. TLM/ESL Modeling stage
  62. 62. Final Integration Stage
  63. 63. Verification and Debugging
  64. 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. 65. Commercial tool: SOC Designer Work Space Cache Profiling window Waveform Viewer Assembly code window Memory maps
  66. 66. Commercial tool: CoWare
  67. 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. 68. SCREAM Lab OpenESL
  69. 69. SCREAM Lab OpenESL
  70. 70. FPGA tool: Berkeley BEE2
  71. 71. FPGA tool: NCKU Multicore
  72. 72. FPGA tool: SMIMS
  73. 73. Where are we going?
  74. 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. 75. Let’s kick off