Driving an LVDS LCD

[BrianHG]

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.

Correct.  In the FPGA, everything is expected to be valid by the next rising clock.  The serial output is skewed/delayed due to internal logic and it is partially grater than a frame/clk_in.

[Miti]

So I'll have to use the second PLL to generate the pixel clock. For now I can use the 50MHz that's installed on the dev board, but for an exact 60Hz frame rate, I will need 32.256MHz. There's no oscillator with that frequency at Digikey, or anywhere. The only option that I found to generate the correct frequency is 45.1584MHz.
Do you have any other suggestion?

[BrianHG]

Why not use 27MHz or 54MHz clock?

Total width  = 900, 800 pixels + 100 for sync, front and back porch.  (32/48 pixels for Hsync should be good)
Total height = 500, 480 lines plus 20 lines for sync, front and back porch. (3/6 lines for Vsync should be good)

This gives a dead perfect 60Hz.  Note that the 27/54MHz is good for synchronized 48KHz audio as it is used in MPEG2 video.  Also note that broadcast video is not 60FPS, is it actually exactly 59.95FPS here in North America.

Also, altpll can make a perfect 27MHz from a 50MHz or 48MHz source crystal.

Unless your panel says it must have something like 1024 pixels per line exact always, there shouldn't be a problem with 900 pixels per line.

Ok, if you must have 32.256MHz, buy a 25.088MHz (or multiple/divider there of) oscillator and setup the altpll to multiply by 9 and divide by 7.  But, just try to find stock compared to 27MHz or 54MHz, or 50MHz if you want to use 2 PLLs to first generate the 27MHz from the 50MHz.  Note that with some effort, you can setup the altlvds_tx by using 1 PLL to generate the 27MHz and 189MHz serial clock simultaneously yourself, then feed the 2 clocks to the altlvds_tx module.

[BrianHG]

30MHz gets you really close to the LCD specs with 60HZ exactly if the LCD will take a video frame of 1000x500.

This is close to 1024x525.

Generally, many LCDs like the horizontal to be an even number while the vertical has some greater flexibility.

[BrianHG]

Just so you know, 4.032 crystals are dirt cheap at 45cents with stock at digikey.  Teamed up with a cheap 1$ PLL clock generator IC, you can multiply that by 8 and get the exact 32.256 MHz.

In fact, if you already need an external MCU like a PIC and it has a built in PLL where you can output 2x/4x/8x, such a crystal on the MCU with it's OSC output feeding the FPGA clk input, so long as it is above 5MHZ, you just need to do a multiply by x and you will get your 32.256 MHz exact.

(Yes, as far as I know, a stupid PIC with an internal 8xPLL costs less than an IC with a XTAL input to generate a CLK output other than making your own XTAL oscillator with the FPGA combined with an inductor & 3 IOs to double that 4.032MHz to pass the required minimum 5MHz of the FPGA's PLL.  You can play/test this immediately with a 4MHz crystal if you have one on hand.  I would still recommend using a 74HC86 xor or 74HC4046 to double and buffer the crystal before the FPGA, but, these functions can be emulated on IOs of the FPGA.)

Example, this PIC@1.08$: https://www.digikey.com/en/products/detail/microchip-technology/PIC32MM0016GPL020T-I-SS/6055556

You last cheapest option is this IC@69cents: https://www.digikey.com/en/products/detail/microchip-technology/PL611-01-N12MC-R/7898437  Sadly, your crystal range is between 10 and 30MHz, but, you can setup weird long multiplies/divides.

[BrianHG]

Why haven't you tried 18.432MHz?
Digikey has plenty oscillators in stock there by multiple manufacturers and packages all below $1.50.  (Still, a minuscule fraction compared to 30MHz or 27MHz and 30MHz is cross compatible with my DDR3 ram controller's 300MHz clock using Cyc-IV/V/Max10.  Also, testing with a 50MHz, you can make 30MHz easy.).

18.432MHz X 7 / 4 = 32.256MHz.

https://www.digikey.com/en/products/detail/kyocera-international-inc-electronic-components/KC2016Z18-4320C15XXK/11610008

[Miti]

Why haven't you tried 18.432MHz?
Digikey has plenty oscillators in stock there by multiple manufacturers and packages all below $1.50.  (Still, a minuscule fraction compared to 30MHz or 27MHz and 30MHz is cross compatible with my DDR3 ram controller's 300MHz clock using Cyc-IV/V/Max10.  Also, testing with a 50MHz, you can make 30MHz easy.).

18.432MHz X 7 / 4 = 32.256MHz.

https://www.digikey.com/en/products/detail/kyocera-international-inc-electronic-components/KC2016Z18-4320C15XXK/11610008

Yes, 18.432MHz is a good catch, thanks! I will do my experiments with the 50MHz that is already on board, fed to the second PLL. 50 X 5 / 7 is 35.714MHz, still below the maximum 36MHz. I don't have a real application now, it's just learning.

[Miti]

I see colors... Some issues with my counters logic but in general it works.

Edit:  The entire image is shifted one pixel to the right. I assume it is related to the registering of the ALTLVDS data input.

[SiliconWizard]

Of course I haven't seen your code, but any registering shouldn't matter here. Just make sure the sync signal (DE) is properly generated. Adjusting the pixel shift should be fairly easy if you have made the front and back porch easy to modify.

[BrianHG]

Edit:  The entire image is shifted one pixel to the right. I assume it is related to the registering of the ALTLVDS data input.

Not possible.  The 'DE' is sent with the valid pixel in parallel.

Remember, if you are generating the output color based on the 'DE' or counters which count triggered from the DE, that data may be delayed by a clock compared to the 'DE'.

Are you using the 1024 clocks per line, 525 lines, or a custom frame size?

[Miti]

Of course I haven't seen your code, but any registering shouldn't matter here. Just make sure the sync signal (DE) is properly generated. Adjusting the pixel shift should be fairly easy if you have made the front and back porch easy to modify.

Yes, I figured out that DE was coming when H_Count was at 1, not at 0 and I corrected it, but then the pattern was shifted 2 pixels to the right, which makes sense, it means that data is shifted 2 clocks relative to DE.
My mistake is that I thought I can get away with no back porch, so start displaying from H_Count = 0 up to 799, then pull DE low, but that makes it harder to shift data. I'll have to start the active portion somewhere in the middle, say H_Count = 10 to 899, so I can shift the data few pixels to the left.

Not possible.  The 'DE' is sent with the valid pixel in parallel.
Remember, if you are generating the output color based on the 'DE' or counters which count triggered from the DE, that data may be delayed by a clock compared to the 'DE'.

Are you using the 1024 clocks per line, 525 lines, or a custom frame size?

Both, the H_Counter and DE are generated in one always @ block. The problem is that the X and Y coordinates that I pass to the pattern generators must be delayed, that's why I see the data for pixel 0 displayed on pixel 2.
Yes, I'm using 1024 X 525 frame. As I said, I think I know what I need to do. Move the horizontal active area a bit to the right inside the H_Counter, and shift the X coordinates 2 pixels to the left. I think vertically I can start the active area from 0.

[BrianHG]

Remember, if the panel doesn't need the HS & VS, just the DE, it has no clue about your internal sync counter and all the relative positions & timing.

All it cares is that the DE is high for 800 pixels per line.
You place the picture inside there.

Beginning your frame with your counters at 0x0 to 799x479 is perfectly fine.  (Yes, remember the ending odd numbers,  You do not know how many time I has to establish this with Nockieboy in the 8-bit GPU thread...)

Having the counters wrap around at 1023 and 524 is fine and if you want syncs, just place them after the active picture area.

Remember, if you construct the picture data output from the coordinates of those counters and that picture data takes 1 clock to compute, you need the DE to also take 1 clock to compute.  If the picture takes 2 clocks, then the DE also should take 2 clocks.

IE (additional clock) ->
DE_generated_from_screen_coords <= (x_coord < 800) && (y_coord < 525);
DE_out <= DE_generated_from_screen_coords;

You would make DE directly from my first expression if the picture data also resolves in 1 clock.  If you are looking up a RAM using the screen coords, then you would use both expressions, or even an additional DE delay to accommodate the ram read delay.

As for the syncs, something like this:
HS_generated_from_screen_coords <= (x_coord >= 816) && (x_coord < 848);
VS_generated_from_screen_coords <= (y_coord >= 482) && (y_coord < 485);

And if you want, delay or not the HS/VS outputs to keep a perfect parallel sync timed image pipe.

I left in enough room so you may try wrapping around your H&V coord counter to 0-999 & 0-499 to make a 60Hz display with a 30MHz pixel clock.

[Miti]

BTW, the differential lines must be pulled low or kept tristate until the supply voltage is stable. Cyclone LVDS outputs cannot be pulled low or tristated. Should I pull nCONFIG low until the supply voltage reaches 3V?
In my experiments it doesn’t seem to care but the data sheet says it can get damaged.

[BrianHG]

BTW, the differential lines must be pulled low or kept tristate until the supply voltage is stable. Cyclone LVDS outputs cannot be pulled low or tristated. Should I pull nCONFIG low until the supply voltage reaches 3V?
In my experiments it doesn’t seem to care but the data sheet says it can get damaged.

Are you talking about the display being damaged?

I need to double check on the tristate.  I know it's been added to the MAX10 IO, but I am not sure about the older Cyclones.  If you are using the LVDS_E_3R IO standard, yes, those can be tristated.  I'm just not sure about the authentic 'LVDS'.

You will need to initiate the ALTIOBUFF to get the tristate working with differential.

The 4-outputs of the altlvds_tx will feed the altiobuff which will give you 4 OEs for the P and 4 OEs for the N pins, and outputs 4xP & 4xN.  I know currently, you might have assigned the differential outputs VIA pin assignment, calling the IOBUFF forces it and provides both the P&N outputs which you can name each the way you like.

Yes, holding the nCONFIG low is another method to guarantee dead IOs until you allow the bootprom to load.
However, I think the reset state has the IOs with a weak pullup.  Most likely not strong enough to damage the receiver IC in the display, we are talking 100k-200k to VCCIO.

Essentially, if the display is powered up with the FPGA, you shouldn't have trouble here.  If the display is separately powered, then I recommend you should have a display detect and keep the IOs in tristate when the display is powered down but still connected.  This is typically the same with DVI/HDMI as the transmitter ICs use the display sense pin and shut-down their output when there is no 5v present on the pin.

[Miti]

Check Note2 on page 10.

[BrianHG]

Yes, do not drive output current until the VCC has passed 3v.

Scope your power rails and check when the LVDS outputs begin to drive current compared to when the VCC for the panel passes 3v.

The power-up and boot time for the FPGA might clear the time for you here.

If the above timing is ok, but you designed your panel to be powered down while the FPGA remains on, then you will need to be concerned about this.

My brown-out reset circuit on the nCONFIG would definitely add and beyond clear this time for you, as well as cut the FPGA's IO ahead of a power drop as it senses the drop from the 5v source feeding your 3.3v switcher before the 3.3v even begins to drop.

[SMB784]

Yes, do not drive output current until the VCC has passed 3v.

Scope your power rails and check when the LVDS outputs begin to drive current compared to when the VCC for the panel passes 3v.

The power-up and boot time for the FPGA might clear the time for you here.

If the above timing is ok, but you designed your panel to be powered down while the FPGA remains on, then you will need to be concerned about this.

My brown-out reset circuit on the nCONFIG would definitely add and beyond clear this time for you, as well as cut the FPGA's IO ahead of a power drop as it senses the drop from the 5v source feeding your 3.3v switcher before the 3.3v even begins to drop.

My understanding of the FPGA boot sequence is that when nCONFIG (I think also called CONF_DONE in other units) will only go high once the power rails have reached a stable voltage, e.g. 3.3v

See fig 3b (erroneously labelled as fig 3a in the description) in attached PDF for what I am talking about in a Max10 FPGA

[BrianHG]

Yes, do not drive output current until the VCC has passed 3v.

Scope your power rails and check when the LVDS outputs begin to drive current compared to when the VCC for the panel passes 3v.

The power-up and boot time for the FPGA might clear the time for you here.

If the above timing is ok, but you designed your panel to be powered down while the FPGA remains on, then you will need to be concerned about this.

My brown-out reset circuit on the nCONFIG would definitely add and beyond clear this time for you, as well as cut the FPGA's IO ahead of a power drop as it senses the drop from the 5v source feeding your 3.3v switcher before the 3.3v even begins to drop.

My understanding of the FPGA boot sequence is that when nCONFIG (I think also called CONF_DONE in other units) will only go high once the power rails have reached a stable voltage, e.g. 3.3v

See fig 3b (erroneously labelled as fig 3a in the description) in attached PDF for what I am talking about in a Max10 FPGA

nCONFIG is an input used to completely clear and reboot the FPGA as well as one of the programmer lines.  Tying it low will clear the active configuration memory and when released, the FPGA will reboot from the bootprom or JTAG.

CONF_DONE is an output telling you that the FPGA has finished booting.

Both are on the MAX10 as well as all Altera FPGAs.

My super slow power-on reset and brown-out circuit here: https://www.eevblog.com/forum/fpga/how-to-eliminate-a-reset-input/msg3488338/#msg3488338

Scope shots are also on the page in subsequent and prior posts.

[Miti]

Remember, if the panel doesn't need the HS & VS, just the DE, it has no clue about your internal sync counter and all the relative positions & timing.

All it cares is that the DE is high for 800 pixels per line.
You place the picture inside there.

Beginning your frame with your counters at 0x0 to 799x479 is perfectly fine.  (Yes, remember the ending odd numbers,  You do not know how many time I has to establish this with Nockieboy in the 8-bit GPU thread...)

Having the counters wrap around at 1023 and 524 is fine and if you want syncs, just place them after the active picture area.

Remember, if you construct the picture data output from the coordinates of those counters and that picture data takes 1 clock to compute, you need the DE to also take 1 clock to compute.  If the picture takes 2 clocks, then the DE also should take 2 clocks.

IE (additional clock) ->
DE_generated_from_screen_coords <= (x_coord < 800) && (y_coord < 525);
DE_out <= DE_generated_from_screen_coords;

You would make DE directly from my first expression if the picture data also resolves in 1 clock.  If you are looking up a RAM using the screen coords, then you would use both expressions, or even an additional DE delay to accommodate the ram read delay.

As for the syncs, something like this:
HS_generated_from_screen_coords <= (x_coord >= 816) && (x_coord < 848);
VS_generated_from_screen_coords <= (y_coord >= 482) && (y_coord < 485);

And if you want, delay or not the HS/VS outputs to keep a perfect parallel sync timed image pipe.

I left in enough room so you may try wrapping around your H&V coord counter to 0-999 & 0-499 to make a 60Hz display with a 30MHz pixel clock.

You are right, I was looking at DE vs coordinates, when I should have look at DE vs colour data. All I need to do was to delay DE one clock through a register and I can see all pixels now, from 0 to 799  and from 0 to 479.
Next is to see how tolerant it is to various pixel counts.

Cheers and beers to all who helped!

[Miti]

Just a quick question, how do you add Altera mega functions to Modelsim? I can’t find Altlvds or Altpll in it.

[BrianHG]

Just a quick question, how do you add Altera mega functions to Modelsim? I can’t find Altlvds or Altpll in it.

On the vsim compile line, add:

Code: [Select]

vsim -t 1ps -L altera_ver -L lpm_ver -L sgate_ver -L altera_mf_ver -L altera_lnsim_ver -L cycloneive_ver -L work -voptargs="+acc"  Yout_test_bench_module_name

All the '-L' includes the Altera libraries and the '-L cycloneive_ver' makes sure that the Cyclone IV-E versions of the megafunctions are used.

2 examples:

This code set-s up Modelsim to compile and simulate my DDR3 controller, I call is 'setup_phy.do':

Code: [Select]

transcript on
if {[file exists work]} {
vdel -lib work -all
}
vlib work
vmap work work
vlog -sv -work work {BrianHG_DDR3_GEN_tCK.sv}
vlog -sv -work work {BrianHG_DDR3_PLL.sv}
vlog -sv -work work {BrianHG_DDR3_PLL_tb.sv}
vlog -sv -work work {BrianHG_DDR3_IO_PORT_ALTERA.sv}
vlog -sv -work work {BrianHG_DDR3_PHY_SEQ.sv}
vlog -sv -work work {BrianHG_DDR3_PHY_SEQ_tb.sv}

#Enable this VSIM for all cyclone parts.
vsim -t 1ps -L altera_ver -L lpm_ver -L sgate_ver -L altera_mf_ver -L altera_lnsim_ver -L cycloneive_ver -L work -voptargs="+acc"  BrianHG_DDR3_PHY_SEQ_tb


restart -force -nowave
# This line shows only the variable name instead of the full path and which module it was in
config wave -signalnamewidth 1

#add  wave /BrianHG_DDR3_PHY_SEQ_tb/*  (IF this line was not commented out, every signal in the tb would be added to the waveform)

add wave -divider "Script File"
add wave -ascii       /BrianHG_DDR3_PHY_SEQ_tb/TB_COMMAND_SCRIPT_FILE
add wave -decimal     /BrianHG_DDR3_PHY_SEQ_tb/Script_LINE
add wave -ascii       /BrianHG_DDR3_PHY_SEQ_tb/Script_CMD
add wave -divider     "RST/CLK_in"
add wave -hexadecimal /BrianHG_DDR3_PHY_SEQ_tb/RST_IN
add wave -hexadecimal /BrianHG_DDR3_PHY_SEQ_tb/CLK_IN
add wave -hexadecimal /BrianHG_DDR3_PHY_SEQ_tb/RESET
add wave -hexadecimal /BrianHG_DDR3_PHY_SEQ_tb/PLL_LOCKED
add wave -divider     "DDR3 SEQ CMD Input"
add wave -hexadecimal /BrianHG_DDR3_PHY_SEQ_tb/SEQ_BUSY
add wave -hexadecimal /BrianHG_DDR3_PHY_SEQ_tb/CMD_CLK
add wave -hexadecimal /BrianHG_DDR3_PHY_SEQ_tb/SEQ_CMD_ENA
add wave -hexadecimal /BrianHG_DDR3_PHY_SEQ_tb/SEQ_WRITE_ENA
add wave -hexadecimal /BrianHG_DDR3_PHY_SEQ_tb/SEQ_ADDR
add wave -hexadecimal /BrianHG_DDR3_PHY_SEQ_tb/SEQ_WMASK
add wave -hexadecimal /BrianHG_DDR3_PHY_SEQ_tb/SEQ_WDATA
add wave -hexadecimal /BrianHG_DDR3_PHY_SEQ_tb/SEQ_RDATA_VECT_IN

do run_phy.do

This code is the 'run_phy.do', I only need to run the 'do setup_phy.do' once, then, every time I edit my code, I just 'do run_phy.do' to recompile and restart the simulation:

Code: [Select]

vlog -sv -work work {altera_gpio_lite.sv}
vlog -sv -work work {BrianHG_DDR3_GEN_tCK.sv}
vlog -sv -work work {BrianHG_DDR3_PLL.sv}
vlog -sv -work work {BrianHG_DDR3_PLL_tb.sv}
vlog -sv -work work {BrianHG_DDR3_IO_PORT_ALTERA.sv}
vlog -sv -work work {BrianHG_DDR3_PHY_SEQ.sv}
vlog -sv -work work {BrianHG_DDR3_PHY_SEQ_tb.sv}

restart -force
run -all

wave cursor active
wave refresh
wave zoom range 0ns 5000ns
view signals


Every once-in-awhile some big code change will not quick re-compile where I need to just re-run the 'setup_phy.do'.

Note that the _phy is for simulating the 'PHY' section of my memory controller and I have a few other setup_xxx.do/run_xxx.do files to simulate different sections of my code and show different waveforms.

[Miti]

And just because I can, a bit of picture-in-picture exercise. Unscaled, of course, because video scaling is way out of my league. 

[BrianHG]

And just because I can, a bit of picture-in-picture exercise. Unscaled, of course, because video scaling is way out of my league. 

No, it is not...
You just need to think things through.

Begin with input res and output res & what X&Y factor you wish.

Second hint, for the Y output, you will want access to 2 different/adjacent Y coordinates of video simultaneously, but, begin with a variable X scale all by itself.

[SiliconWizard]

And just because I can, a bit of picture-in-picture exercise. Unscaled, of course, because video scaling is way out of my league. 

So are you working on a display replacement for an old HP spectrum analyzer?

[Miti]

So are you working on a display replacement for an old HP spectrum analyzer?

It's almost done but this is not related, the LVDS was just a learning exercise.
Take a look here for the CRT replacement:
https://www.eevblog.com/forum/projects/hp-8594e-replacing-the-green-crt-with-lcd/

Covid slew down my prototyping to a halt. I just need to figure out the cables and the mounting and I will offer it for sale. Not sure if there's much interest though.
Again, this project was also a combination of learning and making something useful, as I want to replace my SA's CRT.