Jump to content

Photo

To infinity and beyond... (new hardware)


110 replies to this topic

#101 Spaced Cowboy OFFLINE  

Spaced Cowboy

    Chopper Commander

  • Topic Starter
  • 206 posts
  • Location:San Jose, CA

Posted Fri Jul 27, 2018 5:46 PM

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

lcd-to-vga.png


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
 

vga-circuit-layout.png


Simon.

#102 Spaced Cowboy OFFLINE  

Spaced Cowboy

    Chopper Commander

  • Topic Starter
  • 206 posts
  • Location:San Jose, CA

Posted Thu Aug 2, 2018 9:44 AM

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)
 


xio-routed-almost-complete.png


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

xio-ground-plane.png


And the power plane looks like:
 

xio-power-plane.png



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.



#103 Spaced Cowboy OFFLINE  

Spaced Cowboy

    Chopper Commander

  • Topic Starter
  • 206 posts
  • Location:San Jose, CA

Posted Sun Aug 5, 2018 9:59 PM

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. 
 

layout-pre-design-review-2.png


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 :)



#104 Spaced Cowboy OFFLINE  

Spaced Cowboy

    Chopper Commander

  • Topic Starter
  • 206 posts
  • Location:San Jose, CA

Posted Wed Aug 8, 2018 8:16 AM

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.


#105 Dropcheck OFFLINE  

Dropcheck

    Stargunner

  • 1,236 posts
  • Location:Stigler, OK

Posted Wed Aug 8, 2018 1:58 PM

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?  ;-) 



#106 Spaced Cowboy OFFLINE  

Spaced Cowboy

    Chopper Commander

  • Topic Starter
  • 206 posts
  • Location:San Jose, CA

Posted Wed Aug 8, 2018 3:21 PM

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.


#107 mytek OFFLINE  

mytek

    River Patroller

  • 2,821 posts
  • Location:Santa Rosa, CA

Posted Wed Aug 8, 2018 6:38 PM

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 :) .



#108 _The Doctor__ OFFLINE  

_The Doctor__

    River Patroller

  • 4,505 posts
  • Location:10-0-11-00:02

Posted Wed Aug 8, 2018 10:05 PM

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.



#109 Dropcheck OFFLINE  

Dropcheck

    Stargunner

  • 1,236 posts
  • Location:Stigler, OK

Posted Thu Aug 9, 2018 2:31 PM

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. :)



#110 Spaced Cowboy OFFLINE  

Spaced Cowboy

    Chopper Commander

  • Topic Starter
  • 206 posts
  • Location:San Jose, CA

Posted Fri Aug 10, 2018 11:12 PM

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]



#111 Spaced Cowboy OFFLINE  

Spaced Cowboy

    Chopper Commander

  • Topic Starter
  • 206 posts
  • Location:San Jose, CA

Posted Yesterday, 5:57 PM

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:
 
 

xio2-s25-stm32h7.png


 

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.






1 user(s) are browsing this forum

0 members, 1 guests, 0 anonymous users