zygot

Most of my bigger Series 7 projects use the XADC to monitor and alarm the substrate temperature. It's just not reasonable to expect cheap general purpose FPGA boards to provide the kind of thermal management capabilities that these devices might need for demanding applications. It's also not reasonable to expect an over-designed power supply to meet the requirements of any application. I suspect that even boards with a heat sink and fan like the Genesys2 can get configured with a design that will over tax the core and IO bank supply design. DDR is typically located close to the FPGA and warms up the board and PCB planes quite a bit. While it appears that you've managed to do something that I haven't, which is make the power supply cry uncle, I've certainly seen substrate temperatures venture into the danger zone on both general purpose platforms and custom designed ones as well. You can use the XADC fairly easily on ZYNQ devices with the core but accessing the XADC through the DRP in PL logic with a UART provides a means for monitoring temperature and voltages when the cores and the debugger are no longer talking to each other. Of course if you lose your PL configuration that design isn't much use either. Today's failure isn't necessarily a dead end; it can be an opportunity to learn something new or at least hone a skill. It's really all about your personal curiosity and attitude as to whether failure is a bad thing or a great thing....

Yeah, sorry about that. I meant to refer to the DRP. You might refer to UG780 which is the XADC User Guide. I think that there might be a few more related references in the Xilinx documentation. I was just suggesting that you could try and tie a specific core or IO bank voltage drop to your HDL becoming active. Trying to address the 12V supply that powers the FPGA power supply is unlikely to be of much help. The supply that powers the FPGA is limited to it's design specification and can only supply current to its outputs regardless of the input power that drives it. If you are certain that you are having a supply issue then you would seem to have two choices: reduce the throughput of your HDL design. you've stated that you know where it worked before the current implementation. find a different hardware platform It's not unusual to scale a prototype design to fit within the capabilities of the prototype hardware you are working with. LD13 is ties to the FPGA supply controller "Power Good" status pin so if this is ever de-asserted while running your application then you have problems that you won't solve with a debugger. LD12 is tied to the FPGA CONFIG DONE pin and if you lose your configuration then the ARM AXI bus is sure to fault as there is nothing in the PL to handshake with. I was just trying to throw out some suggestions for you to cogitate on.... one never knows what might provide a useful path to get by a roadblock. Personally, I have no problem starting a side project as an effort to solving a seemingly intractable problem. Sometimes these lead to new and fruitful lines of inquiry that I'd not have considered pursuing otherwise. Worst case is that I have a new tool to refer to when I encounter a similar issue.

Try to eliminate the power supply as the main issue implement XADC in PL logic using DRU add a UART to spit out alarm conditions and or voltages. There are some code examples in the Project Vault area. There are some good 3V compatible TTL USB UART cables and breakout boards from Adafruit and Sparkfun. I have 4-5 laying around and in general most are in use on some project or another. I don't know how your Arm cores connect to your HDL design but try and add some enables to parts of your design to help identify what portion might be causing issues. Try and create a separate debug path in your HDL. Obviously the SW debugger is of no help once the ARM core has faulted. What are you looking for in simulation and HW synthesis or P&L messages? I don't know. Doubling your pipeline latency and clock can introduce unexpected design issues. A good simulation testbench can often help identify areas of interest. The general idea is track down things that you suspect are a problem and divide and conquer parts that might not be obvious areas of problems.

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...

@Pavel Thanks, I was trying to find that particular@hamster post and gave up. it's another interesting idea similar to the one that Dan posted with reference to Sigma Delta modulation.

FPGA output buffers aren't designed to drive reactive loads directly. I suppose that the code that you want to try out may have a lot do do with how you might want to create audible tones. The standard PMODs provide some protection but also limits drive current. The link mentioned above might be interesting and wouldn't cost very much but might not be the best way to use the code you refer to. There are certainly other suitable and inexpensive ways to safely drive a speaker as well. I'm not sure what you mean by 'output impedance of the PMOD connector'. One question to consider is the accuracy and quality of the tones that you want to produce. Dan's project does not produce anything resembling professional audio quality. I believe that Digilent sells an audio codec PMOD as well.

Since the early days of ISE Xilinx has has a habit of releasing tool versions that were just too buggy to use. 20 years ago you could find a vendor FAE who would be willing to steer you around the bad tools.. off the record of course. There was a time when Altera Quartus was quite bug free and reliable. Those days are long gone. Now, it's almost impossible to install the latest tools on any particular version of an OS and hope that they are supported... much less are reasonably functional to where you can work on your projects rather than hunting down bugs and work-around fixes. The impetus for this post is a recent experience with Quartus 20.1 in Win10 for a PCIe based project. Quartus 20.1 supports the Cyclone V/IV. Quartus 20 versions later than 20.1 not so much. What I found out is that I can use Quartus 20.1 on a number of Linux platforms for Cyclone V PCIe projects but not on Win10. I haven't tracked down a fix yet as what I really want to do is complete my project. So, I can use Quartus 18.1 on WIn10 or Quartus 20.1 on Centos 7 or Unbuntu 20.04. The idea that if you want to build a particular project, or even recompile a demo designed with another version of the tools, and be required to install not only the exact version of the tools that the original project was build on but also install a 'supported' OS that meets the criteria for a particular tool version is pretty absurd. It's also absurd to spend more time working out tool bugs than working out your project. Mostly these problems revolve around vendor IP, but the vendors make it impossible to implement some projects without using one or more of these. If your current project is a derivative of a project from a third party then the odds of completing a project in a reasonable amount of time are pretty low. I realize that this is a bit of a rant but the typical reader of the Digilent Forums are no stranger to the kinds of problems I'm talking about. Since even smallish companies can't expect good technical support from the vendors or distributors who's going to step up and address the issue that currently the tools from the major vendors are broken. It would be nice if board vendors providing support for their products would do that.. if allowed. This doesn't have to be as bad as it is. At least knowing what to avoid or a list of how to set up the tools for actual OS versions that we use would be nice. I think that it's time for the FPGA partners making development hardware to step up and start doing what the typical user can't and that is push back on the device vendors to make life for their customers a bit more productive. This starts with how they support their own products.

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.

I didn't notice that tutorial. A lot has changed between Vivado 2015 and Vivado 2019.2. But you point is well taken. It might not be totally unexpected to run into snags trying to upgrade a project from one version of Vivado to another but expecting a tutorial where you build a hardware project from scratch to work, regardless of the tools version, seems to be pretty reasonable. It's possible that the original tutorial had things missing. You could try installing the same version of the tools as the tutorial used and see if that makes any difference. You might find that Vivado 2015 is a better tools version for some of your projects depending on what IP you want to use. Notice that the Ethernet functionality requires a temporary evaluation license so your hard work won't last long anyway. Your experience is one reason why I don't use MicroBlaze or the board design flow, or even Xilinx IP in general. Another reason is that when things aren't going well trying to debug it or closing timing is a lot easier when I have HDL source code that I understand. I really like the Genesys2. If it had 2 standard SYZYGY and 1 SYZYGY transceiver ports instead of the PMOD connectors it'd be almost perfect as a general purpose FPGA platform. Because it has a faster speed grade device and the more capable Kintex device I've found that prototyping ideas is a lot easier than with the normal Artix boards. That is I can try out concepts without worrying too much about timing closure... except for DDR and Ethernet PHY interfaces.

The block diagram makes everything look simple doesn't it? Both the DDR and Ethernet RMII interfaces are non-trivial and require good timing constraints to help the synthesis and place and rout tools make good decisions about where to put the logic in order to meet timing. I don't use MicroBlaze or the block design flows so I can't really help you with that. Digilent seems to have a User Demo for the Nexys Video board using the DDR and Ethernet but nothing similar for the Genesys2. Their support for the Genesys2 has always been worse than other boards. I don't think they've ever provided a demo that is comprehensive as far as all of the external components and connectors are concerned. Throwing combinations at the wall is just going to tire you out. You need to learn how to figure out what the problem(s) is (are) and address them all. One way to get really poor implementation results is to make the tools try and analyze timing for a lot of nets associated with different clock domains. You might try looking at the inter-clock timing. Using a signal created by one clock domain and used as an input to logic in another unrelated clock domain is a pretty reliable way to get the tools working onb solving the wrong problems... resulting in excessive delay paths. Xilinx has a nice user guide for timing closure. Unfortunately, the block design flow gives the impression that the tools are going to figure out all of the design requirements and do all of the hard work for you. Sometimes this works out OK. When it doesn't unwinding the design from the script generated design sources becomes very difficult, and in the case of parts of the Ethernet impossible as the source is encrypted. That's the price of convenience and trying to implement something that you don't fully understand. You can look at the implementation logic placement to get a feel for where logic is relative to the IO pins, but this is complicated with the MicroBlaze stuck in the middle. You can also hunt down all of the constraint files to see what timing constraints, if any, the board design generation process gave you. If you are going to do serious FPGA designs do you really want to rely on a third party who says "Hey just put my soft-processor in your design and drag and drop more IP into a schematic and I'll do everything for you", and then when you get a non-functional result is nowhere to be found? Are you expecting your FPGA board vendor to come to your rescue with answers? Perhaps you'll get lucky but that's not likely especially if they don't provide good support for your board that works with your versio of the tools.

Well that doesn't sound like a problem with your board. It does sound like a problem providing proper timing constraints and resulting in a poor place and route implementation. The Kintex device on the Genesys2 is more than capable of doing both interfaces simultaneously. What kind of timing scores are you getting?

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.

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.

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.

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.

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.

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.

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.

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.

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.