March 5, 2018 at 12:34 PM #19858March 6, 2018 at 6:35 AM #19870
Could you please retest the builds in my GitHub test branch for its LineX5 capability?
Could you also define “glitch” for me?
I‘ve done a bit in order to get a better understanding what the Synthesis can effort and how to tweak the overall speed just by changing the code a bit.March 6, 2018 at 10:05 PM #19876FnnrqwinParticipant
I’ll post a video of it when I’m off work. Basically, in 5x mode 240p sources create small vertical black lines in semi-random locations. Seems like they mostly cluster, or at least are most noticeable, in brighter sections. This happens with scanlines on or off. 2x through 4x does not create this problem. Vanilla 5x works perfectly on my setup still.March 6, 2018 at 10:52 PM #19877
Also in the updated build? The timer analysis give higher F_max for pclk_5x than the values above.March 7, 2018 at 12:12 AM #19878paulb_nlParticipant
I have run the updated build for a while and didn’t get any glitches. Someone on the shmups forum did report glitches but dont know if he used the latest firmware.
Why didn’t you just revert those 2 commits I mentioned instead of changing more of the code? With the reverts Fmax on pclk_5x is 158 & 161Mhz and now with your updated code Fmax of pclk_5x is only 137 & 150Mhz. So that is quite lower than the needed 161Mhz.March 7, 2018 at 12:14 AM #19879
Meeting timing requirements is likely to get harder as the design progressively grows, thus leaving less resources for routing. With couple last official firmwares I’ve had to run around 20 iterations with different initial placement seeds to minimize violations. Another challenge is muxing of various clock sources (PLL outputs etc.) which potentially increases skew. Ideally only a single PLL output would be routed to logic and PLL settings could be changed dynamically, but changing PLL configuration (via ALTPLL_RECONFIG) is not very straightforward with Cyclone IV and would likely consume at least 1 M9K. Timing constraints have also been quite a mess with all inter-clock relationships, but I’ve now made a rewrite of those using additional generated_clocks which simplifies SDC and hopefully improves robustness.March 7, 2018 at 12:29 AM #19880
@paulb_nl: did you check “Hold summary” on Quartus II reports? In many cases hold violations are more severe as they are in effect even if effective pixel clock is lower than given constraint/maximum. A good guideline is to check that there are no setup violations in fast corner and no hold violations in slow corner(s). Minor violations are still acceptable (and often unavoidable) as gate models always include some pessimism.March 7, 2018 at 6:15 AM #19886
Why didn’t you just revert those 2 commits I mentioned instead of changing more of the code? With the reverts Fmax on pclk_5x is 158 & 161Mhz and now with your updated code Fmax of pclk_5x is only 137 & 150Mhz. So that is quite lower than the needed 161Mhz.
Because I didn’t got the same results as you did? Do you use the same fitter seed as I committed (or in general the same qpf file)? Do you use the latest quarts prime version?
With the latest build and by stuck at your ‘benchmark’ I got F_max 165MHz and 177MHz.
Most timing violations I have seen are in the PP-pipeline – either between two RAMs or between the two concurrent multiplier. However, launch clock is always pclk_indirect and latch clock one of the pclk_act, which makes me wonder. Shouldn’t be that added as false paths?March 7, 2018 at 8:23 AM #19890
@borti4938: there is an explitcit rule in ossc.sdc line 64, but it requires certain naming from the pipeline registers so it may not apply to your added registers. I just pushed the commit with rewritten timing constraints – it’s not fully tested yet but something like that should work better.March 7, 2018 at 9:39 AM #19892
Thank you very much 🙂 Also using the /* synthesis ramstyle = “logic” */ primitive on the post-processing registers helps a lot to relax timings. Fw-build runs through but I haven’t tested it yet.March 10, 2018 at 6:17 AM #19974FnnrqwinParticipant
Update on the firmware: the latest firmware resolved the glitch I was having with 5x mode. However, on the vanilla firmware my TV is compatible with the NES and SNES in 5x mode. With this custom firmware, they only display up to 4x. Genesis and N64 work fine in 5x.
The fact that the TV works with the vanilla firmware for those 2 consoles and but not this firmware hints that something’s still up with the way this firmware treats 5x.March 12, 2018 at 11:39 AM #20007mdd45Participant
So hybrid scanlines feature is going to be included in final 0.81 fw ?March 13, 2018 at 9:01 PM #20061
It has been merged into official source and will be in.March 13, 2018 at 9:09 PM #20062rock145Participant
I tested the the hybrid scanlines beta firmware and I like it very much. I would like to thank everybody that contributed in getting this to work with ossc. I wanted to know if it is possible to add a scanline thickness setting. I think that fighting games look better with thicker scanlines like: Streetfighter 2, Mortal Kombat,Art of fighting and many more. It would give a cga arcade look to it.
Here is a link when it was previously talk about. https://videogameperfection.com/forums/topic/scanline-thickness-setting/March 16, 2018 at 12:07 AM #20131HarrumphParticipant
Tested bortis build now, really liking the hybrid scanlines, thank you paulb_nl and borti! Great to see such collaboration!
I see flickery pixels here and there in Lx5 optimized modes, so that bug is not completely ironed out it seems. Tested with both 256×240 (snes) and 320×240 (gbi).
- You must be logged in to reply to this topic.