#Lattice lse vs synplify pro 480p
#Lattice lse vs synplify pro generator
#Lattice lse vs synplify pro code

Having 27MHz could be quite good for doing digital audio over HDMI.ДЄs you say reusing flash after the FPGA switches to user mode should be possible to replace the i2c PROM with a custom booter which is doable - we already did this ourselves for MAX10 internal flash use too. The ECP5 PLL settings are not dynamic so the desired resolution needs to be fixed in each bit file.

#Lattice lse vs synplify pro 480p

There are some other options for the PLL output for HDMI clocks which could be 27MHz and 135MHz for 480p or 65MHz and 325MHz for 1024x768 resolutions, or possibly 25MHz and 125MHz for somewhat simpler DVI at 640x480. So far haven't got it quite nailed down and working fully but I hope this clocking should be possible. Output 4 - 30 or 60MHz (I believe this would be needed to allow feedback divider to use a multiple of 15MHz)

#Lattice lse vs synplify pro generator

Output 2 - 96 MHz (for USB clock to video generator via a P1V counter mod I already made for this previously) Output 1 - 160 MHz (fakePLL clock for P1V)

Second PLL - input 75MHz clock from PLL1 output (VCO set to 480MHz), this PLL input is also pre-divided to 15MHz Output 4 - spare (this can be 750MHz divided by any integer from 2-128) Output 2 - 75 MHz (HDTV pixel clock, close to official 74.25MHz, Valentin mentioned it work for his setups but YMMV) Output 1 - 375 MHz (5x pixel clock for HDMI's 10x output via DDR IO) I am considering using the following PLL setup to allow future HDTV (720p) via HDMI and a USB host in P1V software.ДЇirst PLL - input 25MHz from external OSC (VCO set to 750MHz) Maybe having valid timing constraints could fix that, not sure. Clocks seem best driven directly from PLL outputs not via the original P1V clock divider circuit which has problems with timing. 12.5MHz) using the glitchless DCSC block in the middle of the FPGA and just leave the higher speed 160MHz signal alone (like you did). In some experiments I found that in my case the clock switching logic worked best for meeting timing if you only switch to 80MHz from a lower speed bootup clock (eg. I would have preferred DTR but I think he mentioned that was not available on the FTDI part he uses, but having RTS is better than nothing at all. Hopefully this change actually made it into the final board rev so no-one should have to rework the board, at least that was my intent in requesting it originally.

#Lattice lse vs synplify pro code

Funny you mentioned LSE as being better as I had compiler issues with LSE but that was with a different codebase which probably still included some System Verilog bits and pieces that upset things, I might have to retry with the newer P1V code that I'm currently using that Magnus had cleaned up for Xilinx use.ДЄre you sure that the board needs a resistor mod for RTS? A while back I had asked Valentin to add it and his updated schematic shows it already connected via a 10k resistor to P89B pin as well as to the JTAG interface (it does double duty for both purposes). I've been using Synplify (in Linux) and while yes I do see warnings they mainly appeared to be forward declaration types etc and I did get it to map okay. So I think it often doesn't meet timing without this file being present and correct. Hey did you get some valid timing constraints setup? I have been trying to get that part sorted myself and there appears to be a myriad of various constraint format options/legacy versions SDC vs FDC etc. Glad you got it your board already and working quickly Ariba, and also at 80MHz! Our boards are taking a European vacation on the way to Australia.