Author Topic: Driving an LVDS LCD  (Read 12374 times)

0 Members and 1 Guest are viewing this topic.

Online MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Driving an LVDS LCD
« on: April 02, 2021, 01:49:47 am »
I'm trying to make this LCD module do something and the datasheet is a bit confusing ... to me.
First time I look at LVDS LCD and I don't understand how the sync works and why the pixel clock is shifted relative to the LVDS data. Is there any documentation I can read? Is there a verilog code example I can play with?

Miti
Fear does not stop death, it stops life.
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: Driving an LVDS LCD
« Reply #1 on: April 02, 2021, 02:14:31 am »
What FPGA are you using? For Xilinx 7 series check out xapp585 application note.

Online MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Driving an LVDS LCD
« Reply #2 on: April 02, 2021, 02:19:21 am »
I have two dev boards with Altera Cyclone II and Cyclone IV.
Fear does not stop death, it stops life.
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: Driving an LVDS LCD
« Reply #3 on: April 02, 2021, 02:38:17 am »
I have two dev boards with Altera Cyclone II and Cyclone IV.
Then maybe some of our resident Altera lovers would pitch in on specifics of IO part.

But basically the "clock" is not really a clock, as it's used for framing (so that receiver can find boundaries of a single transmission). If you look closely, not only it's shifted, but it's also non-symmetrical length-wise (it's high for 4 bit periods, but low for only 3), so that if you sample that clock every bit period, you will get a sequence 1100011. So when receiver tries to lock onto the data stream, it basically bitslips the reception by 1 bit time until it can see that sequence on a clock line - and that's how it knows that it's now properly aligned to the boundaries and so it can start processing data from the data lines knowing they are framed properly. Check the diagram in attachment - I think it shows it more clearly.

The easiest way to implement it is by using 7:1 SERDES modules - one for a "clock" line (which transmits a fixed pattern of 1100011 or 1100001 depending on a panel), and then one more SERDES module for each of data lines. I don't know if Altera supports such mode, so this part you will have to find out yourself, or wait to see if anyone familiar with Altera devices would pitch in.

Also you might want to brush up on your Google-fu. This standard is quite popular even nowadays, so I'm fairly certain you will be able to find some info on this subject on the Internet.
« Last Edit: April 02, 2021, 02:59:53 am by asmi »
 
The following users thanked this post: Miti

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Driving an LVDS LCD
« Reply #4 on: April 02, 2021, 03:15:50 am »
I'm trying to make this LCD module do something and the datasheet is a bit confusing ... to me.
First time I look at LVDS LCD and I don't understand how the sync works and why the pixel clock is shifted relative to the LVDS data. Is there any documentation I can read? Is there a verilog code example I can play with?

Miti
I do not like that datasheet's illustration.  So, take a look at page 13 at the bottom.  See that they 'Recommended transmitter: DS90C383 (Texas Instruments) or equivalent'.  I would first go to TI's DS90C383 data sheet and see how they output their data.

For Altera, you will end up using the 'altlvds_tx' function set the 4 channels and the appropriate number of bits/channel.
TI illustrations are dead simple and properly explained.  You would have to set the altlvds_tx to 7 bits.  The CLK out channel will be a fixed 7'b1100011' number while you video and embedded sync will be on the other 3 channels.  (Note that channel TD isn't used as your chosen panel is only 18bit color.)

Modelsim will have no trouble showing you what your code is outputting when testing.

When assigning the output pins, you will need to set them to LVDS (higher speed, but fewer choice of IOs on FPGA), or, LVDS_E_3R (more flexible choice of almost all IOs on FPGA) outputs.

(holy shit, they scrambled up the bit positions....)

Or, if you can find a dev board with a similar LCD already on it, download their example CD and use their code.

« Last Edit: April 02, 2021, 03:26:29 am by BrianHG »
 
The following users thanked this post: Miti

Online MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Driving an LVDS LCD
« Reply #5 on: April 02, 2021, 12:53:14 pm »
Then maybe some of our resident Altera lovers would pitch in on specifics of IO part.

To be honest, I had a free Altera dev board at work and that's the reason why I started with Altera, I don't have preferences, at my level they all do the job  ;D. Moreover, I installed two versions of Quartus, one for Cyclone II and one for Cyclone IV without any issue. Couple of months ago I tried to install Xilinx ISE 14.7 Win7 in my laptop and, after install, it would't start no matter what. I tried multi file and single file installer with no luck.

But basically the "clock" is not really a clock, as it's used for framing (so that receiver can find boundaries of a single transmission). If you look closely, not only it's shifted, but it's also non-symmetrical length-wise (it's high for 4 bit periods, but low for only 3), so that if you sample that clock every bit period, you will get a sequence 1100011. So when receiver tries to lock onto the data stream, it basically bitslips the reception by 1 bit time until it can see that sequence on a clock line - and that's how it knows that it's now properly aligned to the boundaries and so it can start processing data from the data lines knowing they are framed properly. Check the diagram in attachment - I think it shows it more clearly.

The easiest way to implement it is by using 7:1 SERDES modules - one for a "clock" line (which transmits a fixed pattern of 1100011 or 1100001 depending on a panel), and then one more SERDES module for each of data lines.

Now that's good info, thanks! I got confused because it is shown as pixel clock in some datasheets. I saw that it is asymmetrical and my thought that it is used for strobe, in a weird way that I couldn't understand.
Fear does not stop death, it stops life.
 

Online MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Driving an LVDS LCD
« Reply #6 on: April 02, 2021, 01:20:45 pm »
I do not like that datasheet's illustration.  So, take a look at page 13 at the bottom.  See that they 'Recommended transmitter: DS90C383 (Texas Instruments) or equivalent'.  I would first go to TI's DS90C383 data sheet and see how they output their data.

Yes, me neither and I saw that datasheet. What's missing in the LCD datasheet, compared to Ti datasheet, are the HSync and VSync, they show two dashes instead. Does it mean they use DE for sync or how does the receiver know which is pixel 0,0?

For Altera, you will end up using the 'altlvds_tx' function set the 4 channels and the appropriate number of bits/channel.
TI illustrations are dead simple and properly explained.  You would have to set the altlvds_tx to 7 bits.  The CLK out channel will be a fixed 7'b1100011' number while you video and embedded sync will be on the other 3 channels.  (Note that channel TD isn't used as your chosen panel is only 18bit color.)
.....

When assigning the output pins, you will need to set them to LVDS (higher speed, but fewer choice of IOs on FPGA), or, LVDS_E_3R (more flexible choice of almost all IOs on FPGA) outputs.

Yeap, I did look at that megafunction and this info clears up some question marks. I may have some more questions later on.

Modelsim will have no trouble showing you what your code is outputting when testing.

I have yet to learn how to Modelsim  :palm:

Or, if you can find a dev board with a similar LCD already on it, download their example CD and use their code.

I searched hard on Terasic's site and couldn't find one. I'll try again later, after I change the tires.  :scared:
Fear does not stop death, it stops life.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14309
  • Country: fr
Re: Driving an LVDS LCD
« Reply #7 on: April 02, 2021, 02:32:50 pm »
It's standard LVDS interface for LCDs. Yeah, I know it looks a bit confusing when you're first exposed to it. But it's standard really.
You need a 7:1 serializer, and the "clock" signal needs to be generated in the same way data is - through a serializer! The LCD controller will reconstruct the pixel clock from the CLK signal, which serves both as a frame sync for pixel data and as a reference clock for reconstructing the pixel clock.

asmi pointed you to an app note that should help you understand.
For Lattice devices, there's even an IP available for LVDS 7:1. You can check out the document " MachXO2, MachXO3 and ECP5 7:1 LVDS Video Interface".
« Last Edit: April 02, 2021, 02:34:39 pm by SiliconWizard »
 
The following users thanked this post: Miti

Online langwadt

  • Super Contributor
  • ***
  • Posts: 4393
  • Country: dk
Re: Driving an LVDS LCD
« Reply #8 on: April 02, 2021, 03:06:03 pm »
It's standard LVDS interface for LCDs. Yeah, I know it looks a bit confusing when you're first exposed to it. But it's standard really.
You need a 7:1 serializer, and the "clock" signal needs to be generated in the same way data is - through a serializer! The LCD controller will reconstruct the pixel clock from the CLK signal, which serves both as a frame sync for pixel data and as a reference clock for reconstructing the pixel clock.

asmi pointed you to an app note that should help you understand.
For Lattice devices, there's even an IP available for LVDS 7:1. You can check out the document " MachXO2, MachXO3 and ECP5 7:1 LVDS Video Interface".

and with ~32MHz * 7 = ~225Mbit rate it might just be slow enough that using the serializer isn't required


 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: Driving an LVDS LCD
« Reply #9 on: April 02, 2021, 03:42:02 pm »
Couple of months ago I tried to install Xilinx ISE 14.7 Win7 in my laptop and, after install, it would't start no matter what. I tried multi file and single file installer with no luck.
ISE is not updated for many years now and is only required if you want to use older devices (before 7 series). For 7 series and above you can/need to use Vivado/Vitis.

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14309
  • Country: fr
Re: Driving an LVDS LCD
« Reply #10 on: April 02, 2021, 04:16:37 pm »
Couple of months ago I tried to install Xilinx ISE 14.7 Win7 in my laptop and, after install, it would't start no matter what. I tried multi file and single file installer with no luck.

I have been using ISE 14.7 on Win 7 without any problem for years. Still using it for supporting Spartan-6 designs.
Since the supported devices are still sold by Xilinx, ISE is definitely still "supported". It just won't get any update. You might want to try contacting Xilinx for help.
Note that I've never installed ISE on a 32-bit Windows, so if your Win 7 is 32-bit, I have no experience with that. But on Win 7/64 - no issues.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14309
  • Country: fr
Re: Driving an LVDS LCD
« Reply #11 on: April 02, 2021, 04:42:39 pm »
It's standard LVDS interface for LCDs. Yeah, I know it looks a bit confusing when you're first exposed to it. But it's standard really.
You need a 7:1 serializer, and the "clock" signal needs to be generated in the same way data is - through a serializer! The LCD controller will reconstruct the pixel clock from the CLK signal, which serves both as a frame sync for pixel data and as a reference clock for reconstructing the pixel clock.

asmi pointed you to an app note that should help you understand.
For Lattice devices, there's even an IP available for LVDS 7:1. You can check out the document " MachXO2, MachXO3 and ECP5 7:1 LVDS Video Interface".

and with ~32MHz * 7 = ~225Mbit rate it might just be slow enough that using the serializer isn't required

To serialize data, you need a serializer. ;)
What you mean is that you don't necessarily need dedicated SERDES blocks for this, so the serializer can be implemented in HDL and use common FPGA logic.
Note that 225Mbits/s is not very fast, but may still require defining proper timing constraints for IOs, and/or directly instantiate IOBs for reliable operation. The period is a mere 4.4ns...
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 4393
  • Country: dk
Re: Driving an LVDS LCD
« Reply #12 on: April 02, 2021, 05:48:14 pm »
It's standard LVDS interface for LCDs. Yeah, I know it looks a bit confusing when you're first exposed to it. But it's standard really.
You need a 7:1 serializer, and the "clock" signal needs to be generated in the same way data is - through a serializer! The LCD controller will reconstruct the pixel clock from the CLK signal, which serves both as a frame sync for pixel data and as a reference clock for reconstructing the pixel clock.

asmi pointed you to an app note that should help you understand.
For Lattice devices, there's even an IP available for LVDS 7:1. You can check out the document " MachXO2, MachXO3 and ECP5 7:1 LVDS Video Interface".

and with ~32MHz * 7 = ~225Mbit rate it might just be slow enough that using the serializer isn't required

To serialize data, you need a serializer. ;)
What you mean is that you don't necessarily need dedicated SERDES blocks for this, so the serializer can be implemented in HDL and use common FPGA logic.
Note that 225Mbits/s is not very fast, but may still require defining proper timing constraints for IOs, and/or directly instantiate IOBs for reliable operation. The period is a mere 4.4ns...

yes, "the serializer" as in the SERDES block ;)

using IOB FFs should keep everything aligned

 
The following users thanked this post: Miti

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Driving an LVDS LCD
« Reply #13 on: April 02, 2021, 06:45:27 pm »
Modelsim will have no trouble showing you what your code is outputting when testing.
I have yet to learn how to Modelsim  :palm:

VHDLwhiz.com does a LOT of tutorials around Modelsim.  As you might expect, it has a VHDL slant but the information is still valid.
 
The following users thanked this post: Miti

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Driving an LVDS LCD
« Reply #14 on: April 03, 2021, 12:05:34 am »

Modelsim will have no trouble showing you what your code is outputting when testing.

I have yet to learn how to Modelsim  :palm:

It is it's own compiler.  Unlike Quartus, it will only output a logic analyzer waveforms.  It compiles code in a second.  And your 'test-bench' file in Verilog or SystemVerilog is the top hierarchy which is nothing more than another verilog program to drive your design's inputs.

You also can freeze you simulation and inspect any of your logic/variables anywhere in your code as well as add those regs to your simulation waveform.

Yes, Quartus can setup and run Modelsim from your Quartus project, but to get those sweet 1 second re-compile and simulate, you should learn how to run Modelsim all on it's own.  Then transfer your design .v to Quartus.

Here is a step above beginner project I wrote which exclusively runs all in ModelSim or ActiveHDL, or with a patch from asmi, also runs in Vivado Simulator:
https://www.eevblog.com/forum/fpga/systemverilog-example-testbench-which-saves-a-bmp-picture-and-executes-a-script/msg3436876/#msg3436876

The .do script files will show you, (equivilant to a .bat for dos files) how I setup ModelSim and what it will run.

All instructions are there as it is one of my tutorial projects, though, it is written in SystemVerilog, not Verilog.  The 2 are close enough for you to understand.
 
The following users thanked this post: Miti

Online MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Driving an LVDS LCD
« Reply #15 on: April 03, 2021, 09:49:33 pm »
It's standard LVDS interface for LCDs. Yeah, I know it looks a bit confusing when you're first exposed to it. But it's standard really.
You need a 7:1 serializer, and the "clock" signal needs to be generated in the same way data is - through a serializer! The LCD controller will reconstruct the pixel clock from the CLK signal, which serves both as a frame sync for pixel data and as a reference clock for reconstructing the pixel clock.

That part I understand. The data is reconstructed, but how does it know which one is pixel 0,0? If you look at the datasheet that I attached here, there's a DE, a VS and a HS. My LCD does not seem to need HS and VS. I can only assume that DE timing is used for synchronisation. Long low level resets both, the horizontal and the vertical counter, and a short low level resets only the horizontal counter.
Fear does not stop death, it stops life.
 

Online MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Driving an LVDS LCD
« Reply #16 on: April 03, 2021, 10:06:50 pm »
Couple of months ago I tried to install Xilinx ISE 14.7 Win7 in my laptop and, after install, it would't start no matter what. I tried multi file and single file installer with no luck.
ISE is not updated for many years now and is only required if you want to use older devices (before 7 series). For 7 series and above you can/need to use Vivado/Vitis.

I have been using ISE 14.7 on Win 7 without any problem for years. Still using it for supporting Spartan-6 designs.
Since the supported devices are still sold by Xilinx, ISE is definitely still "supported". It just won't get any update. You might want to try contacting Xilinx for help.
Note that I've never installed ISE on a 32-bit Windows, so if your Win 7 is 32-bit, I have no experience with that. But on Win 7/64 - no issues.

I just wanted to get the feeling of it and, after looking at some dev boards on Ali, series 7 is more expensive than series 6. For learning, Spartan 6 would do it.
I tried to install it on my work laptop and some people recommend disabling the security software but I can't do that on this laptop. I will try on my home PC one day.
Fear does not stop death, it stops life.
 

Offline DC1MC

  • Super Contributor
  • ***
  • Posts: 1882
  • Country: de
Re: Driving an LVDS LCD
« Reply #17 on: April 04, 2021, 08:39:11 am »
...
I just wanted to get the feeling of it and, after looking at some dev boards on Ali, series 7 is more expensive than series 6. For learning, Spartan 6 would do it.
I tried to install it on my work laptop and some people recommend disabling the security software but I can't do that on this laptop. I will try on my home PC one day.

It only needs administrative privileges for the JTAG adapter device drivers, just for installation you could convince it to lay its eggs  ;) in a directory where you have access rights. As long as you're in the learning phase and don't talk with the hw, there is no need of JTAG adapter.

 Cheers,
 DC1MC
 
The following users thanked this post: Miti

Offline Scrts

  • Frequent Contributor
  • **
  • Posts: 797
  • Country: lt
Re: Driving an LVDS LCD
« Reply #18 on: April 09, 2021, 04:26:46 pm »
I'm trying to make this LCD module do something and the datasheet is a bit confusing ... to me.
First time I look at LVDS LCD and I don't understand how the sync works and why the pixel clock is shifted relative to the LVDS data. Is there any documentation I can read? Is there a verilog code example I can play with?

Miti

I think this is the OpenLDI data format? I remember I had to do something like this a number of years ago and my solution was a simple 7 state machine running at pixel clock outputting the new "data clock", pixel and sync data. Worked well with 800x480 display.
 
The following users thanked this post: Miti

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14309
  • Country: fr
Re: Driving an LVDS LCD
« Reply #19 on: April 09, 2021, 06:21:51 pm »
It's standard LVDS interface for LCDs. Yeah, I know it looks a bit confusing when you're first exposed to it. But it's standard really.
You need a 7:1 serializer, and the "clock" signal needs to be generated in the same way data is - through a serializer! The LCD controller will reconstruct the pixel clock from the CLK signal, which serves both as a frame sync for pixel data and as a reference clock for reconstructing the pixel clock.

That part I understand. The data is reconstructed, but how does it know which one is pixel 0,0? If you look at the datasheet that I attached here, there's a DE, a VS and a HS. My LCD does not seem to need HS and VS. I can only assume that DE timing is used for synchronisation. Long low level resets both, the horizontal and the vertical counter, and a short low level resets only the horizontal counter.

Yep. I have used another LVDS LCD and that was the same. A DE signal serving as both Hsync and Vsync. See pp. 17 to 19.
Then the DE signal is transmitted on the D2+/- pair, along with B2-B5. See p. 15.
 
The following users thanked this post: Miti

Online MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Driving an LVDS LCD
« Reply #20 on: April 10, 2021, 12:23:21 am »
It only needs administrative privileges for the JTAG adapter device drivers, just for installation you could convince it to lay its eggs  ;) in a directory where you have access rights. As long as you're in the learning phase and don't talk with the hw, there is no need of JTAG adapter.


I'm not sure if that is my issue. I have admin privileges, I tried to run the install as admin, there's no complain during the install but it simply doesn't start.
Fear does not stop death, it stops life.
 

Online MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Driving an LVDS LCD
« Reply #21 on: April 10, 2021, 09:11:08 pm »
Ok, so here's my ALTLVDS_TX module and I think I got it right because I see exactly what I expect at the outputs. Now I would need a video controller and a pattern generator. I think I would need the tx_outclock for that, I was thinking that the falling edge would increment the H and V counters, and the rising edge would load the tx_in register. However, if you look at the phase of that clock relative to the first bit on one LVDS output, the rising edge comes after the data needs to be valid. What's the technique here? The phase shift of the tx_outclock relative to tx_out doesn't do it, I can't do negative phase shift.
« Last Edit: April 10, 2021, 09:16:23 pm by Miti »
Fear does not stop death, it stops life.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Driving an LVDS LCD
« Reply #22 on: April 10, 2021, 10:12:33 pm »
Ok, so here's my ALTLVDS_TX module and I think I got it right because I see exactly what I expect at the outputs. Now I would need a video controller and a pattern generator. I think I would need the tx_outclock for that, I was thinking that the falling edge would increment the H and V counters, and the rising edge would load the tx_in register. However, if you look at the phase of that clock relative to the first bit on one LVDS output, the rising edge comes after the data needs to be valid. What's the technique here? The phase shift of the tx_outclock relative to tx_out doesn't do it, I can't do negative phase shift.
I'm having a little difficulty following your logic, or train of thought.

Internally in the FPGA, everything should be at 1x clock, IE, 1 pixel clock, always rising edge, all video generator counter and image processors working at that 1x clock.

You should be outputting the 18bit color data, 3 bit HS,VS,DE, (we are at 21 bits), plus the 7 bit clock pattern (we are at 28 bits) into the altlvds_tx singular 28bit parallel input.  The altlvds_tx should take that data with pixel clock, in internally generate it's own PLL accelerating the 28bit parallel pixel clock speed input to a serial output stream of 4 lanes by 7x clock speed serial output.

You should never have to worry about the when to increments the HS/VS on weird clock phases.

Note that the altlvds can be setup to be clocked on the incoming data with the tx_inclock so you may ignore or disable the tx_outclock.  The tx_outclock is at the same speed as the tx_inclock, just taken after the PLL generated by the altlvds_tx.  If your design is very high FMAX and you need to run a serializer with a >250MHZ parallel input with GHz outputs, using this output as your logic design's system clock, not an output pin, helps improve fabric routing and FMAX limitations.  You are running your parallel input at ~50MHz, so you don't need to use it.

Do not look at the phase difference on the scope.  The tx_outclock was not meant to be outputted, it is used to internally clock the logic input and it will appear as a weird phase compared to the output data as you are looking at the clock for the input gates, not the time from when that clock runs until the serial shift register output the data.

Now, if you have having a pin-pin timing skew on the 4 bit output pins, this is a different problem where there are a few solutions to fix.

Also, remember that the altlvds_tx will shift out the 7 bits from right to left...
« Last Edit: April 10, 2021, 10:34:26 pm by BrianHG »
 

Online MitiTopic starter

  • Super Contributor
  • ***
  • Posts: 1320
  • Country: ca
Re: Driving an LVDS LCD
« Reply #23 on: April 10, 2021, 11:01:31 pm »
I'm having a little difficulty following your logic, or train of thought.

Internally in the FPGA, everything should be at 1x clock, IE, 1 pixel clock, always rising edge, all video generator counter and image processors working at that 1x clock.

You should be outputting the 18bit color data, 3 bit HS,VS,DE, (we are at 21 bits), plus the 7 bit clock pattern (we are at 28 bits) into the altlvds_tx singular 28bit parallel input.  The altlvds_tx should take that data with pixel clock, in internally generate it's own PLL accelerating the 28bit parallel pixel clock speed input to a serial output stream of 4 lanes by 7x clock speed serial output.

You should never have to worry about the when to increments the HS/VS on weird clock phases.

Note that the altlvds can be setup to be clocked on the incoming data with the tx_inclock so you may ignore or disable the tx_outclock.  The tx_outclock is at the same speed as the tx_inclock, just taken after the PLL generated by the altlvds_tx.  If your design is very high FMAX and you need to run a serializer with a >250MHZ parallel input with GHz outputs, using this output as your logic design's system clock, not an output pin, helps improve fabric routing and FMAX limitations.  You are running your parallel input at ~50MHz, so you don't need to use it.

Ok, my thought was that I need to register the tx_in inputs but what I take from your reply is that altlvds is internally registered and a change in the data input in the middle of a frame, does not affect the data output.

Also, remember that the altlvds_tx will shift out the 7 bits from right to left...

Does it?  I set my D2 to "1011000", see the scope shot below. What am I missing?
Fear does not stop death, it stops life.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: Driving an LVDS LCD
« Reply #24 on: April 10, 2021, 11:24:59 pm »

Also, remember that the altlvds_tx will shift out the 7 bits from right to left...

Does it?  I set my D2 to "1011000", see the scope shot below. What am I missing?
Sorry, my mild form of dyslexia kicked in again...
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf