Over in one of our sister pubs, we did a review of some of the challenges of DDR last year. In particular, DDR3 has some incredible timing subtleties that have to be managed. DDR controllers are available as IP for FPGAs, but they still have to be connected to the memories on the board. And those board connections can seriously affect whether or not the timing requirements of the DDR protocols are properly met.
Mentor has just announced new versions of their HyperLynx PI and SI board power integrity products, and the SI one has a briefly-mentioned little feature that I got to see in action at DesignCon; apparently they’re finding that this “oh and by the way” thing is much more than a trivial add-on. It’s a wizard that allows you to specify how you’ve configured your DDR controller and then check out whether the timing passes muster. It can handle DDR, DDR2, and DDR3. A lot of the popularity seems to be with FPGA applications (although it can be used with other controllers as well). Granted, this is a board design tool, but this is where board meets FPGA.
It’s hooked into the board/FPGA layout information so that much of the laborious entering of pins and other information can be done by the tool (allowing manual override, of course). As we’ll talk about more later on, it’s primarily the setup that has been wizardized; the results, well, not so much.
The wizard starts by asking for the controller and DRAMs from a pick-list. For the verification to work, you have to have IBIS models in place for both the FPGA and DRAMs; the wizard will confirm this, and, if there’s a problem, you can fix it from the wizard. Next you identify which events (read, write) you want to simulate.
At this point, the tool auto-IDs all of the nets, as long as standard naming schemes have been followed. If they haven’t been, you can find and assign the nets manually. Having specified the nets, you can then decide which ones to simulate. Apparently, running all nets can take an hour or so, so for the first time it’s recommended that you do just one net so that you can run the “audit” that makes sure everything works. Once the process is clean on one net, you can do more (or all).
When doing this verification, the main difference between DDR and DDR2 from a setup standpoint is that DDR2 allows on-die termination (ODT), so there are some choices that have to be made there. You need to pick a model to be used when ODT is on and one to use when ODT is off. You can actually set this on one of the memories and then have the setting automatically copied to the other memories, given the likelihood that all your memories are the same.
The actual real-time use of ODT can vary; it can be turned on and off depending on the event or whether a signal is driving or receiving. The simulator takes care of this, but you also need to specify how to do that. Apparently Micron Technologies has come up with a scheme that might be considered a “best practices” approach based on a lot of experimentation, and this scheme is chosen as the default. But it can be overridden if you want something different.
Next you pick timing models; defaults are provided by the tool, chosen based on the speed grade of the memory chosen. On the DRAM side, it’s generally best to stick to the JEDEC models so that any JEDEC-compliant memory will work. But there is much more variation amongst controllers, so here’s where you need to pay more attention.
They provide a waveform view of a model if you want to see it, but – get this – evidently, making a change to a waveform and having that change automatically annotated in a Verilog model is covered by some patent somewhere, so they can’t do that. Instead they can take you to the Verilog, where you can type in the desired timing – which can then be reflected in the viewed waveform. While the model is expressed using the Verilog language, it’s done in a way that’s proprietary to Mentor.
If you’re verifying DDR3, you have to deal with write leveling, which, at least on the surface of it, seems like the toughest part of the timing to get right. This challenge would appear to be greatly reduced since the wizard reports back what it considers to be the optimal write-leveling delays. Alternatively, if you have your own timing already in place, then it will report back the difference between your timing and what it considers to be optimal.
Finally, you specify how to simulate, picking from such options as whether to include crosstalk, which corners to run, limits, etc. Each signal is simulated alone, and, if crosstalk is included, then neighboring aggressor lines are determined from the layout and exercised to measure their impact on the line being simulated. While no specific crosstalk report is generated, the effects are included in the overall verification (if, of course, the crosstalk feature line item has been licensed in the underlying tool).
And now an “audit” can be run, followed by the actual simulations if everything checks out. The output of the simulation is a series of spreadsheet files as well as waveform files. You have several choices of spreadsheet to look at, such as all address/data signals; worst-case signals; and all signals that violate timing, with timing numbers highlighted in red. Given any failures, you can look to the waveforms for the problems, as well as for any glitches that don’t show up as timing violations.
Once you’ve started the simulation, you’re done with the wizard. And this is where further wizardization might have been nice, since it takes a bit more knowledge to select the most relevant of the many spreadsheet files, interpret the numbers, and decide what to do with them. Some of that knowledge, rather than being written up in ap notes or whatever, could actually be worked into the wizard to make the problems easier to find and resolve.
Still, all in all, what has been automated relieves the verification engineer of a lot of the drudgery of setting up the simulation and seems to make good use of the information to which it has access (like the libraries and layout information). This little utility seems to be attracting as much user attention as the rest of the upgrades in the latest release. It may well steal the show, as FPGA designers and others look for help in managing the tricky DDR timing.
