I just received an email from Michael Dunn, who is working on the FPGA-based Let's Design a Scope project at a sister Website, Scope Junction. The subject line for Michael's email was something along the lines of "I need to rant," which didn't sound very promising. To be honest, my knee-jerk reaction was that I had done something horribly wrong that had raised Michael's ire. (I've been married for a long time, so my Pavlovian response to almost anything is that I've done something horribly wrong.)
Well, you can only imagine my surprise when, upon opening the email, I discovered Michael wanted to rant about the lack of documentation associated with Synopsys Design Constraints (SDC), a constraint specification format used in digital electronic designs. In particular, he wanted to rant about this lack of documentation in the context of FPGA designs.
I've grown used to the fact that most people don't even know how to spell "FPGA," let alone worry about the format of an SDC file. (You may laugh, but Gary Smith, an industry analyst, once told me that a few years ago, a young, enthusiastic, fact-checking editorial assistant at a magazine called him to ask how to spell "EDA.") Anyway, Michael's message read as follows:
Hi Max, do you know of a good source of information for the SDC file? Back when I was trying to learn it via Altera, I couldn't even find any web resources that were useful, which I found somewhat surprising given that SDC is not a new format.
In the case of Altera's documentation, I found this to be next to useless. They spend 10 pages describing -- at kindergarten level -- what really needs only one page, thus "muddling the simple." I'm a digital designer, not a baby, so just tell me the key information I need. Don't throw a million keywords at me without any context, and don't repeat the same simple thing five different ways to account for minor differences.
I've also gone through an Altera slideshow, which was hardly any better.
The main problem with all of these resources, I think, is that they start (and stay) at a low level (not trees; blades of grass), which makes it really hard to see the forest.
In my opinion, this topic needs to be introduced from the top down to be of real use, along the lines of: I have an FPGA system consisting of my HDL, some third-party IP, and some vendor-specific blocks. Now what do I do? At what level do I need to write my SDC file? How do I design my HDL to make it more amenable to SDC? Should I adopt a certain kind of signal-nomenclature, such that it's easier to group and wildcard SDC entries? And so on and so forth.
Now that Xilinx is using SDC also, I want to find time to study their documents. Perhaps less confusion awaits…
OK, rant over.
Hmmm, I'm trying to visualize this through the eyes of a beginner. What would you recommend in the way of FPGA-centric SDC documentation that is short, sharp, and succinct while being easy to read and understand?
Alternatively, we could create our own "All Programmable Planet Quick-Start Guide to SDC." All we need is someone to volunteer to write it.
Max, you had a good opinion about your married life, that's why you just responded like that (grin). I think there should be good clarity in any document prepared for beginners, starting from basic level. In most of the cases, it seems that most of the documents attaching with boards, devices or products are suited only for experts.
For XDC, or ucf? For ucf, the forum post list the place to start (my blog), for XDC, I have said all that I can for now. If you are an early adopter, and in beta trial with Vivado, contact your local FAE, as they were just trained last week.
I plan a multi-part blog on XDC once evrything is sorted out, and released.
I did the 5 part timing blog awhile back, and it got an amazing number of views, and is still something I refer people to even today. But, it will need to be completely re-done now that we have the new xdc constraints.
Some constraints convert almost trivially to the new system, wheras others do not (for example, in xdc, all clocks are considered related, until otherwise specified not, where with ucf all clocks are independent, until specified related...)
So, for those just learning how to properly constrain their designs, right now is a particularly bad time to be doing so, as everything you are trying to do in the ucf format will have to be redone in the xdc format.
Good news is that there are new Tcl commands to read in the old ucf file, and convert it to the xdc file, and write it back out. Although not promoted, nor documented, if I am trying to do useful work right now, and will have to change, this is a real useful thing to have! If anyone needs details on this feature, email me, or contact me through my blog, or the forums, forums.xilinx.com.
I am an engineer, after all is said and done, and not a marketeer, so I really don't appreciate (nor understand) the resistance to make these d**ned useful little tricks more widely available...