SESSION#1
- usb_doc.pdf : DUT specificaiton
- utmi.pdf: PHY specification
- USB in nutshell.pdf : USB basics concepts on communcation between host and device
UTMI will be present at both Host side & Core side
Features:
- Device detection not to be covered at core level
- Speed negotitation
- multiple scenarios:
Host is FS capable, Device is HS
Host is FS capable, Device is FS
Host is HS capable, Device is HS
Host is HS capable, Device is FS - what is device role? host role? in speed negotiation process
XcvrSelect = 0 => HS transmitter & receiver enabled
XcvrSelect = 1 => FS transmitter & receiver enabled
TermSelect = 0 => HS, 1 => FS
D+ , D-
0 0 => SE0
0 1 => K
1 0 => J
1 1 => SE1
Device is sending Chirp K => Device is driving 0 on D+, 1 on D-, spec also for how much time?
UTMI Driver & Sequencer will replace the host behavior, UTMI driver will be
actually sending ChirpK & J in response to USB core Device Chirp K
SPeed negotiation:
Power on -> FS mode -> device attached -> Normal -> Suspend -> Reset -> Speed negotiation seqeunce -> Normal data transfers
Data transfers:
Transmit: Device giving data to UTMI host
signals: TxValid(device to host) & TxReady (host to device ack)
Control Transfers:
- Setup Stage: Host indicating to device which all descriptors it wants to read
o Setup Packet + Out Data Packet + Ack Packet - Data Stage: Actually exchanging device descriptor data infromation
- Status Stage : is exhcnge happened properly?
Isochrnous transfers:
- no handshaking stage
- has 80% guaranteed bandwidth in FS, 90% in HS
Interrupt transfer
- Device has the data, host want to read it
- device will not generate interrupt to host, rather host will interrupt
packet to device, if there is no data, device will issue NAK handshake, if
there is data device will send data in packet
AHB (Function) interface: (Master interface)
- Interrrupt handling
- DMA request handling
- Register configuration
UTMI interface: (Master interface)
- Device detection
- Speed negotiation
- data transfers
- suspend
- resume
SRAM interface: (slave interface)
- only for temporary data storage
TB coding:
- wb_tx.sv
- usb_frame.sv
- base_pkt.sv
WB Protocol:
wb_clk_i
wb_rst_i
wb_addr_i : where we want to do write or read
wb_data_i : data to be written(wb_we_i = 1)
wb_sel_i : which all bytes of data_i are valid(1 bit for each of 8 bit of data_i bus)
wb_data_o : data read
wb_we_i : Write or read
wb_cyc_i : continutaiton of previous transfer
wb_stb_i : current transfer on bus is valid
wb_ack_o : slave is ready to accept the transfer
At any +edge of clock, if wb_cyc_i, wb_stb_i, wb_ack_o are high, at the point addr is valid, data is valid
CLock edge 1 => WB master will drive wb_addr, wb_cyc = 1, wb_stb=1, wb_data_i is also driven
CLock edge 2 => wb slave will acknogliedge its readyness by driving wb_ack_o = 1=> at this edge transfer is complete, master can initiated new transfer clock edge 3(not on 2)
Defining WB_tx?
SESSION#2
USB funcitonality:
- register configruation : WB
- Enumeration : UTMI
- speed negotiation : UTMI
- data transfers : UTMI
- dma wr/rd’s : WB
- interrupt handling : WB
- suspend/resume : UTMI
User needs to develop seqeunces specific to above functionality
register_config_seq, dma_wr_rd_seq, int_handling_seq (WB_SEQ_LIBRARY)
Enumeration_seq, speed_neg_seq, data_transfer_seq, susp_res_seq (UTMI_SEQ_LIBRARY)
- Configuration keeps changing from test to test
usb_bulk_basic_test
- 3 ep’s used
- ep0 : control
- ep1 : bulk in
- ep2 : bulk out
usb_bulk_all_ep_test
- 16 ep’s used
- ep0 : control
- ep1(odd number) : bulk in
- ep2(even number) : bulk out
- To program a register we discussed 2 ways of doing
1st: without using register model
`uvm_do_with(req, {req.addr == register_address; req.data == data_to_write;})
- monitor the interface
- make a transaction
- predict the value(register_layer.register.predict())
2nd: using register model
reg_block_name.register_name.write(status, data_to_write);
- 2nd is better, it first updates register layer values(mirrored, expected,
value) then goes and updates DUT register value. We are always maitnigng
copy of register value in tb environemtn
- Every test case goes in following steps(applicable to every design)
- reset
- release reset, wait for design to come out of reset
- power up teh design
o Memory controller is a simple design there is no powering up
o USB need to powered up(detect, attached, reset, …speed negotiation, data transfers) - Wait for design to be proper running state
- then start actual traffic(generating frames)
o configuration of the dut registers
o generating frames
- Powering up verificaiton
- what utmi_driver should do? wb_rst should be applied, FS Mode(txvr_mode_select, term_select both should be 1)
- wait
- what to expect from design?
6.100/7 = 2
data_in = 100
poly = 7
crc5 = 2
numerals
in Pkt, we talk interms of bit arrays
//16 EPs
//EP0 : control
//EP1-5 : bulk
//EP6-10 : ISO
//EP11-15 : interrupt
usb_bulk_test
- only geenrate bulk pkts(in or out)
- which ep to target??
Before I start test(pkt geenration), I need to decide which ep supports which
tfr type? I should constraint token_pkt.endp value accordingly
- ENd goal : create a usb bulk test
- not just involves driving bulk pkts, need to do complete flow
speed neg
enum
config
data transfer
dma
int
SESSION#3
- UTMI Monitor can send informaiton to refernece model in different ways
- byte level
o issue: reference model will have to do all teh analysis, montior will be
just collecting each byte and giving to reference model. rEFE model will
become very complex - frame level
o Issue: DUT will handle input at pkt by pkt level(DUT does not collect whole frame, then process), reference model also should mimick the same behavior
o frame level tx is not right option - pkt level(token pkt, sof, data pkt, hs pkt, special pkt)
o this will mimich the way DUT is behaving
- Pkt level communication between utmi monitor & refrence model
o token, sof, data, hs, special
o Analysis port only supports one type of pkt only
o uvm_analysis_port#(sof_pkt) ap; //ap only supports sof pkt, it will not support data pkt, hs pkt, token pkt, etc
o solutionL: declare AP with base_pkt as communication data
o uvm_analysis_port#(base_pkt) ap; //all pkts are derived from base_pkt, by virtue of polymorphism we will be able to send any pkt derived from base_pkt - Functional coverage for USB2.0 core
- listing down FC points
o generation of all types of pkts
o working at different speeds(FS, HS)
o EP specific coverage, bulk, iso, int, control transfers
o IN/OUT direction transfers
o different EP targeted
o address targeted
o different types of interrupt generation
o is the lrg pkt, sml pkt generated
o dma en for all eps
o number of txs per microframe for each EP
o sram locations targeted
o sram wr/rds
o register’s accessed, wr/rd to registers - implementing FC in testbench
o Some part is implemented in UTMI coverage block (utmi_cov)
o Some part is implemented in WB coverage block (wb_cov)
o Some part is implemented in Register model (usb_reg_block) - analyzing the FC results
- Reference model implementation
o DUT mimicked model
o if SOF comes in to USB core?
o DUT will check if pid is proper(pid[7:4] == ~pid[3:0]) (if it fails?? int_src_reg::pid_error it will be asserted in int_src rgister)
o is frame_no in series? (saves previous frame_no, compares it with current frame_no)
o is crc5 correct? (fails , crc_error in int_src)
o What refreence model should do with SOF pkt?
o same 3 steps as above
o Reference model instead of updating DUT reister, it will udpate register model’s register
o After SOF, TOKEN pkt will come
o what DUT does?
o pid check?
o crc5 check
o addr comparision with my FA? match means process the next data pkt and hs pkt, else drop them since this Token pkt is for some otehr device
o ep_no, check if the ep_no is configured in DUT, get all the ep information, process the next incoming or outgong data pkt accordingly
o What refreence model should do with TOKEN pkt?
o same as what DUT does
o DATA PKT handling?
o DUT will check pid, crc16
o if OUT pkt, data will be written to sram model, generate dma_req to funciton controller
o if IN pkt, dma_req generaetd to FC, start reading data from sram model, send the IN pkt to UTMI interface
o REFENCENCE model will not do exactly the way DUT is doing above
o pid, crc16 check
o it will not write data to sram, it will make sram tx out of this data, it will compare these tx with txs happening on sram interface/utmi itnerface
o it will not also generate dma_req
o it will not write/read to/from sram
o WHile doing all above operations, DUT will access registers to decide how to handle pkts at different stages
o ex: pid error happned, should I generate int or not? int_msk.pid_error_enable
o DUT got token & data pkt, should I send HS pkt? check ep_no, type of ep, if ep_type is ISO, then don;t send, else send
o Reference model also will refer to register model at each stage to decide on how to handle each pkt
- Reference model implementation
o base class: uvm_scoreboard
o it will have 3 analysis implmentation ports to get data from wb_mon, sram_mon, utmi_mon each
o it should analuze the pkts the way DUT does
o data comparision
SESSION#4
- Many to one connection
- all of them will call ap.write
- Env
utmi_agent.mon.ap.connect(ref_model.imp_utmi); //ap.write happens automatically ref_model.write_utmi gets called
- store the pkts in to a mbox or Q
while (1) begin
pktQ.pop_front(pkt); //this will be 0 delay loop
end
while (1) begin
mbox_pkt.get(pkt); //this will be blocking
end
- WB TX conversion to SRAM Format
- wb_tx : byte addressed, each byte has a address
- SRAM_TX(INTF) is word addressed, each word has
WB_TX : 100
SRAM_TX : 100/4
WB_TX : addr => addr >> 2;
data => same
wr_rd => same
- COnverting UTMI PKTS in to SRAM format
- sof
- token pkt
- data pkt
- hs pkt
- special pkt