This document discusses various system design techniques and networks. It begins with an overview of design methodologies like waterfall model, spiral model, and concurrent engineering. It then covers topics like requirements analysis, specifications, CRC cards for system analysis, and quality assurance techniques. It discusses several distributed embedded systems including CAN bus, I2C, Ethernet, and the Internet. It concludes with sections on multiprocessor system-on-chips and shared memory multiprocessors.

1. SYSTEM DESIGN TECHNIQUES AND
NETWORKS
T.Ramprakash
AP/ECE
Ramco Institute of Technology
Rajapalayam

2. Flow of syllabus
• Design methodologies
– Design flows
– Requirement Analysis
– Specifications
• System Analysis and Architecture Design – CRC cards
• Quality Assurance Techniques
• Distributed Embedded Systems
– CAN Bus
– I2C
– Ethernet
– Internet
• MPSoCs and shared memory multiprocessors.

3. Design Methodologies
• The obvious goal of a design flow is to create a
product that does something useful
• Typical specification for a product will include
– Functionality
– Manufacturing cost
– Performance
– Power consumption
– Time to market
– Design cost
– Quality

4. Design flow
• Design flow is a sequence of steps to be followed
during a design
• Some common system software developments
are as follows
– Waterfall model
– Spiral Model
– Successive refinement
– Hierarchical design flow
– Concurrent engineering

5. Waterfall model

6. Waterfall model
• The waterfall development model consists of
five major phases:
– Requirements analysis
• Determines the basic characteristics of the system;
– Architecture design
• Decomposes the functionality into major components;
– Coding
• implements the pieces and integrates them;
– Testing
• uncovers bugs;
– Maintenance
• Entails deployment in the field, bug fixes, and upgrades.

7. Waterfall model
• The waterfall model gets its name from the
largely one-way flow of work and information
from higher levels of abstraction to more
detailed design steps.
• It is unrealistic design process

8. Spiral Model

9. Spiral Model
• Alternative model of software development
called the spiral model
• While the waterfall model assumes that the
system is built once in its entirety, the spiral
model assumes that several versions of the
system will be built.
• Early systems will be simple mock-ups
constructed to aid designers’ intuition and to
build experience with the system.
• As design progresses, more complex systems
will be constructed.

10. Spiral Model
• At each level of design, the designers go through
requirements, construction and testing phases.
• At later stages when more complete versions of the
system are constructed, each phase requires more
work, widening the design spiral.
• The first cycles at the top of the spiral are very
small and short, while the final cycles at the spiral’s
bottom add detail learned from the earlier cycles of
the spiral.
• The spiral model is more realistic than the waterfall
model
• However, a spiral methodology with too many
spirals may take too long when design time is a
major requirement.

11. Successive refinement

12. Hardware software Design Methodology

13. Hierarchical design flow

14. Hierarchical design flow
• Many complex embedded systems are
themselves built of smaller designs
• The complete system may require the design
of significant software components, custom
logic, Application Specific Integrated Circuits,
and so on, and these in turn may be built from
smaller components that need to be designed

15. Concurrent Engineering
• When designing a large system along with many
people, it is easy to lose track of the complete
design flow
• Concurrent engineering attempts to take a
broader approach and optimize the total flow
• Reduced design time is an important goal for
concurrent engineering
• It tries to eliminate “over-the-wall” design steps,
in which one designer performs an isolated task
and then throws the result over the wall to the
next designer, with little interaction between the
two

16. Concurrent Engineering
• Concurrent engineering efforts are comprised of
several elements:
– Cross-functional teams
– Concurrent product realization
– Doing several things at once, such as designing various subsystems
simultaneously (reducing design time)
– Incremental information sharing
– As soon as new information becomes available, it is shared and
integrated into the design
– Integrated project management
– ensures that someone is responsible for the entire project, and that
responsibility is not abdicated once one aspect of the work is done.
– Early and continual supplier involvement
– Early and continual customer focus

17. Requirement Analysis
• Requirements  informal descriptions of what the
customer wants
• Specifications more detailed, precise, and consistent
descriptions of the system that can be used
to create the architecture
• The overall goal of creating a requirements
document is effective communication between
the customers and the designers

18. Requirement Analysis
• We have two types of requirements:
– functional
– Non functional
• A functional requirement states what the system
must do, such as compute an FFT.
• A non functional requirement can be any number
of other attributes, including physical size, cost,
power consumption, design time, reliability, and
so on

19. Requirement Analysis
• A good set of requirements should meet several tests:
– Correctness
– Unambiguousness
• The requirements document should be clear and have only one plain
language interpretation.
– Completeness
• All requirements should be included
– Verifiability
• There should be a cost-effective way to ensure that each requirement is
satisfied in the final product
– Consistency
• One requirement should not contradict another requirement
– Modifiability
• The requirements document should be structured so that it can be
modified to meet changing requirements without losing consistency,
verifiability, and so forth
– Traceability

20. Requirement Analysis
• We should be able to trace backward from the
requirements to know why each requirement exists.
• We should also be able to trace forward from
documents created before the requirements (e.g.,
marketing memos) to understand how they relate to
the final requirements.
• We should be able to trace forward to understand
how each requirement is satisfied in the
implementation.
• We should also be able to trace backward from the
implementation to know which requirements they
were intended to satisfy.

21. Specifications
• It is more detailed, precise, and consistent
descriptions of the system that can be used to
create the architecture
– Control-oriented specification language
– Advanced Specification

22. Control-oriented specification language
• SDL Language
• State charts
• AND/OR tables

23. SDL Language

24. Statecharts

25. Statecharts

26. AND/OR table

27. System Analysis and Architecture Design
• It deals “How to turn a specification into an
architecture design”.
• One such method is CRC card

28. System Analysis and Architecture Design
• CRC card stands for
– Classes
– Responsibilities
– Collaborators

29. CRC Cards
• Standard size is 3” X 5”
• The essence of CRC card is
– Write on these cards,
– Talk about them,
– Update the cards until they are satisfied with results

30. CRC Cards

31. CRC Cards
• The steps to analyze a system
– Develop an initial list of classes
– Write an initial list of responsibilities and collaborators
– Create some usage scenarios
– Walk through scenarios
– Refine the classes, responsibilities and collaborators
– Add class relationships

32. Elevator system CRC Cards

33. Quality Assurance Techniques

34. Case study
• Therac-25 Medical Imaging System

35. Case study
• Therac-25 Medical Imaging System

36. Quality Assurance Techniques
• Quality Assurance Process
• Verifying Requirements and Specifications
• Design Review

37. Quality Assurance Process
• ISO 9000  set of quality standards for industries
–Process is crucial
• (Should know what steps are to be followed to create a high quality product)
–Documentation is important
–Communication is important

38. Quality Assurance Process
• Capability Maturity Model (CMM)  used to measure
the quality of software development process
– Initial (depends on the efforts of individuals, not the organization)
– Repeatable (helps management to trace the cost, scheduling, etc.,)
– Defined (Engineering processes are documented and standardized)
– Managed (detailed measurements of development process)
– Optimizing (continually improve the organization's process)

39. Verifying specification and Requirements

40. Design review format
• Designers (present their design to the rest of the team for review)
• Review leader (coordinates the pre-meeting activities, the design
review itself, and the post-meeting follow-up.)
• Review scribe (records the minutes of the meeting so that designers
and others know which problems need to be fixed)
• Review audience (Audience members will naturally include other
members of the project)

41. Distributed Embedded Systems

42. Distributed Embedded Systems

43. Distributed Embedded Systems
• Embedded system Architecture
• CAN Bus
• I2C Bus
• Ethernet
• Internet

44. Embedded system Architecture

45. Embedded system Architecture
• Network Abstraction

46. CAN Bus
• CAN is Control Area Network
• example - a network of embedded systems in
automobile
• A automobile uses a number of distributed embedded
controllers
• The controllers provide the controls for brakes,
engines, electrical power, lamps, temperature, air
conditioning, car gate, front display panel, meters
display panels and cruising

47. CAN Bus

48. CAN Bus

49. CAN Bus

50. CAN Protocol defined frame bits
• First field of 12 bits ─'arbitration field.
– 11-bit destination address and RTR bit (Remote
Transmission Request)
– Destination device address specified in an 11-bit
sub-field and whether the data byte being sent is
a data for the device or a request to the device in
1-bit sub-field.
– Maximum 211 devices can connect a CAN
controller in case of 11-bit address field standard
– If RTR  1, the packet is for the device at
destination address
– If RTR 0, the packet is a request for the data
from the device

51. CAN Protocol defined frame bits
• Second field of 6 bits─ control field.
– The first bit is for the identifier’s extension.
– The second bit is always '1'.
– The last 4 bits specify code for data length

52. CAN Protocol defined frame bits
• Third field of 0 to 64 bits
– Its length depends on the data length code in the
control field.

53. CAN Protocol defined frame bits
• Fourth field of 16 bits─ CRC (Cyclic
Redundancy Check) bits.
– The receiver node uses it to detect the errors, if
any, during the transmission

54. CAN Protocol defined frame bits
• Fifth field of 2 bits
• First bit 'ACK slot'
– ACK = '1' and receiver sends back '0' in this slot
when the receiver detects an error in the
reception. Sender after sensing '0' in the ACK slot,
generally retransmits the data frame.
• Second bit ‘Ack delimiter’
– Second bit 'ACK delimiter' bit. It signals the end of
ACK field. If the transmitting node does not
receive any acknowledgement of data frame
within a specified time slot, it should retransmit.

55. CAN Protocol defined frame bits
• Sixth field of 7-bits
– end- of- the frame specification and has seven '0's

56. CAN Protocol defined frame bits
• Interframe Bits
– Minimum 3 bits separate two CAN frames

57. I2C
• The name stands for “Inter - Integrated Circuit
Bus”
• A Small Area Network connecting ICs and
other electronic systems
• Developed by Philips Semiconductors
• I2C can support up to 128 slave Devices
• Today, a variety of devices are available with
I2C Interfaces
– Microcontroller, EEPROM, Real-Timer, interface
chips, LCD driver, A/D converter

58. I2C

59. I2C
• Used for moving data simply and quickly from one
device to another
• Low cost, easy to implement and of moderate speed
• Serial Interface
• I2C is a synchronous protocol that allows a master
device to initiate communication with a slave device.
• I2C is also bi-directional by which data is sent either
direction on the serial data line (SDA) by the master
or slave.

60. I2C
• I2C is a Master-Slave protocol that allows
– The Master device controls the clock (SCL)
– The slave devices may hold the clock low to
prevent data transfer
– No data is transferred unless a clock signal is
present
– All slaves are controlled by the master clock

61. I2C
• SDA
– This signal is known as Serial Data. Any data sent
from one device to another goes on this line
• SCL
– This is the Serial Clock signal. It is generated by the
master device and controls when data is sent and
when it is read.

62. I2C distance
• Synchronous Serial Communication
– 400 kbps up to 2 m and
– 100 kbps for longer distances

63. I2C Bus operation
• SDA line Transmits/Receives data bits (MSB is sent
first)
• Data in SDA line is stable during clock (SCL) high
• Serial clock is driven by the master
• Acknowledgment bit is driven by the receiver after
the end of reception
• If the receiver does not acknowledge, SDA line
remains high
SDA
SCL
LSBMSB
ACK driven by
receiver

64. I2C Bus operation
• The format of I2C bus transfers

65. Start Bit
• Initializes I2C Bus
• SDA is pulled low, then SCL is pulled low

66. Stop Bit
• Releases I2C Bus
• SCL is released first, then SDA is released

67. Control bits
• The start bit is followed 7 bit slave address
• Address bit is followed by R/W bit
• If R/W=0, subsequent bytes transmitted on
the bus will be written by the controller to the
selected peripheral
• If R/W=1, subsequent bytes will be sent by the
selected peripheral and read by the controller
R/W
Slave Address

68. I2C typical message format

69. I2C typical message format
• For peripheral chip that contains more than
one internal register or memory address, the
PIC will typically write a second byte to the
chip to set a pointer to the selected internal
register or the consecutive addresses that
follow it

70. I2C typical message format

71. I2C Advantages
• It is faster than asynchronous serial communication
• Number of pins required for communication is less
(only 2 pins)
• I2C supports multi master system
• I2C supports up to 128 slave devices
• I2C supports slave acknowledgment

72. I2C Disadvantages
• Communication is more complex than UART or SPI
• I2C draws more power than other serial
communication
• Slower operational devices can slower the operations
of faster speed devices
• I2C bus can result in entire bus hanging
• I2C bus does not suits long range

73. Ethernet
• Very widely used as a local area network for
general purpose computing.
• Particularly useful when PCs are used as
platforms

74. Ethernet
• Ethernet are not synchronized (They can send their bits at
any time)
• If two nodes decide to transmit at the same time, the
message will be ruined
• Carrier Sense Multiple Access with Collision Detection
• A node that has message waits for the bus to become silent
and then starts transmitting
• If it hears another transmission that interferes with its
transmission, it stops transmitting and wait to retransmit
• The waiting time is random

75. Ethernet CSMA/CD algorithm

76. Exponential Backoff times

77. Ethernet Packet format
preamble
start
frame
source
adrs
dest
adrs
data
payload
length padding CRC

78. Disadvantages
• Ethernet was not designed to support real time
operations
• The exponential backoff scheme cannot guarantee
delivery time of any data
• Three ways to reduce the variance in Ethernet’s packet
delivery time
– Suppress collisions on the network
– Reduce the number of collisions
– Resolve collisions deterministically

79. Internet
• Connectionless communication
• Packet based communication
• Internet packet will travel over several
different networks from source to destination
• IP allows data to flow seamlessly through
these networks from one end user to another

80. Protocol utilization in Internet Communication
A node that transmits data among
different types of networks is
known as a router

81. IP Packet structure
The maximum
total length of
the header and
data payload is
65,535 bytes

82. IP Packet structure
• Internet address is 32 bits in early version
• 128 bits in IPv6
• Typically written as xxx.xx.xx.xx

83. Internet service stack
File Transport Protocol
Hypertext Transport
Protocol (HTTP) Simple
Mail Transfer Protocol
Transmission
Control Protocol (TCP)
Simple Network
Management Protocol.
User Datagram Protocol

84. MPSoCs and Shared memory multiprocessors
• MPSoC  Multi Processor System on Chip
• Shared memory processors  well suited for large amount of
data to be processed
• Most MPSoCs are shared memory systems
• Two types of MPSoCs
– Symmetric
– Hetrogeneous
• Heterogeneous multiprocessors use less energy, are less
expensive

85. TI TMS320DM816x DaVinci Board

86. Accelerated systems
• Use additional computational unit dedicated
to some functions
– Hardwired logic
– Extra CPU
• Hardware/software co-design: joint design of
hardware and software architectures

87. Accelerated system design
• First, determine whether the system really
needs to be accelerated????
– How much faster is the accelerator on the core
function?
• Design the accelerator itself
• Design CPU interface to accelerator

88. Accelerated system architecture

89. Accelerator implementations
• Application-specific integrated circuit(ASIC)
• Field-programmable gate array (FPGA)
• Standard component
– Example: graphics processor

90. Xilinx Zynq-7000
• AMBA bus connects to CPUs and FPGA fabric

91. Accelerator/CPU interface
• Accelerator registers provide control registers
for CPU
• Data registers can be used for small data
objects
• Accelerator may include special-purpose
read/write logic
– Especially valuable for large data transfers

92. Accelerator Performance Analysis
• Critical parameter is speedup: how much
faster is the system with the accelerator?
• Must take into account:
– Accelerator execution time
– Data transfer time
– Synchronization with the master CPU

93. Accelerator execution time
• Total accelerator execution time:
taccel = tin + tx + tout
Data input
Accelerated
computation
Data output

94. Accelerator speedup
• Assume loop is executed n times.
• Compare accelerated system to non-
accelerated system:
• The Speedup S for a kernel can be written as:
S = n(tCPU - taccel)
= n[tCPU - (tin + tx + tout)]
Execution time on CPU

95. Single- vs. multi-threaded
• One critical factor is available parallelism:
– single-threaded/blocking: CPU waits for accelerator;
– multithreaded/non-blocking: CPU continues to execute
along with accelerator.
• To multithread, CPU must have useful work to do.
– But software must also support multithreading.

96. Total execution time
• Single-threaded: • Multi-threaded:
P2
P1
A1
P3
P4
P2
P1
A1
P3
P4

97. Total execution time

98. Execution time analysis
• Single-threaded:
– Count execution time of
all component
processes.
• Multi-threaded:
– Find longest path
through execution.

99. Reference
1. Marilyn Wolf, “Computers as Components -
Principles of Embedded Computing System
Design”, Third Edition, Morgan Kaufmann
Publisher (An imprint from Elsevier), 2012.
2. Wayne Wolf, “Computers as Components -
Principles of Embedded Computer System
Design”, Morgan Kaufmann, 2nd Edition,
2008.
99