asmi

Landing page for JTAG programmers say 1.5V is only supported by HS2 cable: https://store.digilentinc.com/jtag-programmers-fpga-programming-solutions/ However product pages for both HS2 and HS3 say only 1.8-5 V range is supported. Can you please confirm if HS2 and/or HS3 support 1.5V signaling?

I fail to see how your statement that AXI bus is difficult and "was chosen to waste gates" is going to be helpful to the OP. I don't even have any Zynq boards. All my Zynq-related experience was in commercial projects. I prefer working with "pure" FPGA designs. Although that might change soon as I've managed to score few Zynq-030 chips for cheap, so will build a board if and when I will have enough spare time. Even these holidays I will be assembling boards for my customer, so no time for personal stuff :( I also got few Kintex-325 chips from the same source, so I'm really looki

I can't post anything from my work, but I seriously don't understand what the heck is your problem. Do you want me to show you how to send a read request over AR channel? As in - "assign "1" to "arvalid", assign address to "araddr" set up other transaction parameters (arlen, arsize, arburst, etc) as required, wait for "arready" - that means requests is accepted. Then raise "rready" signal over read channel and look for "rvalid" signal which will indicate that you have valid data on rresp lines, which will tell you if request was successful or not, and if it is, the data you've requested will b

So don't use it. Nobody is forcing you to use it, right? You can use AXI Interconnect, which works with any masters and slaves. That last part is nonsense. And you know it all too well to spread this conspiracy BS. Don't place words into my mouth. I don't care what they do or don't prefer, what's important is what I prefer. I don't have time for that, too busy for customer's project atm, but I genuinely don't understand what's the actual problem? Is posting a read request over AR channel and receiving a burst over R channel is really that mind-bogglingly hard to compreh

That is just nonsense. AXI bus by itself does not require any gates, if your core requires a ton of gates to connect to AXI, that's because your design sucks, not because AXI is bad.

Again, there is nothing complicated in AXI bus design, it's used in pretty much all SoCs currently on a market which is why I suspect they choose to use it as well. Same reason why it was chosen for PL-PS interface because they can just connect it to internal AXI buses they already have in PS part. And I also disagree about it being inappropriate. I use AXI and AXIS buses very extensively in my own designs, and overall very happy with them.

That is not an easy question to answer, because feature creep is real, and so you will have to know when to stop, call it "done" and ship. Otherwise you are risking to be stuck in perpetual "almost done" state and never actually shipping anything.

I'd say if AXI bus master or AXI-lite slave is complicated for you, you'd better stay away from FPGAs at all as these are among the simplest things you will encounter. AXI spec is just a bit over 100 pages long (if you exclude ACE part), which is very small compared to some other standards you will have to deal with (803.2 is over 4000 pages, DisplayPort 1.2 is ~500, PCI Express 3 is ~800). Full AXI slave is usually the most complex because you generally have no idea what kind of requests you are going to receive, and so you generally have a choice of either implementing it "good enough f

I'd say the biggest problem with using USB for these designs is the fact that USB is a shared bus which gives no guarantees regarding bandwidth, and it can vary wildly depending on how exactly your device is connected to the root port, and what else is connected to the same logical bus. Typically this is not a problem for video streaming applications as even if some pixel data is lost in transit, it's not a problem because human eye is unlikely to notice few odd-colored pixels within a single frame which is shown for just a fraction of a second, but it might very well be enough for the n

What you need to do is to find out what did you change, and next time think before making changes. That said, if you messed with MIG there is a known issue with the wizard when it doesn't properly recall the frequency it's set to right here (the screenshot is from the different board, but the field is the same): You need to make sure this field is set to 166.667 MHz. Once you fix it, keep clicking "next" until the end of the wizard and then regenerate everything. The bad news? You will have to do it every single time you run the MIG wizard to completion. The good ne

Yes it can. This is a screenshot from the reference manual. I don't understand this question. Don't understand that one either. What does power pins have to do with timing? No, these are dedicated input-only pins for transceiver clocks. But not to worry - there are 160 other pins that you can use as GPIO.

That is exactly how "indirect programming" works. Software first programs FPGA with a bitstream that acts a bridge between the JTAG and QSPI memory, and then programs flash with the data you've selected. At least that's how hardware manager works in Vivado, but I have no reasons to believe that impact is any different. I use HS3 cable to program bitstreams into QSPI flash all the time in Vivado with 7 series FPGA.

<duplicate>

That's the essence of the question - how do you find out what that "known" frequency is if you're designing a component which is meant to connect to external clock which you have no control over?

He's not talking about that, but rather he wants to know the frequency connected clock is running at synthesis time. This is often needed to calculate a timebase if you have some logic which is supposed to work with real time as opposed to number of cycles. Think of DDR3 refresh for example - you are supposed to do it every X us, so you will need to calculate at synthesis time how many clock cycles that is - because as you know, the logic itself has no concept of time and can only count clock cycles. Unfortunately, there is no such way in generic Verilog/SystemVerilog to know the f