GDDDS

It's about time I related what I've been up to while I've been working at Sharp. Since the beginning of October last year I've been developing the Generc Digital Display Driver System, or GDDDS if you want a terribly hard to pronounce acronym. I'm not very good at making up names for things.

'But what is it,' I hear you cry. 'What does it do?'

Sharp's much-hyped CG-Silicon technology makes it possible to make much smaller and more consistent components (such as transistors and resistors) on a glass substrate. The System Display Group, who I'm working with this year, use this technology to integrate complex digital and analog cicuitry into LCD display panels.

To generate an image on an LCD display you need to convert the binary code generated by the host device into a voltage applied to the liquid crystal. Traditionally this has been carried out by a small chip bonded to the panel's Flexible Plastic Connector, but one of the SGD's ongoing research project is to put that circuitry on the panel itself. The disadvantage of that is that the stimulus signals to drive the panel change completely, and the requirements for testing are very different as well. Creating a new board with new software to drive every single different panel designed by th SDG is costly and time-consuming.

This is where my project comes in. The project specification was to create a device that could adapt to generate any voltage required for a panel and all of the control signals, as much as possible under software control, so users didn't need to know how to program an FPGA or to design electronic circuits in order to configure it.

So I've spent most of the last year designing and building such a system, from the nitty-gritty of operational amplifiers to negotiations with contractors for layout and fabrication services, and I've learnt so much in the process that it's hard to believe it!

The architecture I came up with consisted of two main PCBs: Antony, the smaller of the two, which has the USB interface, the power socket, a simple user interface for configuration away from a computer, and 256 Mb of storage for image and configuration data; and Octavian, which has the signal and voltage generator hardware and the diagnostics connectors. In addition to designing those PCBs I had to write the Field Programmable Gate Array (FPGA) cores, and the user software for configuring the system.

Unfortunately, one of the truths of software engineering has been true all the way through the project: 'Always expect to throw one away.' I designed most of the schmatics in OrCAD, but design pricing and the fact that OrCAD corrupted my files meant that I had to rework the schematics from scratch using gEDA; and I wrote a complete FPGA core for Octavian, and then realized that I'd made a lot of bad decisions (asynchronous resets, poor partitioning between functionality, dire bus design) and had to rewrite that almost from the ground up. On the other hand, I've learnt an awful lot about electronic engineering in the real world, and I think it'll stand me in good stead in the future.

I'm having just over a week of holiday now while I go on my last OCYO tour (to Poland) and then I'll be in the final straight: getting my system working as specified, and writing the documentation required for people to use and maintain it after I've left the company.