Once you program the device you should see a debug window that shows your signals.For more information see Xilinx user guide UG908 Programming and Debugging.Also see the Vivado 2020.1 - Programming and Debug page.Realistically, this is best done in simulation using Assert and/or Report. But you need to simulate the ADC too. Hi, I created a project involving Artix 7 FPGA (xc7a200tfbg676-1) in the environment Vivado 2020.2.In the testing phase, while checking a macro , I found that random signals were displaying as 'high' in the CHipscope Logic Analyzer, eventhough i have set the signal to be 'Low' in both reset and initialising phases.You can use the Vivado Chipscope debug core to view registers at run-time on your device.ChipScope AXI Monitor Product Page Version Release Note Initial Release Date v6.0 54448 Vivado 2013.1 Apv5.03.a 47654 14.3/Vivado 2012.3 Octov5.02.a 47654 14.2 Jv5.01.a 47654 14.1 Version Release Note Initial Release Date v2.0 54809 Vivado 2013.1 Apv1.1 47655 14.2/Vivado 2012.2 June.

This has the benefit that you can thoroughly test your interface to it in simulation before getting to the hardware stage.In real hardware you're looking at instantiating a Chipscope ILA core and connecting to it through the JTAG interface to examine registers : to read RAM you'd need to persuade your hardware to transfer its contents onto signals connected to Chipscope.Alternatively, use an FPGA with an embedded ARM processor (Zynq-7 series, or Ultrascale for example). Map that RAM onto the AXI bus to make it accessible to the ARM CPU. Then read the addresses it's mapped to, in a C program running on the ARM, and display the results using. This will write your debug constraints to one of your constraints files.Generate your bit-stream. Then program your device with the bit-stream over JTAG. Make sure to specify your LTX file when programming.

In simulation it works fine, so I feel I can't really gain anything from simulating any more.I have looked at the signals on a logic analyzer, and the controller device (not my design) sends the right messages. Works no problem.But if I send a value using command C, I cannot verify that it was received using command D. Now I've hooked up it up in real life to another device using SPI, and some stuff works, and some stuff doesn't.I can send a value using command A, and verify that the right value was received using command B.

Since it seems not to be working, you can't trust debugging over this interface, because if you get an odd result you can't determine what it means.Since you're working on an FPGA, are there any other interfaces other than SPI which you can get working correctly? Maybe 7-segment display, LEDs, JTAG, VGA, etc?Try to think of other creative ways to get data out of your chip that don't require the SPI interface.If you have 4 LEDs, A through D, can you light up each LED for 1 second each time a command of that type is received?Can you have a 7-seg display the current state of your SPI receiver's state machine, or have it indicate certain error codes if some unknown command is received?Can you draw over VGA to a monitor a binary sequence of the incoming SPI bitstream?Once you can start narrowing down with data what is actually happening inside your hardware, you can narrowing the problem space to go inspect for possible problems. ('Design for debug') is a common term used for thinking about this kind of logic.So you have one chip interface (SPI), which you don't know if it works correctly.

Chipscope Vivado