Skip navigation
> RoadTest Reviews

AVNET MicroZed SOM 7Z010 + Carrier Card - Review

Scoring

Product Performed to Expectations: 10
Specifications were sufficient to design with: 9
Demo Software was of good quality: 5
Product was easy to use: 8
Support materials were available: 6
The price to performance ratio was good: 10
TotalScore: 48 / 60
  • RoadTest: AVNET MicroZed SOM 7Z010 + Carrier Card
  • Buy Now
  • Evaluation Type: Development Boards & Tools
  • Was everything in the box required?: Yes
  • Comparable Products/Other parts you considered: Other Microzed and Picozed SoM's, Ultra96, Kria.
  • What were the biggest problems encountered?: Latest example designs were from year 2016. Microzed documentation on pinout is professional, for example I couldn't find easily pinout for pins that are connected to PL side of Microzed.

  • Detailed Review:

    RoadTest outline

    My goal for this roadtest is to create a custom microcontroller written in Verilog, implement it on Microzed, and connect Microzed to Minized by PMOD and send instructions with VIO debug interface.

     

    What are we RoadTesting?

    Microzed is a System In Module,  that can be connected to one of ready to use carriers or custom carrier with compatible microheaders. Microzed hearth is a ZYNQ chip, that means beside an FPGA it contains a hardened dual-core ARM processor that is capable of running embedded Linux distributions like Petalinux. Microzed have access to 1Gb of RAM memory, uSD card slot, that is SoM "hard-drive", USB connectors and Ethernet.

    {gallery} Microzed Gallery

    Microzed block diagram

    IMAGE TITLE: Microzed Block Diagram

    Microzed TOP-View

    IMAGE TITLE: Microzed Top-View

    Microzed Bottom-View

    IMAGE TITLE: Microzed Bottom-View

    Example designs - Getting started

    As in others *zed family development boards, Avnet provides example designs, bad thing is all these examples are pretty outdated:

    But, it is not that bad. If you are willing to download 2015-2016 Vivado versions, you could probably follow these tutorials and learn some core Vivado development flow, on the other hand older versions of Vivado will differ in GUI!

     

    Let's talk about more interesting things, like bsp support. As the example designs are outdated, I can't say the same about Avnet GitHub scripts. These scripts provide you a starting point for yours designs, just git-clone bdf, hdl, petalinux repositories, and you are good to go

    Let's try to build some projects. As Microzed is based on ARM architecture, we can build our own linux based system with Avnet make files or just Vivado project.

    Based on script description, this script will build design for MicroZed I/O Carrier and Zed Display kit. Starting from 2020.2 we have at our disposal clean "base" scripts, which I think is much better, but I can't test these because of disc space needed for all these Xilinx tools and 2021.1 branch is not ready yet. I think mz7010 should have some extra scripts for dedicated carrier board much like Picozed. PS. build failed... I hope it is fixed in 2020.2

    Constrains file

    The constraints file is general. If you need to connect some pin from MicroZed to external board, search for pinout documentation.

    For my purpose, let see... I would like to connect JM1, JM2, PL-PMOD from carrier to Minized. Let's search in .xdc JM-1, JM-2, PL-PMOD, nothing... only JA, JB, JY. But where all this J* point to? SoM have unnamed Pmod on board. Let's try search in proper documentation.

     

    According to Microzed carrier hardware user guide page 13, I have found JM and page 16 PL-PMOD connections.

    {gallery} Constrains_gal

    IMAGE TITLE: Microzed JM2

    IMAGE TITLE: MicroZed PL-PMOD

    So, sum this up and create new constrains file we could use in our project for PMOD.

    Microcontroller project

    Let's create new Vivado project using Microzed board, import source files.

    Create new block design with Microcontroller hierarchy.

    In this block design, VIO is used as a logic analyzer, uC reset and enabler. From external pins, "program_data_address" and "clk" comes from Minized. Normally, when uC is implemented in one chip, it uses 15 bit "program_data_address" port from control_unit to make jumps in address memory. In this roadtest I will do jumps manually by using VIO to control logic directly . So what does the uC look like inside? It is made from 3 general blocks.

    Control_Unit - interprets program_data instruction at "posedge clk" and sends instructions to ALU and memory block at "negedge clk".

    ALU - takes instructions from control_unit, and makes calculation like add/sub, and also perform comparator functions. For example, if A input is bigger than B input, the A_bigger flag goes to logic "1" etc...

    Memory - general memory block, takes data from program memory → control unit or directly from ALU. You can save data to general_registers or compute_unit_ram. You can use a multiplexer to send new data to the output port to control for example another logic block.

    Program_memory - Contains hardwired program memory.

    We can program this block by using pseudo machine code:

      Or macros that act as assembler for example:

    As this Minized-Microzed implementation is not autonomous (program_data[] won't increment itself) we will act as program counter and select what instruction uC should execute by VIO. Let's jump to Minized project.

     

    Minized project

    Let's create another Vivado project targeting Minized, create new block design and modify .xdc file from Avnet GitHub.

    Minized constrains:

     

    Hardware connection:

    Connect Minized and Microzed together via PMOD_1 and PL-PMOD. I have used some free lying cables and pins to create connection between these systems

    Generate bitstreams for these projects and program both development boards.

    Use Vivado hardware manager to interact with VIO debug cores, interact with Minized output ports and control uC in Microzed fabric.

     

    So after some time spend testing, there is a bug in uC design! It seems that regardless what we do, VIO reads "0" from accumulator, what could be the cause?

    Let's take a few steps back...

     

    Reimplementing design

    Let's connect VIOS/ILA's differently.

    I think that the issue can be in three places:

    -One, you can't possibly variable from load memory, so in the control unit.

    -Two, accumulator is somehow broken.

    -Three, memory bridge is bugged.

     

    Let's Work on ALU unit. Right click on wires/buses and run connection automation to add VIO/ILA cores to system. The next step is implementing design and running it on Microzed.

    Remember what our project does. It reads instructions from "program_memory" and execute command, after the execution the "program_data_address is incremented". Starting from "0" address.

    We are seeing some activity in "program_data_address", it seems that "Overflow" flag is not up and program gets stuck.

     

    Data out, ports stayed at "0" all time, so ALU isn't getting any operand to work on!

     

    Clear all previous debug ports and mark new ports from memory hierarchy for debug, run connection automation to connect system ILAs.

     

    Generate bitstream and program device.

    Click "+" on trigger setup and add trigger on "program_memory_0_program_data"

    In "value" type "1101_0000_0001_0000" binary vector. This should trigger ILA when constant "1" is loaded from program memory.

    Now arm ILA and restart system manually with VIO. The new waveform should be visible in "hw_ila_1" window.

    Focus our attention on CU_RAM, mark more debug ports if necessary.

    So, in my opinion, I have found the bug. Instruction nb[3] loaded from program memory, that means nb[2] is executed. I think it reads "0" not "1" (look at "register_write" and "micro_outpt" ports)

     

    Meanwhile in behavioral simulation:

    Summary

    Agile workflow doesn't work in FPGA's, before writing any code you should thoroughly think about the way you are implementing the actual hardware. There is no, quick re-write, re-compile whole project. Fixing a simple bug in memory bus could take days!

    Even if design is working in simulation, that doesn't mean that it will work in real implementation! This was an interesting project. I have learned a lot about Verilog and designing hardware. This was, I could say, my first Verilog-type project from scratch, and it was quite challenging.

     

    What about dev-board Microzed? It is like an old trusty car. Old design that is working, maybe there is a new paint, but it is a little outdated. I like that this board can work in stand-alone mode aka SoM  or with a carrier board, if you get bored with basic functionality or are interested in developing your own hardware, you could create your own carrier board. What about other similar boards? If you have the extra ~20 dollars, there is Ultra96, or new Kria SoM, which is based on Ultrascale architecture, but you do not need it if you are learning the basics.


Comments

Also Enrolling

Enrollment Closes: Oct 31 
Enroll
Enrollment Closes: Nov 1 
Enroll
Enrollment Closes: Oct 22 
Enroll
Enrollment Closes: Oct 31 
Enroll
Enrollment Closes: Nov 1 
Enroll
Enrollment Closes: Oct 31 
Enroll
Enrollment Closes: Oct 18 
Enroll