As much patience I have there is no way I can found the problem. There are no more places too look for.
Hardware:
Only one thing I know I will never, never build PCB in white color or any other color than green. Why? Those boards don't have proper protection from hand soldering and you may end with short circuits all over the board. Hand soldering takes longer time so heat may destroy protection layer so you will solder components VCC to GND polygon plane. Maybe all of those problems I had are related to my PCB manufacturer but I know one thing for shore that is very hard to discover any problem on white surface. After solving all of those problems Accelerator was still unstable. But why? I didn't have any instability with older designs. Boards are running for several hours without any problems, playing games, using various programs who depends on FastRam, writing and reading from FastRam using AmosPro. First I was thinking that new system maybe sink too much power from Amiga motherboard. Old SDRAM needed about 150mA, new about 170mA so problem can't be here. Also, compiling design I found out that my design consumes only 219.63 mW. So problem can't be here because in theory FPGA could work with 5 times lower power supply, with less Amps, than I provided. Then I was thinking that maybe in the process reducing cost of production that I have removed some essential components needed for proper work, but that was not the problem because I have put them back and problem remains. So next logical approach is to check PLL because we are now at higher speeds. So I checked VCCINT who needs 1.2V for operation. Voltages are OK, GND plane needed for PLL is fine, there are also enough Amps, SDRAM chip is close enough to FPGA, there is nothing strange I can see there. After all I just don't understand why Vampire 500 works perfectly with only minor modifications to MC68K side and this one refuses to work.
Softcores:
Now, after 2 months of testings I can conclude that problem is not in SDRAM controller because every single one I tried behaves the same. Problem is not in any other signal from Amiga 600 motherboard, they are all treated properly and synchronized to support work on higher freq. On other side for signals to and from SDRAM Fast Input, Output registers are used to support all timings mentioned in SDRAM datasheet and according to Timing Analyzer everything is below needed 5.4ns.
Conclusion:
So where is the problem? All instability of the system are related to accessing SDRAM. In that process few hardware parts are included. Crystal oscillator, PLL for generating higher freq. That PLL generates two output signals at same speed, one for running complete core and one slightly phase shifted for running SDRAM chip. So maybe problem can be in determining that phase shift currently set at -1.0ns, but it is the same like on Vampire500 and there everything works fine. So imagine situation where you created Vampire 500 99% based on Vampire 600 design, they are the same only socket is different, cores are the same but somehow Vampire 600 does not work. It is not stable or usable in any way. I have spend 3 years working on this design but I just can't find problem. Vampire 500 is created in few days but works like charm. Now I have no idea what to do.
Update: Found it!!!
Ok here we go. I have a clue what is wrong. It was pure luck to discover such thing. Like we know 8MB of FastRam(Zorro II) are located between $200000 to $9FFFFF. So after detection of that specific range FastRam is added. There are few procedures for memory testings and I have explained few of them in earlier posts, but all the time I was testing $200000 space and didn't test anything higher than that. So few minutes ago I have decided to run LFSR memory tests on $400000 and all of them passed. Then, I have try to write $12345678 sequence into that space using AmosPro and then to read that space after flushing cache and get exact sequence :) So to conclude, something is wrong with $200000 - $3FFFFF address space and that is why I have lost last two months. Another thing that is important to me that reading that sequence in correct order proved that SDRAM clock is correctly phase shifted. So I have tracked down the problem, lets try to solve it.