FPGA Replay Board

[mikej]

Sandisk 4G class IV at the moment I pick up in bulk from a lady in Shenzhen.
You get the choice of "fake" or "not-fake" when you buy them, so who knows what they really are Seem to work fine though.
/Mike

[mikej]

So, the end of february is finally here! Any news on the production run?

Should build em Friday....

[mikej]

Coool, Did they ever make that production video or did someone eat it?

I never received it, and am using a different assembler now.
I am promised photos at least - will ask if they can film the placement.
/MikeJ

[mikej]

No news from the factory yet? How long does these kind of things take?
How many boards was ordered?

I talk to the production people every day.
It takes a fairly long time the first few goes, it usually gets smother later.
100 being built first out of a 500 run.
/Mike

[mikej]

As I see the production got started already so when we may expect to have it in our hands?

It's quite good actually production has started, it's making me focus on production test and sorting out the remaining issues with the firmware.

Status as of today (7th March).
All components are in place at the assembler and they have started SMD work today. They will finish by mid next week. Some work remains, like sourcing packaging, inspection and shipping back to Sweden - and customs/import stuff. I should get them in my hands towards the end of the month, then they can be shipped to customers.

The development framework (VHDL + ARM code) is working well. DRAM training and test is in place. I can load large files directly from SD to memory and then verify the DRAM contents against the file.

The test "loader" design which contains the full system (OSD, system control, memory controller, PS/2, video/audio outputs) compiles in less than 20 seconds and has full timing closure at 133MHz (266Mbit on the DRAM). The OSD is in colour and higher resolution (32x16) with soft scroll.

Now I have fixed the problem with the DRAM clock capture, I have a very wide operating eye. This also means I can test and ship the ~30 boards I have here already which were not working with the old core.

Work remains on dynamic menus for other cores, but this should be finished in the next day or so.

Oh, FDD and HDD are not implemented yet as the protocol has changed. I will fix this asap

I'll be rolling out beta cores to current board owners in the next week - if everything goes smoothly.
/MikeJ

[mikej]

Maybe the core release has been delayed again?

Espskog,
You will need new ARM firmware as well, both will be available from the website when available. Yes, a few issues still, we will see where we are tomorrow.
/MikeJ

[mikej]

As long as the OS software can deal with the bugs in the earlier chips, anything should work fine. It will not run as fast, and will run hotter, but enough power is available and the clocking is flexible.
/MikeJ

[mikej]

If you provide the latest rev 6, i would choose to buy from you... have you manage to find anything like that, or should us, future fpga replay/daughterboard buyers, keep looking for that 68060 version? thanks for the reply.

Still working on it. Getting new MC early rev devices (non-XC) is no problem, just not the bug-free latest mask set

[mikej]

I'm (and many others) also happy to hear some news, or status report or planned roadmap (including 060 daughterboard, and new core).

Indeed, an update is due. No problems, just things are taking longer than I predicted - as usual.

The SMD production is complete, they are hand soldering the connectors etc. Waiting for boxes to be printed, but the boards should leave the factory by mid-week.

I'm taking advantage of the time to sort out some other aspects of the code.
Merging in some updates from other branches, testing the cache/prefetch logic with the new DRAM controller etc.

The codebase is a major change from the minimig project, large chunks are completely new and specific to the Replay board - as is the ARM controller firmware.

There are two reasons for this. One is to optimize and clean up the code for other cores - as much as possible should be common between the Amiga and Atari implementations for example. The other is to tidy up timing issues and get the compile time and area down. There are a lot of Xilinx optimizations, which will probably upset people as they can't just use the code on other boards - but my aim is to get the cleanest, fastest solution for my board.

Finally, building for production test, for example not just memory tests but eye scan so I can be sure the memory is working with good margin for voltage / temperature etc.

Finally, as I have completely re-written all the FD/HD/OSD code and protocol there is a bit of debug to be done there as well.

/MikeJ

[mikej]

Do you use DCM to adjust the DRAM clock signal?

Yes, exactly. The output timing is fixed.

There is no need to use the DQS strobes for capture at these speeds.

There is a careful handover of return valid internally and then a phase change FIFO to capture the data. These params are adjustable during DRAM training, however I have found I can fix them to a common value across all boards, the margins are so large.

/Mike

[mikej]

@ MikeJ:

Any chance if that new core in the next week?  If not then I'll be away at work for another 4 weeks.  I need my FPGA Arcade fix.  

mmm Not sure it will be 100% stable. It's close, mail me mid week.

[mikej]

Sorry, bit behind with emails.
Update ...
Production is complete now. It is raining in Shenzhen and this is delaying the cardboard box delivery. The boards should be shipped out end of the week.

This means I get a little longer to keep playing with the core. It's all good though as I am working on fixing the cache and prefetch logic. The DRAM controller is designed for the daughterboard and has a 32 bit data path for efficiency. This means a bit of logic an endian-ness fiddling is required to attach it to the 68K softcore.

To fully test this, the VHDL testbench now loads an srec file directly into the DRAM at start up and I simulate the processor running with various tests, stalls, refresh etc.

/MikeJ

[mikej]

It's improved a lot, some really good food in SZ.
It's the street dumplings you need to watch, they seem like a good idea after a few beers - and very tasty. They can fight back though

[mikej]

As long as the ram is only accessed by one cpu then the ram is endian agnostic.

Sort of - you have the ARM direct memory access, the video controller and other bits and bobs. The 68060 has pretty strong ideas about which byte enable correspond to which bits, which my memory controller happens to disagree with. Then, the problem of 16 bit vs 32 bit access to the memories.

As a hardware designer, little endian is a whole load easier, byte 0 stays where it is no matter what the access size.

/MikeJ

[mikej]

Some production pics on the "old" website :

http://www.fpgaarcade.com
/MikeJ

[mikej]

Very nice the boards indeed, but is there any way to buy one?

ha ha, soon!