This is the good news: Xillybus is now supporting Altera FPGAs having the hard IP transceiver for PCI Express (and other Gigabit interfaces). If you’re into PCI Express, and into a fairly recent project, odds are that your device is on the list.
There is, of course, the possibility to handle the Avalon-ST interface by yourself, with its quirky Endianess issues. The payload is Endian swapped, the header isn’t.
Or its “interesting” alignment of DWords in QWords, making it Avalon compatible, but also opens an opportunity for exotic bugs in getting the payload data right. And is it only me not being very fond of the delay of three clock cycles between deasserting rx_st_ready and rx_st_valid going low? That kind-of forced me to put a FIFO inbetween. When I can’t get more data, I can’t. Period. And just to play completely unfair, the application logic may deassert tx_st_valid, but not in the middle of a TLP. So much for flow control. They call it readyLatency, but I call it practically no flow control.
This is not to say that the Altera’s PCIe core is bad. It just has its little corners. As has PCI Express itself: Minding the credits for incoming read request completions is something one can’t get away from: In theory, it should have been the data link layer’s work, but since it’s forced to announce infinite credits on completions to unposted requests, user logic must make sure the completion buffers don’t overflow.
Having the user logic aware of max_payload_size and the maximal read request size is just another little detail to handle. Not to mention the need to know our bus and device number (the function is always zero. Shhh.). The chosen implementation for retrieving this information (a.k.a. the “Configuration space signals”) could have been easier and less confusing to handle. The tl_cfg_add, tl_cfg_ctl, tl_cfg_ctl_wr, tl_cfg_sts and tl_cfg_sts_wr are documented in a somewhat confusing manner, and it’s not always 100% clear what information is where.
And I haven’t even started with the PCI Express protocol itself. Not to mention the host driver, in particular if it’s for Windows.
So indeed, Xillybus is good news.
Please post questions and comments here. No registration is required. The comment section below is closed, since comments to posts like this one tend to turn into Q&A.