Institut für Integrierte Systeme

Integrated Systems Laboratory

Department of Information Technology and Electrical Engineering

VLSI II:
Design of Very Large Scale Integration Circuits
227-0147-00L

Exercise 4

Design Review and Block Diagrams

Prof. L. Benini
F. Gürkaynak

Last Changed: 2018-03-20 21:50:37 +0100

Reminder:
With the execution of this training you declare that you understand and accept the regulations about using
CAE/CAD software installations at the ETH Zurich. These regulations can be read anytime at
http://eda.ee.ethz.ch/index.php/Regulations.
1 Introduction
Welcome to this week’s exercise! As a digital designer, it is very important that you can properly document your
design at different levels of abstraction. This allows other people to take over your work, or future you to easily
get back into the design. Furthermore when you are working towards a chip, you will be required to estimate
and predict various information about your design. This includes for example its size and speed, pinout, or the
macro cells it requires. The exercise is structured as follows:
• Section 2 shows you how to document your design as block diagrams.
This should take you roughly 2h (2/3 of the exercise).
• Section 3 shows you how to prepare for the design review.
This should take you roughly 1h (1/3 of the exercise).
If you are pursuing a chip project, we recommend that you skip ahead to the second part after 2h.

Student Task 1:
• Change to your home directory and install the training files with the script provided:
sh > cd ~
sh > /home/vlsi2/ex04/install.sh

• Change to the design directory and start the cockpit:

sh > cd ex04
sh > icdesign umcL65 -update all &

2
2 Block Diagrams
Student Task 2: You will be drawing quite a few block diagrams. Have pen and paper ready!

Always draw your block diagrams with pen and paper first. Afterwards, consider using a tool like TGIF or
Inkscape to create a clean digital version of it. Your project supervisors will be happy to help you with this.
People are generally much happier with a good hand-drawn schematic than a poor digital one. Always start
with pen and paper.

2.1 The Basics

Let us start by recapitulating the basic digital circuit elements and how to draw them. Generally, we draw
subcircuits as boxes, with the inputs on the left and the outputs on the right. Like parlay, this is more a
guideline rather than a rule. As you will see later, it is usually easier to indicate the direction of a port with an
arrow and then group the ports logically together. The following figure shows how the ports can be annotated
with polarity and sensitivity information:

A A A A A A

Active High Active Low Rising Edge High Level Falling Edge Low Level
Triggered Triggered Triggered Triggered

Student Task 3: Quickly think of an example for each of the six cases above. Consider the various types
of sequential elements you know.
• Active High:
• Active Low:
• Rising Edge Triggered:
• High Level Triggered:
• Falling Edge Triggered:
• Low Level Triggered:

Always remember to properly label your input and output ports. In many cases you do not need to explicitly draw
connections for the clock and reset pins, unless you have multiple clocks or resets in your design. Nevertheless,
you must include them as ports.
From your bachelor’s courses you should remember the basic digital gates. Let us quickly build a ”library” of
gates for later reference.

3
Student Task 4: Draw each of the following gates. Don’t forget to label the ports unless there is absolutely
no chance of mistaking one for the other.
Buffer: AND: OR:

Inverter: NAND: NOR:

XOR: D-Flip-Flop:

NXOR: D-Latch:

Show your drawings to an assistant.

4
This scheme works well for basic gates and storage elements. However as the subcircuits in your diagram
grow in complexity, so will the number of ports leading in and out of them. If your subcircuit uses multiple
handshaking interfaces for example, it might make more sense to draw related ports close together, rather
than splitting them up into inputs on the left and outputs on the right. To reduce the clutter in the diagram,
multi-bit signals such as integer numbers should be drawn as single thick lines, with an annotation indicating
how many bits there are to the signal. We suggest the following scheme to indicate port directions and annotate
signals:

32 D Q
A A A A B Clk_CI
CLK

Input Output Bidirectional Multi-Bit Signal Clock Signal Flip-Flop

Port Port Port

Consider the following entity as an example. As you can see it has multiple inputs and outputs grouped together
by interface and function. It is usually a good idea to group together related pins both in code and diagrams.
entity MysteryBox is
port (
Rst_RBI : in std_logic;
Clk_CI : in std_logic;

InputData_DI : in std_logic_vector(41 downto 0);

InputValid_SI : in std_logic;
InputReady_SO : out std_logic;

CfgAddr_DI : in std_logic_vector(7 downto 0);

CfgWrEn_SI : in std_logic;
CfgWrData_DI : in std_logic_vector(31 downto 0);
CfgRdData_DO : out std_logic_vector(31 downto 0);

OutputData_DO : out std_logic_vector(41 downto 0);

OutputValid_SO : out std_logic;
OutputReady_SI : in std_logic
);
end entity;

5
 Student Task 5: Draw the block corresponding to the MysteryBox entity. Don’t forget to add the name
of the entity.

Show your drawing to an assistant.

Note that circuit design should always start with pencil and a blank sheet of paper. Coming up with architectures
and circuit diagrams is where the engineering lies; writing the associated VHDL/SystemVerilog code should be
more or less “typing down” what you see in your drawings. It’s also much easier to communicate to you and
other people how the circuit works based on a drawing, rather than code.

2.2 Counter
So far we have looked at drawing the “outside view” of gates and blocks, and indicating the port directions and
functions. Let us now look at how we can document the inner workings of a simple counter. Even though we
are now interested in the internals of a block, it is important that you still describe how it connects to the outside
world. Consider the following example of a flip-flop:

D-Flip-Flop

D D Q D Q Q

RST RST
G G

RSTn

CLK

6
If your circuit contains well-known arithmetic operations such as negation, addition, subtraction, multiplication,
division, left and right shifts, etc., we suggest that you draw them as bubbles with the operation indicated inside.
Use arrows to indicate which signals are the input operands, and which is the output. For non-commutative
operations such as division and shifts, consider explicitly naming the inputs to avoid confusion. It is also legal
to come up with your own symbols, as long as you clearly document their semantics in the diagram. Consider
the following examples:

A B A B A B A A B A B

A 0
A B Z
B 1
S
Z Z Z Z Z Z

Addition Subtraction Multiplication Negation Division Shift Multiplexer

Let us now look at the following simple counter:

entity Counter is
port (
Rst_RBI : in std_logic;
Clk_CI : in std_logic;
Enable_SI : in std_logic;
Count_DO : out std_logic_vector(7 downto 0)
);
end entity;

architecture RTL of Counter is

signal Count_DP, Count_DN : std_logic_vector(7 downto 0);
begin
Count_DN <= std_logic_vector(unsigned(Count_DP) + 1);
Count_DO <= Count_DP;

process (Clk_CI, Rst_RBI) begin

if Rst_RBI = ’0’ then
Count_DP <= (others => ’0’);
elsif rising_edge(Clk_CI) and Enable_SI = ’1’ begin
Count_DP <= Count_DN;
end if;
end process;
end architecture;

7
 Student Task 6: Draw the block diagram of the Counter entity. Think about how you can draw a multi-bit
flip-flop. Consider labeling internal signals as well, not just ports.

Show your drawing to an assistant.

2.3 Hierarchical Designs

The complexity of circuits can quickly get out of hand. The following is a schematic diagram generated by
Synopsys Design Compiler. You can find the corresponding source code in sourcecode/crc_lfsr.vhd,
sourcecode/crc_hasher.vhd, and sourcecode/crc_stream.vhd. As you can see, the design is fairly
hierarchic:
• crc_lfsr is a loadable LFSR,
• crc_hasher uses the LFSR to compute a hash over input values, and
• crc_stream uses the hasher to append a signature to streams of data bytes.
The shown schematic diagram is a flattened version of the design, which is hard to understand. Part of this is
due to the noise introduced by the many signal wires, part of it is due to the lack of hierarchy. We will now try
to come up with a better schematic for the design.

8
An entity instantiations in your code is usually a good indication that you should draw this entity as an opaque
box in your block diagram, and provide an additional drawing detailing the internals of the entity. This also
holds in the other direction: If it is more comfortable for you to draw something as an opaque box, this is a
good indication that the corresponding code might be better off in a separate entity. These are just hints to
get you started; in practice you must decide case-by-case where to introduce hierarchy, and develop your own
style.

Student Task 7: Let us start by taking a look at crc_lfsr, which is a leaf node in the hierarchy. Answer
the following questions:
• How many flip-flops are there?
• What kind of reset do the flip-flops have?
• On which edge do the flip-flops trigger?
• Do the flip-flops have an enable pin?
• What and how many other logic gates are there?

9
 Student Task 8: Draw the block diagram of the crc_lfsr entity. Consider using multi-bit wires where
possible. Don’t forget to label your input and output pins, and the entire block.

Show your drawing to an assistant.

Your designs will often contain complex combinatorial circuitry, for example to compute the next state of a finite
state machine or some other non-trivial logic function. These are often very hard to draw. The “soup” of logic
gates that they decompose into often does not really help you understand their function and just introduce
confusion. For this reason we suggest that you abstract combinatorial circuitry and FSMs in the following
manner, and either provide a textual description in the drawing or refer the reader to the source code:

A
B X A X
Y
C B Y
D

Complex Combinatorial Finite State Machine

Circuit

10
Student Task 9: Now let us look at crc_hasher, which makes use of the LFSR above. Answer the
following questions:
• How many instances of crc_lfsr are there?
• What kind of gate drives In_D?
• What is the purpose of Sel_S?

Student Task 10: Draw the block diagram of the crc_hasher entity. We suggest you add the entity
name (crc_*) above and the instance name (i_*) below subblocks of your drawing.

Show your drawing to an assistant.

11
 Student Task 11: As the final step, draw the block diagram of the crc_stream entity.

Show your drawing to an assistant.

When you abstract away an FSM in your future diagrams, consider drawing the state graph of the FSM as a
separate diagram. You can refer to the signal names in the drawing, making it easy for you and your readers
to follow.
Always make good use of hierarchy in your block diagrams, and try to introduce useful layers of abstraction.
If you draw a very high-level schematic of a processor for example, it is probably a bad idea to include every
single wire of the processor. Rather, abstract away the details as black boxes and describe their inner workings
in another diagram.

12
2.4 Complex Buses
We can take the concept of abstraction even further. As your designs grow, you will want to bundle up signals
into buses that adhere to a well-defined protocol. This can be as simple as a ready/valid handshake where
the sender and receiver indicate to each other their ability to produce or consume data. Doing so allows you
to simplify your block diagrams: If a bunch of signals adheres to a protocol, you may simply draw them as one
line and annotate which protocol they use. Consider the following example:

Master Slave
8
OutData_DO InData_DI Master Slave
8
OutLast_SO InLast_SI
Out_KO In_KI
OutValid_SO InValid_SI
OutReady_SI InReady_SO

Note that a bus will likely contain both input and output signals, e.g. the ready and valid signals. However,
there is usually a clear direction of the flow of information. In the above example, the bus “master” drives the
data and valid signals, while the bus “slave” drives the ready signal. Thus data always flows from the master
to the slave. We suggest that you use the arrow direction of bus ports to indicate the flow of information.
These protocols are not limited to simple handshakes, however. Let us have a look at the AXI-Lite1 interface,
which allows subcircuits to exchange data. It uses addresses to allow the sender to indicate to the receiver
what exact piece of information it is interested in. The signal list is as follows:

Signal Name Width Master Slave

AWVALID 1 out in
AWREADY 1 in out
AWADDR AW out in
AWPROT 1 out in
WVALID 1 out in
WREADY 1 in out
WDATA DW out in
WSTRB DW/8 out in
BVALID 1 in out
BREADY 1 out in
BRESP 2 in out
ARVALID 1 out in
ARREADY 1 in out
ARADDR AW out in
ARPROT 1 out in
RVALID 1 in out
RREADY 1 out in
RDATA DW in out
RRESP 2 in out

The exact meaning of each of the 19 signals is not important. However notice that the interface has two
parameters: AW which indicates the width of the address in bits, and DW which indicates the width of the
data in bits. This means that in your block diagrams you can fully represent all 19 of these signals by a single
line, as long as
• you specify that the line is an AXI-Lite bus,
• you specify AW ,
• you specify DW , and
• you indicate the master and slave side with the direction of the port arrows.
1 http://www.gstitt.ece.ufl.edu/courses/fall15/eel4720_5721/labs/refs/AXI4_specification.pdf

13
 Student Task 12: Draw the block diagram of the entity system_on_chip. You can find the corresponding
source code in sourcecode/system_on_chip.vhd.

Show your drawing to an assistant.

As you have seen, introducing reasonable bus protocols can help keep your diagrams simple and clean, while
still communicating the fundamental message.

2.5 Multiple Clock Domains

Having multiple clocks notoriously complicates your circuit. Each signal that crosses from one clock domain
into the other must be treated with great care during synthesis and place-and-route. It is therefore crucial for
such designs that the clock domains and the signals connecting between them are easily identifiable. Block

14
diagrams can help you with this. We suggest that you try to clearly separate circuits running on different clocks,
and indicate a clear boundary between the clock domains with a line. See the following example:

ClkA ClkB

D Q D Q
A_DI B_DO

ClkA_CI ClkB_CI

Clock Domain Crossing

Take a look at the SystemVerilog code in sourcecode/cdc_2phase.sv. This is a small circuit that can
safely move data between two clock domains. Your fellow students and the assistants are happy to help you if
you are struggling with reading the SystemVerilog code.

Student Task 13: Draw the block diagram of the module cdc_2phase. Pay attention to the two separate
clocks, and indicate the clock domain boundary with a line through your diagram.

Show your drawing to an assistant.

15
2.6 Checklist
As a final reference for your block diagram artistry, check if your future drawings satisfy the following checklist:
• Are clock and reset easily identifiable?
• If you omitted the clock/reset wires, is it clear to which clock/reset the pins in your design are connected?
• Are internal signals properly labeled?
• For each block in the design, can you tell the name of its entity name (e.g. crc_lfsr)?
• For each block in the design, can you tell the instance name (e.g. i_lfsr)?
• Black boxes:
– Is there a separate diagram detailing its inner workings, or a reference to more information?
– Combinatorial clouds: Is there a description or a reference to code?
– FSMs: Is there a description, separate state graph, or a reference to code?
• Ports:
– Can you easily tell which are inputs and outputs?
• Complex Buses:
– Can you tell what communication protocol is used?
– Are all parameters of the protocol specified (e.g. data width)?
– Can you identify sender/master/initiator and receiver/slave/target?
• Multiple clocks:
– Is the boundary between clock domains clearly identifiable?
– Are all signals that pass from one domain into the other easily identifiable?

16
3 Preparing for the Design Review
3.1 Pinout and Padframe
While working on a design, it is important that you keep in mind how it will connect to the outside world. The
number of pins on a chip may be a precious resource: An average student chip may have multiple 100’000
gates, but only a few dozen pins accessible from outside the package.

Student Task 14: Familiarize yourself with the filter design in sourcecode/filter/ that you have met
in an earlier exercise. The top-level entity is in sourcecode/filter_top.vhd.

Student Task 15: The entity filter_top is the top-level that will be taped out as a chip. Look at the
entity declaration and answer the following questions:
• What is the number of input pins?
• What is the number of output pins?

Now let us jump ahead in the flow a bit and assume that you have run your design through placement and
routing. You have also described the pinout of your design in encounter/src/filter_chip_ord.txt
and generated the padframe with the tools provided by the DZ.

Student Task 16: Take a look at the generated padframe in encounter/src/filter_chip_img_ord\

.pdf. Make sure you can find all of the input and output pins of the previous exercise. What additional
groupspins are there on the padframe? What do they do?

Discuss with an assistant.

Keep the additional pins in mind when planning the pinout of your design.

3.2 Macro Cells

Any of your designs will likely require some memory, which usually come in the form of pregenerated macro
cells emitted by a memory compiler. Memories can take up a significant amount of the overall area of your chip.
You should therefore be able to estimate the area that the macro cells in your design require, and estimate the
overall size of your design.
We have prepared a synthesized version of the filter design for you to inspect things.

Student Task 17: Start Synopsys Design Compiler and load the synthesized design with the following
command:
dcs > read_ddc DDC/filter_5_8_final.ddc
dcs > current_design filter_top

17
 Student Task 18: Use the report_area command to get information about the size of the current
design.
• What area is occupied by macro cells?
• What area is occupied by regular gates?
• How big is the design overall?

Student Task 19: The only memory macro used is called SHKA65_8192X32X1CM16. How many in-
stances of this macro are there in the design, and what are their names? Consider taking a look at the
get_references command.

Memory macros require special care in the backend design flow. You should always be aware of the total
number of memory macros on your chip, and their names/location in the design hierarchy.

3.3 Final Considerations

Wire capacitances and delays: Keep in mind that the area and timing you determine during synthesis is an
optimistic estimate. During placement and routing additional effects such as wire capacitances and delays
will become visible. The backend tool changes the driving strength of cells and inserts additional buffers to
make your design meet its timing. This means that the area will generally increase to meet the same timing
constraints.

Utilization: The area reported by Synopsys is just the sum of all gates and macros. This is a lower bound on
the area required: The placement and routing process will not be able to place your gates and macros without
gaps in between them. The sum of all gate and macro areas divided by the rectangular area occupied after
placement is called the “Utilization”. Expect that your design will have a utilization between 70% and 85%; this
means that your design will be between 1.2x and 1.4x larger than what Synopsys reports. Keep this in mind
when trying to squeeze out the last drop of area for your design.

Have Schematics and Numbers Ready: At the design review, have block diagrams of your design ready and
be prepared to report the expected area, number and size of macro cells, pinout, speed, and other figures of
merit.

Have fun!

E You are done with Exercise 4. Discuss your results with an assistant.
E

18