COMP22111’ Processor’ Microarchitecture’
Upload
others
View
21
Download
0
Embed Size (px)
344 x 292
429 x 357
514 x 422
599 x 487
Citation preview
COMP22111 Part3 Notes
The!module!aims!to!give!a!view!of!the!role!of!a!digital!hardware!designer,!taking!an!idea!and!
implementing! it! as! a! silicon! chip.! A! processor! is! a!
representative! example! of! logic! used! in!
today's!chips,!also!giving!further!insight!into!how!computers!actually!work.!!Having!completed!
the!module!you!should!have!developed!the!confidence!to!be!able!to!take!a!concept!and!realise!
and!microprocessors.!COMP12111!gave!an!overview!of!
the!hardware!development!process;!
skills!with!a!design!flow!from!concept!to!implementation.!It!used!microprocessors!as!design!
examples!to!illustrate!and!reinforce!how!machine!code,!output!from!a!compiler,!is!interpreted!
and!executed!by!a!computer.!
1. COMP22111! Lecture! Notes! (preS2011)! by! Dr! Linda!
Brackenbury,! School! of! Computer!
Science,!The!University!of!Manchester.!
2.
“ARM!System!Architecture”,!S!Furber,!Addison!Wesley,!ISBN!0S201S40352S8!
3.
“Principles!of!Computer!Hardware”,!A!Clementa,!4th!Edition,!Oxford!University!Press,!ISBN!
4. “The! Verilog! hardware! description! language”,! Thomas! &!
Moorby,! 5th! Edition,! Springer,! ISBN!978S0S387S84930S0.!
5. “Digital! VLSI! Systems! Design”,! S! Ramachandran,! Springer,!
ISBN! 978S1S4020S5828S8,!
(ebook!available!to!download!via!JRULM)!
!
! 2!
Assessment& !
This! course! unit! is! assessed! by! a! formal! examination! and!
laboratory! work.! The!
breakdown!of!the!assessment!is!
• exam!–!55%!
• lab!–!45%!
some!updates! for! the!2013S2014!academic!year.!Hence,!when!
looking!at!past!papers! (all!of!
which!are!available!of!the!University!intranet)!take!care!when!looking!at!papers!from!earlier!
years.! If! the! question! looks! unfamiliar,! the! chances! are!
the! subject! matter! is! no! longer!
covered.!No!sample!answers!are!given! for!past!papers.!However,!
I!will!be!happy! to!discuss!
& Course&Website&
& Further! information,! such! as! copies! of! these! notes,!
copies! of! the! slides,! corrections! to! the!
notes,!etc,!can!be!found!on!the!course!unit!website!
make!sure!I!set!aside!enough!time!to!answer!your!questions.!If!you!knock!on!
my!door!out!of!the!blue,!then!I!may!not!have!the!time!to!see!you!!
!
Further! information,! such! as! copies! of! these! workbooks,!
copies! of! the! slides,! extra! notes,!
corrections!to!the!notes,!etc,!can!be!found!on!the!course!unit!Blackboard!site.!
Both! are! IEEE! standards,! supported!widely! and! can! be! used!
for! designing! and! simulating! systems.! However,!
VHDL! is! far!more! general! purpose! than!Verilog! and,!
some!would! argue,!more! complex.! Verilog! is! focused! on!
modelling!digital!systems!which!it!can!do!concisely.!!
behaviour!of!the!components!internally.!!
synthesis!in!1987,!and!since!the!company!that!developed!it!was!taken!over!by!Cadence!Design!Systems!in!1990,!
it!has!become!one!of!the!most!popular!languages!for!the!design,!testing!and!implementation!of!digital!systems!at!
the!RTL!level.!
Verilog!is!a!textSbased!programming!language!that!has!many!features!similar!to!programming!languages!such!as!
operation!of!hardware,!and!the!ability!to!specify!time!delays.!
HDLs! are! good! to! the! designer! because! they! offer! a!
textSbased!way! to! describe! designs! that! can! be! easily!
be!
transferred!between!designers!and!systems.!Being!able!to!describe!a!circuit!in!software!offers!a!way!to!simulate!
the!operation!of!the!system!before!it!is!implemented.!If!there!are!problems,!then!the!code!can!be!easily!debugged!
and! reStested.! This!would! be! very! difficult,! and! expensive!
to! do! using! a! physical! circuit.! CAD! tools! allow! the!
ability!to!translate!Verilog!models!for!implementation!in!silicon,!which!offers!a!rapidly!route!to!market.!
HDLs!are!important!tools!used!in!the!design!of!hardware.!Not!only!can!HDLs!be!used!to!generate!test!bench!data,!
they!can,!more!importantly,!be!used!to!describe!the!function!of!a!logic!block,!which!can!then!be!used!to!translate!
the!description!into!hardware!using!CAD!tools.!
HDLs!describe!an!algorithm!as!a!set!of!text!statements,!somewhat!similar!to!a!programming!language!(such!as!
Java).!
• This!can!be!a!good!thing!in!that:!
into!physical! systems,! but!we! can! also!use! them!as! an! aid!
in! the! testing! and!verification!of!
designs.!!
The!diagram!shows!the!process!adopted!in!the!lab!for!implementation!on!a!Xilinx!FPGA.!We!
typically!have!an!RTL!design!schematic!with!blocks!described!using!behavioural!Verilog.!The!
with! the! behavioural! Verilog.! Verilog! simulations! are!
performed! to! make! sure! the! design!
conforms!to!the!spec,!it!if!doesn’t,!then!it!will!need!modifying.!If!it!passes!the!tests!the!it!can!be!
synthesized! (in! our! case! by! the! Xilinx! tools)! to! produce!
a! gate! level! (structural)! Verilog!
description! of! the! design.! Place! and! route! tools! then!
take! this! information! in! order! to!
programme!the!device!to!offer!the!required!functionality.!
There!will!be!no!use!of!schematics!in!the!lab,!the!whole!design!will!be!produced!in!Verilog.!
What!is!synthesis?!
Synthesis! is! the! processes! of! translating! your! design! into!
a! gate! level! description! for!
implementation!on!the!target!device,!such!as!an!FPGA.!The!synthesis!doesn’t!produce!actual!
gates,!it!produces!a!netlist!of!the!design!which!can!then!be!interpreted!for!implementation!on!
the!chosen!hardware.!!
components! expressed! at! the! top! level! using! bevioural!
view!models.! The!models! are! then!
replaced! over! time! as! more! detailed! RTL! or! structural!
models! are! developed! for! the!
components!as!the!design!progresses.!The!ability!to!simulate!the!system!in!a!consistent!way!
as!the!design!evolves!makes!this!approach!very!flexible.!!
would!be!physically!implemented.!In!some!cases!a!purely!behavioural!description!may!not!be!
sufficient!for!direct!synthesis.! !
! 13!
! !Notes:! ! !
! 14!
Behavioural/RTL!Example! !
There!are!two!examples!here.!
!
The! first! uses! a! logical! description! to! depict! the!
operation! of! the! multiplexer.! From! this!
description!we!have!some!idea!of!how!the!MUX!may!be!implemented.!
Modules!can!contain!other!modules,!tasks!(more!later)!and!functions!(more!later).!A!module!
usually! performs! a! distinct! function,! e.g.! if! describing! a!
RISC! processor! at! the! architectural!
level!there!may!be!the!following!modules!in!the!datapath:!
separated!by!commas.!All!Verilog!statements!end!with!a!semicolon,!;.!
Verilog!names!are!case!sensitive!and!should!start!with!a!letter!or!underscore,!however,!try!to!
make!names!unique.!
Statements!provide!the!assignments!required!to!implement!the!required!function.!
A!module!always!terminates!with!endmodule!without!a!semicolon.!
!
In!the!first!year!you!will!have!been!used!to!using!the!1995!standard!for!defining!the!module!
header,!here,!the!variables!are!defined!in!the!body!of!the!module,!i.e.!
!
module full_adder_4bit(s, c_out, a, b, c_in); output [3:0] s;
output c_out; input [3:0] a, b; output c_in; reg [3:0] s; reg
c_out; //assignments endmodule !
However,!here!we!will!be!adopting!the!more!recent!2001!standard,!where!the!variables!are!
defined!in!the!module!header,!i.e.!
!
module full_adder_4bit(output reg [3:0] s, output reg c_out, input
[3:0] a, input [3:0] b, input c_in); //assignments endmodule !
!
! 19!
Numbers!
By!default,!numbers!in!Verilog!are!decimal.!The!numerical!base!can!be!specified!as!follows:!
! −! subtraction!
! *! multiplication!
! /! division!
! %! modulus!
Concurrency!
It! is! important! to! appreciate! that! both! initial! and!
always! statements! are! the! basic! constructs! for! describing!
concurrency! in! real! systems.! Remember,! hardware! is!
inherently!
parallel!in!nature,!with!things!happening!at!the!same!time!across!the!circuit.!Contrast!this!to!
software!when!instructions!are!executed!in!sequence.!The!job!of!the!simulator!is!to!mimic!this!
concurrency! in!order!
to!give!you!a!real!understanding!of!how!the!circuit!will!operate!when!
synthesized!–!more!on!this!later.!
For!example,!in!the!following!example!for!a!clock!in!a!stimulus!file:!
!
! 23!
! Notes:! ! !
! 24!
Initial!Blocks! Initial! blocks! are! often! used! to! initialise!
the! values! of! variables! in! test! benches,! particularly! at!
the! start! of! a! simulation.! They! execute! once! at! time!
zero! and! are! nonS
synthesizable.!Like!the!always!block!the!initial!block!can!contain!multiple!statements,!if!so!
these!must!be!encapsulated!with!a!begin!and!end.! !
!
module what_an_initial_does(); reg clk, reset; initial begin clk =
0; data = 0; end // other always and initial blocks endmodule
!
In!this!example!the!initial!block!starts!at!time!0,!when!clk!and!data!will!be!initialised!to!the!
value!0!at!the!same!time.!
Here,!the!always!block!will!only!be!executed!if!there!is!a!change!in!the!value!of!a,!b,!or!c_in.!!
The!list!of!variables!in!the!sensitivity!list!essentially!represents!an!OR!function.!
For!example!
What!if!you!forgot!a!variable?!For!example,!consider!the!following!examples:!
!
Both! code! sequences! should! produce! a! half! adder.!However,!
in! code! sequence! 2,!what!will!
happen!to!the!outputs!s!and!c_out!when!b!changes?!In!this!case!the!circuit!will!use!the!old!
value!for!b!resulting!in!a!flipSflop!being!introduced.! !
Instead! of! listing! ALL! the! possible! signals! in! the!
sensitivity! list,! it! is! better! to! use! the! *! to!
identify!that!ALL!input!signals!present!should!cause!the!always!block!to!execute,!i.e.!
!
!
! ! !
begin
Continuous!Assignment!
assigned!must!be!declared!as!a!wire!(NOT!a!reg!).!
Consider!the!full!adder!example:!
!
! !
!
!
! !
The!statements!are!executed!in!order!…!
• if!the!initial!value!of!count!is!8,!its!final!value!will!be!9;! •
if!the!initial!value!of!count!is!9,!its!final!value!will!be!0;! •
if!the!initial!value!of!count!is!10,!its!final!value!will!be!11!
The!results!may!not!be!what!you!expect!!
• if!the!initial!value!of!count!is!8,!its!final!value!will!be!9;! •
if!the!initial!value!of!count!is!9,!its!final!value!will!be!10;! •
if!the!initial!value!of!count!is!10!the!final!value!will!be!undefined!because!both!statements!will!assign!a!
value!simultaneously!!
Any!nonSblocking!assignments!should!be!mutually!exclusive,!thus,!this!is!legal!code:!
else count <= count+1;
blocks!–!this!can!cause!problems!(remember!the!concurrency).!
The!effect!of!blocking!and!nonSblocking!assignments!is!illustrated!below:!
!
combinatorial! logic.!The! flipSflop!will!exist!due! to! the!need!
to! ‘store’!
the! value! of! ‘1’.! Its! existence! depends! upon!how! the!
statements! are!
encapsulated!in!a!block.!
In!the!case!of!the!nonSblocking!code!example,!this!implies!retention!of!
values!so!the!result!will!be!a!3Sbit!shift!register!arrangement.!
model! combinatorial! logic! in! an! always! block! with!
blocking!
assignments.!!
Example:-2:1-multiplexer- module mux2_1(output reg f, input a, b,
sel, clk); always @(posedge clk) begin if (sel) f <= b; else f
<= a; end endmodule
You!can!test!more!that!one!condition!by!chaining!if!…!else!statements,!i.e.!
!
1. always @ (b, c, x) if (x == 0) a = b;
else a = c; 2. always @ (b, c, x) begin
a = c; if (x == 0) a = b; end
3. always @ (b, x) if (x == 0) a = b; !
The!first!two!examples!are!fine!because!a
can!be!determined!without!reference!to!previous!
values!of!a.!In!the!first!either!the!if!or!the!else!must!be!taken.!In!the!second!case!x!is!given!a!
default!value!and!then,!possibly,!redefined.!In!both!cases!the!effect!is!the!same.!!
However,!in!the!third!case,!if!x!!=!0!then!a!is!not!specified!which!means!it!retains!its!previous!
value.!The!consequence!of!this!
is!that!the!synthesis!software!will! introduce!a!register!
in!the!
!
is!fine!because!a!is!expected!to!be!a!register!(the!posedge
clock!tells!us!this!is!a!sequential! block).!
b) always @ (posedge clk) if (x == 0) a <= b; else a <= a;
!
yields!the!same!result!and!is!not!necessary.!
!
!
!
!
module comparator(input [3:0] a, input [3:0] b, output c); assign c
= (a == b); endmodule ! !
! 39!
expression)!with!a!list!of!case!choices.!!
!
case (signal[1:0]) 2’b00: output = 1; 2’b11: output = 0; endcase
!
The!two!cases!of!signal!=!00!and!11!are!covered!by!the!case!list.!However,!what!happens!in!
the!case!where!signal!=!01!or!10?! !
We!could!add!a!default!case!to!trap!these!conditions:! !
case (signal[1:0]) 2’b00: output = 1; 2’b11: output = 0; default:
output = 0; endcase !
If!a!default!is!absent!and!all!the!possible!conditions!of!the!input!signals!are!not!listed!in!the!
case! list,! then! the! synthesis! of! the! design!may! generate!
unwanted! hardware! and!possibly!
undesirable!behavior.!You!should!always!aim!to!have!a!default!case!!
!
where!signal!is!a!1Sbit!value.!
! 41!
Notes:! ! !
! 42!
case!statements!
The!case!statement!is!useful!when!selecting!from!many!choices,!such!as!the!case!of!the!multiplexer.!A!4:1!MUX!
with!control!inputs!a!and!b!can!be!used!to!select!from!4!16Sbit!values!to!give!one!16Sbit!output.!The!Verilog!code!
describing!this!operation!(without!definitions)!may!be!
case (s) 0: c = d0; 1: c = d1; 2: c = d2; 3: c = d3; endcase
!
However,!what! if!a!or!b! take!value! ‘X’!or! ‘Z’,!what!will!be!
the!operation! then?!We!can!use! the! ‘default’! case! to!
capture!all!other!cases!that!we!are!not!necessarily!interested!in,!i.e.!
case ({b,a}) 2’b00: c = d0; 2’b01: c = d1; 2’b10: c = d2; 2’b11: c
= d3; default: c = 16’hxxxx; endcase !
If!more!than!one!cases!have!similar!actions,!then!you!can!specify!more!than!one!case!in!the!case!specification.!If!
no!action!is!required!for!a!case,!then!it!can!just!be!omitted.!For!example:!
case (INSTR[15:13]) 0,1: // actions 2,3: // actions 4,5: //
actions; endcase !
Here,!we!do!not!have!any!actions!for!INSTR!=!6,!7,!or!8,!so!they!have!been!omitted!from!the!case!list!–!you!may!
want!to!insert!a!default!though!.! !
!
case ({b, a}) 2’b0x: begin // only does this for b = ‘0’ and a =
‘x’ end 2’bx1: begin // only does this for b = ‘x’ and a = ‘1’ end
endcase !
!
!
!
!
Implementing!modules!at!different!levels!of!abstraction.! !
It!is!worth!revisiting!abstraction!in!Verilog!to!appreciate!that!there!are!many!ways!that!that!a!
design! can! be! defined! in! Verilog,! and! at! different! levels!
of! abstraction.! Let’s! look! at! the!
example!of!a!4:1!multiplexer.!
Behavioural-description:- !
module mux4to1(input [3:0] D, input [1:0] select, output reg Q);
always@(D, select) // whenever data or select change Q = D[select];
endmodule Behavioural-with-case-statement-description:- !
module mux4to1(input [3:0] D, input [1:0] select, output reg Q);
always@(D, select) // whenever data or select change case(select)
2’b00: Q = D[0]; 2’b01: Q = D[1]; 2’b10: Q = D[2]; 2’b11: Q = D[3];
default: Q = 4’hx; endmodule Structural-description-- !
A!4:1!mux!can!be!constructed!from!basic!logic!gates,!which!we!can!connect!together!to!form!
the!required!functionality.!
module or4(output1, input1, input2, input3, input4); !
module not(output1, input1); The!module!will!thus!be!
! !
In!most! programming! languages! functions! and! procedures! are!
used! to! break! up! code! into!
more! easy! to!manage! parts,! and! to! allow! reSuse! of! code.!
In! Verilog! the!module! provides! a! means! of! partitioning! the!
design! into! more! manageable! and! reusable! parts.! The!
Verilog!
language!also!provides!functions!and!tasks!to!allow!the!behavioural!description!to!be!break!
module.!
Tasks!
A! task! is! similar! to! a! procedure! or! subroutine! in! most!
programming! languages.! They! are!
defined!and!called!within!a!module!to!perform!a!specific!operation.!
•
A!task!begins!with!the!keyword!task!and!ends!with!the!keyword!endtask!
• Tasks!can!have!any!number!of!inputs!and!outputs!
• Tasks!can!call!other!tasks!or!functions!
•
Can!be!used!to!model!both!combinatorial!and!sequential!logic!
parameters!to!produce!some!new!output!on!the!output!parameters!
module task_calling (input [7:0] temp_i1, input [7:0] temp_i2,
output reg [7:0] temp_o1, output reg [7:0] temp_o2);
always@(temp_i1, temp_i2) begin convert(temp_i1, temp01);
convert(temp_i2, temp02); end task convert; input [7:0] temp_in_C;
output reg [7:0] temp_in_F; begin temp_in_F = (9/5*temp_in_C)+32;
end endtask endmodule !
!!!Q.! !
!!!Would!the!above!synthesize?!
! 47!
! Notes:!
! 48!
Functions!
A!function!is!similar!to!a!task!but!only!input!parameters!are!passed!to!it!and!it!returns!a!single!
output!value.!
• A! function! begins! with! the! keyword! function! and! ends!
with! the! keyword! endfunction!
• Functions!can!have!any!number!of!inputs!!
•
Functions!can!return!a!single!result,!which!by!default!is!a!single!bit!
• Reside!within!a!module!
• Can!be!used!to!model!combinatorial!logic!
•
Tasks!have!input!parameters!passed!to!them!and!they!operate!on!the!input!parameters!to!
produce!an!output!!
• Inputs!are!declared!after!the!keyword!function!
• Local!variables!are!declared!after!the!input!!declarations!
•
As!a!function!computes!a!value!to!return!it!must!be!assigned!to!a!variable!when!called.!
A!simple!example!of!how!to!call!a!function!is!given!below:!
!
// simple example of function calling module function_calling(input
a, b, c, d, output e); assign e = mytestfunction(a, b, c, d); //
mytestfunction function function mytestfunction; input a, b, c, d;
begin mytestfunction = ((a+b)+(c+d)); // variable has same name as
// the function end endfunction endmodule ! !
! 49!
! !Notes:!
processor!–!you!will!learn!more!about!the!Stump!processor!in!later!lectures.!
The!Stump!has!a!limited!number!of!branch!instructions!and!three!status!flags!(N!S!Negative!,!Z!
–!Zero,!V!–!Overflow,!C!–!carry).!In!order!to!determine!whether!a!branch!should!be!taken!or!
not!a!function!can!be!used!that!takes!the!current!instruction!and!the!status!flags!as!its!inputs.!
From!this!a!1!is!returned!if!the!branch!is!taken,!and!0!is!returned!if!the!branch!is!not!taken.!!
This! is!used! in! an!if! statement! to!determine!whether! the!
result! is!written! to! the!program! counter:!
if(Testbrach(INST[11:8], CC[0], CC[1], CC[2], CC[3]) == 1)
REG_BANK[7] = S;
!
// input/output declarations
output declartions;
input declarations;
reg declarations;
//internal declarations
reg declarations;
wire declarations;
continuous assignments;
initial //block i1 – can have any number of initial blocks
begin
end;
end;
always @(event(s) // block ai – can have any number of always
blocks
begin
always statements for block ai; does actual computation, i.e.
modelling
end
.
.
always @(event(s) // block an – can have any number of always
blocks
begin
always statements for block an; does actual computation, i.e.
modelling
end
! 52!
input declarations;
output declarations;
input declarations;
output declarations;
input declarations;
input declarations;
! 53!
! !Notes:! ! !
! 54!
Gluing!Modules!Together!–!Structural!Verilog!
Modules!can!be!connected!together!to!make!a!more!complex!system,!e.g.!a!processor.!This!can!
be!done!textually,!or!with!a!schematic!(recommended).!!
The!schematic!illustrates!the!blocks!(which!could!be!Verilog!modules!themselves)!along!with!
the! connections! (nets! and! buses)! between! them.! The!
schematic! can! be! represented! in! a!
textual! form! where! we! instantiate! the! modules! representing!
the! blocks! and! use! wires! to!
identify!the!connections!between!the!modules.!
!
!
module top (output z, input W, X, Y); wire int; AND2 I1(.A(W),
.B(X), .C(int)); //I1 & I2 are unique names AND2 I2(.A(int),
.B(Y), .C(Z)); //signals can be in any order
//because they are explicitly //assigned to pins of AND2
endmodule
or,!we!could!write!an!implicit!description!of!the!higher!level!module:!
module top (output z, input W, X, Y); wire int; AND2 I1(int, W, X);
AND2 I2(Z, int, Y); //signals are in the same order as in the
//AND2 module endmodule !
Here!we!have!to!get!the!order!of!the!signals!correct!in!the!input/output!list!for!I1!and!I2.!
!
At! the! highest! level! connect! system! module! to! testbench!
module.! Again! can! be! done! by!
schematic!(recommended)!or!with!text!description!as!above.! !
! 57!
represent! the! internal! structure!of!MU0! in!Verilog.! In! the!
first!year!(COMP12111)!MU0!was! represented!schematically!with!the!
internal!components,!such!as!the!datapath! implemented!
as!schematics.!Here,!we!will!be!looking!at!implementing!the!whole!design!in!a!purely!textual!
form!using!Verilog.!
At!the!top!level!MU0!can!be!represented!as!a!module!with!the!interface!(input/output!signals)!
as!identified!in!the!slide.!!
The!first!will!need!to!do!is!define!the!module!for!MU0,!i.e.!
module MU0(output [15:0] data_out, output [11:0] address, output
mem_rd, output mem_wr, output halt, input [15:0] data_in, input
clock, input reset); // MU0 structure endmodule
Outputs!are!left!defined!as!wires!
in!this!example!due!to!the!fact!that!they!are!not!assigned!
values!within!the!MU0!block!itself,!but!within!submodules.!
!
We! will! look! at! the! control! block! in! later! lectures,! for!
now! we! will! simply! instantiate! the!
control!block!in!our!MU0!module.!!
We!could!implement!the!datapath!as!a!standalone!module!in!itself,!or!we!could!instantiate!the!
components!of!the!datapath!directly.!For!now,!we!will!look!at!instantiating!the!components!of!
the! datapath! in! our!MU0!module.! To! do! so,!we! need! to!
expand! the! datapath! and! label! the!
nets/buses!between!the!components!in!the!datapath,!as!illustrated.!
!
!
!
!
!
Here!we!have!defined!connections!between!modules!explicitly,!as!this!is!less!prone!to!errors!!
The! signals! defined! in! the! schematic! of! the! datapath! are!
replicated! in! order! define!
connections!between!the!modules.!
We!will!look!at!what!is!inside!the!control!in!a!later!lecture.!
and! to! confirm! that! it!works! according! to! the! required!
specification.! To! test! a! design!often!
involves!instantiating!your!design!(module)!in!a!schematic!with!a!test!harness!built!round!it!
that!specifies!the!inputs!to!your!design!and!monitors!the!output.!Such!a!test!bench!can!be!built!
using!various!levels!of!abstraction!and,!as!we!will!se!later,!can!be!fully!implemented!in!Verilog.!
Notes:! ! !
! 70!
MU0!Testbench!
A!testbench!for!the!MU0!processor!design!we!have!looked!!at!is!given!below.!
/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -*/ /* Defines */ `define PERIOD 100 // Clock period `define
MAX_CYCLES 200 // Cycles from reset to halting module MU0_test();
reg clk, rst; // Global control signals wire [11:0] address; //
Memory address reg [15:0] data_in; // Data read from memory wire
[15:0] data_out; // Data to write to memory wire memory_read; //
Command to read memory wire memory_write; // Command to write
memory reg [15:0] memory [0:1023]; // Memory model (undersized) /*
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-*/ /* Instantiate the device under test */ //<instance>
<name> (<connections>); MU0 processor(.clock (clk), //
Connect ports to local buses .reset (rst), .address (address),
.data_in (data_in), .data_out (data_out), .mem_rd (memory_read),
.mem_wr (memory_write) .halt(halt)); /* - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - -*/ /* Generate clock */
initial clk = 1; // Clock initialisation always #(`PERIOD/2) clk =
~clk; // Clock switching /* - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - -*/ /* Reset and run */ initial // This
block resets the processor begin // and, later, stops the
simulation reset = 0; // First, leave things undefined #`PERIOD; //
Wait for one clock cycle reset = 1; // Reset to define state
#`PERIOD; // Wait for one clock cycle reset = 0; // Release reset
to run #(`MAX_CYCLES * `PERIOD); // Run for predetermined time
$stop; // Halt simulation end /* - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - -*/ /* Simple memory model */
initial $readmemh("$COMP22111/MU0_src/gcd.hex", memory always @
(address, memory[address]) // Simple asynchronous memory read #20
data_in = memory[address]; // With cosmetic delay added always @
(posedge clk) // Make memory writes synchronous if (memory_write)
memory[address] = data_out; /* - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -*/ /* Example of how printout may be
used to trace execution */ /* This gives a trace of fetched
instructions in ncsim.log */ always @ (posedge clk) if (fetch)
$display("Fetching op.code %x from %x at time %t", data_in,
address, $time); /* - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - -*/ endmodule
! 71!
instantiated!within!a!module).!
!The!symbol!could!contain!a!schematic,!or!
it!may!in!fact!be!a!
module.! A! module! may! also! be! instantiated! as! a! symbol!
within! a! schematic.! It! is! key! to!
remember!that!it!is!possible!to!have!mixed!levels!of!representation!within!a!design.!
!
Mixed!Levels!of!Abstraction!
It!is!also!possible!to!have!mixed!levels!of!abstraction!within!the!test.!For!example,!the!Verilog!
stimulus!is!often!written!in!behavioural!Verilog,!but!he!device!under!test!could!be!structural!
Verilog.!!
source!description,!but!it!is!recommended!that!they!appear!outside!a!module!declaration.!
the! included! source! file! appear! in! place! of! the! `include!
command.! You! can! use! the! `include! compiler! directive! to!
include! global! or! commonlySused! definitions! and! tasks,!
without!encapsulating!repeated!code!within!module!boundaries.!
!
! !
! 75!
! Notes:!
! 76!
The!Event!Queue!
All!events!occur!with!respect!to!the!simulation!time.!At!the!start,!the!simulation!time!is!set!to!
zero! and! all! nets! become! high! impedance! (Z)! with! all!
variables! set! to! unknown! (X).! All!
procedural!blocks!(initial!and!always!blocks)!then!become!active.!!
The!pseudoScode!below!illustrates!the!Verilog!simulation!reference!model1.!
}
}
} }
Once!the!event!queue!is!populated!with!events!these!are!evaluated!at!the!current!time!stamp.!
assigned! to! the!value!on! the! leftShand! side! (lhs).!Hence,!
there! is! some!priority! in! the!order! in!which!blocking!
assignments!are!evaluated!that!is!determined!by!their!order!in!the!queue.!
In!the!case!of!nonSblocking!assignments,!only!the!lhs!side!of!each!assignment!is!evaluated,!the!assignment!to!the!
variable!on!the!lhs!is!not!performed!until!later.!
Once!all!active!events!on!the!active!events!queue!have!been!handled!the!update!of!the!nonSblocking!assignments!
is!performed!whereby!the!results!of!the!evaluation!are!assigned!to!the!variables.!
All!these!actions!take!no!time!and!consequently,!as!far!is!the!observer!can!tell,!they!occur!at!the!same!simulation!
time.!
Once!the!queue!is!completely!empty!then!the!simulation!time!moves!on!to!the!next!set!events,!i.e.!the!next!time!
instance!where!an!always!block!with!a!positive!edge!of!clock!in!the!sensitivity!list.!
Events! on! the! event! queue! are! created!when! an! action!
occurs! in! time.! For! example,! an!always! block!with! a!
sensitivity! list!will! cause! events! to!be!placed!on!
the!queue!when! the! signals! in! the! sensitivity! list! change! !
(as!
required).!!The!events!depend!on!what!assignments!are!listed!in!the!always!block!(and!what!new!active!events!
these!generate).!!!
the!assignments!listed!in!the!above!always!block.!This!will!effectively!cause!the!simulation!
time! to! stop! whilst! the! simulator! evaluates! the! events.!
Only! when! the! event! queue! is!
!
signal_C.!Once!signal_C! is! evaluated! then! the!queue! is!
empty!and! the! simulation! time!
moves!on!to!the!next!point!when!events!need!to!be!placed!on!the!queue!(rising!edge!of!clk!
again).!
resulting!events!are!placed!on!the!queue.! It! is!
important!to!understand!this,!as!the!way!you!
! !
this! stage,! simply! the! expressions! are! evaluated.! The!
assignments! are! placed! in! the!
nonblocking!events!queue,!and!are!performed!after!the!active!events!queue!has!emptied.!As!a!
result,!any!assignments!to!variables!that!may!be!being!updated!will!be!to!the!old!value,!not!the!
new!value.!
the!queue!can!be!random.!
events!are!placed!on!the!queue!and!subsequently!evaluated.!In!the!case!of!multiple!always!
blocks!and!depending!upon!the!simulator!used,!the!order!in!which!events!are!placed!on!the!
queue! can! be! somewhat! random.! Hence,! it! is! clear! that!
you!must! understand! the! effect! of!
blocking! and! nonSblocking! assignments,! particular! when!
variables! are! used! in! multiple!
always!blocks.!
!
module modulo10 (output reg carryout, output reg [3:0] count, input
clk, reset); // modulo10 counter using blocking assignments in one
always block always @(posedge clk) begin // logic for the modulo10
counter if (reset ==1 ) count = 0; else begin if (count == 9) count
= 0; else count = count + 1; end // logic for carry stage // look
for count becoming 9 to set carryout if (reset == 1) carryout = 0;
else begin if (count == 9) carryout = 1; else carryout = 0; end end
endmodule
In! this! example! we! have! a! single! always! block! with!
blocking! assignments! only,! so! assignments! are! evaluated! in!
the! event!queue! the!order! they! are! listed! in! the! code! at!
each!
rising!edge!of!clk.!!
!
module modulo10 (output reg carryout, output reg [3:0] count, input
clk, reset); // modulo10 counter using blocking assignments in one
always block always @(posedge clk) begin // logic for the modulo10
counter if (reset ==1 ) count = 0; else begin if (count == 9) count
= 0; else count = count + 1; end end always @(posedge clk) begin //
logic for carry stage // look for count becoming 9 to set carryout
if (reset == 1) carryout = 0; else begin if (count == 9) carryout =
1; else carryout = 0; end end endmodule
In!this!example!we!have!two!always!blocks,!one!to!increment!the!count,!and!one!to!set!the!
carryout.!!
However,! in! this! case! the!events!generated!by! the!
two!always!blocks!at! the! rising!edge!of! clk! can! be! listed!
in! any! order! in! the! event! queue! (remember! the! concurrent!
nature! of!
always!blocks).!Hence,!the!result!depends!on!which!is!evaluated!first.!
!
!
!
!
module modulo10 (output reg carryout, output reg [3:0] count, input
clk, reset); // modulo10 counter using blocking assignments in one
always block always @(posedge clk) begin // logic for the modulo10
counter if (reset ==1 ) count <= 0; else begin if (count == 9)
count <= 0; else count <= count + 1; end // logic for carry
stage // look for count becoming 9 to set carryout if (reset == 1)
carryout <= 0; else begin if (count == 8) carryout <= 1; else
carryout <= 0; end end endmodule
In! this! example! we! have! a! single! always! block! with!
nonSblocking! assignments! only,! so!
assignments!are!(essentially)!evaluated! in!parallel! in!
the!event!queue!at!each!rising!edge!of!
clk.!!
!
module modulo10 (output reg carryout, output reg [3:0] count, input
clk, reset); // modulo10 counter using blocking assignments in one
always block always @(posedge clk) begin // logic for the modulo10
counter if (reset ==1 ) count <= 0; else begin if (count == 9)
count <= 0; else count <= count + 1; end end always @(posedge
clk) begin // logic for carry stage // look for count becoming 9 to
set carryout if (reset == 1) carryout <= 0; else begin if (count
== 8) carryout <= 1; else carryout <= 0; end end
endmodule
In!this!example!we!have!two!always!blocks!with!nonSblocking!assignments!only,!one!for!the!
count!logic!and!one!for!the!carryout!logic.!As!the!events!will!be!evaluated!in!parallel!still,!
this!will!work! in! exactly! the! same!way! as!
the!previous!nonSblocking! example!with! a! single!
We!could!represent!a!design!at!a!higher!level!of!abstraction!than!we!have!seen!so!far!in!this!
course! unit! (and! previous! course! units).! In! fact,! a!
design! could! be! described! in! terms! of! a!
series!of!steps!to!solve!a!problem,!i.e.!an!algorithm.!A!problem!may!in!fact!by!solved!using!a!
number! of! different! algorithms! that! can! be! implemented! in!
different! ways.! Different!
characteristics.!!
!
Large! systems! may! in! fact! be! initially! described! in! a!
highSlevel! language,! such! as! C,! for!
simplicity.!The!role!of!the!hardware!designer!is!to!take!this!design!and!translate!it!to!a!design!
in!hardware.!HDLs,!such!as!Verilog,!make!this!process!much!simpler!as!they!offer!a!means!of!
expressing!a!design!in!a!behavioural!sense.!
Binary&Multiplication& !
We! could! look! at! the! design! of! the! multiplier! using!
standard! gates.! For! example,! when!
multiplying!two!2Sbit!numbers!X!and!Y,!we!would!be!calculate!
design!by!taking!this!design!and!translating!to!Verilog.!
The!full!java!code,!including!testbench,!could!look!something!like!this:!
! // Multiplication of two 8bit positive numbers using shift and
add operations // Using "int" type because java does not have 8 bit
and 16 bit unsiged types class multiplier { protected int S; //S
must be large enough to hold two 8bit
//numbers multiplied together protected int i; //i is variable for
iteration control protected int multiply(int A, int B) { S = 0; //S
acts as the accumulator therefore must
//be zeroed at start for(i = 0; i < 8; ++i) //iterate 8 times
over add/shift
//instructions { if((B & 1) == 1) //Inspect the lsb of B, do
I
!
!
!
!
! !
You!could!also!be!given!the!algorithm!in!C:!
! // Multiplication of two 8bit positive numbers using shift and
add operations. #include <stdio.h> #include <stdint.h>
// Multiplication function for two 8bit numbers uint16_t
multiply(uint16_t A, uint8_t B) { uint16_t S = 0; //S must be large
enough to hold two 8bit numbers
//multiplied together. //S acts as the accumulator therefore must
be zeroed
! !
Notes:!
! 114!
Full!code:!
!
! !
The!example!shown!is!just!one!implementation.!We!could!implement!the!design!in!a!number!
of!ways,!including!a!combinatorial!circuit:!
! //Verilog HDL for "COMP12111", "multiply" "functional" module
multiply(input [7:0] f1, input [7:0] f2, output reg [15:0] S); //
No need for handshake because this multiply is assumed to take
place in one clock cycle // No need to copy f1 or f2, they will not
get altered by this module always @(f1, f2) begin S = f2[0] ? f1 :
0; S = f2[1] ? (S + (f1 << 1)) : S; S = f2[2] ? (S + (f1
<< 2)) : S; S = f2[3] ? (S + (f1 << 3)) : S; S = f2[4]
? (S + (f1 << 4)) : S; S = f2[5] ? (S + (f1 << 5)) : S;
S = f2[6] ? (S + (f1 << 6)) : S; S = f2[7] ? (S + (f1
<< 7)) : S; end endmodule or,!:!
! 117!
Notes:!
! 118!
The!optimised!design!when!implemented!in!Verilog!may!look!like!this:!
! //Verilog HDL for "COMP12111", "multiply" "functional" module
multiply(input clk, input reset, input [7:0] f1, input [7:0] f2,
input start, output reg [15:0] S, output reg done); reg [15:0] A;
reg [7:0] B; reg [3:0] state; reg [3:0] i; always @(posedge clk,
posedge reset) if(reset == 1) begin state = 0; done <= 0; end
else begin case (state) 0 : //Idle state, waits for start signal
if(start == 1) begin done <= 0; //Used to indicate that mulitply
has not finished A <= {8'h00,f1}; //Copy f1 to A B <= f2;
//Copy f1 to B S <= 0; //Initialise S to 0 i <= 0;
//Initialise i to 0 state <= 1; end 1 : if(i < 8) //Is i <
8 begin //yes if (B[0] == 1) //Is B[0] == 1 begin //yes S <= S +
A; //S = S + A end B <= B >> 1; //B = B >> 1 A <=
A << 1; //A = A << 1 i = i + 1; //Increment i end else
//i is not < 8 begin ////End of loop - multiply calculated done
<= 1; //Now you can copy S to p state <= 0; //Finished,
return to idle state end endcase end endmodule! !! !
! 119!
! Notes:! ! !
! 120!
Revised!State!Transition!Diagram! There! is! some! redundancy! in!
the!binary!multiplier!we!have!designed,! as!we!use!
individual!
states! to! perform! individual! tasks.! However,! there! is!
nothing! to! stop! some! of! these! being!
performed!in!the!same!state.!However,!we!will!have!to!be!aware!of!how!long!the!actions!take.!
This!will!then!reduce!the!number!of!states!from!12!to!6.! !
! 121!
! Notes:! ! !
! 122!
Next& !
In! the! next! part!we!will! be! looking! at! implementing! the!
Stump.!We!will! be! designing! the!whole! processor! in!
Verilog,! so! we! will! be! using! structural! Verilog! to! create!
the! datapath,! and! behavioural! Verilog! to! depict! the!
functional!behaviour!of!the!processor.!
LOAD MORE