Ultra96-V2 Workshop: Session 4: Application Using Click Mezzanine and Click Boards

re: Ultra96-V2 Workshop: Session 4: Application Using Click Mezzanine and Click Boards by weiwei2

weiwei2 — Fri, 30 Jul 2021 22:21:46 GMT

there is a typo in the title in the table, should be session 4

Session 3 - Application Using Click Mezzanine and Click Boards

re: Ultra96-V2 Workshop: Session 4: Application Using Click Mezzanine and Click Boards by bhfletcher

bhfletcher — Wed, 18 Aug 2021 17:32:19 GMT

As I mentioned today during Workshop #3, one additional thing that you will need for Workshop #4 is a Mini-USB cable (NOT micro) to work with the MikroE USB I2C click (we'll be using in UART mode, not I2C).

https://www.mikroe.com/usb-i2c-click

Hopefully you have one of these laying around from years ago, but these are also in stock at Newark and Farnell and probably any other local electronics store.

https://www.newark.com/qualtek-electronics/3021003-03/usb-cable-2-0-plug-a-mini-b-914mm/dp/02P4473

https://uk.farnell.com/pro-signal/psg91573/lead-usb2-0-a-mini-usb-b-black/dp/3498548

Bryan

re: Ultra96-V2 Workshop: Session 4: Application Using Click Mezzanine and Click Boards by Andrew J

Andrew J — Wed, 25 Aug 2021 17:54:09 GMT

Thanks to everyone for organising these workshops, clearly a lot of work gone in to them and I really appreciate that.

Some feedback, meant in a totally non-critical manner. I think this particular workshop was the most interesting, the most involved and yet pretty much impossible to follow along with simultaneously. Fortunately it's possible to go back and work through it at a slower pace. In retrospect, I think that the first three workshops could have been 'pre-workshop preparation' as there is a lot of material for installing and getting Hello World to work. Then this one could be spread out over 4 sessions, so a slower pace could be maintained and it would be easier to follow along at the same time. Or perhaps split into 1 workshop for install/hello world and 3 for the Mezzanine Click.

Anyway, good job. I'll be going through this in more detail over the next few days and then seeing where I can take it.

Problems:

Like at least one other person, Vivado locked up as soon as I tried to drop the UART IP on the block design and I had to kill the process. It was impossible to start with the platform created in workshop 2 as it would just lock Vivado. In the end, I created a new project, dropped the UART IP on the block design, then dropped the Zynq MPSoC, ran the board automation and connected the clocks. I've gone through the connection automation steps and it seems ok. Fortunately the platform created in workshop 2 was very simple so it's easy to start from scratch. Note that I had re-created this platform today, from the workshop 2 lab notes, so it seems important to NOT have gone through the synthesis/implementation/Board Generation - in other words, don't go through workshop 2 and then start this, it needs to be combined! (Hope that makes sense.) This may just be an issue with Vivado on Linux.

Adding the UART IP on to the block design resulted in this info message (along with the associated TCL command); I don't know if this will turn out to be an issue:

create_bd_cell -type ip -vlnv xilinx.com:ip:axi_uart16550:2.0 axi_uart16550_0

INFO: [Ipptcl 7-1463] No Compatible Board Interface found. Board Tab not created in customize GUI

Edit: I see you get the same message when you dropped the UART IP as well.

re: Ultra96-V2 Workshop: Session 4: Application Using Click Mezzanine and Click Boards by Andrew J

Andrew J — Thu, 26 Aug 2021 20:29:48 GMT

Hi Bryan, bhfletcher,

I'm going through the design for the PWM IP and have a couple of questions to get a better understanding, hoping you can help.

In the LCD_Backlight_Control_Int.c program, we have:

#define PWM_BASE_ADDRESS XPAR_PWM_W_INT_0_S00_AXI_BASEADDR

Looking at the Addressing for the IP the base address for S00_AXI_reg is 0. That's probably not so relevant but are we saying here that the PWM_BASE_ADDRESS is pointing at the SLV_REG0 address in the AXI Peripheral? My assumption is YES, because we write the entered parameter to that address, which is effectively the duty cycle.

The period parameter is set to 20, to give 2^20 PWM width, approx 1,000,000, presumably it doesn't matter that it's actually a bit more. This is used to control how long the PWM pin is turned on for. There's also this comment/.code in the LCD_Backlight_Control_Int.c:

/* Since the PWM width is 1e6 clk cycles, we need to normalize

* the period to that clk. Since we accept values 0-9, that will

* scale period from 0-999,000. 0 turns off Backlight,

* 999,000 is full brightness. */

brightness = period * 110000;

Is there a reason period isn't multiplied by 111,000 in line with the comment? I presume that it doesn't really matter as a count of 9000 (at full brightness) is < 1% error against the maximum width? 990,000 is a comparison value used in the PWM_Controller_Int.v code.

2a) As a follow on, if the PWM width/period is changed, then the 990,000 comparison value needs to change in relation?

2b) And as a further follow on, are we relying on count overflowing to reset back to 0 (except under a genuine reset situation)?

A Parameter for Period, is used in two of the files. In fact, it would seem that the 'root' value is defined when creating an instance of PWM_Controller_Int which assigns the value to the PWM_Period in PWM_w_Int_v1_0. I think I understand the point of Generic (in VHDL) and parameter (in Verilog) but it seems like it's hard-coded when the IP is created rather than when it is used on a Block Design. Is this externalised somewhere for setting at design time without having to actually change the IP? I feel like I'm missing something here.

Being new to Verilog/VHDL, my understanding of how the code works is that the code in PWM_Controller_Int.v is continually executing and is adjusting the outputs on every rising edge of the clock and doing nothing on a falling/negative clock edge. It is all under control of PWM_w_Int_v1_0.vhd which seems responsible for mapping the ports and assigning the signals accordingly. Duty Cycle is being set under my assumption in question 1, the other port values are generated internally.

Thanks

re: Ultra96-V2 Workshop: Session 4: Application Using Click Mezzanine and Click Boards by Andrew J

Andrew J — Fri, 27 Aug 2021 18:09:14 GMT

This was such an excellent learning workshop. I've had time to go through it much more slowly and took the opportunity to document the different approach I took when I did: rather than just follow on exactly, I took the time to explore what was being done. I captured this adventure in these two posts:

https://www.element14.com/community/groups/fpga-group/blog/2021/08/27/summer-of-fpga-workshop-4-elaborating-on-the-workshop-design

Summer of FPGA, Workshop 4: Elaborating on creating custom IP

Hope this will be of interest and use for others who attended the workshop and are new to it as I am.

re: Ultra96-V2 Workshop: Session 4: Application Using Click Mezzanine and Click Boards by dramoz

dramoz — Fri, 27 Aug 2021 22:28:29 GMT

Hi all, and thank you for the workshops.

I just wanted to update you that I was able to fully run the full workshop 4, from Vivado to generating the XSA file, to Vitis building/programming the Ultra96-V2 and testing using the terminal. (Windows 10)

The only real issue was the Makefile, which was solved by following the Xilinx-Forum link.

Best regards,

Danilo.

Makefile link: https://forums.xilinx.com/t5/Embedded-Development-Tools/Drivers-and-Makefiles-problems-in-Vitis-2020-2/td-p/1188742

re: Ultra96-V2 Workshop: Session 4: Application Using Click Mezzanine and Click Boards by Andrew J

Andrew J — Sat, 28 Aug 2021 16:23:36 GMT

I want to add one more thing for Windows Users particularly and hopefully this is a reasonable place. The USB/I2C click board uses a MCP2221 chip which, from the factory, does not enumerate with its serial number. That means when you attach this click board to your PC it will assign a different COM port to it unless you use the same USB port. Unlikely to happen, but it also means that if you attach another USB/UART board with that chip it will also be given the same COM port if you use the same USB port as this click board (obviously not plugged in at the same time!) That could be a pain as it means either (a) you always have to use the same USB port or you have to change your terminal settings to take account of the newly assigned COM port. It also means Windows is using up COM ports unnecessarily, although that's not a big issue itself.

I found this out because I use the same chip on my Instrument Control Board (blogged elsewhere on E14.)

To get around this you can use the Microchip utility to tell the chip to enumerate with its serial number. If it does that, Windows will recognise this device and assign it the same COM port irrespective of the USB port it is plugged into.

The software download is here.

When you install it, ignore any error message about missing drivers and installing manually. As long as Windows has installed the driver, and it has if this workshop app works, then it's fine.

When you run it, it should pull the current configuration of the chip. You need to enable the Enumerate with Serial Number option then click on configure. You could give it a fancier name as well if you choose by changing the Descriptor field.

Doesn't seem to be an issue with Linux as that OS just gives it the first ttyACMn available, irrespective of USB port used. However, I may just have been lucky as I haven't tried it with mutliple cdc_acm devices plugged in.