Download presentation
Presentation is loading. Please wait.
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.