comp22111’ processor’ microarchitecture’
TRANSCRIPT
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.!
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.!