One problem I encountered in the last 4 weeks is the ULPI Data bus in the out direction not would not meet setup and hold requirements during some builds of the EDK project I was using as a test bench.
When the Sp605 development board running test firmware emulating a mass storage device was plugged into a PC it would not enumerate. Looking at the Lecroy Voyager traces, I could see that bit 7 of the ULPI data bus was getting flipped at times corrupting the returned descriptors and thus making the PC reject the device. After consulting with a Xilinx FAE, it appeared that the ULPI Data Out registers were not being placed into I/O Pin registers when timing would fail. I was about to spend the day learning the details of Xilinx constraints, when it occurred to me that I have not had this problem in 10 years with the EDK. I went back to my old MPD file for my old core and compared the ULPI section to my new core's ULPI section and found that the syntax was different. The old format seems to work every time, the new format may not. The successful format is shown below. (It is all one line, sandvox is wrapping it)
PORT ulpi_data = "", DIR = IO, VEC = [7:0], ENABLE = SINGLE, THREE_STATE = TRUE, TRI_I = ULPI_Data_I, TRI_O = ULPI_Data_O, TRI_T = ULPI_Data_T
With the EDK, bidirectional buses are only implemented at the edge of the EDK system. I actually don't have a port called ulpi_data[7:0] in my wrapper code, the EDK constructs it for me from the 3 ports ulpi_data_I, ulpi_data_O, and ulpi_data_T where ulpi_data_T is the tristate control, in my case I use ulpi_dir as ulpi_data_T.