Scratch that : those bits really are unused in those registers! It's all good. Either assign all bits or reduce the width of the signal. If this is not the intended behavior, drive the inputs with valid values, or inputs from the top CL265 :"/home/roger/Documents/LatticeFPGA/P1V/source/cog_vid.v":50:0:50:5|Removing unused bit 8 of vid. Either assign all bits or reduce the width of the CL271 :"/home/roger/Documents/LatticeFPGA/P1V/source/cog_vid.v":50:0:50:5|Pruning unused bits 22 to 11 of vid. If this is not the intended behavior, drive the inputs with valid values, or inputs from the top CG364 :"/home/roger/Documents/LatticeFPGA/P1V/source/cog_vid.v":22:20:22:26|Synthesizing module cog_vid in library CL265 :"/home/roger/Documents/LatticeFPGA/P1V/source/cog_vid.v":50:0:50:5|Removing unused bit 31 of vid. If this is not the intended behavior, drive the inputs with valid values, or inputs from the top CL271 :"/home/roger/Documents/LatticeFPGA/P1V/source/cog_ctr.v":52:0:52:5|Pruning unused bits 8 to 5 of ctr. Either assign all bits or reduce the width of the CL271 :"/home/roger/Documents/LatticeFPGA/P1V/source/cog_ctr.v":52:0:52:5|Pruning unused bits 22 to 14 of ctr. N: CL134 :"/home/roger/Documents/LatticeFPGA/P1V/source/cog_ram.v":41:0:41:5|Found RAM r, depth=512, CG364 :"/home/roger/Documents/LatticeFPGA/P1V/source/cog_ctr.v":24:20:24:26|Synthesizing module cog_ctr in library CL265 :"/home/roger/Documents/LatticeFPGA/P1V/source/cog_ctr.v":52:0:52:5|Removing unused bit 31 of ctr. I was seeing some strange messages in the reports like this. Will truly only know only once a final P1V build is proven to be loadable/working on Lattice ECP5 and get the numbers again. It's ideal really.įrom this early data ECP5 may seem a bit more efficient on usage compare to Cyclone IV (if you equate a Lattice LUT to an Altera LE), but I am still concerned it might possibly be optimizing some things out in my build. This is a particularly good use of the available resources for a P1V implementation with video and USB hosts using ECP5. In some sitatuation that is okay but not for a 12Mbps USB clock sourced from a poorly synthesized 96MHz clock.Īlready communicated with Valentin about PLL usage recently and yes in the ECP5 there are the two HW PLLs, one can be used for video clocking, and the other for P1V with USB at usual P1V clock speeds.
Add a vivado project to synplify pro code#
The issue is that the P1V video PLL is not HW based (unless you tweak it -) )so there is a lot of jitter there with the fakePLL Chip's code emulates. Eg, I used it for I2S audio, and it is used in SaucySoliton's 80MHz USB host.
Add a vivado project to synplify pro generator#
Initial designs could use SysCLK PLL for the video clock, to simplify clock domains.Īctually the video generator is still useful to keep in there in some situations (not always for video). I don't think there is much practical use for 8 video generator instances. With 2 PLLs showing in the ECP5 series, one could be used for SysCLK and the other as a video clock generator for one instance of video output.
0 kommentar(er)
