About:
Through Xilinx and Element14, a training program to learn about the Zynq 7000 platform which is System On Chip combining an FPGA with an ARM processor. This comes to the students as complete development board packed with goodies like a wireless chip from MuRata (BT/BTLE/WIFI), 8GB Flash memory, onboard RAM, USB to JTAG (JTAG programmable over USB), Arduino-style headers (3.3V compatible only), Microphone, Bi-Color LED, and two additional expansion ports.
See all blog posts for this training here.
Lab 2 - Making it into the real world!
Lab 2 focuses around some of the final configurations to be able to actually run a real program. We have to configure the clock, attach the DDR memory and enable the UART (Serial port).
The UART is set in the PS-PL configuration settings and was pretty straight forward. It was noted that the baud rate is relative to a unique master clock specific for the UART. It does not appear to be tied to a master chip clock; and can be set individually. I'm running at 115,200 and the instructions guide me to use a UART clock frequency of 100 MHz.
DDR (RAM) configuration
Configuration of the DDR RAM can be done a few ways. The Instructions walk me through the nitty-gritty of defining exact memory type, part number, bus width. It even allows for customization of things like memory clock frequency, junction temperature. There are some other necessary settings like latency for each of the four memory buses between the Zync and the DDR chip. If you've ever looked at a board and seen squiggly lines between two chips where it looks like the designer was just messing around and not taking the most direct route, that is a technique to ensure that all the lines in the bus have the same impedance and the same latency (as defined by trace width and trace length). I don't know too much about this process other than there are some provided formulas.
Here are the settings that we used in the training. We have to fine-tune the propagation delay in nanoseconds between the Zynq and the DDR memory.
Getting ready to use real hardware!
We are finally able to export our HW description. This is essentially defining... um... our hardware! What I mean is - If I were developing an embedded system; then at this point I will have already defined all my pin connections, MIO (Multiplexed I/O), serial ports, SPI connections, RAM, Flash, etc. Vivado lets me package all this up in a unit, then pass it on to the "SDK" program. The SDK is where I write the actual code that will run on the chip.
I export from Vivado with the "Generate Bitstream" option. This bottles up a series of files that the SDK can then import and give the user access to the correct peripherals. The bitstream is the imported in the SDK. From this point on, we are using the "SDK" program instead of Vivado. Using this, we create a BSP (Board Support Package). At this stage I'm not entirely sure what this is other than an apparent abstraction layer between the actual project code and the hardware. I'll update more as I get more familiar with it.
Finally, we can create a new application! The SDK has a canned "Hello World" program that we can use as a base. While we have the bitstream loaded, and the Board Support Package loaded on top of it, we click "File--> New --> Application" and can select a "hello world" option. This dumps in all the correct header files, 'includes', and creates a generic C file which prints "Hello World" out to the console.
Once that is done, we can push the code down to the REAL PHYSICAL (finally!) hardware.
Right before that, we have to change the DIP switch on the board to tell it to boot from JTAG instead of Flash. Once we select "Run" from the SDK and watch a few pages of debug info scroll by, we are greeted very kindly from the computer overlord. I got like... REALLY crazy once this happened and spiced up the code a little bit. Hope that is OK 
In conclusion
Today's lab got me through the process of finalizing the physical hardware configuration, exporting it to the Software Development Kit program, and finally being able to bit-bang some code. It did take a while and I feel like I should have acquired a few different types of EE/Computer Science degrees; but the instructions were /very/ well written. Every extra warning message and checkbox was clearly documented in the training program and I wasn't led astray. I'll admit - I usually have a tendency to skim through these type of instructions and skip ahead; but these were done well enough that following them wasn't a problem. I really didn't have any issues getting the final product even if I didn't really understand all the other stuff behind it. I have found that re-watching the training videos at the end of the lesson helps tie things together for me.
I usually like to do videos for each post, and I will make an effort to do so in future posts. Time has gotten away from me and I'm working to make up lost ground. In replacelement of that, here is an action shot of the MiniZed running my WAY AWESOME "Hello World" code This picture is pretty explicit, so please hide all of your loved Ones and Zeros...
Project update:
I think I'll be picking up a set of RobotShop Rover parts and just splicing in line level converters as needed. This seems to be the easiest way to graft together the 3.3V and 5V logic. This will require some 'not for the faint of heart' modifications of the stock PCB on both the MiniZed and especially the Rover boards.
Thanks everyone!