Table of contents

RoadTest: Xilinx Spartan-7 FPGA Maker Board by Digilent

Author: wolfgangfriedrich

Creation date: 18 Sep 2018

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: Numato Saturn – Spartan 6 FPGA Development Board Numato Mimas V2 Spartan 6 FPGA Development Board Papilio Pro - Spartan 6 FPGA Dev Board with SDRAM And a nice overview of all kinds of FPGA dev boards (not necessarily comparable): https://joelw.id.au/FPGA/CheapFPGADevelopmentBoards

What were the biggest problems encountered?: Board should be shipped with a Micro-USB cable to be usable out of the box. Digilent I2S demo project uses the standard on-data line interface (rx or tx), the audio chip I picked uses the bi-directional version. Digilent SDRAM project settings file needed to be hand-modified for VHDL without AXI port interface.

Detailed Review:

Say Hello to the UUT

First of all, I want to thank Element14 and rscasny and his team for organizing this RoadTest and also Digilent for the generous donation of sweet hardware to the community.

Every RoadTest starts with unboxing, which is nice and it increases the anticipation even more: I was surprised how small the board is, because it came in a relatively large box. But this happens all the time with items that look big on the screen. Only the board is part of the delivery, which is clearly stated in the description: (USB Micro cable required, NOT INCLUDED). The device cardboard box was opened before; clearly visible as previous roadtesters mentioned that is virtually impossible to open the latch without damaging the paper. I was impressed by the foam wrapping around the board, all kinds of cut-outs to guarantee perfect fit and protection.

I got a Rev B board; the revision number is printed on the bottom side below the serial number sticker, but almost unreadable and looks like a black square without magnification. A tip to (every) board designer: use the available space for bigger silkscreen fonts. I like the looks of white soldermask with black silkscreen a lot. Makes the board stand out from all the other dev boards around.

It is an ARTY S7-50 with a XC7S50 Spartan7 FPGA. Bonus nerd points for people recognizing the rulers.

Main features that are important for my project:

• 8150 logic slices, enough logic to hold an SDRAM controller and lots of additional logic
• 256MB DDR3L memory with 16 bit data bus
• Buttons(!)
• Arduino shield connectors

Project and Design Decisions

My project, the Radio Rewind Button (RRB) is a FM radio with a rewind function to catch up with the last few minutes of the show. Streaming audio services from your internet radio stations also don't have a rewind option, so I might need a line input as well.

This idea started with my wife wishing to catch a piece of talk in the radio where we missed the beginning of the story or one of her favourite songs playing that she would like to hear from the beginning right now. Putting 1+1 (idea + implementation) together, this is my entry for this RoadTest+.

• Arduino connection might re-use the design as an audio shield.
• Only a single I2S interface and feeding the FM signal as analog line into the audio mixer chip. The single I2S will give a nice synchronous FPGA design.
• Do not use Arduino I2S as it is limited to one direction (maybe in the future as another input to the audio mixer chip)
• All IOs straight to the connector, beauty of the FPGA to map signals wherever they are useful.
• Added audio interfaces: a pick-up of the FM audio (could be used as another line in without the FM receiver. 2^nd line in, line out, headphone out
• Configuration and control through I2C, will initially be a ‘Bus Pirate’ for flexibility, become later a config state machine inside the FPGA (main focus will be on the audio for the road test).
• All additional IOs routed to the FPGA, will come in useful for fully functional design.
• Internal LDO to be used to keep part count and cost as low as possible.

Disclosure: The whole project started as my (unsuccessful) entry for this year’s HackADay price, so I already had a concept and the ARTY S7 turned out to be a perfect base platform.

Downloads

For reference, here is a list of items I had to download to get my project/roadtest started.

Vivado HLx 2018.2: WebPACK and Editions - Windows Self Extracting Web Installer (EXE - 50.56 MB)

https://github.com/Digilent/digilent-xdc/blob/master/Arty-S7-50-Rev-B-Master.xdc (Arty-S7-50-Rev-B-Master.xdc)

https://github.com/Digilent/digilent-mig/ (This Repository holds Xilinx Memory Interface Generator (MIG) settings for Digilent boards. These settings can be imported directly in the MIG IP Core in Vivado.)

https://github.com/Digilent/vivado-boards/archive/master.zip Digilent Vivado Board Files

https://github.com/Digilent/Arty-S7-50-GPIO/releases/download/v2017.2-1/Arty-S7-50-GPIO-2017.2-1.zip Arty S7-50 GPIO Project

https://github.com/Digilent/Pmod-I2S2/archive/master.zip Pmod-I2S2 Source project

https://github.com/Digilent/Pmod-I2S2/releases/download/v2017.4-1/Arty-S7-50-Pmod-I2S2.xpr.zip Pmod-I2S2 Release project

Timeline

20. July                         RoadTest+ Start with the arrival of the package

  8. Aug                         Ordered PCBs and parts

13. Aug                         Parts arrived

16. Aug                         Boards arrived

18. Aug                         Boards populated and tested

Forever and beyond     VHDL Logic Design in Vivado

Software

Vivado 2018.2 Installation

I opted for the Web Installer for Windows 8, which was an initial 53MB download. First window claims this installer is for Win7.1 or 10, no Win 8!? Picked Vivado HL WebPack (Webtalk required). 7.4GB download and 32.8GB disk space required.  1hour 15 min install time.

Digilent Vivado Board Files Installation

The process is nicely described at the Digilent installation page. I had to manually enter the location where the archive is unpacked. In the tcl script ‘Vivado_init.tcl’ the predefined part of the path was different from what the folder was called in the archive.

Vivado_init.tcl :

set_param board.repoPaths [list "<extracted path>/vivado-boards/new/board_files"]

Board file archive path:

Downloads\vivado-boards-master.zip\vivado-boards-master\

This is easy to overlook and could bring a lot of head scratching.

Also, I had to download the board constraints file from a different Github location and copy it into the same location, where the board file definition was located. The .XDC location is here: https://github.com/Digilent/digilent-xdc/ and is mentioned on the product page.

Plugging the ARTY board in for the 1^st time

Preparation before plugging the board in: Power select jumper to use either 5V USB power or 7V-15V power through the barrel jack. Pull-up resistors for I2C through J4 are installed, which is important for my project as the daughter card does not have pull-ups.

The drivers for the USB serial interfaces were installed without any issues. BUT… Later during the 1^st simple design (Getting to blinky) to prove the tool chain, I could not program the board through Vivado. A Digilent tool called ‘Adept’ was able to see and program the board. The FTDI driver needed a setting called ‘Load VCP’ enabled, which is found in the advanced tab of the USB Serial Converter B properties. See below for details.

A simple design is loaded at startup that cycles the 2 RGB LEDs and does a Knightrider effect with the 4 green LEDs L2-L5 when all 4 switches are in the off position. Turning any switch to the on position stops the LEDs and turns the respective LED on. This is a nice demo to verify that the board is operational out of the box. Documentation talks about not to use the RGB LEDs in 100% duty cycle because of brightness/power/heat. This should be designed save and after checking the schematics I can confirm that it is. All LEDs are driven at ~20mA with a max specified continuous forward current of 25mA. But they are BRIGHT, so it is a good idea to dim them down. Initially when I plugged the ARTY S7 board into an USB port on my laptop, it was not going to boot until I unplug the board or press the RESET button. I found out that a non-compliant USB extension was the culprit here. This is interesting, but not really important.

Vivado

As everything to bring the board and my project to life is done in Vivado, I will spend quite some time explaining what I am doing. I consider this part of the roadtest, users starting to use Vivado hopefully find my project part interesting. The ‘Getting Started with Vivado’ guide from Digilent is very helpful and located here: https://reference.digilentinc.com/vivado/getting_started/start. Things still might be different as the guide uses Vivado 2016.4 and I have the latest installation of Vivado 2018.2.

Generating a new project runs through a few windows with expected questions about source and constraint files and the target device/board. The ARTY-S7 is one board option, which shows that the earlier board file installation was successful.

When selecting the constraints file, it is import to check the option to make a locale copy of the file. This way all changes are locale to the project. The SDRAM interface pins are not defined in the ARTY-S7 master XDC file.

The 1^st project I am trying is the obligatory “Getting to Blinky”. This is similar to the GPIO project which is pre-loaded on the board, but I am using VHDL instead of Verilog. All the files can be found on my Github under VHDL/Blinky. (ADD constraint and VHDL code). To run the design a bitstream is generated by clicking on the ‘Generate Bitstream’ item in the Flow Navigator at the far left of the Vivado window.

The next step is to program the target device on the ARTY-S7 platform. I ran into a small issue that the board was not visible after connecting the Hardware Manager to the Vivado Hardware manager local server. To resolve this I had to open the Windows Device Manager and open the properties of USB Serial Converter B under Universal Serial Bus controllers. Under the Advanced tab I had to enable ‘Load VCP’ to load the Virtual Com Port.

After that Vivado Hardware Manager did see the target device and could happily program the bitstream and get to blinky. Mission almost accomplished….. Wait, why almost?

This procedure only programs the FPGA itself, for a more permanent solution the FLASH memory needs to be programmed and load the design at every poser up/reset automatically. A RMB and selecting ‘Add Configuration Memory Device…’ brings up a Window.

With the help of the schematic, the correct device can be selected.

One more step, in the Generate bit file properties (RMB on ‘Generate Bitstream’) the option –bin_file  must be enabled and the ‘Generate Bitstream’ needs to be re-run. Now the bin file can be selected in the device window and we get a permanent blinky until we progress to more complex designs. Mission accomplished!

Re-using the Pmod I2S2 Project

Initially I thought, I am just lucky as Digilent published an I2S project, which I was planning to re-use for this roadtest/my project. But they are implementing 2 classic I2S interfaces, one of them for writing and on for reading I2S audio data. The TI PCM3070 audio chip I selected uses a bidirectional I2S interface reading and writing I2S audio data synchronous with the same LRCLK and BITCLK.  Anyways, here is how to access the sources. The release project (located here) has to be downloaded to a local folder. After extracting the zip file, the .xpr file has to be opened in Vivado. The project was done in Vivado 2017.4 and the Clock Wizard got an upgrade from rev 5.4 to 6.0 in the meantime, so the project import ended with a locked IP because of incompatible versions and the source code is written in Verilog so I would not be able to modify it to my needs. I am going to stop here, and not go down this excessive de-tour as part of this road test.

The SDRAM

As part of the project I am going to use the SDRAM on board. Let’s see how I can make use of the support from Digilent. They provide settings that can be directly imported into the Xilinx Memory Interface Generator. The settings are downloadable from here.

Generating the memory interface is started by clicking on the IP Catalog in the Flow Navigator. Under Vivado Repository > Memories & Storage Elements > Memory Interface Generators > Memory Interface Generator (MIG 7 Series), the memory generator is accessed.

It opens with the Start Screen already knowing the basic information of the project as FPGA type and design language. On the next screen, selecting "Verify Pin Changes and Update Design" enables the option to use existing project and constraints files. I loaded the two files found on the Digilent Github (see above, should be a .prj and a .ucf).

Oddly, under Windows 8 the Brose file buttons are disabled and the path and file name have to be entered manually or copy/pasted. VHDL design is not supported by the AXI port interface. So the .prj file has to be edited manually to make use of the native port interface. My own prj file has a line with <PortInterface>NATIVE</PortInterface> instead of the AXI definition.

The imported .ucf file defines all pins as IO standard SSTL135. Some signals are DIFF_SSTL135.

A validate brings a log message but let’s you continue with the Next button. The termination constraints seems to be fixed in the generated .XDC files.

Next > System Signal Selection: clock is defined; the other signals will only be used internally for now.

After a summary and some info screen, the memory IP core gets generated.

This takes quite a while and generates design sources, config files and simulation sources for the SDRAM controller. The top level module can now be instantiated into the design. A template for that is available under the IP Sources tab. The .xdc constraint file for the DDR3 also got generated and is right next door to the template under Synthesis.

The application interface port looks not quite straight forward; I guess some documentation will be useful. Let’s go Google hunting. Xilinx documentation UG586 ‘Zynq-7000 AP SoC and 7 Series FPGAs MIS v4.1’ is the document to read. Starting at page 20 DDR3 memory solutions will be discussed. Page 90ff explains the user interface signals. I was trying to setup a really simple example without testbench and either move forward from there or dive into the big world of Vivado design simulation. This got much more involved than I initially anticipated pretty quick (/me takes off rose-coloured glasses) and unfortunately blew the timeframe of this roadtest.

TBC…

The Project

The idea is to have a FM receiver chip with analog interface to get the radio data into the audio processor as quickly as possible. The FPGA implements a ring buffer inside the SDRAM memory with an audio processor feeding I2S data from the FM radio into the buffer and a line out/headphone back end. Ultimately the FPGA is going to configure both ICs over I2C and control the radio station and potentially a small display with all necessary information as FM frequency, rewind metric and memory telemetry. Finally the main controller will be implemented as a BIG red button to rewind your radio and give superior listen experience.

The design and layout is finished, schematic (with fixes) and assembly drawing are on the Github.

https://github.com/wolfgangfriedrich/P42-RRB

With 256 MB of memory all used in one big ring buffer and assuming 44.1 kSamples/sec, my math adds up to just under 25 minutes of rewind time, which should be plenty.

Additional information about the project can be found on my HackADay project page.

https://hackaday.io/project/112183-rrb-the-radio-rewind-button

Configuration of the FM receiver

To get started quickly my plan for configuration was, to connect a Bus Pirate (https://www.seeedstudio.com/Bus-Pirate-v3.6-universal-serial-interface-p-609.html) to the I2C interface and do all the settings interactively or in a script uploaded through the terminal software. My program of choice here is TeraTerm with its TeraTerm Macro language (https://osdn.net/projects/ttssh2/releases/). Later I will add an I2C core to the FPGA for configuration, but in the development phase the turnaround time to compile a new .bit file for every test of configuration is just too slow.

It turned out that the configuration of the audio processor was very simple to get basic analog audio out. The Si4731 Programming Guide(AN332).pdf is the document of choice here. It has flow charts for configuration.

Here is the TeraTerm macro. It is self-explanatory.

; power up the FM receiver: CTS and GPO2 enabled, external RCLK, analog output
send '[0x22 0x01 0xc0 0x05]'#13
pause 1
; Get version information
send '[0x22 0x10][0x23 r:8]'#13
pause 1
;set FM tune frequency to 8990 = 0x231E
send '[0x22 0x20 0x00 0x23 0x1E]'#13
pause 1
;Use GET_INT_STATUS (command 0x14) or hardware interrupts Until STC bit is set
send '[0x22 0x14][0x23 r:2]'#13
pause 1
;Call FM_TUNE_STATUS With INTACK bit set (command 0x22)
sendln '[0x22 0x22 0x01]'#13
pause 1

Configuration of the Audio processor

The Audio processor TI PCM3030 is a bit more complex with its 3 line inputs, digital I2S interface to receive and playback and line and headphone output. The PCM3070 App Reference Guide.pdf is good lecture here, it has some examples to show basic configuration but none of them does everything I was looking for. Initially I would be happy to route line in from the FM receiver straight to the headphone. From there I am going to update the configuration to use the I2S interface to detour the audio data through the FPGA.

Using the Buttons on the ARTY board

In the spirit of re-use and in need of at least 1 button (a big red oneJ) I am instantiating the de-bounce module of the GPIO project that was loaded on the board when it arrived. The module is nicely parameterized, so it is possible to use all 4 buttons with a single call. Code can be found as part of the project and full credits to Digilent again for providing excellent support for their hardware. For testing 3 of the 4 buttons are routed to one of the RGB LEDs but will be used for other functions later on. I am thinking station change for the FM receiver.

Summary

The ARTY S7 board is a very flexible and capable FPGA platform. All logic code development happens in Vivado which is a massive tool chain and takes a long time to master. I added as many information as possible to encourage new users to tackle the steep learning curve of FPGA development.

Unfortunately I was not able to finish my ambitious project endeavours in the given time frame. A circuit board was designed and brought to life, but the biggest hurdle at the moment is, to engage the native IP core SDRAM interface in VHDL. I will continue updating this project and a success on this front would benefit the FPGA community.

Other items on the task list are a bi-directional I2S interface and an I2C configuration interface. I also might write an easy to understand tutorial on how to setup a functional testbench in Vivado as this is an essential tool for all FPGA development.

Finally my sincere apology for being late with this road test. I was trying hard to get the SDRAM working, but could not get it done even with the extra amount of time.

And the road-trip continues...

The Dashboard in Vivado:

https://www.element14.com/community/people/wolfgangfriedrich/blog/2018/11/10/vivados-forgotten-feature-the-dashboard