lcd controller model report

8/12/2019 LCD Controller Model Report

1/31

Verilog Simulation Model and

Virtual LCD Screen

13 December 2010

Sponsor/Advisor:

Dr. Greg Tumbush

University of Colorado at Colorado Springs

Robert Ewing&

Steven Wilson


2/31

2

Table of Contents

ABSTRACT ...................................................................................................................................................... 4

INTRODUCTION ............................................................................................................................................. 5 DESIGN OVERVIEW ....................................................................................................................................... 5

FIGURE 1: LCD CONTROLLER VERIFICATION PROCESS .............................................................................. 6

FIGURE 2: LCD CONTROLLER DESIGN LAYOUT .......................................................................................... 7

VIRTUAL LCD CONTROLLER SPECIFICATIONS ................................................................................................ 7

INITIALIZATION DETECTOR ........................................................................................................................ 8

BUS INTERFACE ......................................................................................................................................... 8

COMMAND INTERFACE ............................................................................................................................. 9

ACCEPTANCE TESTING ................................................................................................................................ 10

Bus Initialization Detector Block level Testbench ................................................................................... 11

Bus Interface Block level Testbench ....................................................................................................... 12

Command Interface Block level Testbench ............................................................................................ 14

Acceptance Testing Results ......................................................................................................................... 15

SUMMARY ................................................................................................................................................... 16

REFERENCES ................................................................................................................................................ 18

APPENDIX A: USERS GUIDE ........................................................................................................................ 19 Overview and Features ........................................................................................................................... 19

Supported Features ................................................................................................................................ 19

Using the LCD Controller Model ............................................................................................................. 20

Using the Simulated LCD Screen ............................................................................................................. 22

APPENDIX B: MAINTAINERS GUIDE............................................................................................................. 24

Running the acceptance tests ................................................................................................................. 24

Acceptance test internals ....................................................................................................................... 24

init_detector_tb .................................................................................................................................. 24

bus_interface_tb ................................................................................................................................. 24

command_tb ....................................................................................................................................... 25

LCD Controller Modules .......................................................................................................................... 26

init_detector ....................................................................................................................................... 26


3/31

3

bus_if ................................................................................................................................................... 27

command_if ........................................................................................................................................ 28

Adding Support for Additional LCD Operations ...................................................................................... 31

Read Busy Flag and Address ............................................................................................................... 31

Read Data from DD RAM .................................................................................................................... 31

CG RAM ............................................................................................................................................... 31


4/31

ABSTRACT

This Verilog Simulation Model and Virtual LCD screen is designed for the instructor and

students of a UCCS engineering course for the rapid-prototyping of digital systems using an

FPGA evaluation board. The board used for the course features a character-based LCD module

with controller. To use the LCD, a student must design and debug an LCD master written in the

Verilog HDL. Although provisional designs can be tested on the board itself, the LCD controller

provides virtually no feedback until after an initialization sequence is completed. Because the

initialization sequence incorporates most of the complexity of the overall interface, it is likely

that a design problem in the controller will preclude receiving any visible feedback from the

LCD controller and thus frustrate debugging efforts.The solution is a Verilog simulation model of the LCD controller, capable of validating

the basic protocol and initialization sequence as well as displaying a graphical representation of

the LCD screen. The model must report timing violations (both basic bus protocol violations as

well as post-instruction delay violations) and incorrect initialization steps. It is expected that

simulation using this model will allow students to identify interface problems whose nature

would not be obvious by observing the actual hardware. The design was implemented and tested

successfully, and is expected to be used at UCCS starting in the Spring 2011 semester.


5/31

5

INTRODUCTION

Verilog is a hardware description language (HDL) that models the behavior of digital

logic hardware in a virtual simulation environment. Virtual debugging is faster, cheaper and

easier than debugging on real hardware. The purpose of the Verilog Simulation Model and

Virtual LCD Screen project is to provide the students of ECE4211/5211 (Rapid Prototyping with

FPGA) feedback from their LCD master design. Without a Verilog simulation model, there was

no way for the user to automatically verify their LCD master in simulation. Manual verification

is time consuming and frustrating for the users.

To provide feedback for the students in ECE4211/5211 a Verilog simulation model of theLCD controller needed to be designed. The layout for this design required three modules: the

initialization detector, the bus interface, and the command interface. The command interface

also communicates with the GUI (Virtual LCD Screen). The features and requirements of the

LCD controller are described in the Spartan-3E Starter Kit Board User Guide [1].

DESIGN OVERVIEW

The design required several tasks that are vital to the development of a Verilog

Simulation Model and Virtual LCD screen for ECE4211/5211. The LCD controller model needs

to detect the initialization sequence and report initialization errors. The LCD controller model

must also check low-level timing requirements of the bus interface and respond to commands. If

an error occurs in the user LCD master design, the error messages will be reported to the

simulator transcript window. In addition, the GUI must reflect the state of the simulated LCD

controller to give the user visual feedback. The entire LCD controller must be written in Verilog

and verified by a Verilog testbench on ModelSim SE. ModelSim SE and Verilog are specified

because they are used for digital design instruction at UCCS. Figure 1, shows the LCD

Controller layout.


6/31

6

FIGURE 1: LCD CONTROLLER VERIFICATION PROCESS

The user will design an LCD master which will determine the behavior of the lcdrw (LCD

Read/Write), lcdrs (LCD Register Select), lcde (LCD Enable) and lcddat (LCD Data) outputs.

Figure 2 shows the LCD controllers design layout from the users outputs to the GUI. The first

block that has any effect on the users outputs is the initialization detector. It will check for the proper initialization sequence from the LCD master outputs, and will report an initialization error

if the sequence is incorrect or the timing delays are incorrect. If a successful sequence has

occurred, the initialization detector module will assert the init_done signal. This will enable the

bus interface to start receiving data from the users design. The bus interface will take the

outputs from the users design and evaluate low-level timing errors. If the users design does not

meet the proper timing constraints then an error will be displayed onto the transcript window. If

the users design meets the proper timing constraints, a data_valid or inst_valid will assert(depending on whether a data or instruction operation was completed), moving the output data

from the users design into the command interface module.


7/31

7

FIGURE 2: LCD CONTROLLER DESIGN LAYOUT

Once at the command interface module, the user output data will be tested for a proper

initial command sequence before sending data to the GUI. The command interface module is

checking for a proper command sequence in the following order: Function Set, Entry Mode Set,

Display On/Off, Clear Display and Return Cursor Home. If the command sequence is not in the

order specified, an error will be displayed to the transcript window. If the users design meets

the proper timing constraints, each data write following the command sequence will send a

character to the proper row and column (depending on the current target RAM address, which ismaintained in an internal register), and the GUI window will display the written character.

VIRTUAL LCD CONTROLLER SPECIFICATIONS


8/31

8

The entire specification for the LCD controller model comes from [1]. The parameters

for the LCD controller model are as follows:

INITIALIZATION DETECTOR

The initialization detector specifications required the initialization detector to use an

internalized clock to count clock cycles for the writes to the hold times. The module was also set

up as a state machine to read the proper lcddat data and clock cycle. The sequence, from [1], is

Wait 15 ms or longer. The 15 ms interval is 750,000 clock cycles at 50 MHz.

Write lcddat = 0x3, pulse lcde High for 12 clock cycles.

Wait 4.1 ms or longer, which is 205,000 clock cycles at 50 MHz.


Wait 100 s or longer, which is 5,000 clock cycles at 50 MHz.





BUS INTERFACE

The bus interface was designed to check all timing constraints specified for the signals

controlled by the users LCD master design (Figure 3). The bus interface module checks the 1

s delay between upper and lower bits. It checks the 40 s delay between the write cycles for

the upper and lower 4 bits of a full command/data cycle. It checks the setup time of 40 ns before

the rising edge of lcde , lcde pulse width of 230 ns and the hold time of 10 ns after the falling

edge of lcde .


9/31

9

FIGURE 3: BUS INTERFACE TIMING

COMMAND INTERFACE

The command interface module is designed to check for a sequence of commands before

sending information to the GUI. The proper sequence is Function Set, Entry Mode Set, DisplayOn/Off, Clear Display and finally Return Cursor Home. This sequence is specified by [1], and is

intended to ensure that the controller is in a known configuration. Such a sequence is necessary

because there is no explicit reset signal or command for the LCD module. After the initial

command sequence, the users LCD master may send characters to the LCD screen by

performing data writes, and may alter some elements of the configuration by performing

command/instruction writes. The supported commands are listed in Table 1.


10/31

10

TABLE 1: LCD CONTROLLER COMMANDS

ACCEPTANCE TESTING

Acceptance testing is required to ensure that the individual modules created for the LCD

Controller model meet the design requirements. Three block-level testbenches were created to

cover the three separate modules: the initialization detector module, the bus interface module and

the command interface module.


11/31

11

FIGURE 4: USERS ENVIROMENT

Initialization Detector Block -level Testbench

The initialization detector testbench generates a variety of sequences on the LCD controller bus.

First, a correct sequence is performed, for which the module must indicate no errors and must

indicate a successful initialization. In addition, the testbench generates errors expected from

faulty user designs. The initialization testbench test errors in all initialization timing delays

when lcde is asserted early. The testbench also tests each cycle for proper writes for lcddat . For

more information on the implementation of this testbench, see the init_detector_tb subsection of

the Acceptance Test Internals section of Appendix B

The following scenarios are tested:


12/31

12

1. Good bus initialization sequence. The detector must assert no error signals and must

assert the init_done signal.

2. Insufficient delay for each of the delays between write cycles. The detector must assert

the init_error signal immediately after the timing violation occurs.

3. Write cycles with good timing, but incorrect data on lcddat . The detector must assert the

init_error signal when the write cycle is finished.

4. A write cycle with insufficient width on the lcde pulse. The detector must assert the

init_error signal when the write cycle is finished.

Bus Interface Block -level Testbench

The bus interface testbench follows a procedure similar to the initialization detector

testbench. A stimulus is driven into the bus interface module from the testbench to conduct a

good bus cycle. Once a good test is completed a number of bad test are generated by the

testbench to check various error conditions. The bus interface testbench checks a setup error, a

hold time error, a pulse width error, a delay error between upper and lower bits, and a delay error

between lower and upper bits. For more information on the implementation of this testbench,

see the bus_interface_tb subsection of the Acceptance Test Internals section in Appendix B

The following scenarios are tested.

1. Correct instruction write cycle. The bus interface must assert no error signals, must

assert the inst_valid signal, and must present the correctly-assembled 8-bit data byte on

the data_out bus.


13/31

13

2. Correct data write cycle. The bus interface must assert no error signals, must assert the

inst_valid signal, and must present the correctly-assembled 8-bit data byte on the

data_out bus.

3. Insufficient lcde width. The bus interface must assert the t_pw_errror diagnostic output.

4. Setup time violation caused by a transition on lcdrs . The bus interface must assert the

t_setup_error diagnostic output.

5. A transition on lcdrs while lcde is high. The bus interface must assert the glitch_error

diagnostic output.

6. A hold time violation caused by a transition on lcdrs . The bus interface must assert the

t_hold_error diagnostic output.

7. A setup violation caused by a transition on lcddat . The bus interface must assert the


8. A transition on lcddat while lcde is high. The bus interface must assert the glitch_error

diagnostic output.9. A hold time violation caused by a transition on lcddat . The bus interface must assert the


10. A setup violation caused by a transition on lcdrw . The bus interface must assert the


11. A transition on lcdrw while lcde is high. The bus interface must assert the glitch_error

output.

12. A hold time violation caused by a transition on lcdrw . The bus interface must assert the



14/31

14

13. Insufficient delay between the two 4-bit writes that compose a full 8-bit write cycle. The

bus interface must assert the t_4bit_error diagnostic output.

14. Insufficient delay between two full 8-bit write cycles. The bus interface must assert the

t_c_error diagnostic output.

Command Interface Block -level Testbench

A stimulus is driven into the command interface module from the testbench to conduct a

good sequence of commands. While the test is running the good command test, the module

should display the proper sequence completed successfully with the proper sub commands

displayed. Once a good test is completed, a number of bad tests are generated by the testbench

to check error conditions. The command interface testbench checks the proper sequence of

commands. It places a number of commands out of order to test the module to show errors in the

transcript window. Each command was moved out of place to check for these errors. In

addition, the command interface testbench check to see if the proper timing sequence of

commands were met. Figure 4, shows an integrated testbench that runs a good cycle through all

of the modules needed to create the LCD Controller, and also tests operation of the GUI. For

more information on the implementation of this testbench, see the command_tb subsection of theAcceptance Test Internals section in Appendix B

The following scenarios are tested:

1. Each supported command issued with good timings. The command interface must

indicate that it recognizes each command by asserting the associated diagnostic output.

2. Each supported command issued with an insufficient delay before the next command.

The command interface must assert the cmd_busy diagnostic output.

3. Function Set commands that differ from the standard value only in dont-care bits. The

command interface must recognize these as correct Function Set commands.


15/31

15

4. Function Set commands that do not set the correct operating mode for the LCD

controller. The command interface must assert the invalid_cmd diagnostic output.

5. Out-of-sequence commands in each position in the four-command startup sequence. The

command interface must assert the init_error diagnostic output.

The system-level testbench uses a known-good synthesizable LCD master that serves as a

reference design in the ECE 4211/5211 course. The reference LCD master connects in the same

manner as a users LCD master, and the test verifies that data is successfully relayed from the

LCD bus to the GUI when all of the modules are operating together.

System -level Testbench

1. A correct sequence of initialization cycles is issued.

2. The initial configuration command sequence is issued.

3. Characters are written to the top row of the screen.

4.

A Set DD RAM Address command is issued to change the current address to the start ofthe bottom row.

5. Characters are written to the bottom row of the screen.

6. This test must run to completion without indicating any errors.

Acceptance Testing Results

During development, multiple design and implementation issues were detected and

debugged using the acceptance tests. The delivered code passes all acceptance tests. Figure 5

shows the result of a good LCD master tested with the simulated LCD Controller model and

displaying the LCD master characters on the GUI.


16/31

16

FIGURE 5: GRAPHICAL USER INTERFACE

SUMMARY In summary, this project has created a LCD controller model for the ECE4211/5211

students to test their LCD masters. The model verifies timing and command cycles. Allcommands needed to display characters on the LCD are supported and it is able to set address to

the next row. The primary purpose of feedback on success or failure is displayed in the

transcript window. A summary of the actual work progress is shown by Figure 6; the solid bars

indicate the original proposed schedule, while the dashed bars show an estimate of actual

progress. The user guide is found in Appendix A and the maintainers guide is found in

Appendix B. All code is annotated to help maintain and understand the simulated LCD

Controller design and Virtual LCD screen.


17/31

17

FIGURE 6: LCD CONTROL MODEL PROGRESS


18/31

18

REFERENCES

[1] Spartan-3E Starter Kit Board User Guide v1.1, Xilinx, Inc., San Jose, CA, 2008,

pp. 45-54.


19/31

19

APPENDIX A: USERS GUIDE

Overview and Features

The LCD Controller Simulator supports verification of LCD masters for the Spartan-3E Starter

Kit using ModelSim. It indicates success of key operations and indicates violations of the

interface/protocol specifications.

Supported Features

Bus initialization sequence

Bus interface timing constraints and protocol

LCD controller commands

o Function Set (0x28; bits 1 and 0 ignored)

o Entry Mode Set (shifting not supported)

o Display On/Off

o Clear Display

o Set DD RAM Address

o Return Cursor Home

o Write Data (to DD RAM only)

GUI (simulated LCD screen)

The simulator is provided in four Verilog modules and two Tcl scripts. All of the Verilog

modules must be compiled into your design library, but only the lcd_control module should

actually be instantiated into your testbench. The Tcl scripts provide the GUI, and are optional.


20/31

20

This allows the LCD controller model to be used in a simulator that does not support Tk, such as

ModelSim Student Edition.

Unsupported Features

Some features present in the actual LCD controller are not supported by the simulation model.These are:

All features that use CG RAM

o Set CG RAM Address

o Write CG RAM

o

Read CG RAM Display of non-ASCII characters (Japanese kana, Greek letters, miscellaneous symbols,

and CG RAM characters)

Display of the cursor

Shifting of the display (S = 1 in the Entry Mode Set command)

Cursor / Display Shift command

Using the

LCD

Controller

Model

The LCD controller model contains all of the essential state of the LCD controller and verifies

the behavior of your LCD master. If incorrect behavior is detected, an error message is printed

to the transcript indicating the simulation time and the nature of the error, and the simulation is

stopped to prevent the accumulation of further errors.

The Verilog files that must be compiled into your library are:

init_detector.v

bus_if.v

command_if.v


21/31

21

lcd_control.v

For example, if you are compiling manually on the command line or are using a .do file to

control compilation of your project, the following line will compile the necessary files:

vl og i ni t _det ect or . v bus_i f . v command_i f . v l cd_cont r ol . v

If you are using a ModelSim project to control compilation, you should add the above files to the

project.

In your top-level testbench, include the LCD controller model by instantiating the lcd_controlmodule. For example:

/ / I ns t ant i at e LCD cont r ol l er

l cd_cont r ol l cdc ( . l cddat ( l cddat ) ,

. l cde( l cde) ,

. l cdr s ( l cdr s ) ,

. l cdr w( l cdr w) ,

. char _out ( char _out ) ,

. r ow_out ( r ow_out ) ,

. col umn_out ( col umn_out ) ,

. char _val i d( char _val i d)

) ;

The LCD bus interface consists of the following ports:

lcde

lcdrs


22/31

22

lcdrw

lcddat [3:0]

If using the GUI, the ports char_out[7:0] , row_out , column_out[3:0] , and char_valid must be

connected to wires of the same names, as shown in the example. If not using the GUI, these

signals may be left unconnected.

For more readable transcript output, suppress ModelSim's generic timing constraint messages by

passing the argument +no_tchk_msg to vsim. This allows the customized error messages from

the LCD controller model to be printed without being interleaved with redundant error messages

generated by ModelSim. This can be done on the command line, in a .do file, or by adding the

option to the "Other Vsim Options" text box in the Others tab of the Start Simulation dialog

(accessible in the vsim window menu via Simulate -> Start Simulation...). This is optional, but

strongly recommended.

Using the GUI

The GUI displays characters written to DD RAM after a correct startup sequence. It is supported

only in editions of ModelSim that allow user access to Tk; some editions of ModelSim, such as

the Student Edition, do not support this.

If using the GUI, the files lcd_gui.tcl and lcd_gui_internal.tcl must be in the directory used

during simulation. The GUI is activated by running the lcd_gui.tcl script after launching vsim,

but before starting simulation. For example:

vsi m - novopt - t 1ns +no_t chk_msg t op


23/31

23

sour ce l cd_gui . t c l

r un - al l

If the simulation is restarted without restarting vsim, it is not required to source lcd_gui.tcl again.

However, characters written during the previous run will remain displayed until the Clear

Display command is issued.


24/31

24

APPENDIX B: MAINTAINERS GUIDE

Running the acceptance tests

All acceptance tests are located in the acceptance_tests subdirectory of the main package, andtheir execution is controlled by Tcl scripts (.do files) which must be run in ModelSim.

Run each of the following scripts using the do command at the ModelSim prompt or by usingthe -do argument to vsim. These are fully automated block-level tests that do not activate theLCD GUI window. Each test must run to completion for the acceptance test to pass. "ERROR"messages are normal during these tests; only a "TEST ERROR" message and/or a simulator stop

prior to completion indicate an acceptance test failure.

init_detector_tb.do bus_if.do command_if.do

As a final check, run gui_check.do. This test should run to completion with no error or warningmessages, and you must visually verify that the strings are displayed by the LCD GUI (unlessrunning on a version of ModelSim that does not provide user scripts with access to Tk). Thefinal display should read:

CAP=0x15 I D=0x20

TYPE = 0x20

Acceptance test internals

init_detector_tb

The lcd_4bit_bad_cycle task is incomplete; it was originally intended to support generating

pseudorandom glitches during the LCD pulse, but the code for this was never written.

bus_interface_tb

This module is driven by a 500 MHz (2ns) clock, so the timing constraints are specified in 2ns

units. The values() task is a shortcut for driving the LCD bus; the order of the arguments is:


25/31

25

lcde , lcdrw , lcddat , lcdrs . Error processing is done in the checkflags() task; the argument is a

code that indicates which error signal should be checked. The codes are:

l ocal par am LCDE_SETUP = 4' b0000;

l ocal par am LCDE_WAI T = 4' b0001;

l ocal par am LCDE_HOLD = 4' b0010;

l ocal par am LCDRS_SETUP = 4' b0011;

l ocal par am LCDRS_WAI T = 4' b0100;

l ocal par am LCDRS_HOLD = 4' b0101;

l ocal par am LCDDAT_SETUP = 4' b0110;

l ocal par am LCDDAT_WAI T = 4' b0111;

l ocal param LCDDAT_HOLD = 4' b1001;

l ocal param LCDRW_SETUP = 4' b1010;

l ocal param LCDRW_WAI T = 4' b1011;

l ocal param LCDRW_HOLD = 4' b1100;

l ocal param UPPER_LOWER = 4' b1101;

l ocal param LOWER_UPPER = 4' b1110;

command_tb

Like bus_interface_tb, this module is driven by a 500 MHz (2ns) clock, and timing constraints

are specified in 2ns units. The values2() task is a shortcut for driving the command_if inputs; the

order of the arguments is: data_valid , inst_valid , data_in.


26/31

26

LCD Controller Modules

init_detector

This module is implemented as a clock-driven state machine with a 500 MHz clock and states for

each of the timing periods that must be detected (15ms delay, width of the first lcde pulse, 4.1ms

delay, width of the second LCD pulse, etc.). The localparams for these delays are specified in

clock cycles (2ns period). It should not be necessary to modify this module when adding support

for additional LCD controller features.

init_detector parameters

STOP_ON_ERROR: Controls whether init_detector issues $stop on an error.

0 = do not stop on error (for acceptance tests and debugging)

1 = stop on error (default, for end user operation)

init_detector diagnostic signals

input test_reset: set to 1 and then 0 to reset the internal state of the module

output init_error: set to 1 if an error was detected. The only way to clear this signal is to use

test_reset .

init_detector utility tasks

error_instruction(): Increments the error counter and, if the STOP_ON_ERROR parameter is set

to 1 (the default), stops the simulation by issuing a $stop. This task should be called whenever

there is a user-visible error.


27/31

27

init_state(): Resets the internal state of the module. An end user should generally not be able to

trigger this; it's meant for power-on initialization and acceptance testing.

bus_if

This module handles the assembly of 4-bit bus transactions into 8-bit command or data

transactions. It is designed as an asynchronous machine; its behavior is driven by events on lcde .

Timing constraints are checked by a specify block, whose notifiers trigger always blocks that

handle the display of the error message and the suppression of valid outputs upon erroneous

input. The char_valid and data_valid outputs are delayed by the hold time to allow suppression

of glitches, since a hold time violation cannot be detected before the relevant edge of lcde .

bus_if parameters

STOP_ON_ERROR: Controls whether bus_if stops issues $stop on an error.



bus_if diagnostic signals

input test_reset: set to 1 and then 0 to reset the internal state of the module

output t_setup_error: Set when a setup time violation is detected relative to the rising edge of

lcde . Reset at the following rising edge of lcde .

output t_hold_error: Set when a hold time violation is detected relative to the falling edge of

lcde . Reset at the following falling edge of lcde .


28/31

28

output t_pw_error: Set when an insufficient pulse width is detected on lcde . Reset on the

following falling edge of lcde .

output t_4bit_error: Set when an insufficient delay is present between the falling edge of lcde for

the first of a pair of 4-bit cycles and the following rising edge of lcde . Reset at the following

falling edge of lcde .

output t_c_error: Set when an insufficient delay is present between the falling edge on lcde for

the second of a pair of 4-bit writes and the following rising edge of lcde . Reset on the following

falling edge of lcde .

output glitch_error: Set when lcddat , lcdrs , or lcdrw changes while lcde is high. Reset on the

following rising edge of lcde .

bus_if utility tasks



command_if

This module contains all of the state relevant to user-visible commands, including the DD RAM,

the current DD RAM address and the busy flag. Like the bus_if module, it does not have a

clock; its behavior is driven by rising edges on the inst_valid and data_valid inputs.

command_if parameters

STOP_ON_ERROR: Controls whether command_if stops issues $stop on an error.



29/31

29


command_if diagnostic signals

input test_reset: Set to 1 and then 0 to reset the internal state of the module.

output busy_cmd: Set when a command is issued while the previous command was still busy.

Reset when a command completes execution.

output wire invalid_cmd: Set when an invalid command is detected. Reset on the following

rising edge of inst_valid .

output wire init_done: Set when the four-command startup sequence is completed. Reset

output reg init_error: Set when an unexpected command is issued in the four-command startup

sequence.

output reg cmd_cd: Set when a Clear Display command is recognized. Reset on the following


output reg cmd_rch: Set when a Return Cursor Home command is recognized. Reset on the

following rising edge of inst_valid .

output reg cmd_ems: Set when an Entry Mode Set command is recognized. Reset on the


output reg cmd_doo: Set when a Display On/Off command is recognized. Reset on the



30/31

30

output reg cmd_cds: Set when a Cursor/Display Shift command is recognized. Reset on the


output reg cmd_fs: Set when a Function Set command is recognized. Reset on the following


output reg cmd_cgra: Set when a Set CG RAM Address command is recognized. Reset on the


output reg cmd_ddra: Set when a Set DD RAM Address command is recognized. Reset on the


command_if utility tasks



clear_cmd_flags(): Shortcut for resetting the command recognition outputs.

clear_ddram(): Fills the DD RAM with 'h20, which is the ASCII space character. Used in both

the Clear Display command and in init_state().

lcd_char(row_in, col_in): Updates a single character on the simulated LCD screen. This task

should be used with caution, since it contains time delays.

lcd_refresh(): Updates all 32 characters on the simulated LCD screen. Because this task calls

lcd_char() 32 times, it will pass 64 time steps, so use it with caution.

process_init_error(): Handles detecting errors in the four-command startup sequence specified in

the Spartan-3E Starter Kit User Guide.


31/31

31

Adding Support for Additional LCD Operations

Read Busy Flag and Address

This would require the bus_if module to be enhanced to keep track of read cycles, would require

lcddat to be change to an inout port, and would require the current address and the busy flag

stored in command_if to be made available to bus_if, e.g. by connecting them through additional

ports.

Read Data from DD RAM

Similar to Read Busy Flag and Address above, but there would also need to be a way to make the

data available to bus_if.

CG RAM

This would require adding the CG RAM itself to command_if, as well as a flag to indicate

whether the next Read Data or Write Data operation will be applied to DD RAM or CG RAM, as

they do not have unique command codes. The target is set by a prior Set DD RAM Address or

Set CG RAM Address command, so these commands would need to set the flag to the

appropriate value. To actually display the characters on the simulated LCD GUI would also

require a major overhaul of both the GUI code and the interface, as the GUI currently works by

receiving ASCII character codes and using Tk's built-in font support. Since users can write

arbitrary data to CG RAM, this would require an architecture closer to that of an actual LCD

screen, with individually addressable pixels and a per-pixel refresh process.

lcd controller model report

Documents