Lukas, There are two broad approaches to debug FPGAs, including the B210:
1. Instantiate chipscope/ILA in the Xilinx tool, and use JTAG to monitor signals. 2. Instrument the code, with debug signals (for e.g, a counter that increments when the fault condition happens) and connect the debug signals to a register that is readable by software. Unfortunately, both approaches need you to mess with the HDL code and so you will need to be able to build from source code. I would suggest try to build from source code as-is, confirm that you see the same functionality as the the released image, and then proceed. Of the two methods listed above, 2. is less invasive, but not as powerful as 1. Good luck Chintan On Wed, Jun 10, 2020 at 7:02 PM Marcus D Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > The standard approach for debugging FPGA logic is the JTAG port. This is > true of most FPGA based devices, not just USRPs. If never done that because > I’m not an FPGA guy. > > But I would suggest that you look into that style of “looking into the > black box” if that’s what needs to be done. > > It has been my observation over the last 40 odd years of my tech > development career that debugging environments tend to be useful to debug > problems of a the same class that prompted the development of the debugging > environment in the first place. That inevitably leads to frustration when > things become “subtle” which seems to be what you’re experiencing. > > The FPGA code doesn’t necessarily have a lot of debugging “hooks” in it > because that would consume real estate that could be used for other things, > like better filters or critical features, etc. When you are coming from the > pure software side of the house, you may not have any visceral appreciation > of how constrained the FPGA universe is compared to a modern application > layer piece of software running on a modern OS on a modern computer. > > Sent from my iPhone > > > On Jun 10, 2020, at 4:47 PM, Lukas Haase via USRP-users < > usrp-users@lists.ettus.com> wrote: > > > > Just some additional info: I enabled the maximum possible debug on the > host (UHD_LOG_CONSOLE_LEVEL=trace and debug_level = debug in > .gnuradio/config.conf) and sent both versions to a file. > > Again, the diff is identical! > > (This debug contains the debug messages from gr-uhd but uhd itself does > not seem to generate any debug/trace messages for timed commands). > > > > Is there a way to somehow report back to the host when the command queue > overflows or a timed command could not be processed at the planned time > (late command)? > > > > According to > https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD > "An overflow of the command queue will result in a system halt and often > requires a physical reset of the FPGA.". This does not sound something > that should just be silently dropped! > > > > This works for data streams so shouldn't it work for timed commands too? > > > > The USRP feels like a black box ... commands are being sent but I have > no idea what happens inside or if they are even executed (except, of > course, things are "not working") > > > > > >> Gesendet: Mittwoch, 10. Juni 2020 um 02:30 Uhr > >> Von: "Lukas Haase" <lukasha...@gmx.at> > >> An: "USRP-userslists.ettus.com" <usrp-users@lists.ettus.com> > >> Betreff: How to debug timed commands on FPGA side? > >> > >> Hello, > >> > >> Is there any (somewhat straight forward) way to debug timed commands on > the FPGA? > >> In particular, I want to know: > >> 1.) if any timed command is not executed as timed command but right > away (because it had a timestamp but the command was late so it was > executed right away) > >> 2.) if any command queue overruns > >> 3.) Any other sort of information that causes timed commands to > misbehave > >> > >> I use "tx_command" for USRP Sink to send timed commands. The > "tx_command" tags are injected with an embedded python block. I use "Tag > Debug" and save all tags to a text file. Works. > >> Then, in exactly the same block diagram, I replace the embedded python > block with my C++ implementation that generates tags. > >> Suddenly, some timed commands do not execute at the right moment any > more (these are just few and consistent across re-runs and reboots). > >> > >> However, the tags generated by boths blocks are absolutely IDENTICAL! A > diff between the "tx_command" outputs results in NO differences. Hence I > need to know what the FPGA actually processes in both cases. > >> > >> Thanks > >> Lukas > >> > >> > > > > _______________________________________________ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
