zygot
-
Posts
2,859 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Posts posted by zygot
-
-
If you look at DS180 Table 5 you will see a list of all of the Artix Device-Package options with HP IO Banks... none.
@JColvinprovided the correct answer; that is trying to modify your Arty/CMOD ???? board to use one of the 1.2V standards is a bad idea.
Perhaps you could provide a motivation for wanting to do this and someone could point you in the right direction to achieve your goals. If you really want an FPGA platform with an entire IO bank powered with Vccio = 1.2V you are better off buying a board that was designed to do that. There are UltraScale ZYNQ boards, like the Ultra96V2 board that has two 1.2V banks exposed to IO headers. The GPIO headers on the Mimas-A7 are attached to IO banks that are powered by 3.3V but you can change that to 1.2V by changing the value of one resistor.
Unfortunately, the dual power supply level-shifter approach isn't very high performance if that's what you are after and some of these level translators come with a lot of small print in the datasheet complicating their usage. But you can always design some sort of digital interface to make your 3.3V IO compatible with any other logic standard. That's the preferred way to do what you want.
You can't 'configure' an IO bank to have an IOSTANDARD. Depending on what Vccio voltage a bank is power with you can select from a list of IOSTANDARDs that are compatible with that voltage. Of course, there's more to it than that. Some logic standards require termination. But even if you have all of that correct there's still the issue of how the signal gets from the FPGA ball to some connector pin by a copper trace on a printed circuit board. If your FPGA platform is designed to support a given IOSTANDARD then you can, or should, be confident that you can implement a project with success.
-
Well, as you can see those pins are not connected to anything. Some ZYNQ based FPGA boards have a PMOD or other connector connected to unused PS_MIO pins but your board doesn't.
If you need a second UART you can export the unused PS UART to the PL though the EMIO and either connect the pins to PL logic or PL GPIO. JA or JB seem to be your only options for your board.
-
Be aware that evaluation licenses are temporary.. so not very useful. What you are really paying for with FPGA vendor Ethernet IP licenses is the MAC code which all FPGA vendors provide only in encrypted form. Fortunately, you don't have to use the vendor MAC, or even any MAC for that matter.
-
The addresses for AXI mapped peripherals are defined in the board design interface, if using that hardware design methodology. You can find all of the hardware design information in the SDK in the files that are exported to the SDK from Vivado; system.hdf and system.mss ( assuming that system is the name of your board design ).
Unfortunately, the hdf file isn't readable in a text editor, but you can read it in Eclipse when the SDK is open.
-
5 hours ago, Babu said:
who responsible for this?
Ultimately, it's you the user. Yes, documentation can be confusing or have errors; and does so more often than anyone would like. When users run into these situations all that they can do is notify the vendor and hope that corrections are made. Never connect any external hardware to your FPGA platform until you've worked out the details to verify that there will be no nasty surprises. This is especially true when buying hardware from a vendor other than the one who designed and sells your FPGA platform. This is especially true when using external hardware that your FPGA board vendor doesn't list as compatible.
Personally, I've never had an issue with Digilent JTAG cables and boards from any other Xilinx vendor.
-
Your picture doesn't actually show where all of those wires go...
Using flying leads for configuration isn't recommended. Assuming that you have the wiring correct, have you tried slowing down the configuration clock rate to 1 MHz, just to see if there isn't some connectivity with the HS3? Jamming pins meant for 2.54mm header sockets into 2 mm header sockets can cause mechanical connectivity problems. I'd be surprised if you can configure your board with a 30 MHz JTAG clock given your setup. A JTAG cable with an inline header plus an adapter to connect the pins to the Mimas-A7 JTAG header is a much better way to go. As I mentioned I've been using the HS1 RevA cable ( plus a custom adapter to align the signals correctly) with no issues.
On Win10 the list of supported devices for the Adept Utilities is here: C:\Program Files (x86)\Common Files\Digilent\Data\jtscdvclist.txt
In jtscdvclist.txt search for XC7A$T where the DEVICES{ are listed and add the following line: 50 0362C093h 0FFFFFFFh
The adept Utility will then correctly identify the device by its IDCODE.
The Digilent USB JTAG cables might be expensive but they are way cheaper than the Xilinx Platform Cable USB that Numato Labs recommends as compatible with your board.
I'd really like to connect my HS3 to my Mimas-A7 to confirm that the cable isn't an issue but I still can't find that pesky 14-pin to 6-pin adapter that came with one of the Digilent cables. [edit] I just realized that what I was looking for was a 6-pin to 14-pin adapter that came with the HS1... so it won't do me any good anyway. Frankly, it's just not worth my time to cobble up an adapter for the HS3 for use with the Mimas-A7 as I already have a working solution. Perhaps you could shoot off an email to Numato Labs support suggesting that the next rev of the board has a cheaper JTAG solution for working with the Vivado debug tools.
I really like this board. If it had 2 mm GPIO headers, one header on Vccio = 2.5V banks and the other on Vccio = 3.3V banks ... or better yet user select-able Vccio for each GPIO header, it would be almost perfect for the price. THose 2x40 pin headers are just too long to be useful; 4 2x20 pin headers would be better. It's a shame about the configuration methodology. I shy away from boards that need proprietary (sans source code) software for configuration, but the Mimas-A7 does have a 6-pin JTAG header, though unfortunately not wired to work with Digilent JTAG cables. I've modified my board to have 2.5V Vccio for the GPIO headers because, well they did all of that work laying out well matched differential signal pairs to the headers.***
BTW there's a reference manual for the HS3 here: https://reference.digilentinc.com/programmers/jtag-hs3/reference-manual
The manual is recommended reading, not only for users like you who want cheap JTAG connectivity for non- Digilent FPGA boards, but mostly for potential JTAG customers before they make a purchase.
*** Hint hint to Digilent. The Mimas-A7 is a cheap rip off of the Nexys Video. If you made a rip-off of the Mimas-A7 with the suggested improvements above and modified the FT2232H to look like a Digilent programmer you'd have a very fine platform to sell to your customers. I'll buy a couple....
-
5 hours ago, Babu said:
I verified with HS2 and Artix A7 FGPA its detected
So, are you saying that you were able to configure your Mimas A7 using the HS2 cable?
The recent HSx cables come with a 14-pin 2mm female header. How exactly, are you connecting the HS3 to the 6-pin inline JTAG header on the Mimas-A7?
I mistakenly wrote that the Mimas-A7 uses a 75T device. It uses a 50T device. I checked and, to use the Adept Utility on WIN10 with the Mimas-A7 I did add a line for the Artix 50T IDCODE to jtscdvclist.txt that the Adept Utility uses to identify the device. I have an HS3 cable but can't locate the inline adapter or I'd confirm that my HS3 cable works with your board.
With JTAG being able to detect a device doesn't guarantee that you can configure a device.
-
2 hours ago, Foss_enth said:
I understand the advantage of PYNQ as an excellent way for rapid prototyping without requiring much knowledge about FPGA - Python API abstraction makes the process resemble microcontroller programming.
I agree and couldn't have said it better, excluding the reference to excellence. The problem with this approach is that it stunts your growth as a programmable logic designer. It's also a walled garden that you will find frustrating to get out of once your project dreams outgrow the free IP and layers of user interaction.
An opinion to consider.
I'm not a believer is quick and easy. Learn FPGA development as it should be learned; as digital design. Sooner or later you will need to anyway.
First, assuming that you are coming from a software development background, you need to grasp the basic differences between an HDL like Verilog or VHDL for programmable logic synthesis and a traditional software language... or even an HDL for simulation. For this approach you'll want a basic FPGA platform with basic IO hardware. The ARTY A7 is a fine choice as it has a UART, 100 Mbps Ethernet, DDR etc... the basic stuff you will want to play with. The De0 Nano is also nice as it has an easier to use SDRAM, but lacks the UART and Ethernet. You can always use a TTL USB UART cable or breakout board for UART connectivity.
A requirement is the ability to use the traditional JTAG configuration methods like the Vivado Hardware Manager or Quartus Programmer/SignalTap. If it's hard to configure your FPGA without using those means, then this is a problem.
To get started a few LED outputs, button and switch inputs, a good code editor and a good simulator is all you need. You'll write your VHDL entities, and testbenches. Then you'll simulate the designs. Then you can try out design on hardware. Until you are comfortable and competent writing and verifying basic designs in the HDL of your choice ( I recommend starting off with Verilog even though my HDL of preference is VHDL ), avoid soft processors and all of the related vendor IP. The extra software development will just get in your way and make everything more complicated. DO use the clocking and clock memory IP with native interfaces.
After you are feeling competent you will be ready to choose a hardware platform with specific hardware supporting particular projects; also you might be ready to jump into using a device with an embedded hard processor like the ZYNQ.
Tip: Basic FPGA logic design and development doesn't require vendor IP, except perhaps at the toplevel entity of a hierarchical design where you might need a clock rate other than the ones supplied as external clock module inputs to the device. Quartus provides a version of ModelSim for free. The Vivado simulator really isn't set up to encourage good verification habits. Also, Vivado has never gotten around to allowing you to easily view memory in simulation; something that ISE ISIM did. As long as you can avoid FPGA device specific feature references in you code modules/entities you can use ModelSim regardless of what vendor you want to target your design to. I frequently use ModelSim for low level HDL simulation for all vendors FPGA based platforms.
-
The Mimas A7 JTAG header is wired in a way that isn't compatible with the Digilent JTAG cables without inserting an adapter between the cable and the board. I changed by Mimas A7 to do Synchronous 245 FIFO mode and can't use the official download application because I modified the jtag endpoint descriptor inadvertantly. This can be fixed when I get around to it. I currently am using old HS1 revA cable for configuration without issues. The Mimas A7 uses an Artix 75T device which is not one of the devices that Digilent uses. I don't recall if I had to add a device to the Digilent Adept support device IDCODE text file or not... probably did.
Anyway, you can use the Digilent JTAG cables with your platform if you take care of the details. I've been doing it for some time now.
The rule is: Don't assume that any JTAG header is compatible with any header that can plug into it. Refer to the schematics before attempting to use hardware that isn't supported by your board vendor. As I recall, Numato Labs suggests using a Xilinx JTAG solution for this board.
-
Vivado 2018 or 2019.1 should be fine. Vivado 2019.2 breaks the SDK and IP format. For a device like the Z7020 Vivado 2018 is great.
The original Zedboard was a collaboration of a number of companies but recently Digilent seems to be making and supporting them. There are a limited set of hardware changes from the current board to the most recent. I suggest tracking them all down and creating a text list available for your development. If you select a board as the target in Vivado it's not always clear what version is being selected.
In general schematics are the 'gold standard' for figuring out pin location assignments. Schematics are usually the only way to determine IO Bank Vccio and possible IOSTANDARD selection. Be careful with published 'master xdc' files, even from the vendors. Digilent has had errors in a few of them for years. When connecting hardware always check the schematic. Make sure that the schematic represents the version of your board and that your constraints pin assignments match the schematic. You only have to do this for projects using pins that are different from tried and true older projects.
Avnet still has a website with old projects, material and user discussions of the Zedboard but you have to be careful of tool version changes.
As one 'old school' guy to another, to the extent that those habits force you to do your due diligence and prep work, that's a good thing.
-
Chipscope is an ISE tool add-on. Vivado has its own ILA and VIO capabilities built in. For Win10 users I suggest sticking with Vivado. Since the Zedboard is the 'old man' ** among FPGA platforms, the good news is that you can use earlier, and easier to install, versions of Vivado. The latest versions of Vivado probably aren't the best choice for older boards and devices anyway.
** Nothing wrong with being old... if you are good at what you do and this applies to the venerable Zedboard. Just be aware of the board version changes relative to tools and using code examples in the wild.
-
17 hours ago, Tomas Sarquis said:
The purpose of the design is quite simple: digitalize some AC signals and then process them.
Perhaps that's the purpose but it isn't a description of how the design is supposed to work. No one can help you debug your purpose but perhaps they might have some insight into how you can debug the design. So... again, how's the design supposed to work as you envision it?
17 hours ago, Tomas Sarquis said:how could I simulate the IP behaviour without synthetizing and using the "real" ADC?
I should simulate all the internal signals and responses? That sounds pretty complex...There are a lot of ways to replace the ADC devices in your simulation testbench. The easiest would be to have a process that spits out incrementing data. You don't have to worry about output code formats... just refer to the ADC datasheet and make sure that the data is transferred accordingly. One of the nice things about Verilog for simulation is that you can use parts of Verilog that aren't supported by synthesis. You can read a file with ADC sample words and feed that into your testbench. Trying to see "actual real-world ADC sample data" in a simulation probably not a good choice for a number of reasons.
Really, the more important thing about the simulation is getting confirmation that, on a behavioral or RTL level at least, the whole design is doing what you think that it's doing. Simulating ADC formats isn't necessarily the first thing that you want to do.
I realize that there isn't a lot of texts available on good simulation techniques but you need to develop your verification chops in step with your design flow skills.
One problem with designing testbench code is that you are adding another thing to debug. It's analogous to unit testing software modules. The point is that, as your designs get more complex and hard to follow, your verification skills need to get more sophisticated and crafty as well. Your problem isn't that your design isn't working.. it's that your debugging skills aren't up to the task of figuring out how to find the cause of it's not working.
-
I appreciate that throwing code over the wall and hoping that someone spots the (hopefully) one or two defects that will fix the problem is an easy and quick solution... it's a common approach around this forum.
Perhaps there is a more productive way.
First, since you want to do an all HDL design your sources are missing at least one key element... a Verilog testbench. Part of the design process is verification, and at a minimum behavioral simulation is one part of verification. Simulation will help figure out what's going on with your design. To my way of thinking, if someone claims to have a design and there are no testbenches among the sources, then my first thought is to suggest that they still have some work to do before trying to implement an unfinished design in hardware.
If someone came to me in person with such a question as yours the first question, even before "where's the testbench?", would be "start by providing a brief description of how your design is supposed to work". Perhaps, you could start with that. I can't tell you how many times just asking that question has produced answers to questions; as having to put into words a representation of an amalgam of concepts often reveals bad assumptions and missing elements. Having someone stop, mid sentence as the lightbulb turns on, is most satisfying for everyone.
-
2 hours ago, MaxDZ8 said:
Pulling in the XADC measurement took more effort in finding the documentation than the work itself but the process has been straightforward.
Yeah, but now that you know how to do it the next time will be easy. I strongly encourage using the XADC for all more serious Series7 projects, fan with heat sink, heat sink without fan or nothing at all. If you don't check on things you are just operating on assumptions. In electronics ignorance is rarely bliss ( for long ), especially of you are pushing your hardware.
I kind of agree with you that LUT52% FF68% usage, with minimal or no IO being driven ( I assume ), and clocked at 200 MHz shouldn't cause your platform power supply to roll over and play dead... but that's the nature of this class of boards. As I mentioned the more expensive FPGA hardware comes with a more robust power supply design. Regardless, I'm pretty sure that 1 unhappy customer out of a thousand isn't going to change the way that these boards are designed. I'm betting that 90% of the projects done on them use less than 20% of resources... just a guesstament.
I hate to mention it at this point but there's still that outside, low probability chance that something has gone wrong with the 12-pipeline 200 MHz build. At this point, personally, I might be curious enough to try a few builds sliding from 100 MHz upward to see the power dissipation curve... but I can get overly curious. Most likely it's the hardware platform.
Thanks for keeping us informed about your experiences.
-
3 hours ago, Evocati said:
So I only need a PMOD cable to connect 2 FPGA boards like this, correct?
Well, no. A 12-pin or even 6-pin PMOD cable would violate the 2nd tip: Don't connect Vcc rails between boards. They are fine for PMODs because the add-on boards need Vcc. It's very easy to create big problems with cabling; you have to verify that the cabling is connecting the proper pins together, and nothing else. For 1 MHz signals it's probably ok to use flying leads. You can buy 6" leads with female-female headers, male-female headers or male-male headers from places like Adafruit. You want male-male wires. To be safe you might stick both ends of a male-male lead into each of the mating PMOD connectors; that is connect pins 6 and 12 together for each PMOD. That way you won't accidentally make contact with the Vcc pins with your cabling. The best way to do this is to make a custom cable. Since the PMODs are not keyed it's pretty easy to get things wrong. Verify connectivity with an ohmmeter before powering anything. Never connect or disconnect inter-board cabling while either boards is powered on.
3 hours ago, Evocati said:is there any IPs needed inside FPGA to be used as RX/TX to drive the PMOD?
I use the HDL design flow so I just need to declare a signal as in, out or inout on the toplevel port declaration. The best way to handle external signals is to instantiate the appropriate buffer in the toplevel entity using a primitive. If you don't do this the tools will automatically instantiate one for you, as long as your constraints file has the same name as the toplevel port declaration. If you are using the board design flow you can just make a signal external and the tools will instantiate a buffer. If you want a particular buffer type then you need to instantiate it in your design. Frankly, I don't use the board design flow, except for ZYNQ designs and my toplevel module or entity is always a VHDL or Verilog source file.. so I've never tried selecting a buffer from the IP catalog.
As preparation, make sure that you read the Series 7 Select IO User Guide. There is also a guide for instantiating primitives in HDL, I think that it's UG768.
Once you start doing designs that don't use the limited Xilinx IP or Digilent PMOD IP you are much better off using the HDL design flow. This not only gives you more control over your design but forces you to think about the details.
-
2 hours ago, MaxDZ8 said:
I need some more time to digest all this content. I feel the need clarify a key thing. There has been a time I when I followed and even advocated for best practices. In my spare time I cannot quite stick to it anymore - just today I got assigned to yet another year-long project which would require a whole team and I'll need to complete in in a few months!
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?
-
6 hours ago, MaxDZ8 said:
I flipped a bit in the 'start work' functionality which would cause the device to almost never transition back to ready state
This is where simulation can help, especially when making major modifications to a 'rock solid' design.
6 hours ago, MaxDZ8 said:I can't bother pulling the old, known-to-work design for testing.
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.
-
4 hours ago, MaxDZ8 said:
For the purpose of future readers, I think it is a good idea to document the progress
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...
-
19 hours ago, MaxDZ8 said:
My plan was to move this on A100 but with the ridiculous situation with silicon now, odds are I'll need to wait at least another 2 months!
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....
-
6 hours ago, MaxDZ8 said:
I have dumped "fpga DRU" in duckduckgo
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.
-
2 hours ago, MaxDZ8 said:
have difficulty boiling down the suggestions to a concrete course of action.
-
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.
-
Try to eliminate the power supply as the main issue
What checksum is used for the Cmod A7 EEPROM?
in FPGA
Posted
Wow, that sounds dangerous.
FT_PROG is a utility for changing the configuration values of the EEPROM connected to FTxxx devices like the FT232, FT2232H, etc. If you aren't careful you can use it to render unusable random USB hardware connected to a root Hub in your PC that happen to be using one of those FTDI devices. Why would you want to do this to a part of your FPGA board that is responsible for configuration and UART communication?
If you want to change the contents of a FLASH device connected to your FPGA FT_PROG is not the appropriate tool.