Xeon phi workstation configuration

Xeon phi workstation configuration


Hi ,

I have a question regarding to the workstation configuration of the Xeon phi coprocessor.

Is it possible to have Xeon phi coprocessor workstation configuration without Xeon CPU? In other words is it necessary to have a Xeon CPU as a host in workstation configuration?



12 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

You can't boot a Xeon Phi without a host CPU.


Yes, I know. But my question is, should the Host CPU be "Xeon"? 

Is it possible to boot and to use "Xeon phi coprocessor" with other intel CPUs or AMD, or  even ARM?

Your usual requirements will be a Linux or Windows host processor, Intel64 architecture, and a motherboard BIOS that supports Large Block addressing for PCIe devices (larger than 4GB window).

Someone else (or web search) may indicate if AMD64 is compatible enough to run MPSS.

Jim Dempsey


Thank you Jim,

How about ARM CPU as a host?

Currently I am using a system with ARM CPU which it supports PCIe root complex. It also supports Large Block 64-bit addressing for PCIe devices (larger than 4GB window). It would be wonderful if I could boot and run Xeon Phi coprocessor in this system.

I have to mentioned that my ARM system is working with Linux Ubuntu. Is it possible to run MPSS in Linux Ubuntu?

The problems you will encounter are:

Generally host MPSS is required, however you can make a Linux image and follow some documented rules to boot load over the PCIe. You will have a lot of work on your hands (easier to buy a system).

The second issue is compiling the code to run within the MIC. You'd have to come up with that.

MPSS can run on Ubuntu on Intel64. As to if this can run on ARM, you are on your own.

What is your objection for building a system using supported components? CPU, motherboard, RAM, box, power supply, if you are really tight you might be able to do this for $1000 (Xeon Phi extra).



The problem arises when one needs to have direct access to the “Xeon phi coprocessor”. Actually, I am interested in feeding data directly from FPGA to the “Xeon phi coprocessor” and vice versa. This is the case that I want to find the possible solution. I am currently using ZYNQ soc. ZYNQ incorporates a dual core ARM Cortex-A9 and Xilinx FPGA in a single device. The “PCI root complex” IP could fit inside the FPGA. I am thinking of the  possibility of booting and running “Xeon phi coprocessor” with ZYNQ in a Compact Work station without having to use an extra intel64+motherboard+ etc. I understand that it is a difficult task and requires a lot of work and maybe it is impossible because of driver issues, compiler issues etc. However, I am interested to find out, from hardware point of view, whether booting and running the "xeon phi" with ZYNQ is possible or not. Also, I want to understand how difficult it is to prepare required driver, and solve the compiler issues, etc. If it is impossible, I have to think about a work station with “xeon”+”xeon phi”+”ZYNQ”. In this case the challenge is again feeding “FPGA” directly from/to “Xeon phi coprocessor” as it is mentioned in following link:


Please let me know your comments and suggestions.

There are a few posts here on users that are building custom versions of Linux to run inside the MIC. You might want to start there as you will likely require your own customized version of Linux for running on the MIC. In particular, take note of how they load the boot image, you should be able to do this on your system in a similar manner (and it could include your program). You will also need to implement your own set of MIC-to-Host drivers (derivatives of those in the MIC SDK). You need at least the virtual NIC in addition to your FPGA driver.

Nothing is impossible, some things are much harder than others.

Have you thought of using something like a PCIe bridge? IOW connect your ZYNQ directly to the PCIe of a different system.

Jim Dempsey


Sorry for my late reply,

I don't understand your question when you talk about "PCIe of a different system". Zynq  includes an Integrated Block for PCI that can be configured as an Endpoint or Root Port, compliant to the PCI Express Base Specification Revision 2.1. The Root Port can be used to build the basis for a compatible Root Complex, to allow custom communication between the Zynq and other devices via the PCI Express protocol.  As I understand Xeon phi designed as a Endpoint. The root complex IP could be locate inside the FPGA of ZYNQ. To do this "UG4777 Series FPGAs Integrated Block v1.3 for PCI Express User Guide" explained the details.

Look at http://www.plxtech.com/products/expresslane/techinfo it has some videos and a series of white papers on PCIe bridges as switches. While this may or may not solve your problem, it will at least give you some ideas. You might ask them if they have a pre-sales department where you can ask technical questions as to how they might help solve your problem.

Jim Dempsey

Jim is correct: this generation of Xeon Phi products are PCIe compatible. From a purely hardware perspective, Xeon Phi should act like a PCIe endpoint.

I am aware of one example where a Xeon Phi does not have another local CPU. As one might expect, this does required quite a bit of custom engineering both in hardware and software. Take a look at the "Booster" component of the DEEP project at FZ- Juelich in Germany. The DEEP project is pretty well documented if you search, but here is a link on the "Booster." http://www.deep-project.eu/SharedDocs/Meldungen/DEEP-PROJECT/EN/News/status-summer-2014.html.


One of the major issues you will face is reducing the cycle time of software development especially with respect to having two or three systems involved. ZYNQ, what you place inside the MIC and what you use to develop the software for the MIC. Debugging is another issue.

One option is to use a Intel64 platform, without MIC, to "cross compile" the native code to run in the MIC. Then somehow get the code over to the ZYNQ system (Ethernet, NAS, thumb drive, etc...). Combine the cross-compiled code into MIC Linux boot image (there is information available on how to do this). Then (here is where you are on your own), emulate on the ZYNQ what is done on the PC platform to inject the boot image into the MIC. Here I mean "emulate" as follow similar sequences as performed on the PC platform. This too I think is documented (though I do not have a link reference for you to follow).

The problem with the above is your software development cycle is extended appreciably.

Using a PCIe bridge(like) setup will not only remove the bottleneck but will also provide easier access for debugging an tuning analysis. It may also reduce a requirement of an extra MIC. I am not saying you will have an easy chore to integrate a system as a cluster of ZYNQ+MIC+Intel64. Some searching on the internet may find someone that has already done something like this.

One of the biggest problems you may have to overcome are any prejudices you have developed to get to the point where you are at now. IOW sometimes you encounter a fork in the road(plan) that you hadn't anticipated. And in order to progress you may need to change directions.

Jim Dempsey

Leave a Comment

Please sign in to add a comment. Not a member? Join today