USB has several layers, which are described in the USB 2.0 Specification. If you're familiar with the OSI layered network model, you can think of it like this:
- Session layer = Chapter 10 USB Host Hardware and Software (device drivers)
- Transport layer = Chapter 9 USB Device Framework
- Network layer = Chapter 8 Protocol Layer (bitstream)
- Data Link layer = Chapter 7 Electrical (circuit)
- Physical layer = Chapter 6 Mechanical (cable and connector)
Conceptually USB is based on streams of data, called Endpoints, which can be either IN (to the host) or OUT (from the host). Every device has Endpoint 0, which is used for control and status. A device may have additional endpoints for application data. Each endpoint behaves like a FIFO buffer.
Data is transferred on an endpoint either as Bulk (like TCP/IP, guaranteed that every byte arrives and in the correct order), or Isochronous (like UDP/IP, guaranteed to be fresh but may drop packets). There is a misleadingly named "Interrupt" transfer type, which is really just polled by the host.
USB 2.0 uses a differential pair for datalink. I won't go into much detail as this is covered by the USB 2.0 spec chapter 7. Generally on the PCB layout we treat this as a matched-length, differential pair, and put in the series resistors required by whatever USB PHY (Physical Interface) is being used. USB peripheral uses a high value resistor on one of the D+ or D- lines to notify the host that it is a high-speed or low-speed peripheral.
Soon after the USB host discovers that a device is present, the host requests a bunch of descriptors from the device. This is taken care of behind the scenes by the FTDI chip. The descriptos are described in Chapter 9.5. These include Device Descriptor, Configuration Descriptor, Interface Descriptors, Endpoint Descriptors, String Descriptors, maybe even HID Report Descriptors.
The Device Descriptor includes the USB VID (Vendor Identification) and PID (Product Identification) numbers. The operating system uses this pair of numbers, VID_PID, to determine which device driver shall be used for this device. Note that the VID number is issued by having membership in the USB implementors forum, so that's kind of a problem if you're an individual inventor.
Additionally, there is the HID (Human Interface Device) class driver, which provides somewhat generic input for keyboard/mouse/etc, as well as any generic input/output. One advantage of HID is that it does not require providing a custom device driver, but its throughput is somewhat limited compared to a custom bulk driver. There is a whole other specification document about the HID descriptors; and a HID Usage Table document that details all of the code numbers that describe the various features available on a given human interfaced device.
FTDI chip such as FT220X datasheet provides the USB "serial interface engine" (not to be confused with SPI serial or RS232 serial). This takes care of most of the low-level stuff described in chapters 6, 7, and 8.
FTDI uses an EEPROM (offchip on the FT2232H, on-chip on the FT220X) to contain a little bit of the information that goes into the descriptors. You can customize the VID/PID values, and provide custom description strings.