USB2.

0_aware_DMAC_Requirements

03.11.2010

USB2.0 aware DMAC Requirements

1. Introduction
The document defines the requirements for a USB2.0 protocol-aware Direct Memory Access Controller
(DMAC) Device.
The DMAC is an integral part of a vendor-specific USB2.0 Device Controller System.
The Device is dedicated to USB Communication Channel. It does not perform common system DMAC
functions. It has the potential of being integrated into the Protocol Engine (PE) Device.
The DMAC function, within the USB2.0 Device Controller System, is to transfer data between the
USB2.0 Protocol Engine (PE) Receive/Transmit (RX/TX) Packet Buffers and the Device Controller
Functions Endpoints, in response to PE service requests. The DMAC has both Bus Master and Slave
capabilities. It is configured as Peripheral Device, for the required functionality, by the system
Controller, at system boot time and functions as a Master on the shared system memory and I/O bus
with the Controller, while transferring data back and forth. The joint functionality of the Protocol
Engine and the DMAC, offload communication tasks from the system Controller (C).
The DMAC is capable of performing words gather-scatter, support system data bus width up to 48bits
(6 bytes) and up to 24bits address bus (16Mbytes address range).
Flyby and gather-scatter data transfer modes between Memory and I/O Devices (like FIFOs), are
supported but Memory to Memory transfers does not.

2. GOK System Level Introduction

USB
Connector

Transceiver
Chip (PHY) UTMI

Protocol
Engine

DMAC

Controller

SRAM

AGE

System Bus

ROM/
EEPROM
Fig. 1 Controller-based Device Controller Block Diagram

The USB 2.0 DMAC is programmed by the C, at system boot time, according to the code generated by
the USB2.0 SDK, in the development system. Once, development has been completed and the USB 2.0
Device is ready for production, the C is eliminated from the system (cost saving) and Mask ROMs
replace the Configuration Registers within the Protocol Engine and the DMAC.
The DMAC Configuration Registers contain the information necessary to access the Animation Graphic
Engine (AGE) application-defined Endpoints Buffers (Memory or Register Files), i.e. the data width for
each and every Endpoint.
The DMAC supports up to 4 different functions within a single configuration (though within the GOK,
it supports a single function).
The PE issues a Transaction Request command (ntreq signal) and a Packet transfer request (npreq), for a
specific function Endpoint. The ntreq signal is used also as DMAC requests system bus access
permission from the C (nbreq). When bus access is granted by the C's Bus Arbiter, the nbgnt signal is
used also as a ndack signal to the PE and the DMAC starts data transfer transactions over the system bus
by issuing Endpoint Buffer Address, Read and Write control signals, monitor Function's Wait signal,
start data transfer (between PE Packet Buffers and EP Buffers Registers or Memory), either in flyby
single 16bit (word) data transfer mode or multiple bus cycles gather-scatter mode, to match different
source and destination bus width.
In both single packet or multiple packets data transfers, terminating specific channel/EP In Transaction
(from EP to Host), is done by the DMAC monitoring the End-Of-Transaction (neot) signal, issued by
the Function (last EP Buffer address reached). In case of Out Transaction (from Host to EP), if last
packet size is smaller than the pre-defined EP MaxPacketSize or packet having data size = 0 (zero), the
VLSI LAB

BIU

USB2.0_aware_DMAC_Requirements

03.11.2010

PE de-asserts ntreq signal (bus request de-asserted). In case of multiple packets data transfers, only the
npreq is de-asserted, bus request still asserted (and granted) and DMAC will carry on with next packet
data transfers as soon as npreq will be asserted. When both ntreq and npreq will be de-asserted, the
system bus is released for Controller's usage and the DMAC is ready to perform the next transfer
request.
The DMAC access PEs RX/TX Buffers (FIFOs), as an I/O Devices, using dedicated PE read/write
signals (npbrd/npbwr). Data is transferred over the system data bus.

3. AGE Device Controller System Diagram

+Vcc

-Vss

+Vcc

nbreq
nbgnt

nbreq
nbgnt

XTAL
Oscillator

ntreq
npreq
ndack
ep_dir
epn[3:0]

16bit RISC
Controller

clk
nrst

+Vcc -Vss

-Vss

nrst

clk

USB2.0-Aware
DMAC

abus dbus
npbwr npbrd nwr nrd nwait [23:0] [47:0]

nmi int[0..6] nwr nrd abus[15:0] dbus[15:0]

nrd

LDO
USB
Connector

Data Bus

+V -V

Address Bus
nwr

+D -D
int
CLK
UTMI

USB2.0 PHY

nwr nrd abus

[15:0]

ntreq
dbus
[15:0] npreq
ndack
USB2.0 Protocol ep_dir
epn[3:0]

Engine

epn[3:0]

abus dbus
[18:0] [47:0]

AGE ASIC
Device

npbwr
npbrd

RST
nrst
+Vcc

nwr nrd nwait

clk

nrst

clk

-Vss
+Vcc

-Vss

+Vcc

-Vss

4. Implementation
The DMAC is designed as a Front-End for near future ASIC implementation. It is designed using
Verilog HDL and simulated/logically verified for correct operation, using Cadence Incisive Simulator.
Intermediate Hardware Implementation, for proof of concept and correct functionality, is performed
using FPGA Device, located on Altera DE2 Development Board, under Quartus II Development
Environment. The Incisive logically verified Verilog code is used for implementation.
Quartus II MegaFunction Wizard is not used.
There is an option to incorporate the Protocol-Aware DMAC into the USB2.0 Protocol Engine.

VLSI LAB

BIU