To infinity and beyond... (new hardware)

[+Spaced Cowboy]

So, for what it's worth, here's the entire digital-LCD-output-to-analogue-VGA-display circuit

 

I used line-drivers instead of discrete diodes they'll protect the STM32 from driving too much down the VGA cable, and they're only $0.60 each (Q1) so not much more expensive than the discrete diodes anyway... Apart from that, there's the resistor ladder, some ESD protection, a couple of FETs to buffer the sync lines, and the VGA connector.

 

The resistor values are chosen because we know that VGA wants a terminal voltage of 0.75v into a 75 ohm impedance. The resistors form a parallel array, so their effective resistance is governed by

 

1/R = (1/r1 + 1/r2 + 1/r3 + ...)

which gives R = approximately 272 ohms if all digital lines are high (ie: pure red, green, or blue)

 

Now, we know the terminator impedance for VGA is 75 ohms, we know 'R' so we can determine the voltage that will be output on each of R,G or B into the VGA connector by treating it as a voltage divider with an input of 3.3v using the formula

 

Vout = Vin * R1 / (R1 + R2)

We can see that Vout for a pure colour would be 3.3 * 75 / (75 + 272), or approximately 0.713v. This is close enough to 0.75v to be a good range, and because we used R,2R,4R,8R,...,128R to represent the powers-of-two in the digital value, we have a linear scale from 0 volts to 0.713v, which in turn ought to produce a linear gradient over all of R, G, and B.

 

So that's our VGA circuit. It maps to a nice little self-contained module that looks like

 

Simon.

[+Spaced Cowboy]

Getting there

So, I've been working on getting the board to lay out and work with the new FPGA-based design. The schematic PDF is here for your viewing pleasure, but what I'm really pleased with is the layout. I've taken a lot more care over the routing now, because we have some very high-frequency signals on the board so ground planes and power planes are a lot more important. Here's the overall layout (this is a quick "click on the autorouter" after doing all the prep work)

The ground plane then looks like (ignore the black horizontal lines, it's an artifact of the render):

And the power plane looks like:

I'm pretty pleased with that , the only perforations in the planes are the through-hole components. Eagle was fighting me all the way to get there, insisting on routing signals on the planes even if it wasn't necessary (ie: there were other planes available) - so eventually I put a via next to every GND pin, routed a trace to that via and locked it, then disabled the layer containing the ground plane in the autorouter configuration. Now that there was a pre-routed path to GND, and it was forbidden to use the plane layer for any reason, I got my good-looking ground plane.

Then I did the same for the power-plane. This is mixed (3.3v and 5v) but I can handle the signal-crossing issues with some capacitors on either side to help with the ground loops. I'll also take the time to make sure there's no high-frequency signals (ie: more than a few MHz) crossing the 5v/3.3v boundary.

The downside of the high-frequency requirement is that I have to go back to a 6-layer board - there's just no way of fitting the signals into 2 layers (assuming 1 layer for GND, one for power) on a 4-layer board, and even pushing the design to a 4/4 trace/space didn't really help. At Q100, the price difference is ~$5/board for that, so I'm not *too* bothered about it. Going to a 6-layer board stack-up (see the first page in the PDF above) gives me easier-to-work-with differential traces as well, just due to the microstrip capacitance calculations with the different board geometry.

 

This isn't the final form, but it's getting there (hence the title). I actually plan to remove the wide bus interface between the FPGA and the STM32, and reduce it to a SPI interface in both directions. That'll free up some pins on both devices, and although I think it'll make access to the video memory slower from the FPGA, it'll put less load on the STM32 to service, which gives it more time for video processing. We'll still get 45 MBit/sec, which is fine for slot i/o and using 4-byte bursts, we could still write ~2.8 MBytes/sec which ought to be more than enough for the 6502. I'm cheating a little with the numbers here, because the 6502 could say "transfer this block of local SDRAM to video SDRAM", but then I'll do larger bursts, so we could get to ~5.5 MBytes/sec.

 

The nice thing is that if I use the "standard" interfaces on the STM, I can do a lot of this as DMA without involving the processor, whereas if I implement a custom bus (as now), the CPU has to get involved with all the transfers as they take place, which takes away from any video-processing I want to do, converting Atari's bit-packed graphics fetches into RGB triplets in SDRAM. Given there's an FPGA involved now, I could even do all the bit-fiddling in the FPGA, effectively for free, and send RGB over the SPI interface - a 640x480 image would cost me ~1MByte/sec at 60Hz, so this is also within the realm of possibility. FPGAs are very flexible

 

Anyway, thought I'd update on the routing, which I'm pretty happy with. Once I've run through the design looking for mistakes again for a few days, I'm going to ask for another design review by the people here, and then final fixes and I'll send it off by the 18th to get my voucher savings

 

Simon.

[+Spaced Cowboy]

So, barring unforeseen events, and assuming I don't find something *too* egregious in the schematic, this is the design I'll be proposing for the second design-review meeting.

Notable differences from the last image are:

• There are now three power planes (GND, +3.3v and +5v) which are uniformly contiguous across the entire board - no need to worry about ground loop paths as signals cross the 3.3v/5v split-plane any more
• Instead of a 16-bit-wide bus between the FPGA and the STM32, I now have 4 distinct SPI channels. 3 of them can run at 45 MBit/sec, one of them (I'll probably use this for video) can only manage 22.5 MBit/sec.
• Signal traces like the SDRAM group or VGA group are all pretty localized - there's still a fair distance between the longest and shortest path on the SDRAM group, but a lot of that is due to the way the pins are laid out on the STM32 (they're all over the place). The layout I have is pretty minimal in terms of path length. I don't think it's *as* important on SDRAM as on DDR SDRAM, but these signals are still going to be cycling at ~100MHz, so it's worth taking care.

Beyond that, it's pretty much the same as before. I'm just happier with this layout It's not the final form (it still needs a lot of TLC to the labelling on the board, and I'll probably renumber the components) but that can wait until after it's passed the DR

[+Spaced Cowboy]

Tempus Fugit

 

[warning: links go to PDF documents]

 

So I passed around the PDF of the schematic ahead of requesting another design review, and got some immediate push-back from the FPGA guys. The Spartan-6 FPGA that I'd chosen because it was the only one I could get in QFP format is not supported by the latest tools (the old tools are still available, but they've been mothballed since 2013...).

 

The part is still actively being produced so it slipped past my filter of "active, in-stock" at Digikey, but presumably this is just because it was massively popular and there's an ongoing market. I'm assured that "if I want to prevent myself from getting into a world of pain with no support from the vendor", I ought to go with the newer part (Spartan-7) rather than the old one, just so I can use the new tools (Vivado) rather than the old ones (ISE). That threw something of a spanner in the works - I'd been pretty pleased with the outcome so far, having all the parts feasible (even if not easy) to solder manually. Now, unless I want to ignore the guys whose expert opinion I'm asking, I need to go the BGA route.

 

The benefits (apart from the tools) are pretty compelling:

• It's on a 28nm process, not 40nm, so it'll run faster.
• It's slightly larger (in terms of capacity) for the same price give or take a dollar
• I can get it in a 1mm BGA which is about as easy as they come for BGA
• The i/o is actually slightly faster (1250 MBit/sec not 1080 Mbit/sec)

Of course, it's not all sweetness and light, there are a couple of downsides as well:

• I'll have to make up a Spartan-7 symbol in Eagle, and research how the part is supposed to be connected together. I'd already done that work for the Spartan-6. How similar it will be remains up in the air, despite the similarity in name, this is an entirely new chip.
• The LVDS (low voltage differential signalling) FPGA-to-FPGA connection over USB3 cabling that I was going to use with the Spartan-6 only runs at 1.8v or 2.5v on the Spartan-7, not the much-more-friendly 3.3v that it does on the Spartan-6. There are only two i/o banks on the smaller Spartan-7, and all i/o on a given bank has to share the same voltage standard, practically this means we'll be running at 2.5v for i/o. This means there'll be some level-conversion going on between the FPGA and the STM32, although I'm limiting the signals that talk to both (these will be SPI busses only), so it's not *that* bad a problem.
• Even though it's a "good" BGA, it's still *just* about possible to escape all the pins using 3 layers of board. Looking at the ball layout, and counting inwards to see the depth of balls I need to get signals to, there's a maximum of 6 signals deep into the FPGA that need to be escaped. I can do this with 3 on the top layer, 2 on the bottom, and 1 in an internal layer.
• The other concern I had was that the time it would take to integrate a new chip would take me past my deadline of 18th August for Seeed's coupon off the PCBA. I emailed them, and got a reply back this morning (next day) saying they were happy to extend the coupon by 3 months, which was very nice of them, and removes that worry at least.

 

I have to say that this little project of mine is exercising me in ways I really hadn't expected when I started out, throwing curve-balls at me just when I think all the ducks are lined up... Having said that, I'm having a tremendous amount of fun designing it all, and I have the security blanket of the rest of the crew here to fall back on. I'd be a lot more nervous if it were just me

Simon.

[Dropcheck]

I know we all like to dream of the 'most perfect A8' in the world. It would have the fastest this and the biggest that......

I understand the lure you feel to maximize the potential and follow the expert's advise. I've done it myself from time to time. But I worry the initial purpose is being smothered under the weight of the glitz and glamour of more and better and newer.

I'm sorry for knee-caping you, but after nearly eight months all I've seen is an ever increasing complexity and cost for a board and theory that as yet doesn't exist except on the drawing board so to speak.

Who cares if the FPGA is an older model at this point? Unless I'm wrong or missed something you don't have a functioning prototype yet. Get version alpha up and running nearly faultlessly in a real world environment with the basic features you listed in the first post of this thread. Create some basic add on boards to test your plugin board theory. Work out the kinks in basic operations first with a simpler design. Then you can take what you've learned and make it newer, better and more for version beta. Maybe even improve on that so that it's actually version 1 that is released.

I'm not trying to be mean, believe me, but quit teasing. Where's the beef?

[+Spaced Cowboy]

Hey Dropcheck!

 

I'll just refer you back to the phrase I used in the very first post

 

 

 

There's a long way to go, its early-days yet and things might not go as I forsee, but even though the goal is grandiose, I think it's attainable and it'll be pretty cool once it's up and running.

 

Who cares if the FPGA is old ? Well, I do for one, if I'm the one writing the verilog to get the FPGA to do what I want. If people I trust tell me that the route I'm taking is going to cause me problems, then I'm going to take that on-board.

 

Maybe it's a matter of perspective - I'm not seeing this as a hardware PCB you wire up, plug in, and it works. In my view it's a combination of hardware, firmware on the FPGA and software on both the 8-bit and the ARM chip. It's complex and ambitious, and what you might see as the PCB getting ever more complex, I see as the project as a whole getting simpler to complete. Getting the PCB up and working (passing the smoke test) is only stage one, there's a metric boatload of effort to be expended after that before things will "just work", and sometimes optimising to solve the global problem means local maxima get a little more complex.

 

I *could* drop the FPGA interface and go back to the VHDCI, but I think that'll actually be *more* expensive in the long run - the cables are expensive ($30), the connectors are expensive ($15 each, so that's $60 right there), and they're last-years tech so they're only going to get more so. I don't have a problem with last year's tech (hey, I have an XL!) but it does have a tendency to become obsolete at the most unfortunate of times... If I *was* going to go back to a parallel bus approach, I think I'd probably give up the quest for an elegant interface and just use a ribbon cable - I don't think $60 is worth it for a cable you won't see 99% of the time.

 

I won't disagree that there's been quite a bit of design churn in the process, but that's not me just dropping whatever I have, screaming "ooh! Shiny!" and running to get another, brighter prize. The reasons for change have been (I think) well documented here, and IMHO there's always been a good technical reason for any new direction I've chosen to take. I've learnt a lot about the implications and technical details during the time I've been working on this, and the results of all that investigation have been the driving data behind the project's evolution.

 

As for 8 months (I make it just under 6, actually), there's no time-table on the project (well, not much of one, I do want to use that coupon from seeed) and I thought it was useful posting progress, warts and all, as it goes on - but if it's coming across as teasing, I'm fine going radio-silent and then announcing a fait-accompli when everything is up and running. As I said in post #5,

 

 

 

I'm well aware the project is ambitious, and to be honest I'd normally have tried to get a lot further with it before announcing it

If my current approach to documenting this isn't working for others, I'm fine changing that.

Simon.

[+mytek]

It's fine by me, and it's how I'm planning on documenting my latest project with no actual endpoint specified.

 

It would be different if this was 1985, and you and I were an actual company, or Atari for that matter. And we started posting stuff about the next piece of gear we intended to produce. If this started to drag on, it would also start to get ugly responses from the consumers, which would be expected. Heck I even got pissed waiting for the 1450XLD to arrive, which never did. But that was then, and this is now. We are for the most part looking at a hobby project and it's journey. And thankfully you have decided to share this journey as it unfolds .

[_The Doctor__]

I don't think everyone grasped this is much more than an expansion bus slot box, and there may be those who are thinking about their own project/ideas and don't have the full scope of what you're doing and the possibilities of it in their minds....

 

Good thing this is your project! Keep rolling with it! Each piece tackled and revised until it settles. I think you've got great ideas and the twists and turns will only help the project.

[Dropcheck]

I stand corrected on the length of time. It has only been about six months.

 

I really do hope that you continue this project. I would like to see it completed. I am cheering for that.

 

But I believe you need to do the prototyping with a basic board and feature set up and running first, then work forward to a finished system based on the foundation and knowledge you've built up in the process. That allows you to work out the kinks in the basic system, before you start putting layer upon layer of complexity on top.

 

Trying to start at the end with a finished product and working your way backwards assumes you won't have any hardware gotchas along the way. You might not. I just don't like to assume.

 

Hey, I know I'm the bad guy in this. So be it. Anyway... good luck.

[+Spaced Cowboy]

Hey Dropcheck!

 

Don't worry, there's no chance I'm stopping the project - I'm invested too much at this point and I like to see things through to completion once I've started them.

 

I've been tweaking the schematic a little, and if I drop the aux serial port, I can come up with a compromise design. I branched off the 'xio' schematic to 'xio2', which still has the USB-c interface, but also has space for a PATA serial cable connection - kind of like a mini VHDCI since it only has 40 pins. You can get "round" cables for not very much money (even cheaper on eBay), and the connector is a simple 2x20-way 0.1" rectangular header, so also very cheap.

 

The schematic doubles up, so if we're using it in parallel mode, with a parallel bitstream loading into the FPGA, then everything flows to/from the parallel port to the FPGA, STM32, and slots. If we're using it as a USB-c interface the FPGA regenerates all the parallel bus signals from the serialized data-stream, and the parallel bus becomes a transport between the STM32 and the FPGA.

 

This means I can get it up and running in the simple mode (low speed parallel communication, test stuff out, and then move to the USB-c mode once the basic stuff is working without re-spinning the board. If it turns out that this is beyond me, then it's just a 'no-stuff' option in the build process, and no harm, no foul. If people *really* wanted that extra serial port, well, there are slots.

 

In this scheme, the FPGA acts as the bus-controller and arbiter, so I can react instantly to bus changes, and it requests data from the STM if needed, parsing the bus traffic so the STM doesn't have to and handling the generation of /EXTSEL and /MPD without software intervention. This makes the software side a lot easier. The FPGA will also generate /CCTL, /S4 and /S5 from the address bus, so we don't have to transfer them across the PATA bus from the host, meaning we only need 32 signal wires, which fits nicely into a 40-wire cable, assuming we also common the GND, with seven wires to spare. I ought to be able to squeeze SIO (5) and audio (2) in there too if it's coming from an 1088XEL, making this (almost) functionally identical to what we had with the VHDCI.

 

From the cartridge perspective in the parallel interface case, it's actually on the bus, modulo bus drivers, just like it would have been in a normal Atari, so that's straightforward as well.

 

Simon

 

[update]

 

So it's not *quite* as nice as that - in the parallel case, I need 5 wires for the direction control of the bus-driver chips that sit on the board that plugs into the host. There's a couple of options:

 

• Say sayonara to the SIO wires, and just use the available wires for control
• Add some programmable logic at the host end (currently it's a dumb interface) and encode what we want to send using a protocol over the available lines, then let the programmable logic do its thing to actually control the wires. We can fit that into 2 lines, leaving the 5 left over for SIO.

 

What I'll probably do, when I get to laying out the host board, is a combination of the two - so I can initially get stuff up and running using the simpler first approach, and if that works, I'll be able to switch over to getting the more complex option working, which will give us SIO plug-ins in the slots.

 

[/update]

[+Spaced Cowboy]

It's been a while since the last update, so thought I'd drop a quick post with where I'm at. The board now looks like:

 

There's a few notable differences from the last time, but this is pretty much what I'm going to present to the guys at work for a second design review...

 

• The most obvious differences are that both of the major chips are in BGA form (and yes, those are 0201 capacitors!). This time around I made sure that Seeed have the parts by submitting BOMs to the website and making sure that both the FPGA and the STM chips are sourced by "Seeed", meaning they have them in-stock, and they can get hold of them without problems.
• The next big thing is that it provides both a parallel and an USB-3 interface to the FPGA. As explained in the last post, this'll give me the ability to start off getting everything working with the simpler parallel interface and once that's done, we can move to the gigabits/second USB3 interface. One thing I've learnt though is that the 80-pin PATA cables don't have 40 wires in them, some of the wires are internally connected to ground/each-other. That means we're stuck with the 40-wire cables, and as far as I know there's no 'round' versions of these cables. C'est la vie.
• There are two relatively (100 Mbit/sec) fast full-duplex SPI channels between the FPGA and the STM, which ought to be enough for most purposes. There's no need for bulk data transfer between video RAM and mappable-to-the-host RAM any more, there's just one chip so it's *all* video RAM and it's all mappable RAM - this relieves a bit of pressure on the communications interface.
• I've used two interrupt lines for bus traffic interrupts on the STM, one for read operations, one for write operations. Not a huge deal but it means I have a bit more a-priori knowledge when the interrupt happens
• I've placed pin-headers for the SPI bus between the STM and the slots, and another pin header on each of FPGA<->STM SPI busses. This'll be useful for the logic analyser to attach to when debugging.
• There are 3 Debug-time LEDs for the STM, a further 3 for the FPGA, and LEDs for power-good on the 1.0v, 1.8v and 3.3v rails for the FPGA. There's another LED to show that the FPGA is successfully programmed.
• Since we're talking about LEDs, there are 3 LEDs per slot - one showing that the slot power supply is ok, one showing that a card is in the slot, and one showing that the slot is communicating with the STM32.
• There's an internal 6-signal extension for the FPGA at the lower-left. There's also a 2-pin power/ground header on the far left for mounting stability. This is for any future internal expansion. 6 signal lines might not *sound* like a lot, but each line can push a gigabit of data per second...

 

In the long run, assuming the USB-3 connector works out, there'll be a lot of pins available on the parallel port for future external expansion as well

 

Anyway, I'm down to one 'note-to-self' at the bottom of the design, which I'll clear up by making another 'test-fit' board and sending it off to OSH-Park for a quick turnaround. That way I'll know that the Gerbers are ok for manufacture on the large board. Last time I did that, it picked up on the fact that my cartridge-port drills were too small, it's always kind of nerve-wracking when you make the footprint yourself and it's part of a big project like this...

 

Simon.

[+Spaced Cowboy]

Up for design review

 

So I've finalised the PDF, and have just sent it out to the internal mailing list for a design review. It'll probably be next monday now before people have availability, which gives me a few days to catch up with life again [grin].

 

Some random things:

 

I also sent out a Seeed order for the fit-test board (I figured it was better to test with the actual place that'll be making the PCB than with someone else). That one's in production so it'll be here in a week or two.

 

I was looking for a way to simulate the high-speed communications between the host board and the motherboard - the traditional way is to use software like Mentor Graphics HyperLynx but I didn't have a spare $40k for a license (shucks!). I did find PyBert, though, which looks as though I can take the IBIS models for the Spartan-7 and simulate the data-transfer to see what the eye-diagram looks like. I've currently tried to make the path as straight-line as possible, used the internal termination for better signal integrity etc. But considering I'm doing something not-very-ordinary, running a sim would be "advisable" according to Xilinx support

 

Idea from left field: It seems to me that the main chips (Antic, GTIA, Pokey, even the venerable 6502) could probably be implemented using a Cypress PSoc5 chip - basically an Arm Cortex M3 allied with a tiny CPLD on-chip. These devices:

 

• are 5v-tolerant (there's a PSoc6, but the only ones currently available are 3.6v - though apparently there's a 5v one "in the plan")
• run at 80 MHz (so with an average CPI of ~1.4, you get ~33 instructions to implement each 6502 opcode, for example)
• can have their mini-CPLD programmed in verilog
• have 256k of on-board flash to store, and 64K of RAM to execute, their program in
• have analogue circuitry built-in as well as digital resources, so GTIA/Pokey ought to be implementable.

All round, this seems like a very capable little chip. I'm not planning on doing anything with it until the slots motherboard is complete and all the s/w integrated but it does look like it might be possible to implement the functionality of the custom chips with a bit of clever coding.

 

Simon

[dmsc]

Hi Simon!

 

Idea from left field: It seems to me that the main chips (Antic, GTIA, Pokey, even the venerable 6502) could probably be implemented using a Cypress PSoc5 chip - basically an Arm Cortex M3 allied with a tiny CPLD on-chip. These devices:

• are 5v-tolerant (there's a PSoc6, but the only ones currently available are 3.6v - though apparently there's a 5v one "in the plan")
• run at 80 MHz (so with an average CPI of ~1.4, you get ~33 instructions to implement each 6502 opcode, for example)
• can have their mini-CPLD programmed in verilog
• have 256k of on-board flash to store, and 64K of RAM to execute, their program in
• have analogue circuitry built-in as well as digital resources, so GTIA/Pokey ought to be implementable.

All round, this seems like a very capable little chip. I'm not planning on doing anything with it until the slots motherboard is complete and all the s/w integrated but it does look like it might be possible to implement the functionality of the custom chips with a bit of clever coding.

 

About 4 years ago I sampled that chip little brother, the PSoC 4, it was US$1 each with shipping for the 28pin CY8C4245PVI-482, and tried using the programable block (called "Universal Digital Block" or UDB).

 

My experience was:

 

- You need to use their IDE (based on visual-studio) to develop all the firmware, as the IDE generates some "magic" data to load to the chip, there was no low-level documentation for the UDB.

- You can trigger an interrupt on a condition from the UDB, so you can program the chip to interrupt on read/write to an address and decode the bus logic in the interrupt. This was not as useful as I first tough, as you need to ensure low latency from the interrupt to the handling of the bus.

- Hacking a little I was able to program the chip using OpenOCD and a st-link clone, via SWD.

- Finally, I was able to compile and debug short programs from Linux, but without using the UDB.

 

After that, I continued to use STM32 chips

[+Spaced Cowboy]

Hey dmsc

 

Yep, if I was going to do it, I wouldn't use interrupts - it's not worth the 12-cycle (at best) latency. Given that the chip has 1 job in this instance, running it using BLT ("Big Loop Technology" ) would be much preferable I think.

 

You could still implement bus-decoding into registers using the UDB's, and they have input/output FIFOs that the system bus can access, so effectively a single read instruction followed by a jump-to-offset is all you need in the loop. A bit of assembly (almost all the non load/store ops are single-cycle on the Cortex M3, load/stores are 2-cycles) and you can do quite a bit...

 

Don't get me wrong, I like the STM myself, but the UDBs do offer quite a bit - I could have done the /EXTSEL and/or /MPD using them, for example, and not worried about triggering an interrupt and waiting on latencies

 

Simon

[+Spaced Cowboy]

Regarding PyBERT, I got in touch with David Banas (the guy who wrote it), and he was good enough to give me some tips on how to configure the application for my Spartan-7 I/o. Shout-out to David for such a quick response - I wish some of our *paid* support was as good... Anyway, assuming I've done this correctly (I'll check with the EE guys tomorrow), the eye diagram simulations for the signal actually look pretty good...

I have a pretty limited understanding of the minutiae of eye-diagram reading, but the basics are that you want a solid black bit in the middle, and the larger that black bit is, the better quality the signal. What you're actually looking at is two signals overlaid, one rising as the other falls, and the more they are affected by the transmission line they're traveling down, the smaller that black area will get. To illustrate, if I were to try and push a 5Gbit/sec signal through the same parameters as above, the eye diagram looks like:

Which is a far less well-defined signal.

To get the Spartan-7 diagram, I downloaded the IBIS model from Xilinx, and extracted the parasitic capacitance of the pin (ball), the measured voltage driven by the 3.3v TMDS signalling option I intend to use (which is actually 2.9v) and specified a cable length of 1' (actually 0.33m) which is the length of cable I'll start out with. Any USB-3 cable under 18" is passive (there's no active parts trying to optimize the signal) which'll keep things simple.

What I'm not sure about is whether I also have to add in the C_comp value of the package (the buffer die capacitance). If I have to do that, the eyes are still pretty clean, but they do start to look noticeably worse than the first set:

... with the capacitive loading on the transmission line starting to affect the rise and fall times and the "eye" in the middle concomitantly shrinking. Anyway, this'll be a question for the EE's tomorrow

 

update: David got back to me, and it *is* the latter case for the capacitance, so we're looking at 6.12pF rather than 1.31pF for the capacitive loading. I'll be talking to the EE folks about this when they get in.

Simon

[+Spaced Cowboy]

Fitting the test

 

So, after a fair amount of struggle to get the board routed out (in the end I'm going to get a third-party router for Eagle called Electra), I've got to the stage where I have a candidate for the final board. I'm going to talk to a different bunch of guys at work next week (I'm back in on Wednesday) to make sure I've not screwed up the layout too much I'm thinking I might post it on reddit for review as well - the more eyes the merrier.

Here's what it currently looks like.

There's been a couple of tweaks since the last time I posted, which came out of the second design review. The main issue they had with the design was a power-rail problem. I'd gone with using gated LDOs for the 1.0v, 1.8v, and 3.3v power rails for the FPGA, all sourced from the 5v power plane. The problem was that, with a voltage drop from 5v to 1v and a power requirement of 2A, the LDO would be sinking 8W in heat. That's a lot.

The solution was to drop the LDO approach and use a switching power supply - these are far more efficient because they're either conducting 100%, or not conducting at all. In neither state do they generate much waste heat, in contrast to a linear LDO which effectively dumps all the extra energy (when going from high voltage to low) into an internal resistance, producing a lot of heat.

 

Generally I find that engineering a switching regulator circuit is a lot harder than a (relatively simple) LDO. Fortunately, TI have something called 'Webench power designer' which allows you to type in your fixed parameters and it'll come up with solutions (TI-based, obviously). You can even do Spice simulations of the circuit in the browser, and if you can't source one of their first-choice parts, you can click on it and it offers options from different manufacturers. This made creating the power circuits pretty simple

While doing that, I figured it'd be easier to have a single 3.3v rail, since the switchers are available at fairly high amperage, and it simplified the board layout as well. So now there's a 10A 3.3v rail which goes directly onto an internal continuous 3.3v plane via lots of vias (pardon the pun). Likewise, there are plenty of vias for the ground plane so the return path is unencumbered. I also added copper pour around the input jack, so power can dissipate into the GND, +3V3 planes either from the connection to the inner-plane directly, or via the copper pour and then the vias to the inner-plane. The idea is to keep the path from wall-wart to power plane as low resistance as possible.

 

I also added ground-loop bounce capacitor-pairs along the border of the 5v plane, so that long ground loops couldn't form as signals traversed across the 5v plane boundary.

Now the FPGA is using the same +3V3 plane as the rest of the board, there's no need to route out to the VCCO lines, they just sink a via and get their power, which is nice, but for VCCINT and VCCAUX, I routed a polygon on an inner plane so that they could do the same.

The power budget on the 3.3v rail is about 1A for the CPU, about 1.5A for the FPGA, and about 0.5A for everything else put together. This leave me with 1A per slot and a comfortable overhead remaining of ~3A. Ideally, with modern electronics, a slot shouldn't require 1A of power, it ought to be in the low hundreds of mA at best, but it's there if it's needed.

 

The other issues raised in the design review were of lesser importance (adding 0R resistors rather than direct connections to power or ground, for example), and I've gone through and made those changes.

 

Apart from that, there were a few cosmetic changes

 

• I rotated the SDRAM - I ought to have done this earlier, it makes access to the pins far easier.
• Removing those six 3.3v regulators made some space on the board, so I could move around the cartridge and serial port a bit, making more space for the power region below.
• I added a dip-switch for the FPGA configuration mode. Apparently it can be useful to be able to force the FPGA into JTAG configuration mode, rather than SPI-master.
• The FPGA SPI flash can be written to by both the FPGA and the CPU, but the FPGA wants to be able to read it at a high frequency (about 50 MHz, in Quad-SPI mode), so there are rules about signal integrity and not having spurs etc. The solution was to use an analogue mux, switchable by the CPU, but by default allowing access to the FPGA, which preserves the point-to-point connection that the FPGA wants, but allows the CPU to override it to create a point-to-point connection to the CPU instead.
• I went through and made sure the labels were correct and appropriate, so the board is "ready to go" once I decide to pull the trigger.

Testing the fit

I also got back the test board from Seeed and the cartridge port now fits perfectly. It looks as though the USB-c connector will be good too, but I'm waiting on Digikey to deliver the part before I can claim that. The SD-card connector seems to be a good fit, and the same Digikey shipment will allow me to test the VGA connector.

The only issue with the Seeed board was that the power connector wouldn't fit, the holes for the pins were too small, it looks as though they don't like items on the 'milling' layer. I could, however, fit the power-jack pins into the holes for the VGA connector, so I've altered the footprint for the power jack to have larger holes, and deleted the milling information. That ought to make it work on the real board.

Whew! I think that's about it for today

 

Simon

[+mytek]

Dammm!!! that's a very complicated layout. I'm sure glad you're doing that and not me . I guess this would be a bit too much to manually route .

 

Looking good

[+Spaced Cowboy]

So Digikey delivered the parts I needed to test-fit today. Everything looks good, so now it's just the boring slog through every sheet in the design, cross-checking it against the data sheet to make sure each pin is correctly bound to the right function. I could keep tweaking the circuit layout forever, but at some point it has to be considered "done", and barring errors in the schematic or problems with the layout, I'm now "done"

 

Simon

[+Spaced Cowboy]

It's been a while since I posted. Time for an update...

 

• Now that the design is pretty much down, I've been working on the layout. The current layout is below - I have to try and optimize the SDRAM a bit more - there's currently too much disparity between the clock-signal and the slowest signal (bank-address 0, in fact) but it's definitely better than before.
• There's now an op-amp acting as a voltage follower after the resistor ladders on the VGA. The purpose here is to impedance-match the resistor-ladder to the 75R cable to prevent distortion of the voltage on the line. Given that the entire color signal is based on that voltage, it seemed like a good idea for minimal extra parts (1 chip, 1 resistor, 2 caps)

Apart from that I have some silkscreen clean-up to do (always the last thing I do) and having peeked at the other threads recently, having space for a QR-code / Barcode label would be nice

 

Those not into PCB-porn can look away now

 

Still here ? Zoom in, I dare you

 

[_The Doctor__]

beautiful but layer soup! needed another color to keep my head from thinking they running into each other.. or my eyes/ monitor isn't showing a different shade or gradient. hard to say....

[+Spaced Cowboy]

beautiful but layer soup! needed another color to keep my head from thinking they running into each other.. or my eyes/ monitor isn't showing a different shade or gradient. hard to say....

 

 

So I've changed some of the rendering colours - I'm not actually sure if it's any more legible, though. I think separate images per layer are more useful at this point, but I'm not setting up 6 images, you'll have to make do with the composite

[_The Doctor__]

Gorgeous! Got to thank the camera man.

It really made it easier on my tired old eyes

Edited September 23, 2018 by _The Doctor__

[+mytek]

It's beautiful, but the more I look at it, the more my brain hurts .

 

That has got to be the most complicated piece of hardware that will ever be designed for the A8. I'm sure glad that you are the one doing it (and not me), and also I'm sure it will be awesome when released .

 

Fantastic work!

[ivop]

It looks fantastic! All the serpentine routing indeed makes your brain hurt

 

May I ask, which software do you use?

[Geister]

Yeah, I'm curious what the point of all the saw-tooth routing is about. I could make some wild guesses, but I'd most likely be wrong.