zygot
-
Posts
2,859 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Posts posted by zygot
-
-
I don't know about the staff at Digilent, but I'm getting weary of reading posts from silly people making their FPGA board usable because they decided to experiment with the hardware without first doing their homework or having a back-up plan when things go awry.
If you want to experiment with FTxxxH devices and high speed interfaces there is a correct way to do this that avoids having to make a post to the 'Thread of Shame' ( sadly this isn't the only one ). Over a year ago I was going to post a complete project with source code in the Project Vault and got very close for on using the CMAD-A735T. It wasn't perfect though was 'good enough' until I tried replicating the project on a different PC. I've concluded that the CMOD designs just aren't robust enough for Synchronous 245 FIFO mode. This project also targeted the Terasic DE0 Nano and that demo made use of the SDRAM on board. That one works perfectly for both the Windows and Linux PC platforms but I can't justify posting a project to a Digilent website that doesn't use any Digilent hardware.
I've recently been experimenting with FTxxxH devices and various interfaces... just because I'm a curious guy ( some may say in more ways than one...) and thinking that it's time to cobble up a demo to address the curiosity of those wanting to 'pimp out' out your hardware but don't know how to do it safely.
Anyone interested in a 12 Mbaud PC UART <--> FPGA board interface? Or perhaps a 32 Mbaud or 48 Mbaud UART interface?
-
I've executed quite a few experiments with the Eclypse-Z7 just as a way to figure out a path around the very limited higher-level supporting code that Digilent provides. While it is an unusually and unnecessarily hard platform to work with there are certainly things that you can do with it if you have some HDL development skill.
The maximum 16383 sample limit provided by the high level Digilent supporting code can be gotten around of with a better AXI interface approach. I've done 256 KB ADC capture on both channels, writing samples directly to the PS external memory. Unfortunately, if the signal chain goes through the PS to external memory, clocking can get complicated and become an issue that isn't easily resolved.. for some applications there is no solution. There is no provision on the board for an external Fs clock input for designs having that requirement.
If you limit PS interaction to control things look brighter, though your sampling buffer capabilities are limited to BRAM resources. The PL in the ZYNQ 7020 are similar to an Artix 75 device. There are some project where the board is OK and some where it is inadequate. Unfortunately, not many people are willing to work out the platform requirements that their project has and do the analysis that a particular platform provides. Overly optimistic marketing claims and hard to get at details don't help someone in your position. At the moment the Eclypse-Z7 is for advanced users unless they just want to replicate one of the 'star' demos that Digilent provides for sales promotion. Even for advanced users it can be more work than it's worth to use. My Eclypse-Z7 is just gathering dust these days as there are better platforms for doing what it was designed to do.
As to UARTs on the ZYNQ. All of the Digilent ZYNQ based boards use one of the PS UARTs connected through the MIO pins to a USB connector. The other PS UART can be connected through the EMIO to the PL. Once in the PL you can either connect it to a UART in your HDL code or through pins connected to external connectors such as the 2 PMODs on the Eclypse-Z7. If you do that then you need an external TTL USB UART cable, breakout board or PMOD to connect the UART to a PC. You can also just implement a UART in your HDL that the PS is not aware of and communicate with registers in your HDL directly. I';ve been doing this forever with non-ZYNQ FPGA projects as a user interface or just for debugging.
-
Have you seen this project?: https://forum.digilentinc.com/topic/20331-more-fun-with-phasors/
The Eclypse-Z7 isn't the best platform for your type of project. The XEM7320 has USB 3.0 connectivity. This isn't sufficient for uploading/downloading raw samples at the maximum Fs of the converters but a lot faster than a UART. If you to use a ZYNQ platform and want a UART in your PL that isn't connected to the PS you can do that using a cheap TTL USB UART. Digilent has a PMOD version and Adafruit and Sparkfun have others that might be better for other platforms without a PMOD. If you are going to need sample storage you platform really should have external DDR connectivity directly to the programmable logic. This simple change to the Eclypse-Z7 would have made a huge change to it's relevancy as a general purpose signal processing platform albeit at a slight cost increase.
-
Evidently, one of the changes seems to be that users have to allow scripting in their browser to use the site. With Firefox 78.6 I can't highlght text in a post as a quote to start a reply... in fact I can't do anything with script blockers turned on. This is a change from my experience on Centos 6, which along with every other version of Centos except Centos 7 and Centos Stream has been killed of by Red Hat recently. I really don't like allowing any web site to run whatever script they want behind my back... it's a big problem for me.
-
The RS-232 PMOD is OK if you have a really, really old PC with an RS-232 serial port and DB-9 connector. They haven't made a PC motherboard with those for a long time. Useful baud rates are limited to about 115200 baud. The USBUart PMOD is similar to the TTL USB Uart breakout boards and cables that I referred to. For most Digilent programmable logic boards this is a a fine alternative. The only issue would be that it uses 4 PMOD pins whether you want to or not. The connector is suitable for use with a PMOD. The options that I mentioned just need 2 GPIO pins plus a ground pin so these are more useful for any FPGA board that you will ever use.
So the only question left is the Vccio voltage of the PLD device on the CoolRunner-II. According to the Digilent documentation for your board the PLD has 3.3V IO logic compatibility. So, as long as your PC has a USB 2.0 port available the USBUart PMOD should be fine.
-
On 1/19/2021 at 12:14 PM, Snehashis Haldar said:
Could you please let me know what extra hardware I need to implement the RX, TX of the UART?
Go over to Adafruit or Sparkfun. They sell inexpensive TTL USB UART breakout boards or cables. I use these on boards that have a USB UART capability built in. All you need are two spare IO pins; one for TxD and one for RxD. You can connect the cable or breakout board to a PMOD and have a USB UART that your PC can use.
You can probably find a convenient distributor for these things most places in the world if buying from the sources mentioned is a problem. FTDI also sell a cable a a higher cost.
Be mindful of 5V verses 3.3V logic compatibility when using on older devices.
-
A much easier path would be to choose an FPGA platform that has the infrastructure that you want in place. You should at least look at the Terasic OpenVINO (formerly C5P ) starter boards. No soft processor. Just PCIe, the FPGA application and a PC application. Windows and Centos 7 drivers are included. There's plenty of DDR memory o the FPGA board. I've written software applications for Centos and Win10 for these boards so I know that they work. Yes, you will have to do your FPGA development using Intel tools. If you decide to go this way the GT version is the one that you want as it supports PCIe Gen 2. The GX version only PCIe Gen 1.
Selecting a platform and trying (hoping) to make it do what you want is always a lot more work than selecting a platform that is designed to do what you want.
If there were a similar options for Xilinx users in the price range I'd have tried it and would offer it as a possible candidate for a project similar to yours. I don't believe that there is but would love to be proven wrong.
-
For the curious.
And when the next production run needs a different part that isn't a 'drop in' replacement for either of the two previous FLASH devices then what? Will there be an identification scheme to tell the modules apart at the time of sale? Will there be a change notice, which is a typical practice, published before new modules enter distribution?
If I were going to use an OEM component in a product I'd want this information. I'd want this information even if I decided to buy another CMOD for the lab. My time and costs matter to me and should matter to anyone wanting to sell me stuff, especially in quantity.
-
3 hours ago, Kyle_Jackson said:
I know now that "drop-in" applies to the footprint of the device package only
No, I'd disagree with that comment. Drop-in means that no PCB or board design revisions are required to use any qualified alternate part on the BOM. This certainly includes the footprint. It also means that a customer who might be trying to use multiple pieces of a product that aren't from the same manufacturing run won't notice a change in components. This is an important point from the customer's viewpoint as it can make their life a lot more complicated.
Sometimes, there are no suitable alternate parts available to do a production run. The customer should never be the one to get the surprise. It's the vendor's responsibility to let customers know in advance it they start shipping product that isn't completely compatible in any way with previous copies of a product. If someone wants to OEM a module like the CMOD then they deserve to be allowed to decide whether or not it makes sense to have the burden of maintaining code for multiple versions of a component that isn't even identifiable as unique from other versions.
Even if Digilent did the right thing and made it clear on the sales and product pages that certain versions of a product had unique labels like a run # or date codes signifying different behaviors, and, in the case of something like FLASH, they provided IP that detected the FLASH in the product and handled the unique aspects of every version of the product that was ever produced they have an obligation to make this known in advance of a sale. Yes, for most CMOD customers this kind of thing isn't a big deal. If you are going to OEM a product to other companies then you have a responsibility to consider their needs.
-
17 minutes ago, Kyle_Jackson said:
It is frustrating that Digilent called the Macronix flash a "drop in replacement" for the Micron in their reference docs when it's apparently not.
Adding alternate vendor part number to a BOM in order to do a production run is always prone to error. Complex parts deserve extra attention to detail as component manufacturers tend to overstate compatibility with competitor parts. Using a new part for a product run and sending the results into distribution without extensive functional testing is not a mistake that should ever be made, but this happens. This especially happens when functionality is not a supported feature of the product, which in not uncommon for FPGA development hardware.
At least you have an indication of movement on your issue. Hoping that you are back to doing what you'd want to be doing in short order.
-
1 hour ago, Kyle_Jackson said:
I feel like the solution must be something simple I'm just missing.
Perhaps you should be feeling like the solution is your board vendor's responsibility. Any product production change that changes the behavior of a product is not the responsibility of the customer. Any time a component is replaced there is a chance of this happening. Unfortunately, sometimes due to component availability this is a necessity. What should happen is that someone should be testing board revisions thoroughly. Some vendors are better at allocating resources to doing proper testing than others. When you don't create qualification demos that validate all of the product functionality you're likely to miss important details. Lets, face it. This is a low margin product. But that's not important to a customer wanting to have a product available in quantities over a long time frame.
Try shooting a few more, perhaps better aimed arrows. But, it's good to have this issue prominently displayed for other customers and potential customers.
Likely, this is an unfortunate time of the year to be running into this so there might not be a lot of people seeing the smoke signals.
-
7 minutes ago, D@n said:
I'm not sure I'm ready to respond to it, and so I have not. Let's just say I'm still mulling it over.
1 hour ago, zygot said:Hey, that would have been a sufficient reply. You're generally responsive within the constraints of your workload. I'm happy to knock your concerns around with you if that will help.
-
On 12/21/2020 at 10:29 AM, D@n said:
At the risk of taking this thread far off topic, let me ask, What sort of demo would you like to see?
I sent Dan an email with a description answering that question. He's read the mail but so far has chosen not to make any sort of reply. I mention this because it seems to be germane to my previous post on this thread. Until that changes we are left to presume what that means. I'm disappointed if no one else is. Anyone who's tried going through the design flow favored by Xilinx and Digilent, particularly for ZYNQ projects, know that there are serious issues involved if one wants to do real world designs. I suppose I should start a new post thread discussing roadblocks to success that FPGA vendors throw in the way of customers who want to nudge the odds of success more towards themselves rather than the vendors. At least then anyone wanting to can excoriate me to their hearts content without muddling the basis for the thread.
-
10 hours ago, D@n said:
Help! The FPGA engineer left the company, and I'm just the S/W guy but ..
When someone only gets involved with part of a design project, like doing HW design and never doing SW design in actual use cases, they can be under a false impression that everything they do is perfectly wonderful. I've seen this over and over. Even if working at the same company the SW team might just find a workaround and problems never get back to the HW designer. Often the workload and project schedule don't leave time for sorting out these kinds of issues. Sometimes there's just inter-departmental rivalry or friction. You'd think that this couldn't happen but it more common than a rational person would think that it could be. In some companies the designers never do any verification and it's left to the verification engineer to find the problems and fix them. Feedback on how your designs are performing is an important part of the design process. To my way of thinking even if you are a HW design specialist you need to be doing enough SW design to 'close the loop', at least to dome degree, particularly if the design is so tightly coupled to SW as AXI buses are for ZYNQ.
In a similar vein, if someone is going to provide guidance and suggest solutions to a struggling FPGA beginner then they need to be able to understand the complete flow that such a person would use, even if that's not one that they use. Or they could explain in detail a better development flow. This is what makes answering questions like the one that prompted this thread so difficult to address. If your response to a question asked on this forum is all about you, then it is unlikely to be any benefit to the person needing advice. I'm betting that very few people asking for help on this forum has any interest in writing AXI HDL code. In fact my impression that the draw for using a ZYNQ type device is that they can replace the complicated HDL design flow with something more comfortable and friendly like software design. That's why I try and post answers that I hope are suitable and usable for the person asking for help. This usually requires making assumptions about their level of skill and knowledge and interest in the subject.
-
1 hour ago, asmi said:
but I seriously don't understand what the heck is your problem
I'm not the one asking for advice. My problem seems to be interference with my efforts to attempt to provide a good reply to the question that's the topic of this thread. That's not too hard to understand. Instead of engaging with whatever nit-picky details of my posts that bothers you, it would be helpful for you to either provide an alternate answer and route to a solution to the question or send me a personal mail message detailing your specific grievances. I'm pretty confident that asserting that anyone who is too stupid to write their own AXI IP shouldn't be doing FPGA development is not helpful advice. My problem shouldn't be a problem for @lowenatoo.
I don't post work written for customers as this becomes their property. Surely, you've done a few ZYNQ designs on you own time and have something to share. Instead of spending all of the effort you've spent so far on this thread responding to everything except the question you could have written a generic AXI master Verilog file, since you've done that so may times, to illustrate how easy it is. But the application details complicate the code expression don't they.
Personally, I don't often do ARM embedded designs and proprietary buses have no place in my logic, which is typically resource constrained. I have done enough ZYNQ work to know what's involved with using AXI but for quick prototyping or casual project I've never had the need to write optimized fully verified AXI-specific code; which doesn't mean that I haven't written AXI connected code that was usable to complete a project. As I've posted in other threads I've found the BRAM controller with dual clock BRAMs a convenient way to connect data between the PL and PS. On the HDL side there's no beats or bus faults to worry about. Is it the optimal solution to all ZYNQ designs? No. Does it work without worrying about bus fault issues like some of the Xilinx AXI IP offers? Yes.
Anyone who has the time and interest can do a bit of spelunking about the Digilent IP source code as well as other places to help understand how to implement, perhaps good, perhaps, bad AXI IP. I don't do this often but @D@nhas a blog that nicely describes some of the intricacies of the AXI interface and potential issues though not a complete and useful example of how someone likely to post a question on Digilent's Forum can bootstrap off of for a solution to their particular project.
-
26 minutes ago, asmi said:
don't have time for that, too busy
Hmmm... thanks for the information, you just won me a lunch bet. Perhaps you can answer this question. Why is it that people who have time to engage in unproductive nonsense can't use the time to provide useful help.
Here's a suggestion. Instead of posting snarky remarks, just paste one of your AXI master Verilog source files here with a brief description of how you used it. That can't take up much of your valuable time and could help the average user grasp the topic.
-
I've been involved with as an employee or contractor with a awful lot of companies using a very diverse range of technology. I've yet to meet anyone who's mastered all of that limited set of technology. That doesn't mean the everyone I've met is an idiot or incompetent; it just means that none of them have mastered all of the those technologies. Early TV, the CD player, LTE and 5G rely on very complicated and often non-intuitive concepts and conjectures to work. Very few people have an appreciation for the tricks and details involved. Yet everyone has used them. Thinking that you understand all of the underlying principals of technology doesn't necessarily mean that you are smart, perhaps just not knowledgeable, nor does it make those who know little about them stupid.
I welcome challenges to things that I post on but I'm not too happy with assertions of competence or non-competence. If you think that I'm wrong about any of my assertions please post a reply; but be prepared to back up pure bluster with some evidence. I rarely direct my posts to seasoned expert engineers because these forums are for beginning users. The purpose of the forums is education and enlightenment, and perhaps to steer those with little experience toward a more fruitful path.
The original question was about connecting a ZYNQ PS to the PL so I don't think that anything said so far has been off topic. Yet, I think that it's necessary to state what should be obvious.
-
1 hour ago, asmi said:
That is just nonsense. AXI bus by itself does not require any gates, if your core requires a ton of gates to connect to AXI, that's because your design sucks, not because AXI is bad.
Really? I guess that you missed what I posted above concerning the SmartConnect that Vivado insists must be used with it's own IP, using it own preferred design flow. Well, yes using AXI usually does end up using gates... and the need for larger and expensive parts, which is the whole idea. Can you write your own AXI IP and minimize slice utilization? Of course. Will anyone using the preferred board design flow have similar success? Not a chance. I've written and packaged my own AXI IP which has served the purposes of the project that I've used them on so I'm not just expressing gas on this topic.
I'd modify your words to say that if your design uses a lot of gates then you're probably using the tools as Xilinx or Intel would prefer you do.
So, I'll direct the same challenge to you as I did to @D@n, post a demo project showing off your AXI prowess for the typical Digilent Forum reader's benefit for everyone to admire and learn from as well as see how trivial it is. Dan didn't reply to my explicit mail invitation because, as far as I can tell, he's never actually done a complete ZYNQ HW/SW design project and has a few holes in his understanding of what's actually involved. Calling other people idiots is easy. Directing readers to blogs that don't actually resolve a complete design that can be replicated is easy. Posting projects to the Project Vault with source code is useful. So, put your integrity where you mouth is.. show us what you got. ( I'm pretty sure that I've avoiding degenerating into the abyss that our first dialog sent us to but if not someone will be in touch ). A demo is worth a lot more than idle boasting.
For what it's worth, I never stated that AXI is bad. If a vendor is selling a micro-controller with a general purpose external bus interface knowing that adding programmable logic isn't likely a viable customer option, then sure an overly complicated and general purpose bus that the customer can hang high-performance and or low-performance logic onto makes sense. If the micro-controller is embedded into a large FPGA device then this make a lot less sense for the customer at least. At least provide one high performance simple connection between the PS and PL that doesn't serve a myriad of purposes; especially when there are so many other AXI paths provided. I'm just suggesting that the reason for not doing that has nothing to do with technical problems that ARM can't resolve.
-
17 hours ago, asmi said:
I'd say if AXI bus master or AXI-lite slave is complicated for you, you'd better stay away from FPGAs at all as these are among the simplest things you will encounter.
Hmmm, I guess then that you'd suggest that Intel and Xilinx ( or it's new owners ) had better find a new occupation because they are purveyors of some really bad and or buggy AXI IP. I'd say that this is evidence that you don't have to be an idiot if you struggle designing with it. Let's face it most of the questions asked on this forum aren't from expert and seasoned FPGA developers. Yes, you are correct that there's no mystery in AXI or AMBA specifications; they are freely available. But I'd have to disagree with the notion that they are trivial to work with. The truth is that they are overly complicated and inappropriate for most FPGA design applications, unless of course they are required as is the case with FPGA devices having a hard ARM core complex. Both Altera and Xilinx could have provided a simpler and less complex hose between the PS and the PL but they chose not to because they are in the business of selling gates. If AXI was so trivial you'd think that companies who's income depends on it woulf be able to do a better job with it.
While any of the AXI versions might not be excessively complicated that doesn't mean that only idiots design bad AXI based logic and applications.
In my experience it's rare for an FPGA designer to design logic to use an interface in all of its permutations and capabilities, unless they happen to be in the IP selling business. When creating IP with partial functionality it's sadly not uncommon to find that things were missed. This is more about professionalism and a commitment to robust design over making money. Good engineers working for bad companies usually don't do good engineering.
While am on the subject it isn't just bus specifications that some users might find intimidating, basic concepts like clocked logic and resets are done poorly in many designs that I've seen. Some of us can do something about that and some of can't.
-
17 hours ago, asmi said:
I have personal experience with achieving over 300 MBytes/s of sustained transfer rate over USB 3.0 using FT601 USB3-FIFO bridge
So have I. I've also had experiences with the same device giving me about 10 KB/s. The difference is due to a number of factors. My point is that assuming that the best measured data rates are typical or guaranteed for any application is a bad idea. This is due to the protocol, the drivers, the OS, the software application, etc. A great way to kill your data rate is having to require packet termination. USB isn't overly complex but I've run into more than my share of surprises since I've been developing with it.
-
12 hours ago, lowena said:
I can't figure out how to connect my code to it
Well, I'll offer one way, which is how I do ZYNQ designs. After creating the board design and generating the output products I tell Vivado to create a wrapper file in the project HDL, typically for me in VHDL. This wrapper then gets instantiated into my own toplevel entity where I can connect to any exposed signals that were made external in the board design. Usually, Vivado attaches IO buffers to these signals but will remove them and spit out warnings that can be ignored. You can look over an example here: https://forum.digilentinc.com/topic/20299-fun-with-phasors/
So, in your schematic above the first thing to do is make your UART signals external...
[edit] I forgot a sentence that I always add: When you have Vivado create your wrapper file make sure to de-select the default option that lets Vivado manage the wrapper code. You want to manage this to avoid unnecessary fights with the tools.
-
I recently posted a demo project in the Digilent Project Vault using an 8 pin pseudo-ram device. One of the platforms that I implemented the ram IP on was the Zedboard. You might find this interesting.
On the CMOD-A7 with a UART user interface:
ram IP used: 49 slices, 128 registers, 146 LUTs
user interface used: 134 slices, 146 registers and 238 LUTs
For the Zedboard I used the 'preferred' board design approach to have 2 BRAM controllers and 2 BRAMs, 8 32-bit control registers and 8 32-bit status registers using my own ZXI IP that I did many years ago. Functionally, the CMOD and Zedboard demos did the exact same thing ( note that I wasn't using the BRAMs in this implementation ). Here's the damage on the Zedboard:
the 2 BRAM Controllers used: 186 slices, 412 registers, 405 LUTs
the ram IP used: 52 slices, 129 registers and 150 LUTs
the control registers used 51 slices, 159 registers and 57 LUTs
the status registers used 41 slices, 161 registers and 39 LUTs
the SmartConnect that Vivado added to the board design used: 2627 slices, 8639 registers and 7425 LUTs
For the first iteration of the Zedboard implementation I had only 4 32-bit registers using the Xilinx AXi GPIO and all of the AXI utilization was significantly worse.
You can make of that what you want. One way to look at it is why worry about resource usage when your design doesn't need more? The other way to look at it is for a complicated design will Vivado leave enough resources left for my design after the AXI interface is implemented? Or perhaps more importantly, if I do a design that fits today and tomorrow I want to add functionality will I be able to do it with on the hardware that I started with? The last one is a question that those in industry need to consider.
-
@D@n, I sent you a message.
-
I don't object to saying that writing an AXI master is 'doable', but I'd say that doable a relative term. From what I've read about the work that @D@nhas put into understanding the AXI bus specification and FPGA vendor implementations I'd say that this is no trivial endeavor. I'm always loathe to assert that something can't be done, seems like a guaranteed way to lose a bet. On the other hand betting that specific individuals couldn't do a robust job at it might be a good way to earn beer money.
You don't need to use AXI bus DMA functionality. The ARM complex has a software programmable DMA engine that can be used nicely with PL BRAM.
Writing an AXI master or slave in an HDL is one thing. Packaging and integrating that IP into form that can be used seamlessly by the FPGA vendors' HW/SW tools is another. So @D@n, what's the chance of seeing a compact demo of your IP that does that and can be replicated by user's of this forum using Vitis and Vivado? I'm absolutely sure that more than a few readers of the Digilent Forums would find it to be interesting and useful.
Troubleshooting a possible power issue
in FPGA
Posted · Edited by zygot
It seems to me that you already have a suspect in mind; a power supply issue. So, why not try to either confirm or eliminate that possibility?
If you have a decent oscilloscope you can monitor the core voltages at the point where you think that the problem occurs. If you don't have a scope then you can use the FPGA XADC facility to monitor and set alarms for internal supply voltaes. This might require a bit of alteration to your PL design. Perhaps you could add control bits to allow some functionality in the PL but not others. This would allow you to selectively enable parts of the design.
You don't mention it but the ARM processors are fast enough to cause but faults. I've seen this with standard AXI GPIO IP and trying to flip bits at too high a rate. You can test this by adding delays between successive AXI read/write accesses.
One thing that is important to do when debugging complex (SW + HW ) problems is divide and conquer. Pare down the possible causes of the problem. Often, it turns out to be more complicated than just one thing but a binary approach to eliminating suspects is still the best approach most of the time. It never hurts to take a short break and come back and try and do a fresh review of what's going on with a design and try a few thought experiments. Of course, you've already done your PL design simulation and carefully looked for unexpected changes from previous design iterations.. right? Sometimes, the HW timing reports and messages have a clue as well.
On-board FPGA power supplies are designed to provide a limited range of average and instantaneous power. Trying to change the design behavior by throwing a larger power source or capacitors at it is not a recommended practice. If your prototype platform is limited then you should adjust your prototype performance to suit the platform. Of course, this has as yet to be confirmed.
Oh, and you can instrument your PL design to spit out XADC readings through a HDL UART using 2 spare pins and an external USB TTL UART cable. This will disconnect ARM issues and SW debugging from monitoring the core temperature, voltages, currents etc. In fact, thinking about how to separate HW debugging from SW debugging by instrumenting the PL is never a bad idea...