cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
457 Views
Registered: ‎12-08-2019

LCD interfacing

Jump to solution

I want to interface lcd with Cmod A7 fpga board. The lcd is BOOSTXL-K350QVG-S1. I have interfaced the lcd using other microcontroller but I don't have any idea how to interface it with this fpga board. I need some reference. I need to complete this as soon as possible.

0 Kudos
1 Solution

Accepted Solutions
Scholar
Scholar
393 Views
Registered: ‎04-26-2015

Re: LCD interfacing

Jump to solution

OK.

 

You've posted this on the Vivado HLS (High Level Synthesis) forum. HLS takes C code and turns it into HDL (hardware design language). This can greatly simplify the design process for complex algorithms, because the tool can automatically decide what happens on each clock cycle - and if you change the design slightly then the tool can easily re-calculate that. However, for interfacing to other hardware it's less than ideal because you don't have control over what happens on each cycle. You can't be sure that (for example, with SPI) the data is actually coming out at the same time as the clock signal. Additionally, the task you're doing is not actually very complex, so the big advantages of HLS largely disappear.

As a result, the first thing you need to do is post this on a non-HLS forum, because HLS is not a very good tool to use for this task. Associated with that, you need to select a HDL to learn (VHDL or Verilog) and start learning it.

 

The LCD interfaces using SPI, which is a simple serial protocol. It consists of four pins:

SCK - clock, provided by the FPGA. For this application, you won't want to run at much more than 10MHz. For initial testing, 100kHz - 1MHz will be fine.

MOSI - data from the FPGA to the LCD

MISO - data from the LCD to the FPGA

nCS - chip select, normally at 3.3V, pulled down to 0V to tell the LCD that you want to talk to it

 

A simple SPI controller is very easy in an FPGA. It essentially consists of a clock divider circuit that slows the FPGA input clock (normally 50 - 100MHz) down to SPI speed, and a shift register. A shift register allows you to load a byte of data into it, and then on each clock cycle it shifts that data along one space. This results in one bit "falling off" the end of the register, and that bit is what you connect to the MOSI output. After eight clock cycles, the entire byte has been transferred and the register is empty. If you need to receive data too, then on each clock cycle you can read data from the MISO pin and put that into the shift register. This way, after eight cycles the shift register holds one received byte, and one byte has been transmitted.

Controlling the LCD will require more work; I expect it has some sort of protocol for determining which pixels are being set, whether the backlight is turned on, etc.

 

BRAM (block RAM) is the main memory resource on an FPGA. There's not normally very much of it - ranging from ~10KB on small chips up to maybe 500KB on mid-range ones (and over 100MB on very, very expensive ones). For a simple display application, you would probably start by storing an image in BRAM and then transferring it to the LCD over SPI. Transferring from block RAM over SPI is easy; you just wait until the SPI shift register is empty and then re-load it from the BRAM output. Then increment the BRAM address register so it's reading from the next location. Getting data into BRAM is harder, primarily because you need to decide what is going in there and how it's going to get there. This could be done by specifying the contents on the PC before building the design, by putting a microcontroller core (MicroBlaze) on the FPGA, having a separate block to generate the contents, etc.

 

It looks like there are three fundamental issues you need to look at:

 

(1) Learning a HDL. This is essential for an FPGA, at least if you want to interface to any external hardware.

(2) Understanding how to talk to the LCD, so you can figure out what commands need to be sent to it.

(3) Deciding what you're going to use to create images.

View solution in original post

3 Replies
Highlighted
Scholar
Scholar
431 Views
Registered: ‎04-26-2015

Re: LCD interfacing

Jump to solution

Not with HLS, that's for sure.

 

The easiest way is probably to just make a simple block that sucks data from block RAM and dresses it up to look like SPI. That'll get you an image displayed. Getting an image into block RAM in the first place is up to you - you need to decide how you're going to generate that image.

0 Kudos
Highlighted
Visitor
Visitor
408 Views
Registered: ‎12-08-2019

Re: LCD interfacing

Jump to solution

I didn't get anything. Can you explain a bit.

0 Kudos
Scholar
Scholar
394 Views
Registered: ‎04-26-2015

Re: LCD interfacing

Jump to solution

OK.

 

You've posted this on the Vivado HLS (High Level Synthesis) forum. HLS takes C code and turns it into HDL (hardware design language). This can greatly simplify the design process for complex algorithms, because the tool can automatically decide what happens on each clock cycle - and if you change the design slightly then the tool can easily re-calculate that. However, for interfacing to other hardware it's less than ideal because you don't have control over what happens on each cycle. You can't be sure that (for example, with SPI) the data is actually coming out at the same time as the clock signal. Additionally, the task you're doing is not actually very complex, so the big advantages of HLS largely disappear.

As a result, the first thing you need to do is post this on a non-HLS forum, because HLS is not a very good tool to use for this task. Associated with that, you need to select a HDL to learn (VHDL or Verilog) and start learning it.

 

The LCD interfaces using SPI, which is a simple serial protocol. It consists of four pins:

SCK - clock, provided by the FPGA. For this application, you won't want to run at much more than 10MHz. For initial testing, 100kHz - 1MHz will be fine.

MOSI - data from the FPGA to the LCD

MISO - data from the LCD to the FPGA

nCS - chip select, normally at 3.3V, pulled down to 0V to tell the LCD that you want to talk to it

 

A simple SPI controller is very easy in an FPGA. It essentially consists of a clock divider circuit that slows the FPGA input clock (normally 50 - 100MHz) down to SPI speed, and a shift register. A shift register allows you to load a byte of data into it, and then on each clock cycle it shifts that data along one space. This results in one bit "falling off" the end of the register, and that bit is what you connect to the MOSI output. After eight clock cycles, the entire byte has been transferred and the register is empty. If you need to receive data too, then on each clock cycle you can read data from the MISO pin and put that into the shift register. This way, after eight cycles the shift register holds one received byte, and one byte has been transmitted.

Controlling the LCD will require more work; I expect it has some sort of protocol for determining which pixels are being set, whether the backlight is turned on, etc.

 

BRAM (block RAM) is the main memory resource on an FPGA. There's not normally very much of it - ranging from ~10KB on small chips up to maybe 500KB on mid-range ones (and over 100MB on very, very expensive ones). For a simple display application, you would probably start by storing an image in BRAM and then transferring it to the LCD over SPI. Transferring from block RAM over SPI is easy; you just wait until the SPI shift register is empty and then re-load it from the BRAM output. Then increment the BRAM address register so it's reading from the next location. Getting data into BRAM is harder, primarily because you need to decide what is going in there and how it's going to get there. This could be done by specifying the contents on the PC before building the design, by putting a microcontroller core (MicroBlaze) on the FPGA, having a separate block to generate the contents, etc.

 

It looks like there are three fundamental issues you need to look at:

 

(1) Learning a HDL. This is essential for an FPGA, at least if you want to interface to any external hardware.

(2) Understanding how to talk to the LCD, so you can figure out what commands need to be sent to it.

(3) Deciding what you're going to use to create images.

View solution in original post