artvvb

Digging some more, the MIG configuration also allows the input clock buffer to be removed, so this might actually be doable:

It seems that both the MIG and clocking wizard try to instantiate the input buffer (IBUFG) that the clock must pass through on its way from the pin. If these buffers were removed from generated HDL sources and placed in an RTL module feeding into both the MIG and clocking wizard, perhaps this could work, however, that could be a painful process in the tools, especially managing when those generated sources might be updated and overwritten. The "No Buffer" on input clock option in the clocking wizard would be helpful.
Some related info:
https://support.xilinx.com/s/question/0D52E00006hpsa9SAA/using-a-global-clock-buffer-at-a-clock-capable-pin?language=en_US
And a relevant critical warning:

Thanks,
Arthur

There is such an option:

 

Hello,
I've posted a new tutorial on Project F covering Tcl build scripts with Vivado:
https://projectf.io/posts/vivado-tcl-build-script/
It's surprisingly easy to automate building your design with Tcl. I wish I'd known this when starting out with my Arty board back in 2018. Anyway, I hope you find this useful, and please do let me know if you have any suggestions or spot any errors.
Cheers,
Flux

On it. No promises on an update, but we'll take a look at it. There are a couple other of these ethernet echo server guides for various boards that could also use some TLC.
Thanks,
Arthur

The tutorial is https://digilent.com/reference/learn/programmable-logic/tutorials/arty-getting-started-with-microblaze-servers/start.
If you follow it, you'll see this tutorial is erroneous under current version of Vivado and Vitis 2022.2.2. So, is there any chance for Digilent to update it so that your customers can follow it without errors? Thanks.
Meanwhile, can you please add a note in red at the beginning of the webpage "This tutorial is erroneous. Please don't follow it in Vivado and Vitis 2022.2.2"? That can at least avoid wasting plenty of time of your customers. Thanks.
 

Hey @zzzhhh, sorry for the delayed response.
I'm the one who wrote the guide in its current form a while back, and honestly, I'm not sure. I've been digging around in some Xilinx docs (links below), and haven't been able to come up with anything definitive so far. Perhaps using the clock would impose an otherwise unnecessary clock domain crossing on the AXI data bus connection to the MIG. Perhaps the high fanout of using the clock in many places across the design would make it more difficult to meet timing once the FPGA is more full than it is with the simple setup created in the guide. Perhaps using the clock for logic would pull it off of the CMT backbone that it needs to be on for the MIG (I don't think this one is the case, since the clock on the backbone seems like it could drive both a BUFG and a CMT/PLL?).
Maybe someone with deeper experience will be able to jump in.
If you build a system with Microblaze being clocked from the system clock input and don't run into any related warnings, are able to meet timing, and the clock interactions look okay, you should be good.
Docs in question:
https://support.xilinx.com/s/article/40603?language=en_US https://docs.xilinx.com/v/u/1.4-English/ug586_7Series_MIS, particularly "Clocking Architecture" p69 https://support.xilinx.com/s/question/0D52E00007G0d8DSAR/whats-the-meaning-of-backbone?language=en_US https://docs.xilinx.com/v/u/en-US/ug472_7Series_Clocking Hope this helped,
Arthur

Thanks, Arthur.  Adding the files to the File Groups as you suggested fixed the issue and allowed the instantiation and at least got by the initial errors with synthesis (I had already added them to the Sources but that hadn't fixed the problem).  There are other errors - but I can move on to tackling those.  Your help much appreciated.

The JTAG interface is used to debug Microblaze systems with a Miicroblaze Debug Module (MDM) connected to the JTAG pins, however this capability is somewhat cooked into the tools. It might be possible to adapt the MDM debug interface to access your RISC-V processor if you can get it into a block design environment. Might also be possible to directly connect the JTAG interface, if the processor supports that, Digilent doesn't include the JTAG pins in master XDC files, but the locations may be fixed and BSCAN primitives might be usable to access them (I only have a cursory knowledge of this area). This is complicated by the fact that Digilent has made the business decision not to share the JTAG circuitry portion of our designs, and this is one of the areas affected by that. The same software used for debugging via the Olimex debugger or HS3 also doesn't necessarily support the on-board programming circuitry. 
Various other JTAG programmers that can be connected to Pmod ports could also work. Digilent also manufactures and sells some JTAG programmer components (like the JTAG HS3, which one of my colleagues indicated is also compatible with OpenOCD) that might fit the bill.
Apologies,
Arthur

JTAG pins can't be included into XDC file because they are dedicated function pins, and can't be used for anything except JTAG.
Which is just stupid now considering Xilinx has finally published a tool which can program FTDI's EEPROM to function just like Digilent's programmer/debugger, but it would only cost about $5 in parts instead of $50+ which Digilent charges for it's solution.

Hi, @zzzhhh,
Unfortunately, that's the only Risc-V tutorial we've run through and tested internally. There are some other projects out there using the Arty A7, but from what I can see, most still require some form of additional kit to program the CPU once its loaded onto the board, similar to that Olimex programmer.
Thanks,
Arthur

The feedback is really appreciated.
We found a plugin for the wiki system the documentation site runs on that will allow for PDF download, which has since been installed. There are some incompatibilities with other plugins and some other issues on the site which cause problems in the exported files, but we should be able to fix things up over time. The photo galleries at the top of many manuals are a particular offender, along with mathematical formulas, and some other missing figures here and there.
What this means is that it's currently possible to download any page as a PDF by appending "?do=export_pdf" to the URL. As mentioned above, results will be mixed, but the baseline capability is currently there, and we're looking to keep improving on it. - Edit, and we should be able to add download buttons to individual pages once we're confident that the results for those pages are good.
Thanks!
Arthur

Hi again,
 
(Update)
Turns out that the lwip211 v1.8 has a bug in the xadapter.c file. (../libsrc/lwip211_v1_8/src/contrib/ports/xilinx/netif/xadapter.c) 
Essentially, in the library source file mentioned above, due to a default clause 2 case statements fail to take action and leads to yielding the error that @matrixrifle reported. The most simple solution is to place 2 break statements after each of those cases, so that the default clause doesn't intervene.
 
In more detail: (below line 137 of xadapter.c)
switch (find_mac_type(mac_baseaddr)) { case xemac_type_xps_emaclite: #ifdef XLWIP_CONFIG_INCLUDE_EMACLITE nif = netif_add(netif, ipaddr, netmask, gw, (void*)(UINTPTR)mac_baseaddr, xemacliteif_init, #if NO_SYS ethernet_input #else tcpip_input #endif ); #else nif = NULL; #endif break; case xemac_type_axi_ethernet: #ifdef XLWIP_CONFIG_INCLUDE_AXI_ETHERNET nif = netif_add(netif, ipaddr, netmask, gw, (void*)(UINTPTR)mac_baseaddr, xaxiemacif_init, #if NO_SYS ethernet_input #else tcpip_input #endif ); #else nif = NULL; #endif break; This enabled me to run an echo server on my designs, including those proposed by Arthur. 
Best regards,

hi @artvvb
Thanks for helping me to complete my project.
👍
 

Hi @K.K
Apologies for the delayed response.
The error isn't at runtime, so malloc actually returning NULL (which is usually defined as zero) at runtime is not necessarily what's happening here, but "if flash_env == NULL" is still good advice. Possibly compiler settings were modified between versions to be harsher on something which worked before, which might mean that either a NULL check or an explicit cast of the pointer to an unsigned integer could also help.
As a note, Digilent hasn't tested the Zmod library sources in 2022.1 (edit: or 2022.2).
Thanks,
Arthur

I agree with the notion that keeping copies of documentation with projects is important. What's worse than no PDF? A PDF with errors and misinformation, and boy, Digilent has had their share of those. I'm not picking on Digilent because I've never worked at a place where documentation was up to date, always correct, and readily available. Same for vendor tools and products. Same for stuff that I've created... Digilent isn't the best at providing documentation, but certainly isn't the worst. Some FPGA board vendors don't supply even a minimum.. to the point where they aren't going to sell me anything. Altera documentation used to be pretty good.. but those days are long gone. Xilinx documentation has always been pretty bad, but if anything there's been some improvement over the years.

Ultimately, documentation, like valid constraints files, are living things that have to change with board revisions and part swapping for a production of product when a part on the original BOM isn't available, and in a meaningful time frame. It's a big problem.. for everyone... and there's no perfect solution. Heck, I keep notes on everything that happens during a project development cycle and even those notes sometimes have errors. I've been around the merry-go-round more times than I care to acknowledge and the scenery never changes.

Quite a while ago Xilinx stopped supplying PDF documents. They do have the Document Navigator that keep a catalog of document versions related to tool versions. While I hated this at first, I've come to see it as a positive step. Now, if they could just get those version specific documents accurate and meaningful. As I mentioned.. it's a big problem. I'm sympathetic to document providers everywhere.

These days most browsers can create PDF versions of HTML pages, unless they specifically are written in a way to not work with browser page printing software. Digilent has never produced a PDF of the Genesys2 reference manual ( to my knowledge ) but I still have a PDF included in the /doc folder of all of my Genesys2 projects courtesy of Firefox. So, perhaps asking for PDFs isn't wxactly what we want. Perhaps, what we want is on-line documentation that can be turned into a PDF with any commonly used browser. (Yeah I know that I'm a hold-out with respect to Firefox ).

I feel more comfortable mentioning what I don't want.

I don't want documentation in a form that can have hidden malware embedded in it.
I don't want documentation that tells me stuff that isn't accurate or relevant
I don't want to go online to use a product because there's no way to create viewable documentation ( generally in the form of a PDF ) that I can use off-line. 90% of what I do is on a PC that's not connected to the internet ever, much less all day while I'm working.

I'm sure that there's more to what I don't want... but this is a good start.

[edit] Oh, last complication to the topic that I forgot to mention. Adobe won't like it but the term 'pdf' has become the 'xerox' of the past. These days there are multiple products that create pdfs and even more that render pdfs. Browsers, like the on in Firefox, may not render a pdf the same way as a different browser does. I've seen this. As wonderful as the pdf format is, it's not perfect or even necessarily consistent.

Hi @zzzhhh
Verilog file I/O is not applicable, it's only for use in simulation and for defining the initial states of signals and memories, not for dynamic loading and transfer of files - Verilog describes hardware and doesn't touch anything outside of the FPGA unless you explicitly describe a way to do so. Data transfer between a PC and FPGA hardware can be a big topic, however, for the simplest approach, I'd point to designing a UART receiver, implementing it in the FPGA, and sending data to it using a serial port on the host computer. USBUART hardware on the board provides an interface that lets this controller be relatively simple, and drivers that get installed with Vivado can be used to connect to a serial port from apps like Tera Term (or from stuff like Python with the pyserial module). In addition to the UART controller, you'd also need to design something to convert from the UART's 8-bit data to whatever your LED representation is and to control the LEDs. A project like this is a pretty good early thing for getting your hands dirty.
Thanks,
Arthur

There are some nice tutorials available for anyone wanting to do FPGA based video using an HDL. Most of what I've come across, for HDMI at least, is based on work that Mike Field has published. None of them use external memory as a video frame buffer. This tutorial demo project aims to change that. Enjoy. Thanks Mike.
I've added a demo for the Genesys2 that implements a True Color 32-bit RGBA video frame buffer in DDR for 24-bit RGB HDMI displays. It's the obvious extension of the Nexys Video 8-bit indexed color demo.
 
NexysVideo_Demo_R1.zip
 
Genesys2VideoDemo_R1.zip

@artvvb,
I would also ask Digilent to post and maintain PDF copies of all of their manuals.
It is common for hardware to outlive its support, or for newer versions of hardware to have newer documents that then get confused with the manuals for older products.  My solution to this has always been to download the PDF manual of the user guides or other spec sheets at the time of purchase, to guarantee that 1) I won't get confused by an update to a product I don't have later, and 2) I'll still be able to keep and maintain the manual long after the company that built the product has stopped supporting it.
Thanks!
Dan

According to UG909 (I looked at 2021.1): 
NB: "Dynamic Function eXchange" is what Xilinx is calling the feature they used to call "Partial Reconfiguration".
B/R
 

Thank you very much for the information.

Hi @feplooptest,
Digilent doesn't provide any specific examples on partial reconfig for any of our boards, however, it's my understanding that pretty much any of them ought to support it - though we haven't done any testing. I haven't run through these tutorials, but Unit 6 and 7 here look promising for using a Zybo Z7: http://www.secs.oakland.edu/~llamocca/EmbSysZynq.html.
Thanks,
Arthur

Hey @Mukta
I'm not aware of any specific trainings. There are some example projects, like the lwip echo server, baked into Vivado/Vitis, but Digilent doesn't have any recent material on how to get them up and running. This tutorial, which is very old and out-of-date for recent versions of the tools, is the closest I can find: https://digilent.com/reference/learn/programmable-logic/tutorials/zybo-getting-started-with-zynq-server/start
Thanks,
Arthur

Following up via direct message.