asmi

You can simply reassign a MAC address on your new system to be the same as what you had in the old one, and license will work just fine. I've done it for my license which came with my Genesys 2 board when the time came to replace my PC.

I don't know - that's what debugging is for. I would begin with inspecting an AXI bus from that core in a debugger just to see what's going on there. Also the kind of syncronization you use is not the best - I would use a mutex or a spinlock with atomic operations on both sides, instead of constantly resetting the core. Ditto for using AXI GPIO to control internal signals - I would create a simple custom AXI-lite slave with a single register. Thought I know some people prefer using PS GPIO ports 2 and 3 via EMIO as they give up to 64 channels for zero logic cost (you wil probably need to resyncronize it in PL as PS GPIO is likely running on a different clock from whatever you've got in PL - but that of course is only important for syncronous signals).

Maybe you should stop for a second and actually read and attempt to understand what IDE is telling you? Specifically, you are trying to create a 128x131072 FIFO, which requires almost 17Mbit of BRAM, while your target device (Artix-7 A100T) only contains 4.8 Mbit. Hence the message - "you're requesting more BRAM blocks than your target device actually contain. Consider targeting a larger capacity part, or reduce your demands to something which your target device actually has".

That doesn't make any sense. Try getting rid of RV core and see if problem persists, then you will know what the problem is. You do know that each of GP ports has it's own address space, and attempting to access any addresses outside that space will never reach the port? See address map in UG585, Ch 4.1 Again, try getting rid of RV and see if problem persists. Alternatively, you can use a debugger to inspect live transactions on AXI interface(s) to see what the heck is actually going on. You did update the "range" column in address editor for a wider address window, right?

No need for any of it - you can simply change the address range in the address editor, and Vivado will figure out the rest by itself: If you have separate instruction and data buses (like it's shown in the screenshot), you will need to change it in both places.

If you are only after a license for a single chip, then sure, but if there is a chance that you might want to use some other "paid" devices as well (for example K355T have increased number of MGTs than K325T and so might be very appealing for certain designs), then it might be better in the long run to just pay up once and get access to ALL devices, which includes some very interesting US and US+ devices. That's for sure - at least you can still use the devboard you once bought at any time in the future.

I wish there would be more affordable way (as I've also stuck on old version of Vivado with my 325T board), but it looks like there are only two ways - either buy a new board with K325T part and a voucher, or buy a full license (it will give you access to all parts). Both of those are quite expensive.

I've designed a number of boards with Artix-7 and Spartan-7, and never bothered with power sequencing - I always ramp up and down all rails at the same time via "enable" signal of corresponding DC-DC converters, which is connected to a switch that acts as a power on/off switch for the board. The only downside of such design is that as long as the power supply is physically connected to a board, the "power in" rail (on my boards it's typically 12 or 15 V) is "live" even when the board is switched off via power switch, and it's something that should be kept in mind when tinkering with a board lest one accidentally shorts that rail onto something and bad things can happen.

It's a well-known fact that micro-USB connectors are not very reliable, so those customers who care about this should just stay away from products which use micro-USB. Incidentally I haven't ripped out a single micro-USB connector in my entire life, but I still moved all my new designs to USB-C because it's just more convenient to use. Your assertion is meaningless because nobody in their right mind will do two separate spins of the same board with different connectors. And since A7 board was designed at a time when USB-C wasn't a thing, their options were a (relatively) big and bulky TH mini-USB, or an SMT micro-USB (I don't even know if TH micro-USB connectors ever existed, much less at that time, because their chief value proposition was that they were smaller and so it takes less PCB area). Also A7 PCB is quite high-hech even by modern standards, consequently back then it was pretty much a bleeding edge, so it must've cost them a fortune to manufacture and assemble them all those years ago (even today placing 0201 and 01005 usually commands a premium). WIth that in mind saving PCB space wherever they can must have been a strong motivation. Why haven't they redesigned the board more recently to use modern connector is a good question, which probably comes down to cost as well - PCB engineer's time is very expensive, so their calculus probably was that it's not worth it.

Actually it saves quite a bit because TH parts are often soldered manually, and so you pay for each individual TH part that you have on a board. Which is why many manufacturers now experiment with reflowable TH parts. Thought most modern USB SMT connectors have semi-TH tabs which can be soldered via reflow for additional mechanical strength.

I meant what was you doing with it that caused USB port to be ripped out? That's gotta require some serious force. This devboard is designed to be used in a lab, as it doesn't even have mounting holes if my memory serves me. Devboards are supposed to be used for prototyping, before spinning out a custom board specific to your application, and that board is supposed to have proper mounting provisions (hole pattern, physical size & shape, etc.). Not sure what you used epoxy for.

OMG, what the heck were you doing with that board?

If you need speed, FT60x is a very good option. On my custom board with FT601 I was able to reach about 2.5 Gbps of raw bandwidth (after all overheads are accounted for) over USB 3, and it's interface to FPGA is very simple (though it consumes a lot of IO pins). As far as I remember, FTDI also sells FMC daughterboards with those devices if you don't want to roll your own for some reason.

That new IDE is buggy as hell at the moment. At least for me. Good thing that they've kept the "classic" one so I can actually get things done.

I was far from being the first one to do it. Infact anyone could've done that any time since Xilinx published a tool to program FT devices to be recognized by their IDEs (which IIRC happened around the middle of a last year). I only recently finally got around to it since I was working on a fairly complex board with A100T and an SODIMM DDR3 slot for 64-bit memory interface, which ended up being a 10 layer board, and so I didn't want to risk designing it from the get-go without prototyping USB-JTAG subcircuit first as a single PCB proto run (5 boards) was about $250 delivered, and two days for me to manually assemble it (one day per side, each side contains about 250 components, most of them small 0402 resistors and capacitors), and of course the BOM cost for a single board is also significant enough for me. BTW if anyone is curious to see the full schematics for this board, you can download a PDF here: https://www.eevblog.com/forum/fpga/planningdesignreview-for-a-6-layer-xilinx-artix-7-board-for-diy-computer/msg5134983/#msg5134983 There is also a photo of the board.

If you need exact schematics which Digilent implemented, then you aren't going to get it unless you license it from them for (presumably) big $$$. But if you want this schematics because you want to incorporate something similar into your designs, attached is a schematics of a module which does the job. It's a bit overbuilt because of my somewhat unusual requirement of UART working at a different voltage level than JTAG interface, also the USB side of things is powered by USB while voltage translators are powered by the board, also voltage translators outputs are held in tristate until you actually open a connection to the FT device via Vivado Hardware Manager - this is to ensure that this submodule will not interfere with other JTAG programmers as I also had a TagConnect footprint on the destination board, finally this design is a prototype subcircuit and so there are some extra parts I needed for debugging/experimentation. If config interface of your FPGA is powered by 3.3 V and you won't have any other JTAG programmers on the bus, you can delete voltage translator, same goes for UART - the one coming out of FT2232 is at 3.3 V logic level, so if it's fine with your application, you can get rid of UART translator too. Also please note that parts choice was made for a somewhat compact layout, and so some parts used are very small, but there is plenty of substitute parts in all kinds of packages. And I also use USB Type C connector instead of micro-USB because, well, it's year 2023, and nobody uses micro-USB anymore in new designs. I've designed, assembled this design and verified the functionality, because this was meant to be a part of a much larger design, and so I wanted to retire some design risk by making such prototype. In order for this module to be recognized by Vivado and Vitis, you will need to follow instructions outlined here: https://docs.xilinx.com/r/en-US/ug908-vivado-programming-debugging/Programming-FTDI-Devices-for-Vivado-Hardware-Manager-Support Feel free to ask any questions you may have. And just to make it absolutely clear - this is my original design, it's not any kind of reverse-engineering, or copy-paste, or whatever. It was inspired by Xilinx documentation, as well as a reference design of VCK190 (which Xilinx itself mentions as example) - even though it uses an FT4232 device, which works a bit differently, but also some of my original research and experiments with FT2232 breakout module by FTDI. FTDI Xilinx JTAG.pdf

Your first order of business would be to become familiar with devices themselves. These FPGAs are at least an order of magnitude more complex than even the most advanced MCUs, and so the tooling is neccessarily complex too. So if you want to master these things, you'd better get ready for a lot of reading. First of all you will need to internalize that you don't "program" FPGA - but you design hardware. The HDL "code" you write is not "executed" (because there is nothing in FPGA which can execute anything), but it's used to describe hardware - so your HDL turns into real logic and real registers actually connected with a real wires inside the chip (if you open implemented design, you can actually see all of that). Then you can read about CLB (configurable logic block) in UG474, then some other blocks which are inside the chip - like block RAM (UG473), clocking resources (UG472), DSP tiles (UG479) and I/O buffers and logic (UG471). All these are the basic "bricks" with which you will build your designs. It's unlikely that you are going to remember all these guides after first reading, so keep them handy as you will be referring to them very often. There is also a configuration - which actually configures the FPGA to whatever is in your design, this is covered in UG470. All of the above covers the "tools" you have at your disposal (I've intentionally omitted some more advanced blocks like PCIE, MGTs, XADC as they are are not used in all designs, while pretty much everything I mentioned above is going to be used in every design), but then there is another side to it - namely the "what" of designs. Meaning what exactly are you trying to achieve with your design. Here comes protocols, buses, interfaces - most of it is not specific to FPGAs, but these are things which you are going to be implementing using the tools I mentioned above. As for pre-created IPs, they all perform a certain function, once you understand what exact function they perform and how (this is often covered in "Product Guide" for that IP), it will be easier to understand what configuration parameters do and why they are there.

This connector is not designed for such use, so try minimizing mating-unmating. Also since this is your second board which failed the same way, I would investigate this problem further because there is a chance that third one will follow the footsteps of first two. I also find it extremely odd that Vccio rails are shorted with Vccint. I just can't come up with any believable theory as to how this could've happened.

I don't have Zedboard, but I do have my doubts that ESD event is able to short a Vccio rail to other power rails inside FPGA. I've been assembling and (ab-)using FPGA boards without ESD straps for years, and I've never had any problems. If I were to have something like that, I'd suspect decoupling caps first, as MLCCs are known to fail to shorts from repeated mechanical loads caused by PCB bending due to thermal cycles and/or physical forces (like when you connect/disconnect stuff, or push buttons/operate switches a bit too hard). If you have a thermal camera and a lab power supply, set your lab supply to something like 1 V/0.1-0.2 A, connect it to one of power rails and watch with the thermal camera what is heating up. That will help you to find a location of your problem.

No, as none of those have publicly available datasheets. The only multi-gig PHY of theirs which does is 88E2010/2040L, which is a 5-speed 5G/2.5G/1G/100M/10M PHY. But they are kind of pricey ($40 per chip), and my home network is only 2.5G/10G, so I have no use for 5G anyway at this point. The datasheet is publicly available, and if you sign up with acccout, you can download additional stuff like appnotes, reference designs, software, etc. I've recently designed a board with Artix-7 100T in 484 ball package and an SODIMM module (infact later today I'm going to begin assembling a second respin of those boards after fixing some issues with the first revision), so my plan is to build an addon board with GPY212B1VC. I've already bought a few of those chips, so it's just a matter of spinning up the small addon board. I like that this device has internal DC-DC buck for the core power, so it can be powered for a single 3.3 V rail. This is what rev A of my Artix board looks like after some "fixes" with bodges and stuff :) It's got 3 high-speed connectors, two on the left are for regular IO (diff pairs on the bottom connector, and single-ended on the top one), the one on the top of the board has all MGTs broken out with their clocks, and a single IO byte lane worth of regular IO pins for auxiliary stuff like I2C buses, control pins and things like that.

Yeah that is certainly a weird device. That said, I've mostly moved on from 1G Ethernet towards something faster, currently looking at MaxLinear GPY212 2.5G Ethernet PHY as 2.5x bandwidth for pretty much the same price is very attractive.

I can probe my board a bit later (I need to find it in the storage), but I support zygot's advice to read the datasheet for the PHY (you can find it online, or drop your email to my PM and I will send it to you), as it's got quite un-orthodox MDIO interface (compared to other 1Gig PHYs I worked with), which is why I avoid using it in my board designs - my current favourite is Marvell 88E1510/1518 (for 3.3 and 1.8 V respectively).

There is no way RXCTL is floating, because there is a pull-down (which acts as a strap resistor): I would recommend trying to use eval version of 1G Ethernet Subsystem IP (you can generate an eval license for free at any time) and see if it works. Since demo app works (and yes, it does respond slowly, I've brought it up as well over here years ago and was told that it's normal), I would expect it to work too, if that's the case, that will exclude HW problem.

You can use any QSPI flash which supports a fast read command of some variety (either single read, dual read or quad read) to configure FPGA, however if the memory device is not in the list mentioned by @JColvin, you won't be able to program it via Vivado indirect programming over JTAG. It goes without saying that for boot to work the flash device will have to support a config voltage you've chosen for your board, so if your config voltage is 1.8 V, then the flash has to be rated for that voltage. It is possible in some cases to use a voltage translator, but it requires some serious design trade-offs so avoid that if you can help it. But since the list of supported memory devices is quite extensive, I see no reason to pick any other device because it just makes design easier and reduces a risk of something going wrong.

There is no BootROM in Artix. Looking at names, it looks like you're trying to synthesize one of SiFive cores, so I would recommend you ask them for support, as I assume abovementioned bootROM is going to contain some kind of startup code for their CPU core. I don't think Digilent support folks will be able to help you much on that matter, but if you want, you can of course wait until they respond.