Richm

Dunno exactly but it is very helpful to use a FIFO between the data generator and the UART transmitter. That way you can just write the output data ( one byte per clock cycle using AXI stream) to the FIFO and the communication between the FIFO and the UART takes care of loading bytes when the UART is ready.

I've found Xilinx driver code to be obtuse and buggy while writing my own for the UARTS, timers, and other simpler modules using the TRM is pretty easy. More than once I've had the experience of studying/debugging the provided code only to realize that I could have it working already if I'd started with the TRM and set set/clear the bits myself. I really like MPSOCs because the combination of FPGA and PS makes it easy to create your own peripherals in the fabric specific to the part and use. For instance, if I was interfacing to an SPI display I would write Verilog IP that could do the SPI and higher level maintenance of display with an AXIlite interface so the processor can simply write chars to the local buffer and not be concerned with the rest of the process.

Dunno, I've experimented with many PL only designs but I always use the PL clock & a clock wizard. If you click on the 'board' tab with the block design open, you should see a clock source listed that you can click on and add to your design. It will create the necessary ports, constraints and a clock wizard that you can modify. Note that by PL only I mean no PS in the block design and using the Vivado hardware manager only.

No, the timing isn't super critical. Your RX module should restart with the leading edge of the start bit so that any accumulated error only potentially affects the bits within the byte, not byte to byte. If you use a high enough frequency input clock you can simply count clock cycles to time everything, the error will not accumulate. Also, you want to use a metahardening block in the same clock domain on the rx pin input. On the TX side you will probably want a large enough fifo so as to avoid having to handle the back pressure up stream.

Did you simulate? Sounds like something like a counter is not properly initialized and it takes about 10 minutes for it to roll over.

It could be a problem with the AXI bus in the PL. Double check the assigned addresses in Vivado and the xparameters.h file that Vitis created when you built the platform. An address mismatch will hang the AXI bus and appears to crash the entire system.

C ( and C++?) are highly typed languages so it is worth learning to be precise with constants and data types to avoid unexpected errors. In C, 2 != 2.0f != 2.0. The first is an integer, the second a single precision float and the last is double which is what C defaults without the 'f' suffix. Yes, the compiler can automatically convert in some cases but it is better to be completely explicit. For example, your code maybe working just fine but you are implicitly using double (64 bit) floating point.

I also had a quick look at your code. It looks like you are setting a flag in the isr for the main loop when a character is available? This would be the same as polling ( blocking ) in the main loop with an extra layer added on top. What you want to do read characters in the isr into a double (ping-pong) buffer until the rx fifo is empty and then set a flag and switch buffers when the command framing character ( usually cr or lf ) is received. What I usually do is set the flag to 1 or 2 to tell the main loop which bank of the rx buffer to read. Also, be aware that sending a string longer that 16 chars will cause blocking on the tx side. I skip the character echo and transmit a simple ack/nack ( "OK"/"Error" ) depending on the results of the command parser.

SPI is a particularly simple protocol. Designing an HDL SPI master is an excellent beginners exercise - study the a/d data sheet, it should have everything you need to get started. Can I help any more than that? No. VHDL gives me a headache. I like the clarity & simplicity of Verilog.

Do you have the IP source code? If so, add an output port and assign it the input you want to use elsewhere. Simple & easy.

One also needs knowledge and experience with DSP since that's what you're doing. It took me a couple of years of Sundays to finally get comfortable with Verilog, AXI and Vivado including taking a bunch of Xilinx on-demand classes. Learning how to use the simulator and knowing how to interpret the results is perhaps the most critical part.

This is a bit embarrassing, but I discovered after buying another I2S PMOD that I wasn't driving the MCLK ( PMOD in slave mode ) at the correct frequency ratio to the LRCLK. A simple change to assign the MCLK to a different bit in the clock counter fixed the problem. This error didn't affect the D/A just the A/D thus explaining what I was observing. In my defense I think the data sheets are a bit confusing, but rererereading them fixed the problem.

This is maybe a good application for hardware acceleration?

I could be wrong, but don't you want to use a full power domain ( not LP ) axi master to connect the A53s to the FPGA? Also, did you start with Vitis by creating and building a platform using the xsa file generated by exporting the hardware in Vivado?

Can you elaborate as to what kind of underlying issues might occur when using direct register access for a GPIO? I've never used the PS GPIO, but the AXI GPIO couldn't be simpler - 1 data and 1 data direction register per channel. In my experience, the Xilinx driver code is way over complicated to the point of being hard to use and debug. More than once I have started with Xilinx example code and then ended up doing what I should have done all along - read the documentation and read/write the registers myself, just like I have done many times in the past with HC11/16s, PICs, AVRs and ARM microcontrollers.

The solution is simple. Don't use the buggy Xilinx driver. Read the TRM for the chip and use Xil_In/Out calls to set the registers directly. Look in xgpiops_hw.h for definitions of the register address offsets.

The base address of an AXI lite IP comes from the Vivado address editor. If you examine the documentation for the GPIO, you will find the offsets and bit definitions for all the accessible registers. In this case, the offset for the second channel is 8 so Xil_in32( baseaddress ) will read the switches and Xil_Out32( baseaddress + 8, data ) will write the leds. The problem with Xilinx's driver code is that it can over complicate something simple

What device? If you already have processors onboard, the simplest is to use them. I think that the Vitis bootloader is for hard processors? Vitis works with a somewhat complicated platform/domain/system/app structure and the system level is for grouping all the apps that are intended to run concurrently on the chip. Building the system will create a boot file that contains the fpga bitstream, the elf files for all the processors, the fsbl and possibly the pmufw and ssbl. With a microblaze, doesn't the elf file need to included in the bitstream so that the instruction memory is loaded with the bitstream? This would mean Vivado -> Vitis -> Vivado to include the elf in the bitstream. I'm not sure Xilinx really cares too much about "the little guy", altho I can tell you from experience that the more you use the software the easier it becomes.

I think that might be a good way to permanently "fix" it. If you are looking for a solution that involves tossing out the board you have and buying another, this is it.

Did you look at the available US+ dev boards? I have a ZCU104, which is one of the cheapest Xilinx US+ boards. The chip ( XCZU7EV-2 ) is incredibly powerful with a good size FPGA and A53 and R5 processor clusters. It only costs a finger or two, not an arm & leg. The chip is the largest US+ part that doesn't require a license for Vivado. What I want, for no real reason, is a large Virtex ultrascale dev board, but I'm not a military contractor.

One thing to be careful with is the S2MM (input to ps) must be set up first, before the MM2S channel. If you try streaming data into the DMA before the channel is set up it will lock up. I found this mistake in Xilinx's own example code. I would look closely at the DMA driver code, it could easily have bugs in it. From my experience with both STM and Xilinx, I would say that driver code is often written by inexperienced programmers and not necessarily properly tested. Read the AXI DMA data sheet as well. Using the DMA is basic mode is really simple and requires just 2 register writes per channel. Use this sequence: 1) Set the run bit ( only need to do this once ) 2) Wait for DMA idle ( only after the first transfer ) 3) write the S2MM address and transfer length (bytes) 4) write the MM2S address and transfer length I use an AXI DMA to transfer 64 32-bit words to 8 different IPs by separately multiplexing tvalid. Tready is tied high as I designed the IP to always be ready. The DMA has internal fifos and has no trouble transferring all 64 words in a single burst of 64 clock cycles. I use the OCM, which as been set to non-cachable, as buffers for the DMA transfer.

You need to filter, window and possibly zero-pad the input to the FFT. Streaming raw data into an FFT results in what you got.

use axi DMA to transfer data to/from pl into ps ddr memory. Unless your board has separate ddr for both the pl and ps, you will need to use the ps ddr. I remember reading somewhere that the ps ddr connection is omitted in vivado for zynq US+ because it's not necessary for the block diagram

what is the first create_clock warning about? I don't think you need or want to use this in combination with the clocking wizard. Also sysclk != sys_clk. If you click on the board tab does it show a clock source? If so, you can right click the clock source and add it to block design. This will add the input pin(s) and a clocking wizard and all the necessary constraints. I'm no tcl expert, but I separate the pin constraints into 2 lines ( for a ZCU104 ) : set_property IOSTANDARD LVCMOS33 [get_ports led0] set_property PACKAGE_PIN D5 [get_ports led0] note no ';' termination or curlies

Vitis is very confusing at first. I believe you should create the platform first and then add the application. What processor are you targeting? Make sure to check the 'generate boot components' box when creating the platform. Double click on the 'platform.spr' file in the explorer and you should see domains for both the fsbl and the pmufw. Are you building the platform before adding the application?