xilinx HLS for OpenCV example

refs:
http://xilinx.eetrend.com/files-eetrend-xilinx/download/201305/3986-8011-xapp1167.pdf

MyHDL slides

coverage group based on different bins

bus interface coverage catagology

classification

• functional coverage bins
• address rage bins
• burst len bins
• read/write bins
• burst type bins
• byten enable bins
• cross coverage 
• read trx
• address, burst, read, ....
• write trx
• address, burst, write, ....
• performance coverage bins
• standard/normal bins
• out standard bins
• below standard bins
• cross coverage
• read trx
• standard
• write trx
• standard
• toggle coverage bins
• 0 -> 1 
• 1 -> 0
• cross coverage
• read trx
• 0 -> 1 -> 0
• write trx
• 0 -> 1 -> 0
• FSM coverage bins
• default pass
• protocol coverage bins
• atomic bins
• out of order bins
• divide/conquer bins
• address mapping table bins span tree
• hit rate bins (cache coherence)
• 
  

Cadence SimVision UVM/SystemVerilog debugger

transaction level debug via SimVision....

• transaction waveform info/pin level waveform info 
• transaction database info
• UVM phase sequence info
• assertion info
• coverage rate
• functional
• fsm
• code
• assertion
• performance 
• debug step by step, like gdb forward, backward, stop point, value dump....
• unknown signal trace back
• vif (virtual interface), Driver 

verification IP support lists

• http://syswip.com/
• support env : systemverilog
• IP lists
• AMBA
• CAN
• IO(I2C)
• ...
• http://www.smart-dv.com/products.html
• support env :
• IP lists
• AMBA
• IO(I2C)
• http://www.truechip.net/
• support env : UVM/OVM/SystemC
• IP lists
• USB3.0
• AMBA
• M-PHY
• IO(I2C)
• http://testandverification.com/
• support env UVM/OVM
• IP lists
• USB3.0
• AMBA
• IO(I2S, I2C)
• http://www.avery-design.com/
• support env UVM/OVM
• IP lists
• PCI
• DDR
• SATA

Demo for interview

最近為了 interview 寫了幾個小 project. 有興趣的就參考看看吧！！

xilinx axi bus traffic gen

• AXI4/AXI-stream
• dependent/independent transaction
• initial ram
• error interrupt/ status
• command
• data
• debug
• address gen
• align
• byte 64bit, 32bit...
• un-align
• offset
• type
• inc, wrap, fixed
• data gen
• mem data width
• initial system set
• NOP instruction for dummy loops
• Test DUT performance
• replay Bus transactions when the debugging mode is opened
• 
  
• ref:
• http://www.xilinx.com/support/documentation/ip_documentation/axi_traffic_gen/v1_0/pg125-axi-traffic-gen.pdf

Xilinx Hierarchical_Design_Methodology

• bottom up
• in any conditions should been re-runed partition again
• VHDL/ngc/ngd source changed
• constrains changed
• partition changed
• fpga package changed
• partition(split to small partitions)
• cost, benefit trade off, such as timing area ...
• black box(often used in Memory or fixed devices)
• ngc, ngd
• synthesis token 
• black box syntax in your VHDL like transfer_on, transfer_off
• minimal logic
• small cells. DSP/RAM normal cells
• advantage
• incremental place routing to reduce synthesis time
• no rerun again when it's non-touchable design  
• disadvantage
• the constrains need to be reseted in whole chip view, because in each sub constrains only has it's constrains setting, if some paths from source pad to internal block and this path can cross through two different constrain blocks, it means the sub constrains it seems does't work for this set.
• partition file
• PXML
• synplify smxl2pxml or xilinx xst
• pblock
• reversed place & route block 
• ngc 
• partition cell lib
• BoundaryOpt
• two partition interfaces bridge
• top down

ref:

• http://www.xilinx.com/support/documentation/sw_manuals/xilinx12_3/Hierarchical_Design_Methodology_Guide.pdf
• http://www.xilinx.com/support/documentation/white_papers/wp386_Hierarchical_Design_Synopsys_Xilinx.pdf

UVM AXI BFM 1.0 release

supported list

• AXI3/AXI4 bus protocol
• out of order/ inorder transactions
• each write/read phase is independent
• addr/write/resp is independent
• interlevel
• split
• performance watch dog 
• protocol watch dog
• performance report
• MAX, AVG, MIN bus bandwidth
• through put
• transaction list(disassemble bus info)
•  virtual master
• define each phase delay(req to grant or each valid/ready) or drive trx out time stamp
• virtual slave
• define each phase delay(req to grant or each valid/ready) or drive trx out time stamp
• scoreboard
• check connection
• check the memory read write is pass when the read/write trx in the same address, the read trx must be finished first than write trx to avoid the overwrite the address issue.
• STL 
• user define TRX language
• SystemC analysis port 
• user can use analysis port to link third part debug model by using DPI interface like Verilog to SystemC  or Verilog to C/C++
• 
  
• https://github.com/funningboy/uvm_axi

UVM notes 2

• UVM reference flow
• UVM tutorial
• http://cluelogic.com/tag/vmm/UVM_AGENT
• virtual sequencer
• handle each sub sequencers when the platform contains multi sequences to drive the same DUT. 
• avoid race conditions,  transaction sequence, like multi threads system
•  ex:
•       jb_seq1 = same_flavored_jelly_beans_sequence::type_id::create( .name( "jb_seq1" ), .contxt( get_full_name() ) );
•       jb_seq2 = same_flavored_jelly_beans_sequence::type_id::create( .name( "jb_seq2" ), .contxt( get_full_name() ) );
•       case ( recipe )
•         LEMON_MERINGUE_PIE: begin
•            jb_seq1.flavor          = jelly_bean_transaction::LEMON;
•            jb_seq2.flavor          = jelly_bean_transaction::COCONUT;
•            jb_seq1.num_jelly_beans = 2;
•            jb_seq2.num_jelly_beans = 2;
• configure
• set  register , interface from top to down
• test_lib -> test_env -> test_cfg -> test_agent ... 
• ex:
•    initial begin
•       uvm_config_db#( virtual jelly_bean_if )::set
•          ( .cntxt( null ), .inst_name( "uvm_test_top" ), .field_name( "jb_if1" ), .value( jb_if1 ) );
•       uvm_config_db#( virtual jelly_bean_if )::set
•          ( .cntxt( null ), .inst_name( "uvm_test_top" ), .field_name( "jb_if2" ), .value( jb_if2 ) );
•       run_test();
•    end
• register abstract
• check register r/w limitation(only r/w), fields check, width check, coverage, assertion
• ex:
•       flavor = uvm_reg_field::type_id::create( "flavor" );
•       flavor.configure( .parent                 ( this ),
•                         .size                   ( 3    ),
•                         .lsb_pos                ( 0    ),
•                         .access                 ( "WO" ),
•                         .volatile               ( 0    ),
•                         .reset                  ( 0    ),
•                         .has_reset              ( 1    ),
•                         .is_rand                ( 1    ),
•                         .individually_accessible( 0    ) );
• 
  
• assertion
• 
  
• functional coverage

high level synthesis with Xilinx

key notes:

• write your struct ASIC c code, no class...., only for struct supported
• familiar hardware c (no hierarchal ptr, dynamic/static cast/ptr)
• implemented module select(architecture set)
• sub standard cell assign
•  like a+b  for operator "add", it can be "32bitAdd", or "64bitAdd" ...
• memory assign
• internal buffer, (asyn_fifo) for different clock interface
• for loop extend(unroll)
• like for (i=0; i < 2; i++), it will be extend to l0, l1, sequences for reschedule, if the data doesn't have any dependence in this loop, that can merge these two sequences in one parallel sequence. 
• resource constrain
• area constrain
• sub cell constrain
• timing constrain
• scheduling and binding
• pipeline
• implemented protocol interface
• AXI3/4 AXI stream
• transfer task assign
• req/grant
• burst ... ex: axi_bus_write(addr, [data,..]) => for axi burst write transfer 

• RTL code gen
• verilog/systemc
• report
• trade off
• performance/area
• simulation time estimation
• delay 
• area estimation
• size
• refs:
• http://www.xilinx.com/support/documentation/sw_manuals/xilinx2012_2/ug902-vivado-high-level-synthesis.pdf
• http://www.xilinx.com/support/documentation/sw_manuals/xilinx2012_2/ug871-vivado-high-level-synthesis-tutorial.pdf
• http://www.xilinx.com/support/answers/50929.html

uvm DVCON2011 notes

uvm sequence item

speed up your simulation !!

• keynotes
• no waveform dump
• no timing check
• using unit delay
• using virtual model without real physical model
• atomic test like selftest/unittest
• atomic integration test / merge only input/output modules in DUT
• using two stage 0/1 info without 4 stage info 0/1/X/Z
• using error count num to finish simulation (avoid a lots useless info)
• using assertion to check functional value

ref:
https://www.google.com.tw/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CDIQFjAA&url=http%3A%2F%2Fwww.bawankule.com%2Fverilogcenter%2Ffiles%2FDVCon_Sim_Increase_paper.pdf&ei=bkGnUcOnKMWTiAeZroD4Bg&usg=AFQjCNEyEYLFxQb5Qo8XnYa3gLKppuIobw&sig2=GPKPKLOpKTZ3K4rmwZ571A
http://www.cadence.com/Community/forums/t/24886.aspx
http://www.synopsys.com/Tools/Verification/FunctionalVerification/Pages/VCS.aspx
http://www.deepchip.com/items/0385-03.html
http://www.cadence.com/community/forums/T/23927.aspx

Xilinx ucf constrain notes

ucf constrain

• timing constrain
• input pad to first flip-flop groups
• input offset
• internal flip-flop to flip flop groups
• period
• out flip-flop to output pad groups 
• output offset
• clock
• offset
• duty
• jitter
• rotate
• 90 
• 180
• 270
• multi cycle path
• from one clock dom to another clock dom
• using async fifo to avoid the data missing issue
• data valid
• req fifo.empty/fifo.full
• status
• false path
• not normal paths
• -to
• -from -to
• -through
• -from -through -to 
• data path
• normal paths
• fanout
• set maxfanout
• DCM / DLL/ PLL
• ECO div/mux
• TNM (timing group)
• 
  
• pin assignment constrain
• pad assignment 
• 
  
• slack
• Slack (setup path): =  (requirement - (data path - clock path 
• skew + uncertainty))
• Slack (hold path): = requirement - (clock path skew + uncertainty - data path) 

sytemverilog virtual interface setup time hold time check

we use systemveirlog virtual interface and simulator keys $setup, $hold to check the setup/hold time.

interface my_if #(c_clk_high_time = 5,
                  c_clk_low_time  = 5) (input clk, en);
  specify
    specparam clk_high_time = c_clk_high_time;
    specparam clk_low_time = c_clk_row_time;
    $setup(en, negedge clk, clk_high_time * 4 / 5);
    $hold(negedge clk, en, clk_low_time * 4 / 5);
  endspecify

endinterface;

or

module timing_checks_in_sv (input clk, data, ...); 
  ...
  event ev_data_delayed_toggled;
  
  always @(data)
  begin
    fork
    begin
      # tSetup;
      -> ev_data_delayed_toggled;
    end
    join_none
  end

  property setup_hold_time_checker;
    time curr_time;
    @(posedge clk) (1, curr_time = $time) |->
    @(ev_data_delayed_toggled) (($time - curr_time) > (tSetup + tHold)); // check data arrival time is meet $time - cur_time > (SetUp + Hold)
  endproperty : setup_hold_time_checker

  ASSERT_SETUP_HOLD: assert property setup_hold_time_checker;
endmodule 

ref :
http://learn-systemverilog.blogspot.tw/2010/07/writing-systemverilog-assertion-for.html
http://www.ee.ed.ac.uk/~gerard/Teach/Verilog/me5cds/me95rh.html

UVM TLM2.0 notes

if your are a ESL designer, you may heard about the SystemC TLM2.0 model that can help designer to design system level evaluation models very quick without any detail info such as Pin assignment, protocol selected, timing(real).... as you known, if you can use these abstract level api(blocking_trans, non_blocking_trans), you can replay or remodel design very quick without reconstruct your design again when the project is in evaluation phase. right now you can migrate your design from SystemC to UVM1.1d, because UVM1.1d is based on SystemVerilog that can be more suitable for EDA vendor supported and more friendly for verification designer... that's my guess ...


socket channel connection
initiator_socket : as same as master socket
target_socket    : as same as slave socket

ex:
1. create sockets in master/slave sides
initiator_socket ini_socket; // master socket
target_socket tgt_socket; // slave socket

connect(ini_socket, [tat_socket,...]) // connect one master to multi slaves

2. create trx payload to socket channel in master side
Trx trx = new();
trx.addr = 0x100;
trx.data = [0x1, 0x2, 0x3]; // generation payload
init_socket.write(trx);

3. collected trx in slave side
trx = tgt_socket.get_trx();     // fetch trx from socket channel fifo, and double check the trx is valid
if (trx != NULL) { // do something .... }


4. blocking trx
blocking interface conveys transactions in blocking fashion; its methods do not return until the transaction has been successfully sent or retrieved.  Because delivery may consume time to complete, the methods in such an interface are declared as tasks

5. non blocking trx
A non-blocking interface attempts to convey a transaction without consuming simulation time.  Its methods are declared as functions.  Because delivery may fail (e.g. the target component is busy and can not accept the request), the methods may return with failed status.

6. port, export, imps
port: instantiated in components that require, or use, the associate interface to initiate transaction requests. export : instantiated by components that forward an implementation of the methods defined in the associated interface. The implementation is typically provided by an imp port in a child component.

deep copy or shadow copy in your systemverilog object

as the same methodology as c/c++ or any languages. we usually used copy function to copy trx to avoid the overwrite trx when the trx had new ptr triggered. this is an sample example about what's the difference between deep copy and shadow copy, in short word. deep copy is top down copy, copy from this(current) level info to it's parents info. shadow copy is template current level copy, only for this level info.

class Based #(type T=int unsigned);
  T val;

  function new (T v=0);
    val = v; // assign new val
  endfunction : new

  virtual function void deep_copy(Based b);
    assert(b!=null);
    b.val = val; // b.val = this.val
  endfunction : deep_copy

  virtual function void shadow_copy(Based b);
    assert(b!=null);
    b.val = val; // b.val = this.val
  endfunction : shadow_copy

  virtual function bool eq(Based b);
    return b.val == val;
  endfunction : eq

endclass : Based

class A #(type T=int unsigned) extens Based;
  T val_a

  function new (T v=0);
    super.new();
    val_a = v; // assign val_a
  endfunction : new 

  virtual function void deep_copy(A a); 
    assert(a!=null);
    Based b;
    a.val_a = val_a;
    $cast(b,a);
    super.deep_copy(b);
    // or
    // a.val_a = val_a
    // a.val  = super.val
  endfunction : deep_copy

  // operator overwrite ... eq, lt, lt, ...
  virtual function bool eq(A a0);
    assert(a0!=null);
    Based b0;
    $cast(b0,a0);
    return val_a == a0.val_a & super.eq(b0);
  endfunction : eq


endclass : A


A a0 = new(1);
A a1 = new(2);

a0.val_a = 3;
a0.val = 2;

a0.deep_copy(a1);

// check a0, a1 contains are eq  a0 = a1
assert(a0.eq(a1));  

waveform modeling

as well as your are a ATE engineer, you may very familiar with the ATE test pattern formats that can transfer the waveform info into sample digital codes.
this is  a very example code for req/grant test case.

// timing modeling
task req_grant_00();                                                                                                                                                                 
  m_vif.REQ   <= 0;
  m_vif.GRANT <= 0;
  @(posedge m_vif.CLK);
endtask : req_grant_00

task req_grant_01();
  m_vif.REQ   <= 0;
  m_vif.GRANT <= 1;
  @(posedge m_vif.CLK);
endtask : req_grant_01

task req_grant_10();
  m_vif.REQ   <= 1;
  m_vif.GRANT <= 0;
  @(posedge m_vif.CLK);
endtask : req_grant_10

task req_grant_11();
  m_vif.REQ   <= 1;
  m_vif.GRANT <= 1;
  @(posedge m_vif.CLK);
endtask : req_grant_1

task

task wave_gen();
  list = {`ON_OFF, `ON_ON, `OFF_ON, `OFF_OFF};

  foreach(list[i]) begin
    case(list[i])
      `ON_OFF : req_grant_10();
      `ON_ON  : req_grant_11();
      `OFF_OFF: req_grant_00();
      `OFF_ON : req_grant_01();
    endcase
  end 
endtask

UVM scoreboard to check with c/c++ golden model via uvm analysis port

1.systemverilog DPI interface to interconnect the c/c++ part and systemverilog part

2.uvm analysis port to valid event channel

// golden cehck via uvm analysis port
// ps : the port should be connected to it's callback module. that uvm can collected.
// ex: item_port.connect( analysis_export );

uvm_analysis_port item_port

// DPI import ... for our golen model
import "DPI" void *yuv2rgb(int unsigned y, int unsigned u, int unsigned v);  
// yub2rgb(void* trx); using ptr is a more friendly interface....
import "DPI" void *rgb2yuv(int unsigned r, int unsigned g, int unsigned b); 

// callback func called from callable func/module
task callback(sample_trx trx);

  assert(trx!=null);
  if (trx.type == YUV2RGB)
    dpi_c_yuv2rgb(trx);
  else
    dpi_c_rgb2yuv(trx);

endtask

void dpi_c_yuv2rgb(sample_trx trx);
                                                                                                                                                                                    
  assert(trx!=null);
  c_rst = yuv2rgb(trx.y, trx.u, trx.v)
  assert( c_rst.r == trx.r &
          c_rst.g == trx.g &
          c_rst.b == trx.b);
endtask