Vivado/Vitis new AXI peripheral - at wit's end

[engrpetero]

My current project contained two AXI peripherals I created.  It was working fine (or close to working, at least not producing any errors I couldn't live with).  I added a new AXI peripheral modeled off one of the original two.  In my main project (the one that contains the peripherals), I've updated the memory address of the new AXI peripheral to the desired value (it's very similar to the previous two). 

I've synthesized, implemented, generated bit stream many times, updated Vitis platform project many times, created new Vitis platform and application projects (also several times), and no matter what I do, the xparameters.h file always contains the incorrect AXI BASEADDR and AXI HIGHADDR for the new peripheral.  Moreover, it's killing my ability use the zybo uarts if I keep the new peripheral (they just don't work).

I'm at my wit's end on trying to figure out what to do next.  I can share anything related to what I've done and am doing.  I sure hope someone can help with a suggestion as I can't make any further progress.  Very annoying.  Any ideas?

Edited July 17, 2023 by engrpetero

[engrpetero]

Well, the address is a problem.  But it doesn't seem that's the think killing the UARTs.  Not sure what changed, but the application that used the UARTS just lockes up now.  There is a lot of good with the Xilinx tools.  But there is a LOT that is frustrating.

[engrpetero]

ditto on Frustrating.

I got rid of all existing Vitis workspaces and all existing vivado projects.  Started fresh with a new folder location (no spaces) for Vivado and Vitis.  With NO changes to the Vivado project, I re-synthesized, re-implemented, re-generated bit stream and exported hardware.  

Created new platform and application projects based on the exported xsa file.  Imported sources from my old application project, rebuild both platform and application projects and miraculously, it works, the third AXI peripheral mentioned above has the desired/expected address, and the UARTs are working.

No idea what could possibly have been the cause or the solution.. :-(

[D@n]

Are you using Xilinx's AXI or AXI-Lite slave templates?  If so, you should know they are both quite broken.  They can both cause your design to lock up.  They've been broken for years.

Dan

[engrpetero]

Thanks @D@n.  Through research this spring, I learned exactly what you told me.  I've found the Dan Gisselqust (maybe you are him??!? :-)) series very helpful.  His Axi-lite discussion and my careful attention to it has allowed me to make a few pretty simple memory mapped peripherals.

But I did speak too soon.  Seems that although I can program the Zynq on my Zybo - and I can write to and read the written values back from all the desired registers on all three peripherals - for whatever reason the Zybo is no longer capable of sending messages over the programming UART nor the PS UART.  I can't imagine what I've done as it doesn't *seem* I've done anything different.

FWIW, other peripheral items (like the wdt, scutimer, interrupt system) all work fine.  just can't write out on the uarts (locks up who device).

Edited July 17, 2023 by engrpetero

[D@n]

@engrpetero,

Yes, that is me.   I am the author of the ZipCPU blog, and twitter feed.  To prove it, let me predict the next article will be about formally verifying an SD card block data receiver.  I might even add some hardware lessons learned--since I now have the device (somewhat) running in hardware.  (Yes, the article is mostly written ...)

But back to your struggles ... device lockup can be a challenge to debug.  It's usually caused by a bus slave (or master) that doesn't obey the rules of the bus.  I'm not sure if you are using AXI or AXI-Lite, as there are more rules for AXI than AXI-Lite.  AXI-Lite is usually the easiest to work with.  Lockup with AXI-Lite is typically caused by a request that doesn't get any acknowledgment.  Classic examples would be 1) the number of (BVALID && BREADY)s doesn't match the number of (AWVALID && AWREADY)s or the number of (WVALID && WREADY)s, or likewise 2) if the number of (RVALID && RREADY)s doesn't match the number of (ARVALID && ARREADY)s.  Bus lockups in AXI-Lite can also take place if you expect AWVALID && WVALID to arrive on the same clock cycle, or if you wait for READY before asserting VALID--such as waiting on BREADY before asserting BVALID.  Another problem I've seen recently had to do with someone getting the address to their peripheral wrong, so the design then locked up when they tried to access a non-existent device.

The way to deal with this problem is (easiest to hardest):  1) to formally verify anything before it touches hardware (you knew I would say that), 2) to use an internal logic analyzer to watch these signals, or 3) if all else fails assign some LEDs to the task.  Key signals to look for would be VALIDs stuck without READY, or counters of the above signals counting requests vs responses and then key an LED to the counters not matching.  Another useful LED might be a toggle to just tell you if your IP was accessed at all from the ARM.

Others on this forum will tell you the easiest way to deal with this is not to use AXI at all--but it is kind of hard to avoid with the basic Zynq type of platforms.  (Just giving you a heads up, lest this conversation get off track ...)

Dan

[zygot]

2 hours ago, D@n said:

Others on this forum will tell you the easiest way to deal with this is not to use AXI at all--but it is kind of hard to avoid with the basic Zynq type of platforms.

! doubt that anyone will post that argument since AXI busses are the only possible way to connect the PS and PL in a ZYNQ device ( well except for the EMIO but that is limited ). Now, for logic completely contained in the PL, or for designs completely contained in logic... that's a different matter.

I may have misread the problem, but it seems to be related to setting AXI address spaces, which is done in Vivado which produces the HDF file ( or for Vitas the xsa fie) , not the software tools. I'm thinking that problems with the PS UART are not AXI related. ARM UART blocks are a bit limited in terms of FIFO storage and flexibility.

I don't know how much VItis or SDK work Dan has done, but I sure agree with the OP that ZYNQ development, and using the tools can be overly complicated, especially to someone learning how to use the tools and the architecture at the same time. The easiest way to deal with the Xilinx software tools might be not to use them. Any ideas on that?

I've not used Vitis much but console in the software tools can be set to connect to a USB UART device, in this case other applications can't use the same device. Before freaking out about the possibility that the HW has failed while using the hardware in the software tools, make sure the the connection is still valid. Personally, I prefer using Putty connected to my PS or PL UARTs instead of the software tools for a variety of reasons. For one, you can use a higher baud rate than 115200 that way. For another, the software tools get confused and it isn't always easy to see that a UART is no longer connected. This might just be something that plagues me tho...

Edited July 18, 2023 by zygot

[engrpetero]

12 hours ago, zygot said:

I may have misread the problem, but it seems to be related to setting AXI address spaces, which is done in Vivado which produces the HDF file ( or for Vitas the xsa fie) , not the software tools. I'm thinking that problems with the PS UART are not AXI related. ARM UART blocks are a bit limited in terms of FIFO storage and flexibility.

...

I've not used Vitis much but console in the software tools can be set to connect to a USB UART device, in this case other applications can't use the same device. Before freaking out about the possibility that the HW has failed while using the hardware in the software tools, make sure the the connection is still valid. Personally, I prefer using Putty connected to my PS or PL UARTs instead of the software tools for a variety of reasons. For one, you can use a higher baud rate than 115200 that way. For another, the software tools get confused and it isn't always easy to see that a UART is no longer connected. This might just be something that plagues me tho...

You didn't misread - I probably wasn't very clear due to my frustration. :-)  I was using the Address editor in Vivado to set the peripheral addresses (again there were three items).  The xsa file (for the platform project in Vitis) would always accurately reflect the addresses I'd assigned to two of the items, but never the third.  I have no idea why/what caused Vivado to finally do it correctly.  I did nothing different - or at least I am not aware of anything different I did.  

Over the past two months, I've spent a LOT of time using Vitis to develop the c app for this Vivado project.  Besides poor or non-existent Xilinx documentation issues, and with help from some members of this community, I now feel very comfortable with Vitis.  So I don't think it is the problem (though IMO, Xilinx still has a lot of work to do to make things more seamlessly). Although to make sure comm was happening using Putty (or TeraTerm), I created a C# app to send and receive messages with the Zynq - it is a very helpful debug tool to easily encapsulate messaging to and from the device.

You guys would laugh at the simplicity of my AXI peripherals - so I don't expect they are the problem (I could write to and read from the AXI peripheral registers for each of the three).  But maybe.  This morning, I'll remove all AXI peripherals from my project and see if the UARTs will work again.  I sure wish Vivado/Vitis made it easy to do such things (copying and pasting windows directors doesn't seem to work, at least not the way I'm doing it).  

@D@n - assuming I get the UARTs working again, I'll keep in mind the three things you suggested on the PL troubleshooting side.

As always, I appreciate the help.

Edited July 18, 2023 by engrpetero

[zygot]

56 minutes ago, engrpetero said:

The xsa file (for the platform project in Vitis) would always accurately reflect the addresses I'd assigned to two of the items, but never the third.

It's hard to say if this is a bug ( Every new version of Vivado introduces new bugs, but doesn't necessarily fix old ones ), or user confusion. There can be conflicts with setting AXI space starting addresses and size, but the tools should detect and prominently prevent you from completing your board design until errors are fixed. I've seen really obnoxious errors with clock frequency specifications ( stupid stuff like round-off differences to the 3rd decimal place ). The only way to deal with such things to so figure out how to avoid them. Sometimes you have to re-open an IP or board design after thinking that everything is OK to see that actually there is a problem. The tools are overly complex, especially the GUI tools. It's not uncommon to spent hours debugging the tools, thinking that it's the design. Usually by the time I see weird behavior for the 3rd time or so I get the message that it's the tools, not me, that's the problem.

I've never encountered an AXI bus fault producing PS UART failures. Generally these have a much more dramatic ending to a software debugging session that involves a power cycle and reconfiguration to move forward. I can see having data problems with the PS UART and faulty AXI bus behaviors, but not the UART just not talking. Aside from checking connectivity of the software console, if you are using that, you make sure that the OS is still connected to the USB UART device. UARTs don't stop working. UARTs garble data if there's a baud rate problem. USB devices stop working on a host if the device gets detached for some reason.

[engrpetero]

53 minutes ago, zygot said:

I can see having data problems with the PS UART and faulty AXI bus behaviors, but not the UART just not talking. Aside from checking connectivity of the software console, if you are using that, you make sure that the OS is still connected to the USB UART device. UARTs don't stop working. UARTs garble data if there's a baud rate problem. USB devices stop working on a host if the device gets detached for some reason.

Yeah, that's why this has been particularly puzzling.  If I had another Zybo, I'd plug it in and see if same behavior.  It can't be that it is completely not working as I can program the board over the microusb connector.  I *ought* to keep a simple design on hand (one of the example designs) that simply uses the programming uart 0 to send some messages.  That will be next step.

Absolutely the Xilinx tools are overly complex.  Time is limited - perhaps not a great excuse - to try to learn every nuance of the tools.  At my peril, I do ignore warnings often, even critical ones as many times they make no sense to me (or they don't seem relevant as I'm using content from trusted places (like the Digilent pmods example - see pic below as an instance).  But obviously I do not ignore errors. 

I do so much wish I could copy and paste (windows explorer) Vitis and Vivado folders so I could more easily edit content without constantly having to modify designs.  Synthesis, implementation, generate bit stream, export hardware, build platform project, build application project, test cycles take 15 minutes (min).

I'll report back when I find a solution (or just have more relevant information)

[engrpetero]

new info...

I simplified the Vivado project and just removed all the peripherals I created.  The project now is merely the Digilent pmod example project - but it does have a few other things (like UART1 in the PS enabled, the SCU Timer, etc.).

Using this simplified project hardware platform, I obtained the xscutimer_polled_example project to do some testing (it xil_printf()'s some messages).  I used two instances of TeraTerm, one connected to the normal programming microusb connector (UART0) but also one connected to UART1 on the PS MIO 14-15 (Zybo JF pins 9:10).

When I run the example program using the 'default' config (where xil_printf() goes to UART0), nothing shows up on TeraTerm.  however, when I modified the xparameters.h file to send xil_printf() output to UART 1, I did get the expected messages over in TeraTerm.

Also, I can obviously program the Zynq part so I *must* be able to send messages to the Zybo over UART0.  And when I'm connected with TeraTerm, I can type characters on and see the UART0 Zybo rx led blink on and off while I type.  It seems that somehow, the Zybo (or the Zynq itself) just can't send characters over UART0.  I do wish I had a second ZYbo to try (I'll order one today).

Does this extra info spur any thoughts?

[zygot]

The Zybo is one of the few ZYNQ boards that make the 2 PS UARTs available to physical pins without going through the PL. Sometimes the BSP swaps the UART references and causes confusion. This has an impact on the supporting libraries. It can get confusing. Fortunately, all of the relevant hardware related information is available in text format ( at least in the pre-Vivado2019.2 SDK... honestly I don't about Vitis; I've only used it for Linux operation. The first thing to do, when confronted with unexpected behavior is to make sure that all hardware addresses, and software assignments are in agreement about what they are referencing. I typically have the xparameters.h, and hdf ( SDK ) files handy for viewing. I'm a hardware guy so I personally would rather use PL UARTs implemented in logic as I know what's going on and can easily debug issues with an ILA if need be.

I don't typically use the Xilinx standalone libraries for things like UARTs. I'd rather use a C-style pointer coding style. If the ZYNQ is running Linux or an RTOS, then I have to abide with the rules of the OS. Do make sure that both of your UARTs are set up properly and aren't stepping on each other. The Xilinx software tools want you to do thing their way. You might find that reading the hardware description for PS UARTs and understanding the registers is a better approach. I can't advise one way or the other because everyone has a different development flow that they prefer.

31 minutes ago, engrpetero said:

I can obviously program the Zynq part so I *must* be able to send messages to the Zybo over UART0. 

The JTAG and UART USB endpoints are enumerated as separate devices by your host PC. The Zybo reference manual claims that you don't have to worry about either interfering with the other. I'd disagree since I've experienced just that using an ILA while using the UART port at high baud rates. Anyway, the two devices are separate; the fact that one is working doesn't imply anything the other. If your host OS isn't seeing one of them as the appropriate device then you've got problems. There seems to be a LOT of UART related issues in the past year or so posted the Digilent's forums. I don't know of Win11 is the culprit, or bad drivers, or some other thing is the cause. I use Win10 and Linux as hosts and generally don't have connectivity issues for my FPGA board. I also don't let Win10 automatically install drivers.

I can't tolerate wasting time with petty UART issues cause by other peoples tools or decision making. There are a number of cheap USB TTL UART cables and breakout boards available. I use these a lot since there's no fuss, once you figure out how to use them. Even for non-FPGA work, like the OrangePi that has a UART running at a non-standard 1.5 Mbaud rate these things come in handy.  

Control what you can so that you have more time killing bugs... and hopefully a bit of time actually doing development work....

[engrpetero]

Thanks @zygot.  I've been using this platform project and application project successfully with both UARTS multiple messages every second for months.  Same WIn 10 computer, same cables connected to the exact same laptop USB/serial port cables.  It did take some time to work through the UART issues but for months, it's been working - both PS Uarts - without any problem. 

As I can't imagine anything I did to break it, I'll try on one more Zybo before doing too much more debugging.  The AXI peripherals need some work to achieve what I truly want so I'll focus there for a bit while waiting on the new Zybo.  I'll post anything relevant if/when it occurs just as a touchpoint for anyone following the thread.

As always, your guys' help is much appreciated.

[JColvin]

Hi @engrpetero,

The programming port is not on UART0. As per https://digilent.com/reference/programmable-logic/zybo-z7/reference-manual#usb-uart_bridge_serial_port and https://digilent.com/reference/programmable-logic/zybo-z7/reference-manual#zynq_apsoc_architecture in the second table, the UART-USB port is on UART 1 which is on MIO 48 and 49; that is why when assigning xil_printf to UART1 lets you see messages over Tera Term.

I'm unexpectedly at my home office today (meaning no Digilent hardware or Vivado installs on hand) so I can't readily get any screenshots or build a reference design for using UART0 through the MIO pins on JF, but I should be able to get material for you tomorrow.

Thanks,
JColvin

[engrpetero]

2 minutes ago, JColvin said:

Hi @engrpetero,

The programming port is not on UART0. As per https://digilent.com/reference/programmable-logic/zybo-z7/reference-manual#usb-uart_bridge_serial_port and https://digilent.com/reference/programmable-logic/zybo-z7/reference-manual#zynq_apsoc_architecture in the second table, the UART-USB port is on UART 1 which is on MIO 48 and 49; that is why when assigning xil_printf to UART1 lets you see messages over Tera Term.

I'm unexpectedly at my home office today (meaning no Digilent hardware or Vivado installs on hand) so I can't readily get any screenshots or build a reference design for using UART0 through the MIO pins on JF, but I should be able to get material for you tomorrow.

Thanks,
JColvin

Sorry - I got the ports mixed up.  UART0 is on MIO 14:15 (pmod JF pins 9:10).  UART1 is what is essentially exposed on the programming micro-usb connector.  I do think it was you, @JColvin, who pointed me to the MIO UART0 as an alternate to UART1 a few months ago.  The puzzling thing is I've been using this Zybo to send and receive messages over both UART0 and UART1 for months now with absolutely no issue.  I added a shell for an AXI peripheral last Friday (since removed) and since I did that, UART1 (the microusb) has not functioned for sending messages.

[JColvin]

Your diagram showing the association of UART0 and UART1 is accurate, as is the Zynq processor screenshot configuration.

What I would personally end up doing in your shoes would be to create a separate barebones "hello world" project (Xilinx / AMD has a premade Vitis app to help add another layer of sanity checking to your debugging process iirc). You can then further modify the example to spit out whatever text on a button press or when a timer reaches some value.

Ostensibly, the hardware itself is working; if the FTDI chip was malfunctioning, I wouldn't expect you to be able to configure the device in the first place, so intermittently (or not intermittently) receiving characters feels like a different root problem, or at least that is what I would be looking for first.

Adding an AXI peripheral to a system whose entire point is to be able to reconfigure it shouldn't have caused an issue. But like all issues in this field and the rest of life "shouldn't" is relative and inconsistent, so maybe something did happen. Just need to work from individual steps to eliminate different variables until we find the root cause.

Thanks,
JColvin

[engrpetero]

Thanks, @JColvin.

From a barebones perspective, I guess I can just create a new vivado project, add the zynq subsystem (and processor reset), enable UART0 and UART1 (remembering to disable the pull-ups on the MIO pins!). 

Then I could export the XSA, create a new Vitis project (the default one with the 'Hello World.c' app), and try to send messages from both UARTs.  That's an easy and relatively quick way (if anything can be called quick with a Vivado/Vitis project) to see if chars can be written over both UARTs.

[engrpetero]

Well....  I did just what I said in that last post.  And - surprisingly to me - I did get messages over both UARTS. 

So good news is the Zybo still seems to work.  The bad news is I have no idea how I screwed it up.  I'll build back up slowly and when I figure it out, I'll let you guys know in case you see it again.

 

Edit - I was going to upload the simple Vivado and Vitis projects used for this test in the event someone else was struggling with this in the future (or just wanting to see both PS Uarts work) but even these VERY simple projects when compressed are still HUGE (over 17 total MB).

Here is the Vivado project.  Let me see if I can get rid of anything in the Visit (entire workspace) and I'll try to attach that separately.

UartTest-Vivado.zip

Edited July 18, 2023 by engrpetero

[engrpetero]

I wanted to be doubly sure before posting an update, especially since I can't make any sense our of it.

I use the Xilins UpartPs V 3.11 drivers (well, a modified version) for working with the UARTs.  Anyone who has struggled through those drivers and BSPs for the Zybo especially (but likely for other platforms?) knows there is some odd stuff going on, particularly when using interrupts.  It *seems* sometime along the way, Xilinx (or whomever is responsible for BSPs related to those drivers) mixed up the Device IDs and Interrupt IDs for the two Uarts UART0 and UART1.   In fact, back in March when I had time to start this project, it took me the better part of a week to track down these inconsistencies with the V3.11 driver, understand the driver, and make some minor fixes (there's a long post on that here in the forum).

For the past few months (I went back and looked archived projects), I have been using the following constants in my app (Uart0 is the 'Debug' uart and Uart1 is something called 'Dmcc') Since that time, my c app has successfully responded to interrupt driven messages written to the zybo and has successfully sentmesssges (no interrupts used ont he send side). 

#define UART_DEBUG_DEVICE_ID	XPAR_XUARTPS_0_DEVICE_ID	// THis stuff works as is - seems screwed up in defined files
#define UART_DEBUG_INT_IRQ_ID	XPAR_XUARTPS_1_INTR
#define UART_DMCC_DEVICE_ID		XPAR_XUARTPS_1_DEVICE_ID
#define UART_DMCC_INT_IRQ_ID	XPAR_XUARTPS_0_INTR

After adding the third AXI peripheral, I of course had to resynthesize, reimplement, regenerate bitstream, export hardware (the set of tasks associated with hardware changes).  Then on the Vitis side, Update Hardware Specification, Build Platform Project, Build Application Project.  I never touched the Zynq subsystem in the Vivado project (and doesn't seem like it should matter ever if I did as I don't know of a way to modify interrupt vectors).  But low and behold, even though the actual values of the items on the RHS didn't change (and I did not change any of the c code using these UARTS), the correct IDs are now...

#define UART_DEBUG_DEVICE_ID	XPAR_XUARTPS_0_DEVICE_ID	// This magically fixed itself in mid-July???
#define UART_DEBUG_INT_IRQ_ID	XPAR_XUARTPS_0_INTR
#define UART_DMCC_DEVICE_ID		XPAR_XUARTPS_1_DEVICE_ID
#define UART_DMCC_INT_IRQ_ID	XPAR_XUARTPS_1_INTR

So this issue all came down to UART Interrupt IDs for the UART and GIC drivers.  My frustration has now changed from not knowing what happened to puzzling how the sequence Resynthesize, Reimplement, Regenerate bitstream, Export hardware (Vivado), Update Hardware Specification, Build Platform Project, Build Application Project (Vitis) with me not touching the Vitis project nor the Zynq subsystem could have caused this (and why something similar could happen in the future).

And I assume it was just coincidence that this happened at the same time I added the third AXI peripheral (but I don't really buy this was a coincidence).

Edit to add...

When I was struggling to debug the Xilinx UART driver, a few of the prolific, smart posters on this site suggested the if I make a copy of it and add it to my project, I would have more luck stepping through it with the debugger.  That advice was golden, so much so that if I even consider that I might need to make changes to a driver, I automatically now make a copy of it and add it to my project.  So even updates to the board support files (if there were actual changes) would not have affected the UART driver being used by my Vitis app.

Edited July 19, 2023 by engrpetero

[zygot]

6 minutes ago, engrpetero said:

And I assume it was just coincidence that this happened at the same time I added the third AXI peripheral

I doubt it. Between the hardware description file that Vivado produces and gets exported to the software tools. creating a BSP, adding library support for hardware, and the standalone libraries there's a lot of room to swap references ( like uart0 and uart1 ) and generally introduce confusion by each of those pieces of the process... and Xilinx, in my experience, seems to dislike missing any opportunity to confuse its users.

Until you get used to the tools and their quirks, and there are a lot of quirks and bugs, you just need to simplify and carefully manage ( check ) everything that's produced by the tools.

My approach to ZYNQ is not appropriate for most people.

I put all of the hard stuff, timing dependent functionality into the PL and make the PS as stupid as possible. I don't use the drivers and library functionality ( to the extent possible ) for controlling simple hardware like UARTs. I avoid interrupts to the extent that is possible. Really, the PS cores are plenty fast enough for a lot of applications. I write code as if I were programming a micro-controller in C. I read about the hardware, learn what registers are available and what the bits mean. For me this is easier and ultimately quicker than banging my head against the opacity of the tool libraries. (actually, you can work out exactly what the libraries are doing if you have a LOT of time on you hands. )

Basically, it comes down to this. If all you want to do is replicated simple demos or the functionality of the libraries is good enough then the tools, as they are, can be a quick way to do something. If you want to do something that's substantially different than the pre-baked cookies that the tools provide ( VIvado or VItis ) then be prepared to do some heavy lifting just to get to a point where you are productive.

I have no doubt that many people will disagree with this opinion, but it's as good as I can provide.

Figure out how to slay the dragon, or it will slay you.

[artvvb]

23 hours ago, engrpetero said:

Edit - I was going to upload the simple Vivado and Vitis projects used for this test in the event someone else was struggling with this in the future (or just wanting to see both PS Uarts work) but even these VERY simple projects when compressed are still HUGE (over 17 total MB).

If you don't have custom IP in the system, File -> Project -> Write Tcl could be sufficient to recreate your project. File -> Project -> Archive is typical and includes all dependencies - I assume this is what you used. In Vitis, File -> Export creates an archive that can be easily imported into a workspace.

Any shot that the reversed rx & tx lines between the two UART peripherals might cause some issue? I hadn't noticed that piece of trivia before, and it seems kind of counterintuitive.

It's also worth double-checking the xuartps_g.c file - this is where the device IDs are actually mapped to the different configuration sets. If which UARTs are enabled changes, this file potentially changes.

Would you be able to share your AXI IP? Addressing parameters should be controlled and passed to Vitis through the UI Layout and Software Driver TCL scripts. UI Layout handles Vivado setting the config parameters which specify the addresses, while the Software driver script defines what gets included in parameters. You could technically modify these scripts to pass more params to the xparameters set if you really felt the need.

Thanks,

Arthur

[engrpetero]

On 7/19/2023 at 3:52 PM, zygot said:

I doubt it. Between the hardware description file that Vivado produces and gets exported to the software tools. creating a BSP, adding library support for hardware, and the standalone libraries there's a lot of room to swap references ( like uart0 and uart1 ) and generally introduce confusion by each of those pieces of the process... and Xilinx, in my experience, seems to dislike missing any opportunity to confuse its users.

Until you get used to the tools and their quirks, and there are a lot of quirks and bugs, you just need to simplify and carefully manage ( check ) everything that's produced by the tools.

My approach to ZYNQ is not appropriate for most people.

I put all of the hard stuff, timing dependent functionality into the PL and make the PS as stupid as possible. I don't use the drivers and library functionality ( to the extent possible ) for controlling simple hardware like UARTs. I avoid interrupts to the extent that is possible. Really, the PS cores are plenty fast enough for a lot of applications. I write code as if I were programming a micro-controller in C. I read about the hardware, learn what registers are available and what the bits mean. For me this is easier and ultimately quicker than banging my head against the opacity of the tool libraries. (actually, you can work out exactly what the libraries are doing if you have a LOT of time on you hands. )

Basically, it comes down to this. If all you want to do is replicated simple demos or the functionality of the libraries is good enough then the tools, as they are, can be a quick way to do something. If you want to do something that's substantially different than the pre-baked cookies that the tools provide ( VIvado or VItis ) then be prepared to do some heavy lifting just to get to a point where you are productive.

I have no doubt that many people will disagree with this opinion, but it's as good as I can provide.

Figure out how to slay the dragon, or it will slay you.

Wow - a lot packed into that replay (thanks!).  I spent many years with AVR microcontrollers.  So I appreciate many of your comments.  The only interrupts I am using at the SCU timer and the SCUart.  I am not so skilled (yet!) with the PL side of things so I'm taking that slowly and putting things there when I think I truly understand them.  And there is good and bad with the examples I've looked at.  I'm sure the authors had a purpose to do what they did but I've found them to be very confusing and obfuscated.  As I gain more experience with the tools - and frankly have a bit more time - I think I'll end up where I ended up with the Atmel stuff.  Much tighter, purposeful libraries to interact with the Zynq functions that meet my needs.  Not there yet.

[engrpetero]

On 7/19/2023 at 5:40 PM, artvvb said:

Any shot that the reversed rx & tx lines between the two UART peripherals might cause some issue? I hadn't noticed that piece of trivia before, and it seems kind of counterintuitive.

It's also worth double-checking the xuartps_g.c file - this is where the device IDs are actually mapped to the different configuration sets. If which UARTs are enabled changes, this file potentially changes.

Would you be able to share your AXI IP? Addressing parameters should be controlled and passed to Vitis through the UI Layout and Software Driver TCL scripts. UI Layout handles Vivado setting the config parameters which specify the addresses, while the Software driver script defines what gets included in parameters. You could technically modify these scripts to pass more params to the xparameters set if you really felt the need.

I don't think so on the rx/tx lines.  After looking at the Zynq IP, I"m not sure I'd even know hoe.  I did think it weird initially but internet searches suggested the problem so I didn't think much of it further.

I *think* I've got the IP straightened out now.  At any rate, the address of the peripheral is correct now in the xparameters.h file and it seems usable.  If it happens again, I'll certainly archive it immediatelly with hopes you guys can provide some idea of why it is screwed up.

[engrpetero]

well, the issue is back.  These tools drive me nuts.  I guess I ought to look for a 'bug report' feature over at Xilinx.  Regardless of how I set the memory addresses for my AXI peripherals, it's hit or miss whether they 'take'.

So right now, instead, I'm trying to cleanup 'critical warning's (or at least make sense of them).  I'll open up another thread about this and hopefully return here in the future once I learn something more.

[D@n]

If you have critical warnings, definitely clean them up before submitting anything.  Those should all be cleaned up before you expect the tool to perform.

I also recommend passing a Verilator -Wall test.  Indeed, I've been doing that this morning for one of my own projects ...

Once all that passes, write me again but in more detail, and we can try to understand together what's going on.

Dan

[zygot]

2 hours ago, D@n said:

If you have critical warnings, definitely clean them up before submitting anything.

Indeed. There's just no point to exporting HW that doesn't work to the software tools.

It used to be that ISE and early versions of Vivado provided a good default timing report for nets with the worst delay, set-up, or hold performance. This is no longer the case. If using the GUI to create an implementation netlist, you have to open the Implementation in the timing view pane and create a custom timing report. From there you get clues to where you need to start creating more constraints to get timing closure. The default timing report might help inform you about how to do this.

If you have poor clock or IO timing constraints to start off with it's possible to have no issues show up even though your design won't work on actual hardware. Once IO timing constraints are in reasonable shape, you need to address issues caused by synthesis and place & route due to IO signals coming from all of the IO banks in regions that might span the entire device.

There are user manuals and tutorials for synthesis, timing closure, and related subjects as well as how to use the tools available in Vivado's Document Navigator; read them.   

For a significant design Vivado's own IP can cause hundreds of warnings, many of which can be forgotten about, but not ignored. Figuring out how to sort the really important ones from the not so important ones takes a bit of on-the-job training.

A tool to find bad RTL code like Verilator isn't all that useful if your project and code is VHDL. If your entire design is contained in the Board Design schematic using Vivado IP then finding timing problems and achieving timing closure can be a lot more work than alternate design flows. For ZYNQ, you need to have at least a minimal board design that has a ZYNQ block in it.

Edited August 1, 2023 by zygot