SignalTap breaks my design

[Altera_Forum]

I'm using the DE2-115 development kit. It contains a Cylcone IV FPGA and I am interfacing that to the on board ISP1362 USB Driver (device mode only). My design asks the ISP1362 for it's chip ID. According to my external logic analyzer, 20 ns after I toggle the Read and Chip Select lines the ISP1362 will drive the bus. If the design is broken the ISP1362 drives the bus to 0, if it is working it drives it to 3630h. Again, working or broken the chip drives the bus at 20 ns after I toggle the read I/O. This is repeatable. The datasheet says it will take 22 ns to drive the bus to a valid value. My code toggles the I/O in the exact same way regardless if the chip responds correctly or not. I've measured the timing parameters and logic levels. 

 So, what breaks the design? In SignalTap if I set the sample depth to 8k the design works and I read 3630h. If I set the depth to 64k I read 0000h.  I understand that signaltap modifies the overall design, but does not (should not?) modify my code and thus does not modify my behavioral. I've constrained every signal in my design to 20 ns. (CLK is 50 MHz). I've used the generic I/O location/voltage level/constraint file. I've constrained the I/O to 20 ns as well. I've optimized the project for speed. I do not have any timequest timing violations and fmax in worst case scenario is 65 MHz (or so).   Where should I look to debug this problem?  I appreciate any questions, comments, concerns.

[Altera_Forum]

The samples of SignalTap II are stored in a on-chip RAM blocks in FPGA. Your problem is that you are willing to have too much samples. RAM blocks on different locations are used and design does not work anymore. Take less samples and a slower clock for acquisition.

[Altera_Forum]

Your answer doesn't make a lot of sense. As long as the design is properly constrained and that Timequest doesn't complain, the size of the Signaltap buffers shouldn't change the behaviour of the design itself. 

JPL, are you sure that Timequest reads your constrain correctly and did constrain all the I/O's? In the Timequest report you can find the number of unconstrained ports. Check also all the warnings when it reads your constraints files and check that it did understand everything correctly. It's difficult to see anything from your screenshots. Did you try to see what was happening on the pins of the ISP1362 with a scope or a logical analyser in both cases? Try also and delete the db and incremental_db folders each time you recompile your project. I have several projects that actually need this to work properly. There seems to be a bug in the instantiation of some megafunctions when reusing results from the previous compile, but it is a very difficult bug to reproduce.

[Altera_Forum]

linas, Daixiwen, thank you for your replies. 

 As Daixiwen pointed out, TimeQuest reports that even with 64kb buffer size my design meets all of the timing requirements, even worst case scenario.  I have deleted the db and incremental_db folders. The problem persists.  Compilation Report -> Unconstrained paths: All fields read zero.  I didn't realize that the forums constrain the uploads so badly. Use this: i.imgur.com/bSKJxGa.gif You should be able to see that the behavior at the I/O is exactly the same. F6 is reset, B5 is chip ID, 3630 is the valid value. Look at the red and blue lines which point out the valid or invalid read value. The logic analyzer is looking at the GPIO on the board which is routed (wires, not registers) from the USB I/O pins. I have probed some of the USB I/O pins to verify my design is reaching them.   I read through the entire console window after compilation, this line slightly concerns me: Info (17049): 138 registers lost all their fanouts during netlist optimizations. How do I find a list of those registers? I do have a 16x1k fifo that is being optimized out because I haven't started using it, yet. It is not critical to my current design.  Ignored assignments: 2, Global Signal input clock (from external source), and output of PLL clock. I have instantiated a global buffer. It doesn't seem to do anything. Time Optimization Advisor says that my base (input), virtual (I/O), or generated (PLL) clocks do not use global resources. These assignments were made in the assignment editor.  This is my SDC file. To be honest, I guessed the min/max for input/output delay. The ISP1362 USB Chip requires 22 ns max for a valid value to settle on the bus. I read the value 40 ns after asserting RD/CS, plenty of time, right? # Create clock constraints create_clock -name CLOCK_50 -period 20.000 # Create virtual clocks for input and output delay constraints create_clock -name io_clk -period 20.000 # Derive PLL Clocks derive_pll_clocks -create_base_clocks # derive clock uncertainty derive_clock_uncertainty # set input and output delays set_input_delay -clock { io_clk } -max 3 set_input_delay -clock { io_clk } -min 2 set_output_delay -clock { io_clk } -max 3 set_output_delay -clock { io_clk } -min 2

[Altera_Forum]

Then I'm not sure what's wrong. But two find out what you should put as input and output delays, you can have a look at this guide (http://www.alterawiki.com/wiki/timequest_user_guide) to determine what values to use, depending on the setup and hold requirements from the device.

[Altera_Forum]

That is confusing me. I'm holding the I/O lines at value for several clock cycles (80 ns) to far exceed the 22/25 ns requirements for read/write. I'm reading after 40-60 ns. So, do I even need to care about the I/O min/max?  

 One last question. If my behavior works once (in both simulation and real) then isn't my code correct or proper? Is there any chance my code could be wrong somewhere? Again, this assumes I'm not modifying the hardware abstraction layer (I/O interface module).

[Altera_Forum]

From your screenshots it seems that it is the chip itself that isn't replying you with the correct answer. I don't know this chip, but could there be any other cause that would make it not reply in some cases? A bad reset signal, chip busy, or something else? 

If the timing is correct I really don't see why you would get a different behaviour just by changing the signaltap buffer size. But it's difficult to say for sure that your code is correct or bad. Something could make it break, or on the contrary it could just work "by chance" in your first case...

[Altera_Forum]

When it does work, I mash the reset signal multiple times which resets the entire design. It continues to work. If it is broken, then the same thing happens, it continues to not work. The F6 command is a reset command. That's why in the 'working' capture INT (interrupt) goes low. 

 I've contacted NXP, the current owner/maker of the chip and hopefully they can give me some insight. The goal is (was) to publish the interface once it is done.  I appreciate you taking the time to help.

[Altera_Forum]

solution Since the design worked some of the time/compile, it was assumed there was a race condition somewhere.  After examining the data sheet for the billionth time; I rewrote the hardware interface to be very conservative. The address line requires a 1 ns hold time after WR goes high. I now hold the address line for 1 clock cycle after WR and the problem has yet to reappear.  1 ns. . .. 1-fing-ns.  After I finish this god forsaken design I'll post it online.   Thanks again Daixiwen for your help.