zygot

Yeah, I sometimes get sloppy with some projects. But here's a different way to think about making the best use of your very limited time; it's one that I keeps getting thrust into my mindset by complicated projects. For 'side' projects this is all about self-preservation and self-defense. Spinning my wheels is more frustrating than forcing myself to do some sort of code version preservation. There are no hard rules and you don't need versioning tools. Just zipping up a project when you know that there are going to be major changes is often sufficient. Developing some good, simple, habits and processes might only pay off big every so often.... but when they do it saves you so much time. Archiving whole project snapshots is good because you can compare messages, reports, simulations easily. You can also add measurement instrumentation to both the old and new project. If there's an unexpected major change in behavior it might help find unintended changes. Anytime you're using Vivado board design to create code there is that potential. I've seen Vivado do some very strange things when I make minor changes. (I should mention that I never use the board design flow except for ZYNQ projects ). Somewhere, there's some good balance between working on a project and doing what's needed to evolve a project without encountering undue pain. What works for me doesn't necessarily work for you. Some projects turn out to be as simple and straight-forward as expected. Others, not so much. If you think about it, projects done for personal growth are no different than those done for work ( aside from the usual noise associated with a team project having a strict deadline ). They both take up your time; so why not make the time you have as productive as possible? Just some personal thoughts on the subject.

I thought of something that I forgot to mention. The standard PMODs are good for low toggling rate interfaces. Also they have 200 ohm series resistors that, to some extent, help protect from ESD and shorts, both temporary and long term, and to a lesser extent transmission line issues. Even still try and keep cabling as short as possible, especially with flying leads.

I've done this many times. What boards are your using? Tips: make sure that you have a good bonding of the GND reference for both boards, especially for single-ended signals. PMODs have 2 GND pins. Don't connect any power rail of both boards together Before configuring both boards as a connected system take extra precautions to be sure that your have assigned the pin locations correctly; that is check the post route pin assignments. Make sure that there is no possibility of contention. The pin on the sink side should be an input only and the pin on the source side should be an output only. For relatively slow signalling assign output driver SLEW as slow and output drive at 4 mA or the minimum available for the first test. Open-drain or open collector outputs are one way to connect drivers safely. The safest way to connect external hardware is through external buffers as a protection for the FPGA pins. Before powering anything double or triple check the interface wiring and design. Be aware that the PMODs are not keyed... so it is possible to have connection/cabling issues with potentially disastrous consequences. You don't want to tie the GND and VCC together or drive output buffers into either of those rails. What exactly are your concerns?

This is where simulation can help, especially when making major modifications to a 'rock solid' design. I've found that, when not confined to a code versioning system, archiving a project that is at a 'good stopping point' before making changes is a good practice. This make is easy to refer back to a previous known state in the project. Sometimes it just makes sense to keep archived snapshots of just the HDL source. Sometimes, it makes sense to save the project as a new one so that I can open either the old 'working' version or the new 'in progress' version. This is really no different than standard software development except that the FPGA tools create way more intermediate files on the HD. Not everyone works the same way but I thought that this was worth mentioning... you know, for future readers who might find it interesting.

I second that motion. If you open the Xilinx Document Navigator and do a search for XADC you will see quite a few references, some with code examples. On the subject of your temperature measurements. I also have an IR thermometer as a quick 'safety' check when I connect new external hardware. I do this mostly in case there is bus contention or driving outputs to ground**. As a more general measurement as to how your components are faring when there aren't any defects in a design I would caution against putting too much faith in such measurements. Fortunately, the Series 7 devices all have the capability of measuring substrate temperature using the XADC. This, in my view, is the proper way to assess thermal conditions. All of the components on your board have maximum operating substrate temperature limits that need to be adhered to. Let's recap the post so far. As I understand it, your initial observation was that once your PL design started running 2 LED indicators indicating the health of the power supply and FPGA configuration status indicated that both immediately indicated failure conditions. After this your communication between the SDK debugger and the ARM cores stopped. It's certainly reasonable, barring other considerations, to suspect that a drop out of some of the power supply rails precipitated these events. The next step might be to try and prove this hypothesis, and perhaps find a way around the root cause. The ZYNQ has a number of PLLs on the PS side that generate derived clocks for all of the internal peripherals like DDR controller, Ethernet PHY, UART baud rates and of course AXI bus clocks. You can export these clocks to your PL. You can also use the PL MMCM and PLL clock generators to generate PL logic clocks. There's no wrong way to go as long as you adhere to basic clock domain principals for passing signals between clock domains. There are a lot of ways to do this correctly, but of course there are a lot more ways to do it incorrectly. Most high speed data transfer involves elastic storage, like a circular buffer or a FIFO. If there are two clock domains involved then the FIFO and buffer must have 2 clocks. The full AXI BUS is not trivial to work with and there are a lot of ways to cause bus faults. Bus faults will certainly terminate your debugger session but I have no idea how they could cause the power supply controller to fail to regulate an output rail or cause the logic to lose configuration. ( I also don't do a lot of ZYNQ design work so I haven't had the need to do some serious investigation into all of the details about those devices... and the interesting details are usually not easy to find in the literature ) I'm not at all surprised by the push-back to my suggestion that expecting a cheap general purpose FPGA board aimed at the educational sector be able to handle the full capabilities of the FPGA devices is unreasonable. The Series 7 devices are really quite capable. What separates expensive commercial or military grade products from something like the Arty Z7-20 is testing and guaranteed specifications. That's what you're paying for when you buy expensive products. It's easy to underestimate the cost of over designing a power supply for a low profit margin product. I don't know of any vendor of general purpose FPGA boards in the educational market that provide a demo project that even attempts to explore the maximum operating conditions of their boards. In fact, it seems to me, that for most of these boards the vendors are banking on the user to create projects that use only a small subset of the external interfaces, and IO, and FPGA resources available and that few will ever need to do timing closure because of high clock rates on most of the logic resources. Beyond simply using a beefier power supply other ancillary costs usually go with enhanced performance, like more PCB layers, heavier copper planes, etc. , etc. Estimating production costs verses profit is a complicated business... and many companies don't do it well. ** You might think that this is the result of bad design processes, and in the end I suppose that you'd be correct. But it's a lot easier to get into these conditions than you might realize. A location constraint might be wrong or ignored by the tools ( always , always check the post route pin assignments) or perhaps you didn't get the timing constraints correct. Sometimes the tools automatically resolve a misunderstanding between your source and what they infer as your intent; and the only indication is a warning, among hundreds of messages, that something is terribly amiss. There are a lot of critters in the swamp of FPGA development waiting to take a bite out of you if you fail to notice their presence...

Xillinx branded boards typically have more robust and heftier power supply designs.. at a cost premium. The ZC702 is a Z7020 board with 2 FMC connectors and might work. Unfortunately, these are no longer in production and the ones in distributor stockrooms have undergone a dramatic price increase over what the originally sold for. I don't know it Xilinx sells them directly anymore. The older Ti power module designs though can be a pain when things go wrong and are a bit clunky. I've had experience with this. Always refer to the schematic as part of your pre-purchase analysis. I do like the idea of going with a non-ZYNQ platform if you don't need the ARM cores. It is indeed frustrating to find out that your purchased platform can't keep up with your project requirements. Doing your due digilence before purchasing hardware is goo practice and, as you've likely found out an expensive lesson. Fortunately, the Vivado tools can help with power estimation though when a design has lots of output pins being driven accurate estimation requires some detailed analysis.

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

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.

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.