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.
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
Edit: The entire image is shifted one pixel to the right. I assume it is related to the registering of the ALTLVDS data input.
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.
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?
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.
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.
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
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.
Just a quick question, how do you add Altera mega functions to Modelsim? I can’t find Altlvds or Altpll in it.
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
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
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
And just because I can, a bit of picture-in-picture exercise. Unscaled, of course, because video scaling is way out of my league.
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?