1. Vinculum II Device Hardware

2. Content Device overview. Architecture. Power consumption. Packages.
CPU.
USB interface.
FIFO.
SPI.
Timer.
PWM.
DMA.
Power consumption.
Packages.

3. VNC2: Product Introduction
VNC2 is a programmable USB Host / Slave controller with embedded microprocessor core.
Designed to provide powerful, programmable USB Host / Slave capability within embedded applications.
VNC2 is FTDI’s 2nd generation of dual USB Host / Slave controllers.
Enhanced features and capabilities over VNC1L:
Upgraded CPU offering increased the processing power.
Programmability, supports user customised firmware.
Hardware acceleration of USB processing.
Multiple interfaces
Software design tools and development resources to enable faster time to market, as well as provide a low-risk easy to adopt solution.
Information in VNC2 Data Sheet: Vinculum II Embedded USB Host Controller IC
16 bit uC as opposed to 8 bit uC.
256k Flash as opposed to 64k Flash
16k RAM as opposed to 4k RAM

4. VNC2: HW Architecture Two independent USB Host / Slave interfaces.
16-bit Harvard architecture MCU core.
3 CPU operating frequencies
12/24/48MHz.
256KBytes Flash Memory for firmware storage.
16KBytes RAM.
Interrupt and timer interfaces

5. VNC2: HW Architecture Interfaces: UART SPI Slave SPI Master FIFO mode
8 PWM blocks
GPIO
Debug Interface
4 DMA engines for managing I/O transfers
UART – Traditional interface for communicating with an embedded CPU device. Supports transfers up to 6MBaud
SPI – 2x SPI slave. 4-wire interface, popular device interconnect. SPI can be used to drive display controllers. SPI master can also be used for SD card type interfaces
Supports following modes: Full duplex, half duplex, half duplex (3-bits), and unmanaged mode.
1 SPI master port – Supports full and half duplex communications. 1 slave select pin.
FIFO – Fast data communication interface, connects to PLD to FPGA type devices. ‘245’ implementation similar to other FTDI products.
- Asynchronous and synchronous modes supported.
- Asynchronous mode: 10Mbps max transfer rate
- Synchronous mode: 48MBytes/s
PWM – Pulse width modulation. Traditionally used to control motors. Allows the device to be used to connect to motorised or mechanical devices.
- 8 PWM channels
- 16-bit counter, trigger inputs.
- Interrupt control
- Generate 4 outputs with output enable.
GPIO – Connect input / output devices to VNC2. Support up to 40 GPIO. Can be used with interrupts.
Debug Interface – Single pin, supports half duplex operation at 1Mbps. UART style interface 8 data bits, 1 start bit and 1 stop bit.
DMA Engines – Designed to manage data transfers between interfaces and memory and memory to memory. 4 DMA engines allow 2 interfaces to be used at the same time where 1 engine is used for TX and another for RX. Limited internal buffer memory within the device.

6. Architecture

7. Architecture
Vinculum II internal structure is centred round 3 internal buses:
Program memory bus (32 bit wide)
CPU collects instructions from the flash on this bus.
Additionally used by the flash programmer to program the flash and via the debugger for debug purposes.
Data memory bus (32 bit wide)
Memory can be written/read from a number of masters on the bus: debugger, USB hosts/slaves, DMA engines and the CPU.
Memory is byte addressable
Peripheral bus (8 bit wide)
Large bus with a number of masters and slaves.
All other peripherals act as slaves on the bus: FIFO, GPIO, UART, Flash Programmer, timers, etc, etc.
Internal bus is pipelined and data is written/read per cycle.

8. CPU
Vinculum II has expanded the Vinculum I CPU to provide a cost effective, USB optimised CPU:
VNC1 – 8 bit Harvard architecture
VNC2
16 bit Harvard architecture
Operating frequency – 48MHz, 24MHz, 12MHz.
Variable length instruction word – instructions can be 16 bit to 64 bits in size
8, 16, 32 signed/unsigned support
Byte addressable
CPU Performance 6-8DMIPs

9. CPU Resource
A large percentage of VNC1 software functions have been moved into VNC2 hardware, releasing CPU resources.

10. VNC2: USB Support VNC2 has two independent USB Host / Slave interfaces
USB 1.1 & USB 2.0 compliant interfaces.
Supports 1.5Mb/s (Low Speed) and 12Mb/s (Full Speed) transactions.
Supports 4 transfer types of the USB specification.
Interrupt transfers:
Bulk:
Isochronous:
Control
Timely, reliable transfers, eg keyboard and mouse.
Large blocks of data less time critical eg Printers, FT232R.
Defined bandwidth & latency eg. Webcams.
Used for device configuration and enumeration.
Slide detailing USB support.
2 independent USB Host / Slave channels. Both channels are independent and therefore one port can be used as a host while the other can be used a slave.
USB Transfers – Main change is the introduction of isochronous transfers opening up the use of the device for web cam or similar types of applications.
USB Host capability
OHCI host controller used, which is comparable to the type of USB host controller found in a PC. The advantage of this type of controller is that the USB processing is done in the controller, thus freeing up the CPU for user application processing. USB controller is not fully OHCI compliant, so customers cannot integrate their own OHCI drivers. Discussed later.

11. USB Host
The USB Host has been modelled on USB OHCI (Open host controller interface) specification.
Powerful, autonomous host processing engine.
Minor CPU resource is needed to manage the USB Host.
Expanded USB class support compared to VNC1L
Supports chaining of USB transfers
Note: the USB Host is not fully OHCI compliant. Customers cannot port their own OHCI driver to it.
OHCI exceptions – 14-bit addressable space vs 32-bit addressable space for a full OHCI host.

12. USB Slave
The USB Slave is a simplified extension of the host controller.
A maximum of 2kbytes can be transferred in one transfer descriptor.
A transfer descriptor has the following format:
ZB – a 0 byte packet was received (OUT) or terminate the transaction with a 0 byte packet (IN).
Sz – max packet size of 8, 16, 32 and 64.
Error Code – what type of error occurred.
Buffer pointer – current byte read/written from memory.
Size of buffer remaining to be transmitted.

13. DMA
All peripherals have very small internal buffers – typically 2 bytes.
Buffering is performed using main data memory, via DMA engines.
Buffers can therefore be configured to any user specific size.
The DMA engines provide the following features:
Push – transfer data from memory to the IO.
Pull – transfer data from IO to memory.
Memory copy – copy data from one memory location to another memory location.
FIFO – use the main data memory as a FIFO.
The USB Host and Slave engines are autonomous and effectively have DMA engines built in.
Four DMA engines have been instantiated to support two peripherals simultaneously – e.g. one DMA engine will be used for the UART’s TX path and one engine will be used for the UART’s RX path, leaving two DMAs for a second peripheral.
The DMA engines additionally have a number of status registers, such as bytes transferred, etc.

14. UART GPIO Standard UART supporting 183baud to 6Mbaud.
Supports the following connections:
TXD, RXD, RTS#, CTS#, DTR#, DSR#, DCD#, RI, TX_ACTIVE
GPIO
The GPIO supports 40 general purpose that can be configured as inputs or outputs.
Interrupts can also be raised when any of the inputs transition (high to low or low to high) or are at a configured level.

15. FIFO VNC2 support FIFO style communications interface.
FIFO implementation consistent with other FTDI products.
Asynchronous FIFO mode
Also known as ‘245’ FIFO mode.
Max transfer rate 10MBytes/s max transfer rate.
8 bit data interface with RXF#, TXE# outputs and WR# and RD# inputs.
Synchronous FIFO mode
Max transfer rate 48MBytes/s.
Same data and control lines as asynchronous mode.
Additional FIFO_OE# input and FIFO_CLKOUT output.

16. Asynchronous FIFO
RXF# low indicates data is available to be read in FIFO. User drives RD# low to read data
TXE# low indicates data is can be written to FIFO. User drives WR# low to write data

17. Synchronous FIFO Mode
Transfers synchronised with CLKOUT. Transfers occur when OE# is low

18. SPI Interfaces Popular 4 wire serial interface.
VNC2 supports two SPI Slave ports and one SPI Master port.
SPI master feature supports SD card interfacing, amongst other applications.
SPI max clock rate derived at ¼ of CPU clock frequency.
Normal mode, CPU 48MHz, SPI max clock is 12MHz
Lowest power mode CPU 12MHz, SPI max clock is 3MHz.
Various supported operating modes.

19. SPI Master & Slave
The SPI master and slave both support “unmanaged modes”.
The SPI slave additionally has extra “FTDI” modes.
Unmanaged mode transfers data in both directions at an access:
Note: CPHA=0 may be dropped from the SPI slave.
Unmanaged Mode
CPHA – Clock phase control. CPOL - Clock polarity control determines if data is clocked in and out on rising or falling edge of SCLK.
In example CPHA and CPOL

20. SPI slave
The SPI slave protocol by default does not support any form of handshaking.
FTDI have added extra modes to support handshaking, faster throughput of data and reduced pin count. These modes are as follows:
Mode
Pins
Word Size
Handshaking
Speed
Comments
Vinculum I 4 12
Yes
Read – 66%
Write – 66%
Legacy Mode
Full Duplex 8
Write – 100%
Read – 50%
Bi-directional
Read – 100% 3
Write – 50%
MOSI becomes bi-directional, removing MISO

21. Debug Interface Designed to support firmware debug via software tools.
Modelled one bit bi-directional pin, using UART 1Mbaud, 8 bit, 1 start, 1 stop, no parity protocol.
Debugger is a master on all internal buses and can therefore configure peripherals, change memory, write to the flash, etc.
Accesses CPU’s breakpoint unit (effectively a peripheral) to set breakpoints, halt, step, etc.
Protocol: simple command, followed by address and data protocol.
The command options are as follows:
R/W – read or write.
Byte, word, dword or block access (block can be up to 64 bytes).
Address space – peripheral, data memory or program memory.

22. Debug Interface
Debug module circuit. Used to translate debug pin to a USB I/F for software tool access
Users can implement entire circuit or implement compatible debug header

23. IO Multiplexer VNC2 features an internal IO multiplexer (IOMux)
Designed to provide a flexible mechanism for connecting pins.
A device signal, eg UART_TXD, is allocated to one of four groups.
Signal can be connected to any IOBUS device pin in the group.
Each IOBUS pin can also be pulled up/down, have extra drive strength and can be a schmitt trigger.
Asserting device PROG# and RESET# pins will cause IOMux pins to return to default settings.
UART TX
Possible Paths

24. Timers 4, 16 bit user timers, with the option of a 16 bit prescaler.
3 timers are available to designer, 1 is used by RTOS.
Functionality includes:
Stop/start
Clear/initialise
Can read current timer value.
Count up or down.
Interrupt when threshold is hit.
One shot or continuous mode.
32 bit watchdog timer.
When it expires the CPU is reset.
CPU should clear this counter at a predefined interval.

25. PWM 8 PWM outputs with 8 bit prescaler and 16 bit timer.
16 bit comparator per output to support 8 toggles per PWM cycle.
Programmable shot or continuous mode.
Can be started from external interrupt.
Example output from a single PWM pin:

26. Power Consumption Vinculum II has four power modes of operation.
The first three power modes are used while operational:
Mode
Power Mode
Power consumption when running RTOS only
Typical Operating Power Consumption
48 MHz
Normal
11mA
25mA
24 MHz
Low
8mA (estimated)
mA (estimated)
12 MHz
Lowest
4.3mA
8mA
The fourth power mode is standby mode, where the part can be fully suspended, consuming ~150uA, and can be woken when any of the following configurable pins change:
USB0/1 DP or DM toggles
SPI slave 0/1 SSn toggles
uart_ri toggles

27. Packages  Vinculum II comes in 6 different packages: Device/Package
VNC1
VNC2
Comments
LQFP – 32 pin 
LQFP – 48 pin
See app note AN_118 on migrating from VNC1L to VNC2
LQFP – 64 pin
QFN – 32 pin
QFN – 48 pin
QFN – 64 PIN

28. VNC1L Backwards Compatibility
Remove
Replace with VNC2
Change capacitors to 27pF.
Change
C10 to 4.7uF, C11 to 100nF, R7 to 0ohms.
Remove
8 BOM changes required to adapt design to support VNC2. Further details in AN_118 Migration Guide.

29. VNC2 to VNC1L Summary
Feature
VNC1L
VNC2
USB Mode
2 x USB 2.0 Host / Slave
Transfer Modes
Bulk / Interrupt
Bulk / Interrupt / Isochronous
CPU
8-bit Harvard architecture
16-bit Harvard architecture
Memory
RAM
4KBytes
16KBytes
E-FLASH
64KBytes
256KBytes
Interfaces
UART, SPI slave, FIFO
UART, 2 x SPI (slave),
SPI (master), FIFO, PWM, Debug
Pre-compiled firmware
Yes
Tools for creating own firmware No
Configuration Ports
UART, USB (after initial programming)
UART or Debug port.
Package
48-pin LQFP
32 pin LQFP/QFN, 48-pin LQFP/ QFN, 64-pin LQFP, QFN
USB processing moved to hardware, freeing up CPU cycles
48-pin LQFP backwards compatible with VNC1L

30. Miscellaneous Prog Loader
Prog loader is a utility which occupies the bottom pages of flash to facilitate programming the of the flash memory.
When PROG# is asserted, the part can be programmed via the debugger or via the UART (programming protocol backward compatible with VNC1).
Prog loader is programmed into a reserved area of Flash memory during manufacture. Cannot be overwritten by a user.
Asserting PROG# and RESET# pins will put device IOMux settings back to the default state.
A bootloader is compiled into the ROM file and is used to load program into RAM.
Power on reset is also present. Reset could be tied high.

31. Summary
VNC1 to VNC2 – more powerful, flexible part, with a number of software functions offloaded to hardware.
Packages – 32, 48 & 64 pin packages in QFN and LQFP.
Architecture – part revolves around 3 central buses: peripheral, program and data memory.
Peripherals – an extensive range of peripherals exist, including powerful USB Host/Slave
DMA and timer resources to aid I/O throughput and program control.
Power consumption – VNC2 has low power modes, including a standby mode.
Miscellaneous – VNC2 programming is backward compatible with VNC1