Dot-to-dots are a fundamental part of American kiddie culture. Maybe it’s universal; I don’t want to speak to things I know nothing about… (much). But at least here in the US, it’s a typical child’s pastime (or homework busywork to placate parents that don’t want their children wasting their time playing): a piece of paper has a few strategically-placed numbered dots. You fill in the missing information by supplying the path between the dots; the result should reveal an image that wasn’t evident at the start.
I know… an article that starts by describing how to connect the dots must be really stretching for some meaty technical content…
For those of you who haven’t clicked away in disgust (thankfully, not everyone reads the first paragraph critically), there’s a point to this: a dot-to-dot starts with a minimal set of image information. The child provides the missing information – the paths between the dots – thereby transforming it into much more than what it was at the start.
What’s useful about this is that an entire picture can be recreated from only a few essential points, along with some ‘heuristics” or knowledge about how to fill in the missing bits.
Using that logic, SpringSoft’s Siloti is a sophisticated child doing a complex dot-to-dot that it creates itself.
Let’s unwind that a bit to see why.
Simulation can run along at a nominal pace until something goes wrong and you need to debug the problem. In order to do that, you need to dump out much internal information so that you can figure out what was happening under the hood when things went awry.
Question is, what info to dump? You don’t know what’s going wrong; it could be anything. So, hell, why not dump the whole damn thing?
So now you run simulation again, with the dump box checked, painstakingly recording each jot and tittle so that you can then go back in and wade through the morass to find the problem. That can slow things down a lot (by 3x, according to SpringSoft). And the dump files can be ginormous.
To cut down on the scale of the signal dump, you could do an educated guess as to a subset of the signals to record. That would go faster. If you were right, that is. If not, then you’d need to do it again, using a different guess. And maybe again. Which would nullify your clever time savings.
Siloti is a “visibility automation” tool from SpringSoft. Its goal is to provide visibility into the innards of your circuit without requiring a full dump. It does that by identifying a minimal set of essential signals to dump out; it can then recreate the rest.
So the most important question is, what qualifies a node as “essential”? That can vary: it depends on specific signals you may want to view or the scope of the design you’re interested in. At the most simplistic level, it can be all the flip-flop states.
The next obvious question is, given those essential signals, how are the rest reconstructed? That’s determined by behaviors stored in the analysis phase. In the case of flip-flops, it’s simply a matter of evaluating the combinatorial logic between them.
Now, upon hearing this, the test genes in me were immediately expressed and said, “Whoa Nelly. You’re assuming that the combinatorial logic is all working correctly – what if there’s a problem there?” At which point I was gently reminded (I think I actually figured it out myself while in the midst of looking a bit silly by asking the question) that this is simulation, not test. Yes, the logic is all assumed to work correctly. You couldn’t use this for debugging or failure analysis on actual failing devices, since then you couldn’t assume the logic between flip-flops was all working.
This process takes the 3x run time for a full dump and makes it more like a 1.5x run time (where 1x is the simulation time with no dump). The resulting file is about 25% or so of the size of a full dump file.
It actually sounds moderately simple to do this, but, as always, the details of making it work are where a lot of the value lies. There are two analysis steps that drive this, first to determine the circuit behavior, and then, based on that, to determine the essential signals. In addition, much of the simulation work is done at the gate- or netlist-level; users want to see the results at the RTL level. So there’s a fair bit of futzing required to make that correlation. In particular, where the synthesis tool creates new nodes, you’ve got signals that may get reported that don’t exist in the RTL. Siloti needs to reconcile that.
And that’s where a part of the news comes in. There’s a fair bit of work that’s been required to get a design ready for a debug session. You have to generate the various files that encapsulate the structure and behavior of the design; those are combined with the actual output results of the essential signals to provide the full picture to the Verdi Debug tool.
Up to now, there have been a couple of suboptimal things going on here: first, the work to prep the design for debugging had to be repeated for each session, even if the design hadn’t changed. Second, Siloti and Verdi were actually pretty independent: you had to switch back and forth between them to make this all work.
With the new release, the analysis results are persistent and can be used from session to session. You simply compile each new design version as you check it in, and those results are reusable. SpringSoft claims that this speeds up the prep time by 10x. In addition, Verdi and Siloti are now more tightly integrated. They share the same GUI, and Siloti operates more in the background, providing services to the Verdi tool.
All of this new feature stuff can’t hide the true nature of Siloti, however. The analysis simply creates a set of essential dots, which Siloti then connects after simulation.
It’s simply a big electronic dot-to-dot. Sheesh, I bet even a kindergartener could do it.
More info: SpringSoft Siloti
