You are here: HomeProjectsSeries 1 - Display Driver BoardsSeries 1: Part 6 - Towards Creating a Universal Display Driver Board (LQ043T3DX02)

Series 1: Part 6 - Towards Creating a Universal Display Driver Board (LQ043T3DX02)


0000317In this part of the design series the foundations are laid for developing a universal display driver board for displaying data on the LQ043T3DX02 display used in the Sony PSP. The engineering design flow of firstly considering the project aims through to finally extracting the system requirements is demonstrated.  By considering the design of the board from a customer's and not a design engineers view point, the requirements derived in this part of the series are captured from a users point of view. Consequently this part of the series achieves the aim of determining the system requirements of a universal display driver board.

1.6.1 Introduction

In the previous editions of this series, on interfacing to the LQ043T3DX02 display, the primary design goal has been to interface the display to a Field Programmable Gate Array (FPGA) in general and to the Xilinx Spartan 3A Starter Kit in particular. This was demonstrated successfully and after the elation and imaginary feeling of walking on water it is now time to return back to land, put to one side the sandals and robe and tackle the next stage of the design project.

One unexpected outcome that has arisen over the duration of the first 5 parts, of series 1, is the significant interest shown by engineers other than digital design engineers. A welcoming interest has been shown by users of micro-controllers too. Of the readers interested in using FPGA’s, a variety of FPGA vendors have been mentioned including Altera, Xilinx, Actel and last but not least, Lattice Semiconductor.

This interest, from outside of the original intended design group, warrants attempting to develop a universal LQ043T3DX02 display module driver board. Hence, the new design goal is to develop a LQ043T3DX02 driver board that can be used in a variety of different ways.

Part 6 of the series therefore will concentrate on laying the foundations for developing a universal driver board. It will do this by firstly, listing the specifications for a universal driver board. Then, secondly, the systems requirements will be extracted by examining the specifications previously realised.

The final stage in this part of the series will turn the system requirements into realistic and achievable design aims. Thus, the system requirements that should be derived at the end of this design phase could be considered as the design goals of developing a universal LQ043T3DX02 display board.

1.6.2 Customer Requirements

Although this project can be regarded as a relatively small one, we should follow established system design techniques. By adhering to solid system analysis principles, from the very beginning of the project, we will hold ourselves in good stead for when things don't quite work out as we expect them to.

It is when things are going wrong that we will be required to dig deep into our reservoir of knowledge to find solutions to the problems, that crop up, with our design. Inevitably, this will occur from time to time. It is at this stage of the design that the design engineer who has approached the design methodically and who has performed some form of system analysis on the design upfront usually comes to the fore.

One technique that could be used, as the starting point of the system design process, is to try and view things from the user or potential customer’s point of view. Try and avoid seeing things solely from the design engineer’s view point. So to kick the whole design process off we shall look at the design from a potential user’s perspective. Let’s assume the role of a client looking to commission an engineer to design a universal driver board. The client's specification for a LQ043T3DX02 display driver board could look like those listed below. Client Specification

I require a driver board to drive the LQ043T3DX02 LCD display module used in the Sony PSP. The display's driver board could be designed to the following specification although any alternative suggestions could be considered:

FPGA: An FPGA should be used as the graphics chip on the driverb board.

Configuration: A user with no prior knowledge of FPGAs should be capable of updating the FPGA with the latest graphics algorithms.

Micro-Controller: The FPGA should provide an interface to a micro-controller of a yet to be determined type.

LQ043T3DX02 Display: The FPGA should provide all of the display synchronisation signals as well as the RGB data signals used to drive the display.

SDR SDRAM: Single data rate SDRAM should be used as graphics memory on the driver board.

Touch Screen: (Optionally) The driver board should be capable of communicating with a touch screen attached to the display.

Please find attached an upper level design diagram.


Figure 1:6-1: An upper level diagram of the clients specifications. It looks a bit sparse but we should be grateful for even this little piece of information. A lot of the time the client only has a concept without knowing anything about the underlying technology. Client Specification Analysis

Given the project requirements or "client’s specification'' the next thing to do is to analyse the requirements in an attempt to understand the client’s intentions. This not only provides us with an appreciation of the end goals of the project, but at the same time it allows a degree of difficulty to be associated with each of the client's listed specifications.

Once an analysis of the client’s specification has been performed we can take our first stab at providing a solution to the problem of designing a universal LQ043T3DX03 display driver board. We could do this by acquiring the projects systems requirements. Hence, the client’s specification analysis stage of the design process described next will be followed by the system requirement stage.

Let’s look at the client’s specification again and go through them one by one:


1. FPGA: An FPGA should be used as the graphics chip on the driver board.  

This requirement seems fairly straight forward and those of us familiar with FPGAs will initial look at selecting a device from our favourite range of FPGAs, from our choice vendor. However, it should be remembered that there are four major FPGA vendors namely Actel, Altera, Lattice Semiconductor and Xilinx. Each of these vendors manufactures FPGAs that could be readily selected for use on this project.

Nevertheless, there are slight subtleties from FPGA vendor to FPGA vendor, for example, the number of available I/O pins in a relatively small packaged FPGA.  Small differences like this could prove to be decisive when choosing the appropriate FPGA device to use, especially at the prototyping phase of a project.

Why? Well, it is sometimes possible to quickly prototype a design, to prove the point, using a small quad flat pack (QFP) FPGA. This is sometimes preferably to going all out and choosing a BGA device with all of the advantages and headaches that they have to offer. The time and expense saved choosing the smaller device could prove to be absolutely critical when experimentally debugging the design or when there is a need to quickly show the client a prototype. Thinking small on this occasion might not be such a bad idea!

Hence, although we could already have our favourite vendor's FPGA in mind careful thought should be applied to the choice of FPGA, that should be chosen for this project, especially when the next client requirement is taken into consideration.

2. Configuration: A user with no prior knowledge of FPGAs should be capable of updating the FPGA with the latest graphics algorithms.    

The killer requirement! This could prove to be the toughest requirement to meet. Engineers that are familiar with FPGAs can easily narrate the ease with which an FPGA can be configured using a JTAG programming solution. Equally, every engineer can talk about the alternative proprietary and non-standard FPGA configuration techniques which can differ from FPGA to FPGA and from vendor to vendor. 

Configuring an FPGA via JTAG would not appear to be the solution on this occasion. It is doubtful whether a user, that is not familiar with FPGAs, would want to know (about) how to configure an FPGA using JTAG.  Also, the user may not want to bear the burden, or the extra expense, of purchasing a JTAG programming pod or download cable. If we add to this the potential steep learning curve, in knowing how to use the FPGA vendor’s proprietary configuration software, it seems to be a very unattractive option indeed.

Hence, an FPGA that could work very well on this occasion could be one that retains its configuration data. That is, an FPGA that once it is programmed stores its configuration data internally within the FPGA. Alternatively, an FPGA with the ability to reconfigure itself with the same configuration data each time it is powered on, without intervention from the user could be used. If we are able to find an FPGA that fulfils this requirement then we are only left to answer the question of how the user will reconfigure the FPGA with updates.

Well, since most FPGAs can be reconfigured via a custom serial or parallel programming port, as well as the JTAG port, one technique that could be used to fulfil this particular client requirement could be to provide a means of configuring the FPGA via the client's micro-controller. Alternatively, some other means could be used to configure the FPGA using its proprietary configuration port connected to a PC. Whichever method is used once the FPGA has access to its configuration data it should be seamless to configure the FGPA at power-on without user interaction.

3. Micro-Controller:  The FPGA should provide an interface to a micro-controller of a yet to be determined type.

This is quite a hard requirement to fulfil without knowing the type of micro-controller that will be used. We could anticipate using an address, data and control architecture interfaced to the micro-controller's expansion port. However, in general micro-controllers tend to have proprietary expansion ports and attempting to accommodate all of the variations would be tedious at best and impossible in the worst instance.

Couple this with the fact that some micro-controllers do not even have an expansion port, then the idea of using the expansion port of a micro-controller, to interface to the FPGA, would limit the ”universal” design to only a few select micro-controllers.

However, there are some medium to high-frequency serial interfaces that are common to most micro-controllers, including SPI and I2C, that could be used to provide a control and data interface between the micro-controller and the FPGA used as a graphics chip.

With today's SPI interfaces capable of achieving frequencies of up to 75MHz and more, it is worth investigating whether this interface could be used as the graphics interface between the FPGA containing the graphics algorithms and the user’s micro-controller that wishes to display graphics on the display.

4.  LQ043T3DX02:  The FPGA should provide all of the display synchronisation signals as well as the RGB data signals used to drive the display.

This part of the design has already been undertaken successfully in the previous parts of the series. Apart from considering an alternative backlight circuit that incorporates a Pulse Width Modulated (PWM) dimming control interface, the rest of the design should remain relatively the same.

5. SDR SDRAM:  Single data rate SDRAM should be used as graphics memory on the driver board.

SDR SDRAM is available in abundance and should be readily available for use on this project. Whether we choose a chip that has a data bus that is 8, 16 or 32-bits wide depends on the complexity of the graphics algorithms implemented in the FPGA and the minimum rate at which data should be retrieved from the memory device.

However, if we intend to develop a quick prototype to demonstrate the idea then the less complexity involved in routing the data signals between the memory device and the FPGA, the higher the probability of successfully laying out and routing the design will be.

Bearing the previous point in mind and anticipating the use of a low pin count FPGA, to prototype the design, would suggest that focus should be placed on using SDR SDRAM with an 8-bit interface.

6. Touch Screen: The driver board should be capable of communicating with a touch screen attached to the display.

The touch screen design has also been completed in the previous parts of the design and although untested there is no reason to suggest that it could not be used in its entirety here. Hence, it would appear that the minimum amount of effort should be required in implementing this part of the design.


1.6.3 System Requirements

Armed with all of this knowledge we are now in a position to move onto the system design phase of the project. System Requirements Analysis

One useful way of compiling a list of system requirements is to derive a system design interface diagram from the client’s specifications, as shown in Figure 2. This diagram allows us to breakdown the specification into manageable chunks that could be treated individually, in the first instance at least.


Figure 1:6-2:  A diagram showing the component interfaces that could be used in a design could help to define the I/O requirements of the FPGA. Hence, it could be used to approximately determine the size of FPGA, in terms of packaging, that could be used. 

As expected the main hub of the design is the FPGA.  The figure above immediately exemplifies why FPGAs, with their luxurious number of I/O pins, are favoured for use in this type of design. An estimation of each of the number of I/O pins required is shown in brackets next to each interface in the figure and listed in the table below for convenience.


Table 1:6-1. A table of the approximate number of /O pin required for each proposed interface.



From the estimate of the number of I/O pins it should be possible to prototype the design using a “small” packaged FPGA. A study of each of these interfaces would suggest the following.

  1. We could propose that the FPGA chosen should have a proprietary serial port that can be used to configure the FPGA using a PC or micro-controller.
  2. We could also propose, in the first instance, that 8-bit SDR SDRAM should be used as the external graphics memory. This should allow us to prove the design principle and reduce the number of I/O pins required to interface the SDR SDRAM to the FPGA to the barest minimum. This will allow us to achieve our short term goal of using a small packaged FPGA. If we decide to use SDR SDRAM with a 16-bit or 32-bit data interface later on it could require using a larger packaged FPGA, which would require a PCB redesign. However, a redesign, at a later date, could be considered to be less severe and technically challenging than experimentally designing the universal driver board other than with an 8-bit interface to begin with.
  3. If we propose to the client that the driver board should interface to a 4-wire resistive touch screen, then we could use the touch screen circuit that has already been designed in an early part of the series. As this interface communicates with the FPGA using the SPI protocol the I/O requirements of this interface is minimal. This again reduces the overall number of I/O pins required of the FPGA used in the design.
  4. The interface to the display itself can be considered as two separate sub-interfaces. The first sub-interface provides the control of the backlight circuitry and the other to the data and timing signal interface of the display. A modified backlight circuit is likely to require a single I/O pin for the Pulse Width Modulation (PWM) control to dim the display's backlight.
  5. The synchronisation and data interface of the design should be identical to the one that has been designed previously and baring any modifications should require about 28(?) I/O pins.
  6. As commented in the previous section, without prior knowledge of the type of micro-controller required the best that we can do is to propose a standard interface found on most micro-controllers. As the SPI interface is already been used to interface to the touch screen controller and the flash ROM, see Part 5, it seems reasonable to propose that this interface should be used to interface the FPGA to the micro-controller too. Using the SPI standard could be quite advantageous as it would not require us to write a new batch of FPGA code!
  7. In a real-world situation if the client likes the idea then we are in business. However, if he doesn't then we might need to seriously re-think our low pin count FGPA solution as a high pin count parallel interface could be desired by the “client”'. For the purposes of this exercise we shall use an SPI interface. System Requirements Specification

We are now in a position to compose the systems requirements specification of the project. This should be presented to the “client” as our proposed solution along with a presentation of our analysis of the client’s requirement specification. Hopefully, the “client” will be impressed enough to commission us to do the work!

As commented upon previously, the system requirements specification will define the blueprint of the project, once they have been agreed with the client. Never work without one! The proposed system requirements for this project have been tabulated below in Table 1:6-2.

Table 1:6-2. RequirementsSpecification




Figure 1:6-3 : A diagrammatic version of the systems requirement specification can be seen in this figure. Although the information in Table 1 provides us with enough information to work with providing a diagrammatic version of the system requirements specification is always helpful when explaining the design to non-technical engineers or business accountants. 


1.6.4 Conclusion

In this part of the series a systematic approach to defining the systems requirements has been taken. This has been done by firstly providing a description of the project from a user’s point of view. By attempting to understand the design from the users view point, the system requirements and hence the solution to designing a universal LQ043T3DX02 display driver board has been proposed. In part 7 of the series the system requirements will be used to perform the component selection and analysis phase of the design, as performed previously. The design specifications of the Universal LQ043T3DX02 display driver board will be derived from this process.

Go to comments start