Thiet Ke Vi Mach So Nang Cao Truong Quang Vinh Asic&Ip Ch1 (Cuuduongthancong - Com)

ĐẠI HỌC QUỐC GIA TP.
HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC BÁCH KHOA
KHOA ĐIỆN-ĐIỆN TỬ
BỘ MÔN KỸ THUẬT ĐIỆN TỬ
om
.c
ng
ASIC CHIP AND IP CORE DESIGN
co
an
th
ng
Chapter 1: Introduction to ASIC chip and IP design
o
du
1.1 ASIC and FPGA-based chip design flow

u
1.2 ASIC chip: analog versus digital

cu
1.3 IP design
1 CuuDuongThanCong.com https://fb.com/tailieudientucntt
• Hardware design flow
om
.c
ng
co
an
th
o ng
du
u
cu
Bộ môn Kỹ Thuật Điện Tử

CuuDuongThanCong.com https://fb.com/tailieudientucntt
2
om
.c
ng
co
Chip
an
Design
Flow th
o ng
du
u
cu

3
Feature ASIC design FPGA-based design
om
Language VHDL, Verilog, System C VHDL, Verilog, System C
.c
Simulator ModelSim, VCS ModelSim, VCS
Synthesis -Synopsys -Atera: Quartus, Maxplus
ng
-Cadence -Xilinx: Vivado, ISE
co
-Mentor Graphic -Lattice: Lattice Diamond
an
-Apollo, Astro, Daracula, DIVA, (tools depended on FPGA
th
Ansoft, Synplify ng vendors)
Advantage -for massive products -for prototype products
o
/disadvant -optimized in area, timing, -not optimized in area, timing,
du
ages power. power.

u
-Low cost solution in large -High cost solution in large

cu
quantities quantities
-slow to market -fast to market

4
1.2 ASIC Chip Design Flow: Analog
om
.c
ng
co
an
th
o ng
du
u
cu

CuuDuongThanCong.com
Source: http://www.vlsi.wpi.edu/cds/flow.html
https://fb.com/tailieudientucntt
5
Design Specification
• “Specs” typically describe:
om
– Expected functionality
.c
– Technology
Maximum allowable delay times
ng
–
Silicon area
co
–
– Power dissipation
an
• As an example specs for a one-bit binary full adder circuit:
th
ng
– Technology: 0.8 um twin-well CMOS
o
– Propagation delay of "sum" and "carry_out" signals < 1.2 ns (worst case)
du
– Transition times of "sum" and "carry_out" signals <1.2 ns (worst case)

u
– Circuit area < 1500 um^2

cu
– Dynamic power dissipation (at VDD=5 V and fmax=20 MHz) < 1 mW

6
Schematic Capture
• Schematic editors provide simple, intuitive means to draw, to
place and to connect individual components that make up your
om
design
.c
• The resulting schematics describe
ng
– main electrical properties of all components and their interconnections.
co
– the power supply and ground connections
an
– input and output signals
th
• Corresponding netlist is generated for later stages of the design
o ng
du
u
cu

7
Symbol Creation
• Each module can be assigned to a corresponding symbol
om
• This step largely simplifies the schematic representation of
.c
the overall system
ng
• Default symbol icon is a simple rectangular box with input and
co
output pins.
an
th
o ng
du
u
cu

8
Simulation
• Simulation is performed by Simulation tool
om
• The initial simulation phase also serves to detect some
.c
of the design errors
ng
– Missing connection
co
– Unintended crossing of two signals
an
th
o ng
du
u
cu

9
Mask Layout
• The creation of the mask layout is one of the most important
steps in the full-custom
om
• Physical layout design is very tightly linked to overall circuit
.c
performance (area, speed and power dissipation)
ng
• The detailed mask layout of logic gates requires a very intensive
co
and time-consuming design effort.
an
th
• The layout design must not violate any of the Layout Design
ng
Rules
o
du
u
cu

10
Design Rule Check (DRC)
• The mask layout must conform to a complex set of design rules
om
• Design Rule Checker, is used to detect any design rule violations
.c
• The designer must perform DRC, and make sure that all layout
ng
errors are eventually removed
co
an
th
o ng
du
u
cu

11
Design Rule Check (DRC)
om
.c
ng
co
an
th
o ng
du
u
cu

12
Circuit Extraction
• Circuit extraction is performed to create a detailed net-list for
the simulation tool.
om
• The extracted net-list can provide a very accurate estimation of
.c
the actual device dimensions and device parasitic
ng
• The extracted net-list file and parameters are subsequently used
co
in Layout-versus-Schematic comparison and in detailed
an
transistor-level simulations
th
o ng
du
u
cu

13
Layout Versus Schematic Check
• Layout-versus-Schematic (LVS) Check
om
– compare the original network with the one extracted from the mask
layout
.c
– prove that the two networks are indeed equivalent
ng
• A successful LVS will not guarantee that the extracted circuit
co
will actually satisfy the performance requirements.
an
th
o ng
du
u
cu

14
Post-Layout Simulation
• The detailed simulation performed using the extracted net-list will provide a
om
clear assessment of the circuit speed, the influence of circuit parasitic, and
any glitches.
.c
• Note that a satisfactory result in post-layout simulation is still no guarantee
ng
for a completely successful product
co
• the actual performance of the chip can only be verified by testing the
fabricated prototype
an
th
o ng
du
u
cu

15
ASIC chip design flow: digital
om
Front-end
.c
ng
co
an
th
Back-end
o ng
du
u
cu
Sign-off

16
ASIC chip design flow: digital
om
.c
ng
co
• Design Flow
an
by Synopsys
th
o ng
du
u
cu

17
Design Flow by Synopsys Design Compiler
1. The input design files for Design Compiler are often written
using Verilog or VHDL.
om
2. Design Compiler uses technology libraries, synthetic or
.c
DesignWare libraries, and symbol libraries to implement
ng
synthesis and to display synthesis results graphically.
co
3. During the synthesis process, Design Compiler translates the
an
HDL description to components extracted from the generic
th
technology (GTECH) library and DesignWare library.
ng
– The GTECH library consists of basic logic gates and flip-flops.
o
du
– The DesignWare library contains more complex cells such as adders

and comparators.
u
cu

18
Design Flow by Synopsys Design Compiler
4. After translating the HDL description to gates, Design
Compiler optimizes and maps the design to a specific
om
technology library, known as the target library.
.c
5. After the design is optimized, test synthesis is performed to
ng
integrate test logic into a design during logic synthesis.
co
6. After test synthesis, the design is ready for the place and
an
route tools, which place and interconnect cells in the design.
th
Based on the physical routing, the designer can back-
ng
annotate the design with actual interconnect delays; Design
o
du
Compiler can then resynthesize the design for more accurate

u
timing analysis.
cu

19
1.3 ASIC chip design flow: IP core
IP development environment IP release environment
Documents :
om
Specification :
Customize, re-configurable & SoC (Specification, timing/ block
(Architecture, block & timing diagram) diagram, datasheet, etc)
.c
etc
Packaged soft-IP :
RTL design coding :
ng
Logic simulation & debug (Encrypted Verilog files, installation
Soft
(Verilog, VHDL files) scripts & manual ) IP
co
Specification group
an
Gate synthesis & verification : Packaged soft-IP :
th
Synthesis, gate-level simulation & debug (Netlist file) (evaluation netlist, evaluation C-
model)
ng
Verification group
o
Layout :
Place & route, timing simulation & anal. Packaged hard-IP
du
(GDSII file)
Physical design group
Hard
u
cu
Release packaged IP core: IP

(Tích hợp trong một thư viện phần mềm phát triển SoC (ví dụ SOPC builder); hướng dẫn sử dụng, hướng dẫn cách tích hợp
IPs trong SoC, những application có thể với IPs.
Customize IP core theo yêu cầu sử dụng của khách hàng và mô phỏng trong SoC :
(GUI for Core Parameterization)
Bộ môn Kỹ Thuật Điện Tử CuuDuongThanCong.com https://fb.com/tailieudientucntt

20
Problems in SoC Era
• Productivity gap
om
• Time-to-market pressure
.c
• Increasing design complexity
ng
co
– HW/SW co-development
an
– System-level verification
th
ng
– Integration on various levels and areas of
o
expertise
du
– Timing closure due to deep submicron

u
cu
• Solution: Platform-based design with

reusable IPs
21
Design for Reuse IPs
• Design to maximize the flexibility
om
– configurable, parameterizable
.c
• Design for use in multiple technologies
ng
– synthesis script with a variety of libraries
co
– portable for new technologies
an
• Design with complete verification
process th
o ng
– robust and verified
du
• Design verified to a high level of

u
cu
confidence
– physical prototype, demo system
• Design with complete document set
22
Parameterized IP Design
• Why to parameterize IP?
om
– Provide flexibility in interface and functionality
.c
– Facilitate verification
ng
• Parameterizable types
co
– Logic/Constant functionality
an
– Structural functionality
th
• Bit-width, depth of FIFO, regulation and selection of submodule
o ng
– Design process functionality (mainly in test bench)
du
• Test events
u
• Events report (what, when and where)

cu
• Automatic check event

– Others✱ (Hardware component Modeling, 1996)

23
IP Generator/Compiler
• User specifies
om
– Power dissipation, code size, application performance, die size
– Types, numbers and sizes of functional unit, including processor
.c
– User-defined instructions.
ng
• Tool generates
co
– RTL code, diagnostics and test reference bench
an
– Synthesis, P&R scripts
th
– Instruction set simulator, C/C++ compiler, assembler, linker, debugger,
ng
profiler, initialization and self-test code
o
du
u
cu

24
Logic/Constant Functionality
• Logic Functionality • Constant Functionality
om
– Synthesizable code – Synthesizable code
assign tRC_limit=
.c
always @(posedge clock) begin
(`RC_CYC > (`RCD_CYC + burst_len)) ?
ng
if (reset==`ResetLevel) begin
`RC_CYC - (`RCD_CYC + burst_len) : 0;
co
…
end – For test bench
an
else begin always #(`T_CLK/2) clock = ~clock;
…
th …
ng
initial begin
end
o
#(`T_CLK) event_1;
du
end #(`T_CLK) event_2;

u
…
cu
end

25
Reusable Design – Test Suite
• Test events
om
– Automatically adjusted when IP design is changed
– Partition test events to reduce redundant cases when test for all
.c
allowable parameter sets at a time
ng
• Debug mode
co
– Test for the specific parameter set at a time
an
– Test for all allowable parameter sets at a time
–
th
Test for the specific functionality
ng
– Step control after the specific time point
o
du
• • Display mode of automatic checking

u
– display[0]: event current under test

cu
– display[1]: the time error occurs

– display[2]: expected value and actual value

26
Reusable Design - Test Bench
• Use Global Connector to configure desired test
om
• bench
.c
• – E.g.: bus topology of IEEE 1394
ng
co
an
th
o ng
du
u
cu

27
IP – Intellectual Property
om
.c
ng
co
an
th
o ng
du
u
cu

28
Coding Guidelines for IP Design
• The coding guidelines provide the following recommendations:
om
– Use simple constructs, basic types, and simple clocking schemes
.c
– Use a consistent coding style, consistent naming conventions, and a
consistent structure for processes and state machines
ng
– Use a regular partitioning scheme, with all module outputs registered
co
and with modules roughly of the same size
an
– Make the RTL code easy to understand, by using comments, meaningful
th
names, and constants or parameters instead of hard-coded numbers
o ng
du
u
cu

29
Basic Coding Practices
• The following guidelines address basic coding practices,
focusing on lexical conventions and basic RTL constructs
om
• General Naming Conventions
.c
• Example 5-1 Using downto in port declarations
ng
entity DW_addinc is
co
generic(WIDTH : natural);
an
port (
th
A,B : in std_logic_vector(WIDTH-1 downto 0);
ng
CI : in std_logic;
o
du
SUM : out std_logic_vector(WIDTH-1 downto 0);

CO : out std_logic;
u
cu
);
end DW01_addinc;

30
General Naming Conventions
• Guideline – When possible, use the signal naming
conventions listed in Table 5-1.
om
Signal naming conventions
.c
ng
Convention Use
co
*_r Output of a register (for example, count_r)
an
*_a
th
Asynchronous signal (for example, addr_strobe_a)
o ng
du
*_pn Signal used in the nth phase (for example, enable_p2)

u
cu
*_nxt Data before being registered into a register with the same name
*_z Tristate internal signal

31
Naming Convention for VITAL Support
• VITAL is a gate-level modeling standard for VHDL libraries and is
described in IEEE Specification 1076.4
om
• Background
.c
– VITAL libraries can have two levels of compliance with the standard :
ng
VITAL_Level0 and VITAL_Level1
co
– VITAL_Level1 is more rigorous and deals with the architecture of a library
an
cell
th
– VITAL_Level0 is the interface specification that deals with the ports and
ng
generics specifications in the entity section of VHDL library cell
o
• Rules
du
– IEEE Specification 1076.4 addresses port naming conventions and

u
includes the following rules

cu
– These restrictions apply only to the top-level entity of a hard macro

32
Architecture Naming Conventions
• Guideline – Use the VHDL architecture type listed in Table 5-2
om
Table 5-2 Architecture naming conventions
.c
ng
Architecture Naming Convention
co
an
synthesis ARCHITECTURE rtl OF my_syn_model IS
th
or
model ARCHITECTURE str OF my_structural_design IS
o ng
du
u
Simulation ARCHITECTURE sim OF my_behave_model IS

cu
or
model ARCHITECTURE tb OF my_test_bench IS

33
Include Headers in Source Files
• Rule – Include a header at the top of every source file,
including scripts. The header must contain:
om
.c
– Filename
ng
– Author
co
– Description of function and list of key features of the nodule
an
– Date the file was created
–
th
Modification history including date,name of modifier, and
ng
description of the change
o
du
u
cu

34
Examples
• Example 5-2 Header in an HDL source file
-- This confidential and proprietary software may be used
om
-- only as authorized by a licensing agreement from
.c
-- synopsys Inc.
ng
-- In the event of publication, the following notice is
co
-- applicable:
an
--
th
-- ( C ) COPYRIGHT 1996 SYNOPSYS INC.
ng
-- ALL RIGHTS RESERVED
o
--
du
-- The entire notice above must be reproduced on all

u
cu
-- authorized copies.
--
-- File : Dwpci_core.vhd
-- Author : Jeff Hackett
35
Examples
-- Date : 09/17/96
-- version : 0.1
om
-- Abstract : This file has the entity, architecture
.c
-- and configuration of the PCI 2.1
ng
-- MacroCell core module.
co
-- The core module has the interface,
an
-- config, initiator,
th
-- and target top-level modules.
ng
-- Modification History:
o
-- Date BY Version Change Descroption
du
--------------------------------------------------
u
cu
-- 9/17/96 JDH 0.1 Original

-- 11/13/96 JDH Last pre-Atria changes
-- 03/04/97 SKC Changes for ism_ad_en_ffd_n
-- and tsm_date_ffd_n
36
Use Comments
• Rule – Use comments appropriately to explain all processes,
functions, and declarations of types and subtypes.
om
• Example 5-3 Comments for a subtype declaration
.c
-- Create subtype INTEGER_256 FOR built_in error
ng
-- checking of legal values.
co
subtype INTEGER_256 is type integer range 0 to 255;
an
th
ng
• Comments should be placed logically, near the code that they
o
describe
du
• The key is to describe the intent behind the section of code

u
cu

37
Keep Commands on Separate Lines
• Rule
om
– Use a separate line for each HDL statement
.c
– Although both VHDL and Verilog allow more than one statement per
ng
line, the code is more readable and maintainable if each statement or
command is on a separate line.
co
an
th
o ng
du
u
cu

38
Line Length
• Guideline – Keep the line length to 72 characters or less.
om
• Example: Continuing a line of HDL code
.c
hp_req <= (x0_hp_req or t0_hp_req or x1_hp_req or
ng
co
t1_hp_req or s0_hp_req or t2_hp_req or s1_hp_req or
an
x2_hp_req or x3_hp_req orx4_hp_req or x5_hp_req or
th
wd_hp_req and ea and pf_req nor iip2);
o ng
du
u
cu

39
Indentation
• Rule – Use indentation to improve the readability of continued code lines
and nested loops.
om
• Example: Indentation in a nested if loop
.c
if (bit_width(m+1) >= 2) then
for I in 2 to bit_width(m+1) loop
ng
spin_j := 0;
for j in 1 to m loop
co
if j > spin_j then
if (matrix(m) (I-1) (j) /= wht) then
an
if (j=m) and (matrix(m) (I) (j) = wht) then
matrix(m) (I) (j) := j;
th
else ng
for k in j+1 to m loop
if (matrix(m) (I-1) (k) /= wht) then
o
matrix(m) (I) (k) := j;
du
spin_j := k ;
exit;
u
end if;
cu
end loop -- k
end if;
end if;
end if;
end loop; -- j
end loop; -- I
end if;
40
Do Not Use HDL Reserved Words
• Rule
om
• Do not VHDL or Verilog reserved words for names of any
.c
elements in your RTL source files.
ng
• Because macro designs must be translatable from VHDL to
co
Verilog and from Verilog to VHDL,
an
• It is important not to use VHDL reserved words in Verilog
th
code, and not to use Verilog reserved words in VHDL code.
ng
o
du
u
cu

41
Port Ordering
• Rule – Declare ports in a logical order, and keep this order
om
consistent throughout the design.
.c
• Guideline – Declare one port per line, with a comment
ng
following it (preferably on the same line)
co
• Guideline – Declare the ports in the following order:
an
– Input :
th
• Clocks, Resets, Enables, other control signals
ng
• Data and address lines
o
– Outputs:
du
• Clocks, Resets, Enables, other control signals

u
cu
• Data

42
Examples
• Example 5-6 Port ordering in entity definition
entity my_fir is
om
generic (
.c
DATA_WIDTH : positive;
COEF_WIDTH : positive;
ng
ACC_WIDTH : positive;
co
ORDER : positive;
an
);
th
port (
-- control Inputs
ng
--
o
clk : in std_logic;
du
rst_n : in std_logic;
u
run : in std_logic;
cu
load : in std_logic;
tc : in std_logic;
--
Data Inputs

43
Examples
data_in : in std_logic_vector(DATA_WIDTH-1 downto 0);
om
coef_in : in std_logic_vector(COEF_WIDTH-1 downto 0);
.c
sum_in : in std_logic_vector(ACC_WIDTH-1 downto 0);
--
ng
Control Outputs
co
--
an
start : out std_logic;
hold : out std_logic;
th
ng
--
o
du
Data Outputs
u
--
cu
sum_out : out std_logic_vector(ACC_WIDTH-1 downto 0)

);
end my_fir;
44
Port Maps and Generic Maps
• Rule – Always use explicit mapping for ports and generics,
using named association rather than positional association.
om
• Example 5-7 Using named association for port mapping
.c
-- instantiate my_add
ng
U_ADD: my_add
co
generic map (width => WORDLENGTH)
an
port map (
th
a => in1, ng
b => in2,
o
ci => carry_in,
du
u
cu
sum => sum,

co => carry_out
);

45
Examples
• Verilog :
// instantiate my_add
om
my_add #(‘WORDLENGTH) U_ADD (
.c
.a (in1 ),
ng
co
.b (in2 ),
an
.ci (carry_in ),
th
ng
.sum (sum ),
o
du
.co (carry_out )
u
);
cu

46
VHDL Entity, Architecture, and Configuration Sections
• Guideline – Place entity, architecture, and configuration
sections of your VHDL design in the same file.
om
• Example 5-8 Using pragmas to comment out VHDL
.c
configurations for synthesis
ng
-- pragma translate_off
co
configuration cfg_example_struc of example is
an
th
for struc ng
use example_gate;
o
end for;
du
end cfg_example_struc;
u
cu
-- pragma translate_on

47
Use Functions
• Guideline – Use functions when possible, instead of repeating
the same sections of code
om
• Example 5-9 Creating a reusable function
.c
VHDL:
ng
-- This function converts the incoming address to the
co
-- corresponding relative address.
an
function convert_address
th
ng
(input_address, offset : integer)
o
du
return integer is
u
begin
cu
-- … function body here…

end; -- convert_address

48
Examples
• Verilog:
// This function converts the incoming address to the
om
// corresponding relative address.
.c
ng
co
function [‘BUS_WIDTH-1 : 0] convert_address;
an
input input_address, offset;
th
integer input_address, offset;
o ng
du
begin
u
// …function body goes here…

cu
end
end function // convert_address

49
Use Loops and Arrays
• Guideline – Use loops and arrays for improved readability of the source
code.
om
• Example 5-10 Using loops to improve readability
.c
shift_delay_loop: for I in 1 to (number_taps-1) loop
delay(I) := delay (I-1);
ng
and loop shift_delay_loop;
co
• Example 5-11 Register bank using an array
an
type reg_array is array(natural range <>) of
th
std_logic_vector (REG_WIDTH-1 downto 0);
signal reg: reg_array (WORD_COUNT-1 downto 0);
ng
begin
o
REG_PROC:process (clk)
du
begin
if clk=‘1’ and clk’event then
u
if we=‘1’ then
cu
reg(addr) <= data;

end if;
end if;
end process REG_PROC;
data_out <= reg(addr);
Bộ môn Kỹ Thuật Điện TửCuuDuongThanCong.com https://fb.com/tailieudientucntt

50
Examples
• Example 5-12 Using arrays for faster simulation
poor coding style:
om
function my_xor (bbit : std_logic;
.c
avec : td_logic_vector (x downto y) )
ng
return std_logic_vector is
co
variable cvec :
an
std_logic_vector(avec’range-1 downto 0);
th
begin
ng
for i in avec’range loop -- bit-level for loop
o
du
cvec(I) := avec (I) xor bbit; -- bit-level xor

end loop;
u
cu
return(cvec);
end;

51
Examples
Recommended coding style:
om
function my_xor ( bbit : std_logic;
.c
evec : std_logic_vector (x downto y) )
ng
return std_logic_vector is
co
variable cvec, temp :
an
std_logic_vector(avec’range-1 downto 0);
begin
th
ng
temp := (others => bbit);
o
du
cvec := avec xor temp;

u
cu
return (cvec);
end;

52
Use Meaningful Labels
• Rule – Label each process block with a meaningful name. This
is very helpful for debug.
om
• Guideline –Label each process block <name>_PROC
.c
• Rule – Do not duplicate any signal, variable, or entity names.
ng
• Example 5-13 Meaningful process label
co
-- synchronize requests (hold for one clock).
an
th
SYNC_PROC : process (req1, req2, rst, clk)
ng
o
du
… process body here …

u
cu
end process SYNC_PROC;

53
Coding for Portability
Use Only IEEE Standard Types
om
 You will create code that is technology-independent, compatible with various
simulation tools, and easily translatable from VHDL to Verilog ( or from Verilog to
.c
VHDL).
ng
co
 Rule (VHDL only) - Use only IEEE standard types.
an
th
--Create new 16-bit subtype ng
subtype WORD_TYPE is std_logic_vector (15 downto 0);
o
( Example 5-14 Creating a subtype from std_logic_vector )
du
 Guideline (VHDL only)

u
cu
- Use std_logic rather than std_ulogic.

- Likewise, use std_logic_vector rather than std_logic_vector.

54
Continue
om
- Be conservative in the number of subtypes you create.
.c
: Using too many subtypes make the coder difficult to understand.
ng
co
an
th
- Do not uese the type bit or bit_vector.ng
: Many simulators do not provide built-in arithmetic functions for
o
these types.
du
u
cu
Use ieee.std_logic_arith.all;
Signal a, b, c, d : std_logic_vector (y downto x);
( Example 5-15 using built-in arithmetic functions for std_logic_vector )

55
Do Not use Hard-Coded Numeric Values
om
- Do not use hard-coded numeric values in your design.
.c
: As an exception, you can use the values 0 and 1 (but not in com-
ng
bination, as in 1001).
co
an
Poor coding style Recommended coding style
th
wire [7 : 0 ] my_in_bus; `define MY_BUS_SIZE 8
ng
reg [7 : 0 ] my_out_bus; wire [ ` MY_BUS_SIZE-1 : 0 ] my_in_bus;
o
reg [ ` MY_BUS_SIZE-1 : 0 ] my_out_bus;
du
( Example 5-16 using constants instead of hard-coded values )

u
cu

56
Packages & Include Files
 Packages
om
.c
- Collect all parameter values and function definitions for a design
ng
into a single separate file (a “package”) and name the file
co
DesignName_package.vhd.
an
th
ng
 Include Files
o
du
 Guideline (Verilog only)

u
- keep the `define statements for a design in a single separate file

cu
and name the file DesignName_params.v.

57
Avoid Embedding dc_shell Scripts
om
− Although it is possible to embed dc_shell synthesis commands
.c
directly in the source code, this practice is not recommended.
ng
− Others who synthesize the code may not be aware of the hidden
co
commands, which may cause their synthesis scripts to produce
an
poor result.
th
o ng
du
u
cu

58
Use Technology-independent Libraries
 Guideline
om
- Use the DesignWare Foundation Library to maintain technology
.c
independence.
ng
co
 Guideline
an
- Avoid instantiating gates in the design.
th
- Gate-level designs are very hard to read, and thus difficult to
ng
maintain and reuse.
o
du
- If technology-specific gates are used, then the design is not port-

u
cu
able to other technologies.

59
Continue
 Guideline
om
- If you must use technology-specific gates, then isolate these gates
.c
in a separate module.
ng
co
 Guideline – The GTECH library
an
th
- If you must instantiate a gate, use a technology-independent library such as
the Synopsys generic technology library, GETCH.
o ng
du
u
cu

60
Coding For Translation (VHDL to Verilog)
om
- Do not use generate statements.
.c
: There is no equivalent construct in Verilog.
ng
co
an
- Do not use block constructs.
th
ng
: There is no equivalent construct in Verilog.
o
du

u
cu
- Do not use code to modify constant declarations.

: There is no equivalent capability in Verilog.

61
Questions
1. What are differences between ASIC and FPGA based
om
chip design?
.c
2. What are steps of ASIC design flow for analog chip?
ng
3. What are steps of ASIC design flow for digital chip?
co
4. Explain about Layout-versus-Schematic (LVS) Check
an
5. What is IP core?
th
ng
6. List the needed characteristics of IP core
o
du
7. What are coding guidelines?

u
cu

62
Assignment
• Design an IP core, select one of the following list :
– Adder
om
– Subtractor
.c
– Multiplier
ng
– Divider
• Configurable parameters
co
– Width of input data
an
– Reset level
th
– Unsigned / signed number
ng
• Required deliverable set
o
du
– Behavior model
– RTL code
u
cu
– Synthesis report
– Testbench
– Verification report

63

Thiet Ke Vi Mach So Nang Cao Truong Quang Vinh Asic&Ip Ch1 (Cuuduongthancong - Com)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Thiet Ke Vi Mach So Nang Cao Truong Quang Vinh Asic&Ip Ch1 (Cuuduongthancong - Com)

Uploaded by

Copyright:

Available Formats

ĐẠI HỌC QUỐC GIA TP.

1.1 ASIC and FPGA-based chip design flow

1.2 ASIC chip: analog versus digital

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

ages power. power.

-Low cost solution in large -High cost solution in large

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

– Transition times of "sum" and "carry_out" signals <1.2 ns (worst case)

– Circuit area < 1500 um^2

– Dynamic power dissipation (at VDD=5 V and fmax=20 MHz) < 1 mW

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

– The DesignWare library contains more complex cells such as adders

Bộ môn Kỹ Thuật Điện Tử

Compiler can then resynthesize the design for more accurate

Bộ môn Kỹ Thuật Điện Tử

Release packaged IP core: IP

Bộ môn Kỹ Thuật Điện Tử CuuDuongThanCong.com https://fb.com/tailieudientucntt

– Timing closure due to deep submicron

• Solution: Platform-based design with

• Design verified to a high level of

• Events report (what, when and where)

• Automatic check event

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

end #(`T_CLK) event_2;

Bộ môn Kỹ Thuật Điện Tử

• • Display mode of automatic checking

– display[0]: event current under test

– display[1]: the time error occurs

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

• The coding guidelines provide the following recommendations:

Bộ môn Kỹ Thuật Điện Tử

SUM : out std_logic_vector(WIDTH-1 downto 0);

Bộ môn Kỹ Thuật Điện Tử

*_pn Signal used in the nth phase (for example, enable_p2)

*_z Tristate internal signal

Bộ môn Kỹ Thuật Điện Tử

– IEEE Specification 1076.4 addresses port naming conventions and

includes the following rules

– These restrictions apply only to the top-level entity of a hard macro

Bộ môn Kỹ Thuật Điện Tử

Simulation ARCHITECTURE sim OF my_behave_model IS

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

-- The entire notice above must be reproduced on all

-- 9/17/96 JDH 0.1 Original

• The key is to describe the intent behind the section of code

Bộ môn Kỹ Thuật Điện Tử