Debian 7.2 and OpenCPI

A client of ours using OpenCPI had selected the Debian flavor of Linux for their work. That's fine. Certainly in the FPGA space, and for that matter, across all processor technologies, we have tried not to dictate any particular Linux. That said, the developers had added support for RedHat, CentOS, and MacOS from the ancient times. More recently Ubuntu was added into the mix. And just yesterday, with this commit, we dealt with Debian. It's interesting seeing the subtle, and not-so-subtle, differences across a dozen different Linux distributions.

OCP-IP move to Accellera

We're cautiously optimistic, maybe even excited, about the news that went public yesterday of OCP-IP being rolled into Accellera's warm arms. We have participated in technical issues for both; but very much like that Accellera is a proven conduit to IEEE standardization. Open and accessible standards are a good thing. Time will tell, but out of the gate we are pleased that our man years of investment into the OpenCPI Worker Interface Profiles (WIPs), which often incorporate OCP-IP concepts, can live on. Come see us at FPGA-2014 in Monterey to understand why, years later, we still feel the OCP/AXI choice is like Coke and Pepsi.

Ubuntu 13.04 and OpenCPI

We've been using RHEL as our standard Linux for over five years. Initially RHEL5 64b WS, then RHEL6. On the plus side, RHEL is almost always embraced by our CAD and CAE tool vendors as a supported OS. On the minus side, the libraries are as old as the hills and we really weren't feeling the love of sending $200/machine-image/year to Red Hat for this configuration grief. We had noodled in earlier versions of Ubuntu and had some mixed feelings. With Ubuntu 13.04 this past summer, I tried it again and it was just great: everything "just worked". We didn't even have to muck around with GPU drivers. What used to be a half day project of dependency-hell installed in one apt-get. Wow! I don't think of us as OS-bigots; but the understandable contrast between the library hassles we had with something as old as RHEL5 and didn't have with an OS as modern as Ubuntu 13.04 was just too much to overlook. We've started to let our RHEL licenses lapse; just keeping around a few frozen RHEL5s and one maintained RHEL6 so we have them in shop. But unless a client or application needs some other Linux; it's Ubuntu 13.04 in our shop this fall and going forward.

Jim Kulp at Parera did us all a solid by refreshing the OpenCPI mainline to build cleanly to Ubuntu 13.04 as well. Nice! He pushed those changes to the OpenCPI GitHub repo this evening. Thanks Jim!

Port Mirroring

We have FPGAs carrying on conversations with other FPGAs all the time. Frequently we use layer 2 Ethernet between known devices on a LAN, although we are working our way up to layer 3. Wireshark is a go-to tool to see what is going on and share pcap captures with our colleagues. But how do you see the traffic between two FPGAs on a LAN when they are talking to each other? Port Mirroring!

We had been playing all kinds of games before we found this little gem: the Netgear GS105E. $60 to Amazon, a dorky Windows configuration dance, and we feel we've found just the ticket for our packet capture needs. We set ours up to only mirror the ingress from ports 1 and 2 to port 5. We plug our chatty FPGA board into ports 1 and 2 and anything running Wireshark into port 5. Ta dah. No more sending broadcast packets just to see what is going on!

4DSP FMC116

We have used 4DSP products before. We recommend them to clients. We've evaluated several different models and liked the FMC150 so much, we purchased one to keep. We recently had the chance to work with the FMC116, a 16 channel, 125 MSPS FMC module. We were happy, but not surprised, that it took less than a day to bring up in our lab. This is using their supplied user guide; but our own, homegrown BSV codes. I would not want to say that operationalizing any FMC module is easy; but through the work and doc 4DSP put into this quality product, ... it was! Thanks Pierrick and team!!!

4DSP FMC116 On bench

Vivado 2013.1 / ISE 14.5

Xilinx shipped Vivado 2013.1 last week. If the engineering design and verification community needed any validation that "FPGA CAD Tools are closing ground on their ASIC centric brethren", Vivado is an excellent example. We see so much runway and room to grow here that we've been making proactive investments around nascent aspects of Vivado, such as IP Integrator (IPI). Our efforts in this regard were mentioned in this press release.

While most of our clients are in the heart of design cycles with 28nm silicon; we are also supporting a user base with legacy silicon, particularly Xilinx 6-series, such as the olde-timey, four year old,  ML605 platform. To this end, ISE has bumped from 14.4 to 14.5. We are progressing through our regression tests for OpenCPI and others without drama.

Component Based Design

We've been working with beta versions of Vivado IP Integrator from Xilinx. Taken at baseline, this is a fine way to compose component assemblies of IP. Out of the box, graphically, it feels like a grown-up System Generator for the masses, not just for DSP.

The choice of an industry standard for component metadata, IP-XACT, helps strengthen the value-proposition. (Disclosure: We are observers on the Accellera Technical Committee).

Perhaps our greatest excitement for this technology is the ability to package our own and our client's IP components. In this manner, they too become first-class citizens in an IP catalog standing alongside the IP catalogs of others.

We would be careful about using phrases like "Correct by Construction" or "Plug and Play". But the fact is that well-defined interfaces with strong guards and type-checking help the situation.

Vivado 2012.4 Digilent USB/JTAG with RHEL6 64b

Getting the Digilent bits to work properly with Vivado 2012.4 with RHEL6 64b can be a bit of a dance. Clear webcase reporting to Xilinx is the best way to help drive this issue to ground. Here at AR Auburn, we have refined our procedure for the delta on top of the vanilla 2012.4 install:

Follow the AR42728 . Note that it is now applicable to 14.4/2012.4. The current version of libusb at this writing is 1.0.9, no big deal.

For the next steps, take all the default options...

• cd to /opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/digilent
• cd to /digilent.adept.runtime_2.9.9-x86_64, run the install script with root permission
• cd to /ftdi.drivers_1.0.4-x86_64, run the install script with root permission
• cd to /libCseDigilent_2.2.10-x86_64, run the install script without root permission

We have found this gets us user (non-root) access for both impact and xsdk with the KC705, VC707, and ZedBoard. If it doesn't work for you, well, there should be a webcase in your future.

Update 2013-06-11: Be sure to look at the updated Xilinx Answer record AR54382. With Vivado 2013.2 just about out the door, this is where you want to start to get your hardware session straight!

Vivado 2012.4

For three weeks now we have been all over Xilinx' release of Vivado 2012.4 . We are excited about this release for several reasons. We have been using 28nm 7-series silicon for sometime with the KC705 and VC707 TDPs; and soon we will increase Zynq's participation in the mix. Although only in beta test at this point, the rapidly maturing functionality of IP Integrator got our attention as well. While running native on RHEL6.3 we've seen zero crashes; and love that we can have any mixture of command-line, scripted and GUI build awesomeness.