ISP 1761 VHDL USB Peripheral Controller Timing Issues

[Altera_Forum]

Hi Altera Forum Members, 

 I am currently Designing on the Terasic DE4 with a Stratix IV EP4SGX230 and Quartus 12.1SP1(formerly just 12.1) for my Master Thesis. I have no experience with the Nios II and am kind of a purist, so I wanted to write a VHDL Controller Core for using the ISP1761 as USB Peripheral. The Chip Controller has got 3 entitys. One HAL managing the Timing specifications, a Configuration Controller, Configuring the ISP1761 as Peripheral and a "worker", which handles interrupts, Descriptor Requests/USB Requests and Incoming/Outgoing Data on the EP1 Bulk Endpoint. I got to the point, that everything, beginning at USB Bus Enumration and Sending of Data worked flawless. Then I added some more entitys. The ISP Core (which runs at 50 MHz) is connected to a Communication Controller (running at 200MHz because interfacing to the DDR-Ram is planned) which implements a custom protocoll of commands, via two DCFIFO's. Sometimes the ISP Core Works, but at some point, when i change some code in any entity the Design suddenly doesn't get through usb bus enumeration, waiting forever for the interrupt, that tells the controller, the Descriptor has been transmitted. Even if I change something in the Communication Controller it can happen, that the ISP Core suddenly doesn't work anymore. I am struggling for about two months with this issue, sometimes it works, sometimes not. The behaviour is, in a way nondeterministic. So I assume, that this has something to do with the Timing Constraints, and that the Fitter Places the entity to another location, when something in the design changes. I tried it with a Logic Lock on the ISP Core, which worked fine for a while, but at some point it all crashed again. Because the communication with the ISP is somewhat asynchronous, I tried to constrain my design, following this post: alteraforums.net/forum/showthread.php?t=24810 but had no luck with that. Following the Data Sheet (shop.in-circuit.de/data/datasheet/ISP1761.pdf ,page 142 - Peripheral PIO Timing), I had the following constraints:   create_clock -name GCLKIN -period 10.0 # base clock derive_pll_clocks derive_clock_uncertainty create_generated_clock -name OTG_WE_n_CLK -source }] create_generated_clock -name OTG_OE_n_CLK -source }] # positive edge of OTG_WE_n is the same edge, that triggers sampling of the DATA line -> multicycle to 0 set_multicycle_path -hold -to 0# data has to hold 2 ns after WR_N HIGH set_output_delay -clock OTG_WE_n_CLK -min -2.5 ]# CS_N has to hold 1 ns after WR_N HIGH set_output_delay -clock OTG_WE_n_CLK -min -1.5 # input delay from RD_n to output of DATA from USB (multicycle set to 2, since 50MHz clk) set_multicycle_path -from {OTG_D } -to {ISP1761Control_INST|isp_hal|hal_out.DAT } 2 set_input_delay -clock OTG_OE_n_CLK -max 33.0 ] # false paths for peripheral (such as buttons, leds etc.) set_false_path -to }] set_false_path -to }] set_false_path -to }] set_false_path -to set_false_path -to set_false_path -from }] set_false_path -from }] set_false_path -from set_false_path -to   These constraints didn't work, as the behaviour of sometimes working, sometimes not occured again. It would be great if someone could give me a hint on how to constrain this correctly. Since I have to transfer Image Data it would be really annoying to switch back to UART. I hope I gave sufficient Information. If not, feel free to tell me. I had to remove the http from the links, as I am not allowed to post links with my postcount :confused:  Thank you all in advance.  Best Regards Felix

[Altera_Forum]

Hmm, that goes a bit over my TQ kung fu but at least one detail: the target of the generated clocks that you're using for the constrains should be the FPGA pin (get_ports something), not an internal register.

[Altera_Forum]

Thanks for the hint rbugalho. In fact, I did just that earlier in the design process. But that didn't work. In my HAL entity I have this: 

  OTG_OE_n <= usb_read_n; OTG_WE_n <= usb_write_n; OTG_D <= usb_d_in when (usb_write_n = '0' and usb_read_n = '1') else (others => 'Z'); usb_d_out <= OTG_D;   usb_read_n and usb_read_n as internal signals, so I don't have to declare OTG_OE_n and OTG_WE_n as buffers (at my working group they say this is bad design practice) to get the tristate working. When I set OTG_WE_n and OTG_OE_n as the targets, TimeQuest says I have unconstrained Clocks:   --- Quote Start ---  Node: ISP1761Control:ISP1761Control_INST|ISP1761HAL:isp_hal|usb_write_n was determined to be a clock but was found without an associated clock assignment. Node: ISP1761Control:ISP1761Control_INST|ISP1761HAL:isp_hal|usb_read_n was determined to be a clock but was found without an associated clock assignment. No paths exist between clock target "OTG_WE_n" of clock "OTG_WE_n_CLK" and its clock source. Assuming zero source clock latency. No paths exist between clock target "OTG_OE_n" of clock "OTG_OE_n_CLK" and its clock source. Assuming zero source clock latency.  --- Quote End ---    When I hit "Report Unconstrained Paths" usb_write_n and usb_read_n are listed as unconstrained Base Clocks, since they are feeding OTG_OE_n and OTG_WE_n.  I assume the "Assuming zero source clock latency" is not so good for analysing the timing :)

[Altera_Forum]

Hi, 

you're right, clocks don't propagate though registers.  So the solution would be to create a derived clock at the register and then another at the port.

[Altera_Forum]

Thank you for your help rbugalho. 

As I'm running out of time, I fixed this Problem by modifying my HAL entity. It now runs with 100MHz and setup states for CS_n, ADR and a hold state after WE_n goes high. The core now runs without any Timing constraints.