Long-overdue progress update...

[Chris McClelland]

It has been a while, so I thought I'd post a message about progress.
Apologies for the length of the email.

Remember from my mail about statistics before, the MegaDrive asserts
/OE to signal the beginning of a memory access. Remember too that the
minimum /OE assert period is 7 cycles or the FPGA's 48MHz master
clock, and that the minimum /OE deassert period is also 7 cycles.
Bearing in mind that the signals must traverse the level shifters
twice, and that the signals must be internally synchronised to the
48MHz clock, there's not a lot of leeway.

So, we can make some observations:

1) It's impossible (or rather, infeasible) to predict when the
MegaDrive will assert /OE.
2) The latency is critical. Once /OE is asserted, the memory
controller has four, perhaps five cycles to fetch the data and drive
it on the data bus.
3) Once /OE asserts, signalling the beginning of a cycle, we are
guaranteed to have at least 14 cycles (7+7) before the MegaDrive
asserts /OE again for its *next* read.

So, over the last few months I have spent a lot of time learning about
VHDL verification using a functional simulator (GHDL & GTKWave), and
building & testing (in simulation & on a real board) an SDRAM
controller. The cycle times are:

16-bit read operation: 4 cycles (~83.3ns)
16-bit write operation: 3 cycles (~62.5ns)
Refresh operation: 4 cycles (~83.3ns)

I had hoped to design the SDRAM controller to do refresh cycles on a
timer (as is usual for SDRAM controllers), but unfortunately that
approach will not work because if the SDRAM controller happens to be
in the middle of a refresh cycle when the MegaDrive asserts /OE,
there's no way the data will be ready in time. So an alternative
approach is to keep the SDRAM massively over-refreshed by doing a
refresh after *every* MegaDrive read. It won't do any harm, and
there's plenty of time before the next MegaDrive read. In fact,
there's easily enough time for the host PC to do a read (or write) in
addition to the refresh operation, with at least two cycles to spare,
before the next MegaDrive read. Phew!

So I've started designing the PCB (it needs to be a four-layer board
so I've switched from Eagle to KiCad) and sourcing components. A bit
of effort on eBay goes a long way here...there are lots of component
suppliers in China who will ship (albeit slowly) for free, and they
have really good prices. And I have a good quote from a UK-based
company who owns a Chinese PCB fab (therefore no China-UK shipping
fees and no import tax, etc). I should be able to get 20 boards for
£200. I'm not too sure about the component cost, but I'm guessing
probably about £30.

I'm thinking it makes sense to split the cartridge into two separate
boards, joined edge-to-edge (in the same plane). The the generic stuff
like the FPGA, SDRAM, USB interface, config EEPROM & possibly the
SD-card slot goes on one board, which has an edge-connector with ~48
general-purpose FPGA I/Os and lots of grounding. This will be very
useful for other projects too. It also contains all the logic that
really *needs* a professionally-fabricated PCB. Then all the
MegaDrive-specific stuff (MD cart edge-connector, a pair of
transistors for switching /RESET & /DTACK to GND, and the three 16-bit
level-shifters) will be on a separate board. The connection between
the two can either be permanent (i.e soldered together with a
double-row 40w 0.2mm pin-strip), or temporary (i.e pins soldered to
one board, socket soldered to the other board) allowing the FPGA board
to be unplugged and used for other purposes.

The separation means less mechanical robustness, and will mean a
slightly larger footprint, but it also increases the chances that we
can recover from design errors, because whilst the routing of the
high-speed logic (FPGA, SDRAM, USB) is actually very straightforward
(just a star arrangement around the FPGA) and I'm unlikely to get it
wrong, the routing on the MegaDrive-side PCB is more difficult, and
error-prone. However, whilst I cannot fabricate the FPGA-side PCB
itself at home (it has four layers for a start, and some big SMD chips
with very finely-spaced pins), I *can* make the MegaDrive-side PCB at
home. So if a mistake *does* creep into the professionally-made PCBs,
it's likely to be on the MegaDrive side, whereupon I can just make a
revision-2 PCB at home and avoid incurring more PCB fab costs.

Again, sorry for the length of the mail. As always, comments and
suggestions welcome.

Chris

[Chris Smith]

Hi Chris,

apologies for the late Response.

Thanks for the Update :)

I'd vote that you split the Boards to give you the flexability.

Cost wise: can I pass you some Cash for the Components and PCB costs?

Regards,

Chris.

[Chris McClelland]

Well, probably about 90% of the work I'm doing on UMDKv2 is work that
I would have done anyway, components I would have bought anyway, etc.
So I don't want to accept money just yet.

You should have a look at the 3D model of the PCB design I mentioned
in the other mail though; it's pretty cool, and only needs a
web-browser to view it.

Chris

[Chris Smith]

Chris,

I shall aim to have a look at the latest by tomorrow Night. I am caught
up with a Freescale DSP at present :)

Tbh I'd feel happier if you didn't have to carry all the
Development-Costs off your own bat, Chris.

Chris.

[Chris Smith]

Chris,

that's a snazzy Application :D

Will these Boards be fully populated?

Regards,

Chris.

[Chris McClelland]

It's cool, isn't it? It's amazing what you can do with a bit of
Javascript these days.

When I get the boards back from fabrication, they will be completely
unpopulated. I have a lot of the components now, still some to arrive
though.

The boards do have soldermask so it should be easier to solder the
fine-pitch chips to these than to the home-etched boards I'm used to
working with, but even so I'm not looking forward to that particular
job!

The FPGA board is almost finished now, I'll probably send it for
approval by the PCB factory tomorrow. They will run an automated check
to make sure I've followed their design rules (minimum track widths &
separations, etc), and will let me know if I need to change anything.

Chris

On Mon, Aug 13, 2012 at 9:54 PM, Chris Smith <c.a.smi...@gmail.com> wrote:
> Chris,
>

[Rafael Gama]

Hey guys,

Apologies for the long silent period.

And I just have time for a short reply.

I saw the PCB 3D model, it's really great!

So, let me know about the fabrication costs. 

I still want to buy some of them.

Regards,

Rafael.

2012/8/13 Chris McClelland <proph...@gmail.com>