Se ha comentado en la página 290, y como ando con otras cosas no he podido comentarlo todavia. Os pego lo que ha dicho abrasive respecto al chip y al tema del DSP. Asi resumido, se enconró que el fabricante del chip Altera, núcleo-superglu de toda su placa, se dejaba de hacer. Ante esa tesitud se vió en la situación de decidir que hacia, comprar un lote enorme, y hasta que se acabase, cambiar a otro chip compatible, arriesgandose a bugs, o rediseñar la placa. esta última opción ha sido la elegida, siendo la PCB beta diferente de la versión final. Cosa que ha traido el consabido retraso en sus planes.
Obsolescence
Hello! Long time no see! But what a busy time it's been.
First of all, I'd like to apologise for the repeatedly-delayed update. At the moment I've got both a toddler and an exam-season medical student in the house - and it's winter, to boot. This culminated in a fantastic triple-whammy: I got sick, and when I recovered my kid got sick with something else... and then as she recovered she gave me that bug. The latter bug was particularly nasty; it's taken a couple of weeks already and I'm still not running at 100%. But such is life with a little person! And here, finally, is an update. In fact, I've got three updates lined up for you in short succession.
Before I get to today's technical update, I'll talk a little about the more abstract management of the project. It is quite clear that the demands of my everyday life are high, and they're not going to quiet down anytime soon; this runs the risk of pushing the project times further and further out. To combat this, I'm doing something I've never been very good at: I'm asking for help. Working with others on a personal project is very new to me. I've always been the go-it-alone type; back when I was a student and my time and energy were plentiful, that used to work really well. Now I have to think really carefully about where I put my energy. And in my day jobs I've come to see that working with others is not just more effective but can be a real pleasure: seeing skilled people doing good work is a beautiful thing. And I'm delighted to find that some people actually find this project interesting ^_^
So now certain parts of the project have been greatly accelerated, compared to what I could do slogging away on my own. For example, someone's taking care of mechanical design of the cartridge, and looking at design for manufacturability aspects. A professional UX designer is making sure the menu software will actually look great and be a pleasure to use, in contrast to the clunky placeholder I'm using now. And I'm still hoping to find a little more help: for example a skilled Saturn coder could implement the menu design way quicker than I could. I'll talk more about the progress these areas in my next couple of updates; today, though, I'm going to cover a piece of work I had to do on my own.
Obsolescence
Quite some time ago - almost a year, in fact - a little trouble popped up on the horizon. It looked like this:
To decode this somewhat cryptic form of trouble: the Altera CPLD that glues the Satiator together was being discontinued, and I'd no longer be able to buy them after February 2018. This left me with two choices: either buy up enough chips to make every Satiator the world will ever need, or change the design to use a different chip. The former option requires a lot of cash on hand as well as the ability to predict pretty well how many people will ever want a Satiator... neither of which I had. So I figured I'd change the chip later, and forgot about it for the time being. It wasn't holding up my other dev work so I just kept on plugging.
Now, as I'm pulling things together to get beta units out, I decided it's a great time to do the work and change the chip over. Beta means getting some serious testing happening on multiple consoles and with a whole range of games, which will take a lot of effort and time. I could do that with the Altera chip - I did buy enough to cover the beta! - but what if the chip change introduces a new issue? I might not find out until going to production, which could be a very expensive mistake indeed. That's why I decided I'd rather work out the new design now, so that it can be tested as intensively as possible. (It also means that, barring any unforeseen misadventures, the beta users' hardware will be able to accept firmware updates for the production units in the future.)
Refreshing
Having decided to replace the Altera CPLD, what to replace it with? CPLDs are a type of programmable system, but rather than running instructions one after the other - like a CPU - they implement a set of logical relations at the same time, like wiring a bunch of AND, OR etc. gates together. (They are the simpler, poorer cousin of FPGAs). This makes them good for doing simple things but very fast, whereas CPUs do complex things but more slowly.
The CPLD used here acts as glue to connect the Satiator's brain - a modern ARM microcontroller - with the Saturn's CD Block bus. The ARM has a fast serial link, 1 bit wide and running at 3.3 volts; the Saturn's bus is a 16-bit wide, 5 volt affair. The CPLD essentially acts to bridge the one to the other. The problem isn't overly complicated; most any modern CPLD could do the job. But where it gets tricky is the signal voltages.
Over the years, digital logic has used many different supply voltages. In the vacuum tube and relay eras, voltages were all over the shop; from six volts up to hundreds of volts. With the introduction of more-delicate chips, things settled down a little bit. One of the most enduring standards is 5 volt signalling, which dates from the rise of TTL in the late 1960s. This was still very commonly used all the way through the '90s, including throughout the Saturn; but since then, it's been thoroughly replaced by 3.3 volts and even lower voltages (2.5, 1.8, 1.2...) as systems can waste less power at lower voltages.
I'd originally chosen the Altera MAX 3000A CPLD family precisely because they date from the late '90s: they are designed to handle 5 volt signals, although internally they run on 3.3 volts. Of course, their advanced age is why they're being discontinued! - Intel bought Altera a little while ago, and I think they are cleaning house a bit. 20+ years is a long time to make the same chip in a fast-moving world of configurable logic.
As 5 volt signals have died out, so too have 5 volt CPLDs. There are still a lot that take 3.3 volt signals, though! So one option is to add specialised chips to the design to act as level translators - converting the Saturn's 5 volt signals to 3.3 volts for a modern CPLD, and vice versa. That's not at all impossible; in fact it's exactly what I did in the Drag'n'Derp Game Boy cartridge, so that I could stick a hunk of shiny modern ferroelectric RAM (FRAM) into a 5-volt Game Boy. They're the two long chips at the bottom here:
But that's not the only option. There are still one or two 5V-tolerant CPLDs around! After some poking around I decided to look at a Xilinx XC9500XL series CPLD. These are pretty close in specs to the Altera units... and haven't yet been discontinued. This way I don't need to wedge anything else on the board... in fact, the changes might be pretty minor?
Chop and Change
I quickly reworked the PCB to accommodate the different pin layout of the chip - luckily most of the pins are configurable so it's nothing too complicated. Here, spot the difference:
Pretty much the only obvious change is the colour! My board house turns around green faster than the other colours, and I didn't want to wait. (I also got rid of some no-longer-needed debug features - more on that in a subsequent post.)
Getting the chip on to the PCB is the first part of the puzzle. The second part is getting my logic programmed in. The thing with CPLDs is that they are basically a configurable chip; they can become whatever logic you need them to be. You start off by specifying your logic in a hardware description language (HDL); here's some of the Satiator's code, written in VHDL:
As you can see, it looks a lot like a regular programming language. In fact, much of the syntax was apparently inherited from Ada. But instead of running the statements one by one, top to bottom, like a regular program - they are considered as if they all happen at once. A bit weird when you get started but after a while it all makes sense.
Once you're happy with your HDL you use special tools provided by your CPLD manufacturer to compile this to a "bitstream" you can burn into the CPLD to make it work - just like firmware. And when I say "special tools", I mean a monolithic behemoth that is capable of doing anything with the dozen chip families that manufacturer makes, and has the classically terrible UI of software that is designed by engineers:
So I downloaded the Xilinx toolchain that I needed. The old Altera toolchain weighed in at a hefty 5.6GB... and the Xilinx one flabs out at 11GB. Oof! (11GB and I get that UI?!)
It took a little bit of faffing about, but I eventually got a sane Makefile-based CLI workflow to build the bitstream; and here, once again, I fired up the tools I wrote ages ago to validate connections and found a data entry error that would have taken hours to find in debugging. Yay for tools!
And finally, I had a bitstream ready to program into the new Xilinx CPLD.
Burning Problems
So! I said to myself. I assembled a board with a Xilinx CPLD, flashed the microcontroller, loaded the bitstream into the CLPD, crossed my fingers, and powered it on -
It got hot.
The CPLD got pretty warm. The board's 3.3 volt regulator got painfully hot. Not hot enough to burn out, sitting on my desk, but... way, way too hot. Uh-oh! Panic! Is something shorted out? Is it a floating input? Is this ever going to work??
I calmed down and got to debugging. There were no short circuits, no misconfigured pins. Getting rid of floating inputs didn't make a dent in the power consumption. I then turned back to the bitstream generation - was there something hiding there? There was.
The new, unfamiliar Xilinx tooling had a number of compile options whose values I had guessed at. In particular, "-power", which had two possible values: "std", or "low". Since "stanard" was obviously the sensible default I picked that. Unfortunately, it was... not a sensible default in this case.
The XC9500XL architecture uses sense amps to do its logic calculations. These involve feeding a bunch of inputs to a common line (via resistors) which is biased to a certain voltage (also via resistors). Depending on the state of the inputs and the line, this wastes a certain amount of power in those resistors. There's a tradeoff here: smaller resistors consume more power, but pull the line around faster, for better performance. That "-power" switch actually controls the resistor values - switching between a fast mode and a slow mode, between high power and low. And I'd inadvertently selected high power mode.
Sense line structure of the CPLD - reproduced from Xilinx XAPP114. R1 and R2 are the power dissipating resistors.
After rebuilding the bitstream with "-power low", my burning problem went away, and I was able to jack it into my Saturn; to my great delight, I was rewarded with a running game straight away, Redbook audio and all. Victory!
Ultimately this was a pretty unsatisfying exercise in engineering. I put in a bunch of work to update the PCB and set up new tooling to generate a new bitstream - and what do I have to show for it? I have a new PCB that looks and functions exactly like the old one, except it has a different part number for one of the chips. I guess that's just engineering in the real world and, in the end, I can be happy that this exercise wasn't more "interesting"! I'm glad my connection checker tooling saved me a few hours once again, too. It's paid for itself many times over.
All right folks, that's all for today! I'll be back in a few days to share some of the delicious UI design that's coming together for the menu. Hopefully I'll be able to say I've found a menu coder too - suggestions welcome! Thanks for following along and thanks as always for your support.
- James
Más imágenes en su post:
https://www.patreon.com/prof_abrasive