Posted by Richard Solomon on May 16, 2017
Ok, so maybe that’s not the 6P’s (or 5P’s or 7P’s depending on where you first learned it) most folks may be familiar with, but it seemed pretty proper for a performance posting…plus someone said Solomon is a serious sucker for alliterations! (Hey, now that I can no longer make IDF jokes, you just KNEW I was going to have to find another outlet!)
Hopefully you read my previous performance posting pertaining to PCIe bandwidth (ok, ok, I’ll stop with the alliterations now) so you’re already familiar with the basics of PCIe bandwidth provisioning. That’s what one might think of as the first-order effect on bandwidth – you’ve got to have the right link speed and width (number of lanes) to be able to even approach your bandwidth target. However, as I mentioned in that posting, there are “many factors which can come into play” and affect whether you can get close enough to that upper bandwidth number. So what are those “many factors” and how can you measure or control them to get the results you want?
Probably the second order effect on bandwidth is the maximum packet size (Max_Payload_Size in PCIe-speak) *BUT* for most designers that is out of their control. When two PCIe components are communicating, the Max_Payload_Size (MPS) that is used has to be the minimum of their two capabilities – and the folks who build mainstream root complexes have said (and shown) time and time again, that they’re not going to support particularly large MPS. Typically that means at most 256-bytes – which for an old-time storage guy like me is just painful (disk drives, remember those spinning things?, really liked 512-byte or 4KB blocks, so aligning MPS with them would have been ideal).
After that you’re into things like the number of outstanding transactions (related to “tags” in PCIe- speak), the number of various PCIe credits you advertise, and things like replay buffer size. All that is “just” protocol effects, before you even get into the efficiency (or lack thereof) of your controller implementation! So how is a PCIe designer to figure all that out?
There are a few choices:
I like option 3 myself 😀 and luckily that’s what Synopsys offers with our PCIe controllers through the coreConsultant tool. I actually think this is one of the coolest but least appreciated things Synopsys offers: the ability for any user to adjust and experiment with all the various parameters – and see what impact they have on performance and area. Not long ago, I did a video on one particular aspect of performance exploration using coreConsultant – hopefully this will give you an idea of the power of the tool.
For those of you going to the PCI-SIG Developers Conference in June, you should absolutely check out a presentation being done by one of my friends and co-workers from our R&D team, Paul Cassidy*. I had the bright idea to expand on the video and go through more of those “many factors“, but I needed some help putting together the actual simulation data, so I roped Paul into helping…. Somehow, probably before he even knew what was happening, I had sort of, well, co-opted Paul completely and turned it all into his project! (Please come to the presentation on Day One – Wednesday, June 7, 2017 at 3:30pm in Track 3, so Paul may someday forgive me.)
3:30 pm – 4:30 pm (3) Performance Tuning PCIe Systems
I’m extremely pleased with how the whole thing turned out, so I think you’ll find it very interesting – regardless of whether you’re a Synopsys customer or not. Paul’s material is applicable to *any* PCI Express system – he just used coreConsultant and our performance simulations to show the effects of those various parameters on measured performance. If you’re using your own (or heaven forbid a competitor’s) PCI Express interface, you should still be able to take away some valuable performance tuning tips – you just won’t get the easy adjustment and nice graphical performance reports that coreConsultant provides.
So please mark your calendars for June 7-8 and stop by the Synopsys booth to say “Hi” to Scott and me if you can. Until then, please subscribe to ExpressYourself by clicking here for RSS or here for email so you don’t miss any future episodes.
*Fair warning: Paul speaks actual English, but don’t worry, his American is pretty darn good too 😀
I’ve been involved in the development of PCI chips dating back to the NCR 53C810 and pre-1.0 versions of the PCI spec so have definitely lived the evolution of PCI Express and PCI since the very beginning! Over the years I have worked on variations of PCI, eventually moving on to architecting and leading the development of the PCI Express and PCI-X interface cores used in LSI’s line of storage RAID controller chips. For the last ten plus years I've also had the honor of serving on the PCI-SIG Board of Directors and holding a variety of officer positions. I am still involved in PCI-SIG workgroups and I present at many PCI-SIG events around the world. Back before the dawn of PCI, I received my B.S.E.E. from Rice University, and hold over two dozen U.S. Patents, many of which relate to PCI technology.