Upload
thanhvnpt
View
222
Download
0
Embed Size (px)
Citation preview
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
8/12/2019 LCD Controller Model Report
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
8/12/2019 LCD Controller Model Report
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
8/12/2019 LCD Controller Model Report
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.
8/12/2019 LCD Controller Model Report
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.
8/12/2019 LCD Controller Model Report
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.
8/12/2019 LCD Controller Model Report
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/12/2019 LCD Controller Model Report
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.
Write lcddat = 0x3, pulse lcde High for 12 clock cycles.
Wait 100 s or longer, which is 5,000 clock cycles at 50 MHz.
Write lcddat = 0x3, pulse lcde High for 12 clock cycles.
Wait 40 s or longer, which is 2,000 clock cycles at 50 MHz.
Write lcddat = 0x2, pulse lcde High for 12 clock cycles.
Wait 40 s or longer, which is 2,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 .
8/12/2019 LCD Controller Model Report
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.
8/12/2019 LCD Controller Model Report
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.
8/12/2019 LCD Controller Model Report
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:
8/12/2019 LCD Controller Model Report
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.
8/12/2019 LCD Controller Model Report
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
t_setup_error diagnostic output.
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
t_hold_error diagnostic output.
10. A setup violation caused by a transition on lcdrw . The bus interface must assert the
t_setup_error diagnostic output.
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
t_hold_error diagnostic output.
8/12/2019 LCD Controller Model Report
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.
8/12/2019 LCD Controller Model Report
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.
8/12/2019 LCD Controller Model Report
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.
8/12/2019 LCD Controller Model Report
17/31
17
FIGURE 6: LCD CONTROL MODEL PROGRESS
8/12/2019 LCD Controller Model Report
18/31
18
REFERENCES
[1] Spartan-3E Starter Kit Board User Guide v1.1, Xilinx, Inc., San Jose, CA, 2008,
pp. 45-54.
8/12/2019 LCD Controller Model Report
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.
8/12/2019 LCD Controller Model Report
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
8/12/2019 LCD Controller Model Report
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
8/12/2019 LCD Controller Model Report
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
8/12/2019 LCD Controller Model Report
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.
8/12/2019 LCD Controller Model Report
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:
8/12/2019 LCD Controller Model Report
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.
8/12/2019 LCD Controller Model Report
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.
8/12/2019 LCD Controller Model Report
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.
0 = do not stop on error (for acceptance tests and debugging)
1 = stop on error (default, for end user operation)
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 .
8/12/2019 LCD Controller Model Report
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
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.
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.
0 = do not stop on error (for acceptance tests and debugging)
8/12/2019 LCD Controller Model Report
29/31
29
1 = stop on error (default, for end user operation)
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
rising edge of inst_valid .
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
following rising edge of inst_valid .
output reg cmd_doo: Set when a Display On/Off command is recognized. Reset on the
following rising edge of inst_valid .
8/12/2019 LCD Controller Model Report
30/31
30
output reg cmd_cds: Set when a Cursor/Display Shift command is recognized. Reset on the
following rising edge of inst_valid .
output reg cmd_fs: Set when a Function Set command is recognized. Reset on the following
rising edge of inst_valid .
output reg cmd_cgra: Set when a Set CG RAM Address command is recognized. Reset on the
following rising edge of inst_valid .
output reg cmd_ddra: Set when a Set DD RAM Address command is recognized. Reset on the
following rising edge of inst_valid .
command_if utility tasks
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.
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.
8/12/2019 LCD Controller Model Report
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.