Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
15539 Discussions

Strange code behavior, once it works, once not.

Honored Contributor II



Quartus version: Quartus Prime 17.1 Lite Edition 

OS: Linux Ubuntu 16.04 

platform: DECA by Arrow Development Tools (MAX10) 

project: USB audio card. FPGA is interfacing USB via TUSB1210 (ULPI interface). DAC side not touched yet, it's not a problem right now. 



problem: once USB speed handshake works properly, 'dmesg' command outputs "[ 650.148030] usb 2-1.1: new high-speed USB device number 11 using ehci-pci" so hurray. 


But, i.e. when I am adding new register to the top/endpoint_ctrl.v FSM (i. e. to send more than 1 byte in answer to the "GET_STATUS" request), handshake fails(!) and FSM 

in usb_handshake_multiplexer.v is stuck on DETECT_K or DETECT_J state after reset. Sometimes the same happens with uncommented LED outputs. 


tldr; main problem: sometimes it works ok, sometimes I modify module "A", and it causes problems in module "B", but module "B" hangs on few first states when state of 

module "A" is not important.  


Testbenches do not show anything abnormal. Design simulates as intended. Times are not violated (but, well, there are unconstrained paths). 

Maybe I have a clue - I could not communicate with tusb1210 as it is written in ULPI standard. To write to tusb1210 register, I had to make some hacks (i.e. register 

usb_stupid_test in top/ULPI.v), what is ridiculous, but after this hack it finally started to work (for few days...). And I've tested ULPI.v on hardware (writing to "draft/test" 

register values which increments by 1 per 0.2s and read it back - on LEDS it has shown nice and normal counter). 


What can I do wrong? Has anyone had such a problems? It is my first project with verilog and altera, I had not such issues with VHDL on another, non-altera platform. 

Maybe some input/output port constraints (except pin locations)? 


When I've been working on this project this bugs with hanging on some strange states happened frequently. Solution was to write as not complicated code, as possible, 

but now, I don't know what to do. Turning off optimisations has not helped.  


I will be very grateful for a help. I just spent to much time on this project and, because of other interests, I am thinking (sadly) about giving up. 


With regards, 

0 Kudos
1 Reply
Honored Contributor II

Timing violations seems to be the reason.  


I've copied constraints from another DECA example project, and I've changed optimization settings to "aggressive performance" and now after adding additional register I still have high-speed on 'dmesg' output. So it seems that I should constrain design more.