Home Your Account FAQ Topics Content Submit News Top 10
  Login/Create an Account    

Menu

Amiga600_FPGA.gif Amiga FPGA Accelerator
· Introduction
· Pictures
· Voltage Level Translation
· Sharing ideas
· Who helped?New content !
· Apollo-team chat

Amiga600_FPGA.gif Vampire 600
tree-L2.gif About
tree-T.gif Schematics
tree-T.gif Core
tree-T.gif Soldering
tree-L.gif Soldering V2
· Terms of service
· Ordering
· Core upload
· Vampire 600 map
· All News

Amiga600_FPGA.gif Vampire 500
· All News

Amiga600_FPGA.gif Vampire 1200
· All News

Amiga_Ball.gif Amiga Talk Talk
· Amiga 1200 Coldfire
· Talk regarding A608
· Amiga PPC

icon_members.gif Amiga Repair
· Amiga 600 restoration
· Mouse repair
· Cold solder joint
· Amiga 600 repair
· Keyboard repair

favoritos.gif Amiga Tutorials
· Install WB from WinUAE
· Play HAM Video

som_themes.gif Amiga Testings
· Amiga 600 plays video
icon_community.gif Forum
nuke.gif Downloads
home.gif Web Hosting
som_downloads.gif Web links

Info

Only registered users can shout. Please login or create an account.

Vampire 600: Where is the problem ?
Posted on Friday, July 19 2013 @ 09:59:48 CDT by majsta

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.


Sponsored links

Related Links
· More about Amiga FPGA accelerator
· News by majsta


Most read story about Amiga FPGA accelerator:
HDMI test 1


Article Rating
Average Score: 3.42
Votes: 7


Please take a second and vote for this article:

Excellent
Very Good
Good
Regular
Bad



Options

 Printer Friendly Page  Printer Friendly Page

 Send to a Friend  Send to a Friend


Sorry, Comments are not available for this article.

Re: Where is the problem ? (Score: 1)
by tnt23 on Friday, July 19 2013 @ 10:25:22 CDT
(User Info | Send a Message)
Did you have a chance to run TimeQuest on your design, especially for the SDRAM controller part?


Web site powered by PHP-Nuke

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest
You can syndicate our news using the file backend.php or ultramode.txt
Web site engine's code is Copyright © 2003 by PHP-Nuke. All Rights Reserved. PHP-Nuke is Free Software released under the GNU/GPL license.
Page Generation: 0.163 Seconds