zygot

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.

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.

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

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.

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.

Schematics rarely lie. Though in the early days of the PC IBM was famous for publishing schematics with errors, as a way to identify infringing clone copying, much as map makers use to do.

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.

Alternatively, when using the Xilinx Standalone OS you can just access gpio and other hardware in C using pointers instead of the provided library api, just as you might for a uC application without an OS. Just be aware that even the Z7010 ARM cores are fast enough to cause bus faults for some AXI interfaces, like the Xilinx AXI-GPIO IP, so you can't necessarily poll GPIO at the highest rates. Still, if you like using AXI BRAM as an interface between your PL and ARM cores, it make for a more consistent coding style. Don't try this with a linux or RTOS OS.

There are shipwrecks caused by foolishness and shipwrecks caused by misfortune and shipwrecks caused by guile and noncompetitive practices. The Gates fortune was built on the graveyard of , not only competitors ( worthy and unworthy ) but also 3rd party Windows dev. foolish enough the believe that they would be given a fair shot at financial success investing in the early Windows tools and and the personal desktop juggernaut that was the early days of Microsoft. For the mainframe tycoons.. good riddance as far as most of us are concerned. For the benefit of the whole low cost computing revolution and all of it's paying customers I don't believe that any untold billions of $$$ of personally selected gifting will atone for what was potentially lost in the possibility of a better today. This goes far beyond technology as every successful tycoon spawns thousands of would be imitators. Well, it's all history... or not as our current and future lives are molded by the past... unless we have the will and power to change society. BTW I looked at the website of the Kintex vendor that you mentioned and didn't see anything about the board you refer to. Well, if you have a large budget then those expensive desktop FPGA accelerator cards from Xilinx and Intel might be great. A large budget isn't available to very many users of the Digilent Forums. So, perhaps I'm missing something. Where are those PCIe drivers for random Xilinx FPGA boards? Every Series 7 device seems to have some sort of PCIe hard controller but I haven't run into those pesky drivers.

It's really unlikely that timing constraints for your UART interface IO pins are causing problems with the results. A general rule for clock logic is that the delay for combinatorial logic and routing have to be less than the clock period. With no timing guidance, even simple designs can break this rule. Default timing reporting in recent versions of Vivado are almost useless, even with good IO timing constraints. Still, if you learn how to set up the reports properly they can help track down issues. It just isn't as easy a task as the older tools made it. If your hardware isn't matching your simulations then you need to add some instrumentation to the design to try and figure out why. Of course, FPGA instrumentation is true to the Heisenburg principal, in that adding logic to see what's going on in a design will alter the synthesis and place and route results, and hence timing. You could try adding an ILA to your SHA256 core and try to see what might be wrong. Often a better approach is to have a good user UI that works with serial device terminal programs and allows you to look at internal register states.

Block memory resource in FPGAs are very high data throughout and the fastest ways to transfer data, excluding transceivers. So your soft processor is the bottleneck here. If you are comfortable doing HDL design getting rid of the MicroBlaze would be a good first step. This is especially true for iterative algorithmic computations. I don't know the details of your project of course so this is just my first impulse from reading your post. I don't use soft-processors. An alternate design scheme would be to disconnect the data processing from the MicroBlaze and use a state machine to run the algorithm. You might find that the processor is not essential. If you do need the processor for some reason, it would just setup the algorithm, let it run to completion, and then access the results and do with that data as required. Understanding AXI requirements and timing is non-trivial. The MicroBlaze compatible AXI IP may or may not hide the complexity for implementation but it certainly doesn't help with calculating timing parameters for your algorithm. Well that depends on how naive you want to be with respect to the inner workings of your design. BRAM is fairly straight-forward, in terms of timing and conceptualization of the details. DDR is not. DDR implementation is also not straight-forward with respect to platform migration of a completed project design. That being said, FPGA vendors are good a hiding the details as long as you are happy with what they give you. Figuring out what it is that they give you might be a hard problem for some project goals. At first reading your project seem to be one of them. The MiG tool allows you to create HDL designs that use the DDR on a particular board but you have to create the logic that controls the read/write operations to the DDR controller. None of the FPGA vendors that I now of, and few FPGA development board vendors are too interested in helping you out with that, because, well it's just better for them if you submit to the Soft Processor vendor IP limited functionality playground. Any really useful advice requires a bit more information about a few details of your algorithm and what the application needs to do to showcase it. Do you want a PC interface for user control or data transfer or just run the algorithm, detect if the results are correct and measure the throughput? Are you pretty confident of your HDL skills or are you hoping to use the FPGA vendor IP to hide all of the nasty, hard to do implementation details? Those kinds of details separate good useful advice from bad advice. Good advice for me isn't necessarily good advice for you.

I took a glance at the information available for your sensors. Both use an interface board to create a voltage output with some relationship to the transducer output. Unfortunately, not much information about either the conversion board or the transducers for either sensor is provided. There are two major things to consider here. One is sensor output impedance and ADC ( including analog driver circuitry ) input impedance. Ideally, the sensor would have very low output impedance and the ADC very high input impedance. The other consideration is whether the sensor output is constant or fluctuating. The description of the sensors that I saw, and I only briefly skimmed through what was provided, indicates that it is not constant. A multi-meter display reports the results of some average measurement, usually under 20 readings per second. So, for a constant signal it can be pretty accurate. For a fluctuating signal the display can be very misleading. If you aren't well informed about the basics of conversion between the analog and digital domains you might think that any ADC module will work with any signal that meets a limited set of specifications, like voltage range. Unfortunately, this isn't, by and large true. The details that one needs to consider aren't necessarily obvious from the component datasheets and specifications; sometimes the datasheets and specifications that are published conveniently ignore the details that you need. I doubt that the AD1 is the correct converter that you need but choosing the right one takes a bit of investigation.. if you know what you are looking for, ADI has some good application notes and books available on the subject for scientists that aren't converter specialists.

ADC datasheets are tricky to navigate even for seasoned engineers so don't feel bad about being a bit confused. Most ADC converters, and the successive-approximation type like the AD7476A are mixed signal components; they have a digital section for sending the output code to another digital device, and an analog section that connects to the circuit being measured. The part of the datasheet that you've posted refers to the digital part of the converter and isn't likely to be related to your problems. It will help if you tell us what sensors you are connecting to the AD1 analog inputs. Trying to get your ADC to agree with a multi-meter may or may not be a good idea depending on the sensor output.

With the release of Vivado 2019.2 Xilinx abandoned the SDK framework and went with the new Vitis framework (that is to say that there is no Vivado 2019.2 or later SDK). If you really want to use the SDK instead of enjoying the work and pain of transitioning a project to Vitis I'd advise sticking with Vivado 2019.1. It has some bugs but none that are fixed in Vivado 2019.2. In fact, since the later versions of Vivado use Vitis more bugs were introduced, and less documentation is available to use it tools. It was a nasty trick on users what Xilinx did with a version '.2' of the tools.

@RTalis, I've enjoyed reading your 2 posts; interesting insights. Actually, he's constantly battling wits with one or two witless FPGA vendor's tools ( if you don't count each version as a separate tool...) all the time, so he didn't forget. He just tries to restrict commentary to encompass the minimum , except when he gets off on a tangent. I figure that if you are going to jump into FPGA development from a completely different experiential plane of existence you're already expecting to make the commitment to do it right. The elephant in the room is the question of whether or not you believe that the FPGA tool vendors will hand you everything that you need to create any application you want using their IP and GUI based tools. Given the intended sphere of experimentation noted in the questioner's post, I still think that the Cyclone V GT board is the best bet, in terms of initial cost and available support. Yes, you have a lot of work to do with the Ethernet PHY but you can use the Terasic OpenVino PCIe Centos 7 or Windows driver and provided API to do the software application with whatever language tools your pefer to use. The emphasis for getting to something useful is 'lots of work'. One ( of the many ) problem with FPGA vendor support for PCIe. Yes, the tools support the hard PCIe blocks, but good luck with using the board in a PC and connecting it to your software application. One alternative is using cores from Xillybus ( if it supports your platform ) and you can stand communicating to it as a device. The Terasic OpenVino boards are, as far as I know, the cheapest platform available as an entry to experimenting with AI and the like. I happen to really like Kintex family, especially the UltraScale versions, but Xilinx seems to have lost interest. Avent, at one point had an interesting, and affordable, board based on an UltraScale Kintex but I couldn't buy it from Avnet USA even though the same distributor in Europe has a few in stock. Avent claimed that they couldn't ship one internally to sell to me. I'm thinking that interest in setting up fab schedules to produce a few thousand Kintex Ultrascale devices isn't worth the cost. Could it be that the bill for going fab-less is now due? Anyway, it seems to me that Xilinx has decided that pushing Kintex is not in its current marketing plan. So, my takeaway points are: Don't forget about the software drive component of PCIe based applications, and don't forget about device licenses, unless you are flush with enough cash to buy tool licenses every year. At over $3000 per vendor ( or more it you want to use multiple Intel device families ) few of us can ignore the 'hidden' costs.

I can't think of a modern FPGA that won't let you create a derived clock with a phase shift relative to the source clock. Of course I suppose that you could have an unreasonable shift requirement. In general you can specify DCM or PLL phase shift in terms of ps or degrees. Perhaps you could add some details on your project goals and requirements as that is likely more pertinent to board selection and design approach. "I want a a 25 MHz clock which also has a phase shift" isn't much information to work with.

Division has always been complicated to do in logic. Those old assembler level routines to do coarse integer estimation can be good tutorials in basic math algorithms. ADI has some good literature available for its DSP devices that make for interesting reading. There are also good texts available for a variety of algorithmic computation techniques. Rarely, do people decide that they need to implement division in hardware. Since the result is rarely an integer, you need to handle fixed point, floating point, or block floating point number formats. Even in the early days of microprocessor based designs people rarely found the effort worthwhile. If you can work it out so that the division problem is x/n where n is known and fixed and x is a variable, then replacing that with x * m, where m=1/n is a much faster and simpler way to go. It's surprising how often you can arrange your design to do that. You can also convert your numbers to log(x) in a convenient base and do log(x)-log(y). For both approaches you need to select a number format and understand how to keep track of the decimal point. Unfortunately, the log(x) algorithm is also a bit complicated and time consuming. You can speed the calculation up with pipelining. The consequence of pipelining is that to get one result incurs a delay or latency proportional to the number of pipe stages. If your are pushing lots of numbers through the pipe then, after the latency to get the first value out you get a new value every clock period, so it generally makes sense when you want to process a lot of data at a time. Any time you are working with non-integer values there are lots of subtle details, like rounding and truncation effects, to keep track of to avoid errors.

Thanks for reporting your success as well as your problems. I'd have been happier to have been able to offer answers to more of your questions but it's been so long since I've use the ATLYS for video I'm not sure what PC those projects are on, and I didn't want to rely on memory. But, it's always better to see someone figure out solutions on their own anyway.

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.

As @FlyingBlindOnARocketCycleseems to have lost interest in interacting with a discussion of his post I should make it clear that his source might be useful to someone trying to learn about Ethernet and FPGA HDL implementations. It's just not complete enough to use in anyone's application. Look around this site and you will find other projects that might be a better starting point. The idea of connecting FPGA pins directly to Ethernet cables or equipment, however is a very bad idea. So is finding hardware interfaces on the internet and deciding that it's worth trying out without understanding how it works, or more importantly, if it's compatible. If you are willing to read and understand the vendor reference material for your FPGA device and are up to the task of designing suitable interface hardware then that's another matter. Digilent makes a few good low-cost platforms with a 10/100 Ethernet PHY that are quite suitable for learning and experimenting with implementing rudimentary Ethernet connectivity without resorting to MAC IP, soft-processors like MicroBlaze, or any other vendor IP. When done intelligently, I'm all for this kind of endeavor and encourage it. Ethernet is complex and has a lot of moving parts to understand so be prepared to put in some research effort and don't rely on a couple of posts. Just because something appears to 'work' doesn't mean that that it does reliably or safely.

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.