Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Announcements
Need Forum Guidance? Click here

Search our FPGA Knowledge Articles here.
19199 Discussions

invalid data received when communicating over ULPI bus

Altera_Forum
Honored Contributor II
1,006 Views

I have implemented simple FPGA-design that tries to read vid/pid register from ULPI PHY presented on DECA board over ULPI bus. 

 

But unfortunately my project is not working correctly. I am able to read only VID_LOW (address 0). See attached ulpi.png file. When I try to read value of other VID_HIGH, PID_HIGH and PID_LOW, I am still receiving value of VID_LOW. Do you have any idea what can be cause of such behaviour? 

 

Another anomaly that I noticed is that usb_ulpi_nxt is set on the same tick as I put usb_ulpi_data. As far as I understand from ulpi_doc_timing.png usb_ulpi_nxt bit should be set on the second tick after start of usb_ulpi_data transmission from us. This is very strange for me that usb_ulpi_nxt is set on the same tick as data started to be streamed from usb_ulpi_data.
0 Kudos
2 Replies
Altera_Forum
Honored Contributor II
107 Views

Hi, 

 

--- Quote Start ---  

// High level of dir means that PHY transmitting, otherwise it is waiting for data from us. 

assign ulpi_in_w = usb_ulpi_dir ? usb_ulpi_data : 8'b0; 

assign usb_ulpi_data = usb_ulpi_dir ? 8'bZ : ulpi_out_w; 

 

--- Quote End ---  

 

Here “ulpi_in_w” will have either 8’bZ or 8’b0 and that will update the “ulpi_value” which decides VID_HIGH, PID_HIGH and PID_LOW, VID_LOW as in the following instantiation, 

.ulpi_in(ulpi_in_w),--- > ulpi_value <= ulpi_in; ----> .ulpi_value(ulpi_value), ---> ulpi_value 

case (ulpi_reg) REG_VID_LOW: begin vid <= ulpi_value; ulpi_reg <= REG_VID_HIGH; end REG_VID_HIGH: begin vid <= (ulpi_value << 8) | vid; ulpi_reg <= REG_PID_LOW; end REG_PID_LOW: begin pid <= ulpi_value; ulpi_reg <= REG_PID_HIGH; end REG_PID_HIGH: begin pid <= (ulpi_value << 8) | pid; request <= 0; state <= IDLE; end endcase 

 

 

 

 

--- Quote Start ---  

Another anomaly that I noticed is that usb_ulpi_nxt is set on the same tick as I put usb_ulpi_data. As far as I understand from ulpi_doc_timing.png usb_ulpi_nxt bit should be set on the second tick after start of usb_ulpi_data transmission from us. This is very strange for me that usb_ulpi_nxt is set on the same tick as data started to be streamed from usb_ulpi_data. 

--- Quote End ---  

 

Check design code again. 

 

Best Regards 

Vikas Jathar  

(This message was posted on behalf of Intel Corporation)
Altera_Forum
Honored Contributor II
107 Views

Actually the problem appeared to be that I handled usb_ulpi_nxt too soon. Somehow it usb_ulpi_nxt started being active on the same clock front as I start usb_ulpi_data transmit. I think this is probably due to usb_ulpi_data are changed with some T_setup_time and usb_ulpi_nxt is checked with some T_clock_to_output time. It started working after I introduced one more state to delay usb_ulpi_nxt checking one tick later.

Reply