Вы находитесь на странице: 1из 4

Verification Academy Patterns Library

Verification Academy Patterns Library


Pattern Name: SW-HW Pipe Pattern
 Intent: The SW-HW Pipe Pattern is an implementation pattern that provides a
buffered one-way communication channel between separated HVL and HDL
module hierarchies in a dual-domain partitioned testbench. Writing to and
reading from the pipe can be done at any rate. Writes block if the pipe is full.
Data written to an empty pipe is available for reading on the next clock cycle.
Reading from an empty pipe has a well-defined behavior.

 Motivation: Implementing an efficient driver in a dual-domain testbench with


partitioned HVL and HDL module hierarchies targeted for the simulator and
emulator can be problematic as the nature of a driver in a reactive testbench
dictates that the UVM driver is not always able to provide data in advance, or
provide any data at all. At the same time, the testbench should be able to react
to events in the DUT with little delay. In order to facilitate optimization of the
HVL-HDL (or inbound) cross-domain communication channel, it should be
implemented using one-way, non-blocking function calls. However, the
generally unpredictable rates of writing to, and reading from, the channel
requires a return path for the implicit state (i.e. the buffer fill level) of the
channel. A return HDL-HVL (or outbound) call must be decoupled from its
corresponding forward HVL-HDL call to enable optimization of the latter in
environments that support it. The frequency of return path calls is reduced in
proportion to the size of the buffer.

 Applicability: The SW-HW Pipe Pattern is applicable in any situation that


requires reactive one-way transfer of data between separated HVL and HDL

Page 1 © Mentor Graphics Corporation, all rights reserved.


Verification Academy Patterns Library

domains in a common dual-domain testbench context. The pattern is pertinent


especially if the transfer is part of a reactive loop of the testbench.

HVL domain HDL domain

HVL driver HDL driver


uvm_driver subclass BFM as an interface

task write(bits); A2: write_fifo()


… buffer
endtask;
A1: wait_fifo()

proxy object sequential logic


B1: update_fifo_limit()

 Structure: The above diagram shows the flow of data and control between
partitioned HVL and HDL domains. Two decoupled processes are depicted,
namely the HVL domain write task (A1 and A2), and the sequential logic in the
HDL domain (B1).

 Implementation: The HVL proxy object implements a task wait_fifo() that


blocks until the proxy object determines that there is room for at least one more
entry in the HDL-side buffer. This task must be called by the HVL write() task
(step A1) before writing to the buffer using the write_fifo() function (step
A2). The HVL proxy object tracks the current buffer write level as well as the last
known buffer read level.

The write_fifo() function call implementation must do nothing, except


write into the buffer and update the buffer state. In must not – directly or
indirectly – trigger an event that causes a cross domain call. The HDL sequential
logic block is free to read from the buffer and should call the function
update_fifo_limit() to update the buffer read level state in the HVL proxy
object (step B1). This function should be called if there is a risk that the buffer
will underflow on the next clock cycle, but only if the last read level update was

Page 2 © Mentor Graphics Corporation, all rights reserved.


Verification Academy Patterns Library

significantly different from the current level. This is critical because the call to
update_fifo_limit() cannot be optimized and should therefore be called
only when necessary.

 Example: Example implementation, pseudo-code:

interface bfm_interface;
...
fifo_proxy proxy;
int read_index;
int write_index;
int write_limit;
...
function void write_fifo(input bits);
buffer[write_index++] = bits;
endfunction
...
function void do_update_limit();
write_limit = read_index+BUFFER_SIZE;
proxy.update_fifo_limit(write_limit);
endfunction
...
function bit read(output bits)
if ( read_index== write_index ) return 0;
bits = buffer[read_index++];
if (read_index+BUFFER_SIZE-write_limit>BUFFER_SIZE-1)
begin
do_update_limit();
end
return 1;
endfunction
...
always @(posedge clock) begin
// On 1st pass call do_update_limit()
// to update proxy state.
// Call read(bits) to get the next item;
// returns 0 if queue is empty.
end;
eninterface

class driver extends uvm_driver;


...
fifo_proxy proxy;
bfm_interface vif;
...
task write(input bits);
proxy.wait_fifo();
vif.write_fifo(bits);
endtask
endclass;

Page 3 © Mentor Graphics Corporation, all rights reserved.


Verification Academy Patterns Library

class fifo_proxy;
int buffer_write_level;
int buffer_write_limit;
event buffer_event;
...
function void update_fifo_limit(input int limit);
buffer_write_limit = limit;
-> buffer_event;
endfunction
...
task wait_fifo();
while( buffer_write_level==buffer_write_limit )
@(buffer_event);
buffer_write_level++;
endtask
endclass

 Consequences: The SW-HW Pipe Pattern can significantly reduce cross domain
communication, as compared to two-way calls, by reducing synchronization
events in emulation. The return path function call cannot be optimized, but the
number of invocations can be reduced. The performance savings ultimately
depend on usage and buffer depth, but the SW-HW Pipe Pattern never performs
worse than a blocking task call.

 Related Patterns: The HW-SW Pipe Pattern implements the BFM-Proxy Pair
Pattern.

 Contributor: Kristian Borum, Marvell Technology Denmark.

 Release Date: June 10, 2016

Corrections and Suggestions: To improve the quality of the Verification Academy


Patterns Library we welcome your comments, suggestions, and corrections. Please
contact us at: https://verificationacademy.com/contact

Page 4 © Mentor Graphics Corporation, all rights reserved.

Вам также может понравиться