Is it possible using ChipScope for a very high frequency clock?

Hello,

I am using ISE14.7 on Linux machine targeting a Virtex-5 FPGA (XC5VLX50T).
I have implemented a design operating at almost 500 MHz and design was fully placed and routed succesfully.
I have some internal signals that will respond to some changes . I would like to know can I trace my design and see my specific signalsè reaction using ChipScope tool??
I heard that ChipScope is for debugging a design but I want to use it to monitor and ensure the correct functionality of my design at this frequency. Is it feasible???

Thanks and Regards,

The ChipScope has to run at the 500 MHz frequency if those are the signals you are monitoring. Yes it might run that fast, but you probably won't be able to do much more than the most simple of triggering modes. I've found that adding Chipscope with more complex triggering most definitely can have an impact on maximum achievable operating frequency.

The real question is why are you trying to use Chipscope as a functional verification tool? I would use a simulator like Modelsim with code to spit out intermediate locations in code and perhaps use matlab or something to post process the data to determine correct functionality. Chipscope isn't a suitable replacement for implementing a good functional verification testbench and running simulations.

Basically - No
Verify your design in a good self checking testbench - then run it on the hardware. No chance getting chipscope to work that fast.

If you have issues routing the chipscope, you can always add a serial to parallel converter on the high rate signals. eg, have multiple registered versions of the signals that then go to slower clocked register that go to chipscope. The results are harder to analyze. Some trigger conditions might not be possible (i forget what the limit is for and/or logic). Any complex triggers can be added into the hardware if you really need them. However, they will meet timing as the or-reduction at the end adds around one level of logic while the period is doubled.

If your issues are due to incorrect constraints, incorrect clock frequency, psu issues, or anything not covered by static analysis you may not get reliable results from the chipscope.

Likewise, BRAM can be an issue if your model does not include read-write/write-write collision detection. The simulation will have a defined behavior while the implementation will not.

Chipscope uses core logic (logic cells and block ram) and undergoes the same timing constraints as the other design. So the basic answers is, yes you can use it. But you should be aware that timing closure might fail after adding chipscope if the design is already running near the maximum device speed. Just try.

A possible solution could be to exclude the signal path to the debugger component from timing analysis and check if the data is still meaningful for monitoring purposes.

ads-ee said:

The ChipScope has to run at the 500 MHz frequency if those are the signals you are monitoring. Yes it might run that fast, but you probably won't be able to do much more than the most simple of triggering modes. I've found that adding Chipscope with more complex triggering most definitely can have an impact on maximum achievable operating frequency.

The real question is why are you trying to use Chipscope as a functional verification tool? I would use a simulator like Modelsim with code to spit out intermediate locations in code and perhaps use matlab or something to post process the data to determine correct functionality. Chipscope isn't a suitable replacement for implementing a good functional verification testbench and running simulations.

Click to expand...

Thank you @ads-ee for your kind reply.

Regarding your question about why do I need to use Chipscope, is that I implemented my design, and it was fully placed and routed and the Post place and route simulation results with Isim are prefect ! But my teacher asked me to find a way to verify its correct functionality in real-world in real implementation ! He says, even passing post place and route results successfully, there is not a guarantee to have a functional circuit in real world at the core of FPGA !!

I also did not get your point regarding the suggestion that you've made with that code ! Could you please explain it more?

Thanks and Regards,

Best way to garantee it's working on the chip
Input data - get correct result
No need to use chipscope.

msdarvishi said:

But my teacher asked me to find a way to verify its correct functionality in real-world in real implementation ! He says, even passing post place and route results successfully, there is not a guarantee to have a functional circuit in real world at the core of FPGA !!

Click to expand...

Wow where did that come from...either that teacher hasn't done much designing, isn't constraining designs correctly, or isn't adding margin into the design.

Only in the rare occasion where the tools had a bug, which actually changed the functionality of the design, have I ever seen a case where the functionality of the design was wrong in real-world in a real implementation when the post place and route successfully met my constraints. I've so far been lucky enough to not be using bleeding edge timing files, so I've never had to deal with the problem of the timing being overly optimistic (though getting worst case silicon, worst case voltage, and worst case temperature is typically highly unlikely, i.e. worst case PVT).

But then again I actually run high coverage simulations on my designs. And the times I've had to resort to Chipscope was to find subtle interaction issues in the system, e.g. a system with constant packet rates that turn out to be output incorrectly as variable rate with an aggregate rate that sort of matches the constant rate, due to a bug in another FPGA.

Basically the rule is only run simulations on stuff you want to work, for everything else you can just forget about simulation (of course that means it probably won't work either ;-))