Browse Source

Added first embedded system exercize

Federico Amedeo Izzo 8 years ago
parent
commit
55eba727ac
1 changed files with 93 additions and 0 deletions
  1. 93 0
      Advanced OS & Embedded Sys/exe_01.md

+ 93 - 0
Advanced OS & Embedded Sys/exe_01.md

@@ -0,0 +1,93 @@
+# Advanced Operating Systems and Embedded Systems - exercise session 1
+#### Davide Zoni
+###### 13 October 2016
+## Embedded Systems - Multicore Design
+### Course structure
+Multi core architectures require an interconnection layer to be exploited fully.
+
+The course is structured in three parts:
+- On chip communication
+- Architectural simulation
+    Used to test architectural solutions without designing a complete RTL architecture.
+- RTL Design Verification and Simulation
+
+This course will be focused mainly on the power requirements, not covering power, reliability and timing
+for lack of time.
+
+__Exam structure__
+Written exam: 23 points
+Project + presentation: 9 points
+
+## Multi-core history
+From 2000-2005 the CPUs development began hitting the "frequency wall"
+And the power consumption and single thread performance limits aswell.
+
+But the market demands for more processing power, so the response
+was development of the multi-core architecture.
+
+#### Market and Energy Efficiency
+We have two conflicting needs.
+The market asks for devices that are able to run the same applications no
+matter what the underlying hardware.
+while the technology viewpoint says that on mobile phones we have limited resources,
+for example battery, so it's not easy to raise performance.
+
+__Reference book__: Low Power Methodology Manual, ARM&Synopsis, 2007
+
+Halving the size of transistor does not halve the power consumption,
+so reducing size brings to increasing the power density.
+
+## Realiability
+
+#### Escape Bugs:
+They are bugs that ship with the device, due to improper design, and they produce
+a different results from the specification.
+Simple architectures have less escape bugs, and usually the number rises as user discovers them.
+#### Hard Faults:
+Hardware damage due to not proper usage, ex: overvolting.
+
+To test an architecture for escape bugs you have to try all the inputs for all the possible states, because
+usually the CPUs are not *stateless*
+5Million flip-flops means 2^5million states.
+Usually __Bug Inspection__ is done partitioning the design and testing the more common states to be bug-free
+This testing is constrained by time-to-market. But later the verified portion can be expanded.
+
+### Multi-cores
+In general it is more likely to have multiple applications using few resuources, than a single application
+using more resources.
+
+## On-chip interconnects
+Usually the main types of traffic on *on-chip interconnections* are:
+- Data from *load* and *store* OPs
+- Data for cache coherence.
+
+### Different Architectures
+- __Point-to-point__ Used by intel since 2010 in i5 CPUs
+It is fast and simple but grows with n\*(n-1) to the number of cores
+
+- __Bus__ Simple but usually need a split architectures, for example a bus between
+CPU+L1 and L2 and a slower one between L2 and memory.
+
+- __Crossbar__ is a non-blocking architectures until two sender are reaching the same destination
+or vice versa.
+The crossbar is no more than a *multi-bus* architecture, it can be *full* or not.
+The idea is that the more bus used, the more power consumption we have.
+
+- __Network-on-chip__:
+
+
+## On-chip Bus Architecture
+The bus is manager by an __arbiter__ that is not shown usually on schemes.
+
+The bus is not a single line/wire a shown in theory
+In fact there are three different architectures:
+- Tri-state: 
+- AndOr: 
+- Mux: is the most common, it does not have native broadcast support, it can scale better
+but if i want to send a broadcast message (ex: for snooping) i have to consume more power.
+
+The BUS is the ideally placed in the between of the cores, to reduce the length of the wires.
+The BUS has also to avoid __deadlock__ situations.
+
+A __bridge__ is a piece of hardware that interfaces two different communication protocols.
+