MARLUG - Mid-Atlantic Region Local Users G ANNUAL CONFERENCE - OCTOBER 12, Johns Hopkins University Applied Physics Lab – Laurel Object Oriented Programming – Lessons Learned Mike Mintz Co-author Hardware Verification with C++ [email protected]
Dec 29, 2015
MARLUG - Mid-Atlantic Region Local Users GroupANNUAL CONFERENCE - OCTOBER 12, 2006
Johns Hopkins University Applied Physics Lab – Laurel, MD
MARLUG - Mid-Atlantic Region Local Users GroupANNUAL CONFERENCE - OCTOBER 12, 2006
Johns Hopkins University Applied Physics Lab – Laurel, MD
Object Oriented Programming – Lessons Learned
Mike MintzCo-authorHardware Verification with [email protected]
mfm, www.trusster.com, OOP Lessons Learned, October 2006
2
Overview
• OOP Basics• The OOP Process• Summary• Q&A
mfm, www.trusster.com, OOP Lessons Learned, October 2006
3
Why OOP? A brief look back…
• machine code• assembly code• procedural code• Information Hiding• Data Abstraction do_action (void* opaque_ptr)
do_this(); do_that(value);
MOV.W R3, #100
0100100; 0111100;
struct foo {int a; char b;}
OOP is the main technique to manage programming complexity in large projects.
mfm, www.trusster.com, OOP Lessons Learned, October 2006
4
What is OOP?
• Structures inheriting from structures
• Can have data and/or function members (called methods)
• Can override or add behavior (cannot subtract)
• Can have access control
Source: Hardware Verification in C++, Chapter 1
class base
public:int some_data;
virtual void method_two ();
void method_one ();
class derived : public base
public:int some_data;
virtual void method_two ();
void method_one ();
mfm, www.trusster.com, OOP Lessons Learned, October 2006
5
The OOP Process
• Thinking OOP• Designing OOP• Classes in OOP• Connecting Classes• Coding OOP
mfm, www.trusster.com, OOP Lessons Learned, October 2006
6
Thinking OOP
• Essential versus Implementation complexity
• Apparently Simple• Adaptability and Ends-in
design• Interface, Implementation
and base classes
mfm, www.trusster.com, OOP Lessons Learned, October 2006
7
Designing OOP
• OOP is much more than syntax!
• Clearly define algorithms and actors
• Beware of apparently simple
• Interface versus Implementation
• Layers, Layers, Layers
Verification Component Hierachy
verification top
test watchdog timer
testbench
test component
irritator
chip
C++HDL
Source: Hardware Verification in C++, page 177, page 50
mfm, www.trusster.com, OOP Lessons Learned, October 2006
8
Classes
• A class is what you want it to be
• Not everything is a class• Bring derivation and
virtual in as needed• Beware the second
system effect
memory_1
memory_2
memory_3
memory_cache
hdl
GPU
memory_bank
c++
read () write ()map ()
Your verification code
memory_bank
memory_bank
Memory bank lookup
Memory Bank Objects
Source: Hardware Verification in C++, page 82
mfm, www.trusster.com, OOP Lessons Learned, October 2006
9
Connecting Classes
• As important as classes themselves
• Symmetry of connections
• Thicket versus well ordered mesh
uart::bfm_agent
uart::generator uart::checker
Detailed BFM Agent Connections
To UART SFMand chip
From chip andUART BFM
Channel
ActualExpected
Source: Hardware Verification in C++, page 294
mfm, www.trusster.com, OOP Lessons Learned, October 2006
10
Coding OOP
• The goal is to put the “if tests” in the obvious place
• Many tricks and idioms exist
• Coding style is always evolving
• Beware of coding standards
wishbonedriver
uart::uart_16550_sfm
uart::bfm
uart::basic_test_component
uart_test_0
testbench.v
uart::bfm_agent
uart::generator uart::checker
uart::uart_16550_sfm_agent
UART Example: Objects and Connections
Wire
Agent
Transaction
wishbone::driver
teal::memory::write()
1655 UART
uart::checker_agentuart::generator_agent
Source: Hardware Verification in C++, page 275
mfm, www.trusster.com, OOP Lessons Learned, October 2006
11
Summary
• OOP is a little bit syntax and a large amount of attitude
• Learning OOP is gradual process, making mistakes is in integral part
• Just Do It!• See www.trusster.com for
forums, articles, etc.
mfm, www.trusster.com, OOP Lessons Learned, October 2006
12
mfm, www.trusster.com, OOP Lessons Learned, October 2006
13
Deleted Scenes/Bonus Material
• This section contains “extra” slides that will be covered if time permits.
• Compares Verilog and OOP• Goes into some examples of OOP
mfm, www.trusster.com, OOP Lessons Learned, October 2006
14
Teal and Truss
• What is Teal?• Comparing Verilog and OOP• What is Truss?
mfm, www.trusster.com, OOP Lessons Learned, October 2006
15
What is Teal?
• A tiny, open source C++ to Verilog gasket
• Two stage logging• Stable, independent,
random number generators
• Thread management• Memory interface• Parameter passing
dictionary
void verification_top () { vreg clk (“testbench.clk”); vreg data (“testbench.data”); for (;;) { at (posedge (clk)); data = 1; }}
DUTreg clk;wire data;
testbench
mfm, www.trusster.com, OOP Lessons Learned, October 2006
16
Comparing Verilog and OOP in C++
Verilog Teal/C++ Comments
module class or struct
task compute_crc () void compute_crc ();
function reg build() reg build();
reg[7:0] clk; reg clk (8); Teal
$display (“Hello”); vout << “hello” < endm; Teal
clk <= 1; clk = 1; Teal
@ (posedge (clk)) at (posedge (clk)) Teal
fork/join start_thread (function)/join_thread Teal
$rand() RAND_RANGE() Teal
mc_scan_plusargs/vpi_get_vlog_info
dictionary::find() Teal
mfm, www.trusster.com, OOP Lessons Learned, October 2006
17
What is Truss?
• A small, open source, framework for verification
• Provides “the Dance”• Is a Design Pattern – not
always code• Can be the basis for
your test system
mfm, www.trusster.com, OOP Lessons Learned, October 2006
18
The Dance
• Top Level Dance• Test Component and Irritator Dances
mfm, www.trusster.com, OOP Lessons Learned, October 2006
19
The “Dance”
new()
WatchdogTest Testbenchverification_top
randomize()
time_zero_setup()
out_of_reset()
start()
wait_for_completion()
report(“final”)
report(“timeout”)
Createtopobjects
Build andconfigure
Maintestrun
Timeoutpath
Testresults
The Dance
Source: Hardware Verification in C++, page 97
your_test::new(testbench*, watchdog*, std::string)
testbench::new(std::string)
verification_top()
your_test::randomize()
testbench::randomize()
watchdog::time_zero_setup()
testbench::time_zero_setup()
your_test::time_zero_setup()
watchdog::out_of_reset()
testbench::out_of_reset ()
your_test::out_of_reset()
watchdog::write_to_hardware()
testbench::write_to_hardware()
your_test::write_to_hardware()
watchdog::start()
testbench::start()
$TRUSS_HOME/src/watchdog.cpp
your_test::start()
your_test::wait_for_completion()
testbench::wait_for_completion()
your_test::report(“Final Report”)
testbench::report(“Final Report”)
$PROJECT_HOME/verification/tests/your_test.cpp
$PROJECT_HOME/verification/testbench/top/testbench.cpp
Hold the reset line for the minimal amount, then release it. Return when registers can be accessed
Pull wires/registers up or down before releasing the reset line
Perform top-level randomization, for example, chose interfaces or features to be tested
testbench
Legend
your_test
watchdog
watchdog::new(std::string)Build objects,apply constraints
Push the configurations down to the hardware
Pause until the checkers are finished
Print which components have completed
Exercise the chip
The Dance – Detailed Flow
Source: Hardware Verification in C++, page 119
mfm, www.trusster.com, OOP Lessons Learned, October 2006
20
Lower level “Dance” – Painfully Detailed
your::new(generator, bfm, checker)
your::randomize()
your::time_zero_setup()
your::out_of_reset()
your::write_to_hardware()
test_component::start()
your::generate_()
test_component:wait_for_completion()
test_component::final_report (“Final Report”)
Start your generator, BFM, and checker
Performs the same function as the top-level components
Set up and run your“main traffic” method
Wait for your checker to complete
test_component::start_()
your::start_components_()
test_component::run_component_traffic_()
$PROJECT_HOME/verification/test_components/your_test_component.cpp
your_test_component:wait_for_completion_ ()
$TRUSS_HOME/inc/truss_test_component.h
called from the same named method in test
Test Component Dance – Detailed Flow
base implementation provided
you must implement
Your test
The test buildsyour test component
Legend
your_test_component::randomize()
test_component::start()
your_test_component::generate_()
Start your testbench generator, bfm, checker
Start_ runs in a thread!
Set up and run your “main traffic” method
test_component::start_()
your_test_component::start_components_()
test_component::run_component_traffic_()
The irritator dance
irritator::run_component_traffic_()
your_test_component::inter_generate_gap_() Pause the generate loop
from your_test::start()
until irritator::stop_generation()
$PROJECT_HOME/verification/test_components/your_irritator.cpp
$TRUSS_HOME/inc/test_component.h, and irritator.hyou may implement
you must implement
Legend
Source: Hardware Verification in C++, page 120 Source: Hardware Verification in C++, page 121
mfm, www.trusster.com, OOP Lessons Learned, October 2006
21
Summary(long form)
• OOP is a little bit syntax and a large amount of attitude
• Learning OOP is gradual process, making mistakes is in integral part
• Teal is a Verilog/C++ gasket• Truss is a verification framework• There are good examples in the book and on the
web
mfm, www.trusster.com, OOP Lessons Learned, October 2006
22