Choices of Design and Build one FPGA Project on Digilent Arty-S7

The simple answer is perhaps to pick the right tool for the task in hand.

However it can be hard to know which is the right tool unless you are familiar with each of them.

Productivity, time and cost may influence the decision.

I've been reading a book on digital design recently and after consuming the first 150 pages or so of old school 'bare metal' logic design, the author decides to allude to the reader that it is impractical to keep on designing like this as the scale of integration continues to increase. It is a lot more productive to use computer aided design to optimise the design for you using HDL. So, next chapter it is introduction to VHDL or Verilog (depending on which version of the book you bought). It wouldn't surprise me if by the end of the book the author informs the reader that it is impractical to keep on designing like this and it is more productive to synthesise directly from C++ using modern design tools (and to buy his next book... )

As with most technologies these days various layers of abstraction likely come into play. I suspect most people are only ever working mainly within a small window on the technology timeline, with most of the detail having being abstracted away in order to increase productivity and to maintain portability across platforms.

The MicroBlaze soft processor is an interesting one. I could potentially see a learning path which makes this a very useful entry point to FPGA for those already familiar and comfortable working with microcontrollers. You start with the soft processor, you then customise the soft processor to fit your needs. You then create a custom peripheral to use along with the soft processor. Finally you create multiple soft processors and multiple peripherals to create a highly customised microcontroller design all on the one FPGA device.

There are some downsides:

 Useable resourse in an FPGA costs a great deal more than it does in application level silicon designs like micro processors and micro-controllers. (That's why Xilinx have Xynq with embedded ARM processors).

The tools to develop with standard processor designs have had the benefit of thousands of man years of development.

Simple FPGA processors like MicroBlaze are quite cheap although the single source toolset leaves a lot to be desired. As soon as you customise the processor (in any significant way)  you are on your own.

Custom peripherals are all very well but the FPGA silicon environment isn't a good place for RF, analogue or power control - if logic will do all you need that's fine.

Multiple custom processors and peripherals in a single design will get very difficult (and expensive) to develop.

I've usually found the best place to be is with a standard micro-controller and a seperate FPGA. The design complexity is much easier to manage and control. The interface between the two can be a problem, I wish there  were application processors with a good fast board level interface to FPGA type devices.

MK

There are some downsides:

 Useable resourse in an FPGA costs a great deal more than it does in application level silicon designs like micro processors and micro-controllers. (That's why Xilinx have Xynq with embedded ARM processors).

The tools to develop with standard processor designs have had the benefit of thousands of man years of development.

Simple FPGA processors like MicroBlaze are quite cheap although the single source toolset leaves a lot to be desired. As soon as you customise the processor (in any significant way)  you are on your own.

Custom peripherals are all very well but the FPGA silicon environment isn't a good place for RF, analogue or power control - if logic will do all you need that's fine.

Multiple custom processors and peripherals in a single design will get very difficult (and expensive) to develop.

I've usually found the best place to be is with a standard micro-controller and a seperate FPGA. The design complexity is much easier to manage and control. The interface between the two can be a problem, I wish there  were application processors with a good fast board level interface to FPGA type devices.

MK

"I've usually found the best place to be is with a standard micro-controller and a seperate FPGA."

Why not use something like Zynq-7000 series device? You get one or more processors and programmable fabric. Since everything is inside the chip, interfacing between the two is without any external connections.

Cost, power,  complexity ! (The comment was made in a thread based on Spartan6/7 which are being pushed as "entry level" FPGAs)

The ARM cores in the Zynq are application processors not micro controllers.

They can go fast and are usually used with a big operating system and external dynamic RAM. They don't have on chip flash.

If you follow the questions on forums you'll see that a very large proportion of the questions asked about Zynq are actually Linux issues.

You can use the ARM cores on the Zynq running bare metal but you are swimming upstream - it's not waht most people are doing and its not where the support is.

All Zynqs come in BGA packages, if you use DDRAM that will too, and your pcb design gets complex (time matched and impedance controlled traces).

I've designed lots of different micro plus smallish FPGA type systems on 4 layer 0.15mm design rule pcbs with no need for impedance control and using QFN or TQFP packages.

Usually less than 64k bytes of code in the uP.

Contrast with a typical Linux  !

I'm not suggesting that sometimes a Zynq isn't just what you need, just that when you need to format shift the audio data from a high end camera and send it out over an AES interface (a real paid for example) then what you need is £2 uP and a £4 FPGA.

MK

(steering away from Spartan, over to Zynq land. a bit of a side story:)

The new Tektronix 2 Series oscilloscope uses a Zynq UltraScale. In this interview with EEVblog, Andy Tedd briefly discusses what runs in the fabric and what on the application processors.

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

RE: Choices of Design and Build one FPGA Project on Digilent Arty-S7

Poster

Upload Preview

Ok

Cancel

It's insight that's not always out there, but no surprises on what goes where..

not affiliated.

Thanks for your excellent, detailed reply. You made some really good points there!

Cheers,
Saad

What I had envisioned here was a learning path that takes someone with microcontroller experience on say an Arduino Uno and give then an alternative route into FPGA by building on what they already know, whilst at the same time demonstrating some of the advantages of FPGA right from an early stage.

Using the MicroBlaze soft processor on the likes of the Arty S7 being discussed here could perhaps achieve that, assuming it was done well by encouraging the leaner to build upon their existing knowledge before diving into hardcore HDL design.

Using the likes of the Arty S7, then I envisioned the first steps being to be to turn it into an Arduino Uno like board using the basic MicroBlaze microcontroller preset and the block design mode to wire up some Arduino shield header pins. Then write some code to drop onto the MicroBlaze instance to do the blinky thing and output 'Hello world' to the console.

This should help keep them close to the comfort zone whilst getting to grips with a new IDE and leave them with a foundation that they can continue to do familiar stuff with and explore further.

However it hasn't really demonstrated any significant advantages over their existing platform. For that you need to be able to do something a bit new like changing the memory size, selecting and deselecting the peripherals to change the footprint or by adding additional peripherals like timers, UARTs, PWMs from the IP catalogue. Add a second MicroBlaze instance and target different programs to each. Play around with the different MicroBlaze presets. Something a bit different from what can be done on the likes of the Arduino Uno platform, demonstrating some of the flexibility and why they may want to continue exploring FPGA.

Once comfortable, then time to explore HDL and start adding custom logic blocks into the design.

All this would be running on the same dev board so at this stage no issues with interfacing between a microcontroller and separate FPGA or multiple instances of different vendors software. That aspect can be left for another day. Analogue inputs could be done through an Arduino shield or through PMOD modules.

I noticed the other day that Whitney Knitter ( knitronics  ) has created a fairly new 5-part video series but using the Arty Z7:
https://www.youtube.com/watch?v=or3yYwGyGpA&list=PLSTiCUiN_BoIM4anuvWS_bM7PTbECZ3PE

Rather than MicroBlaze soft processor, she walks through getting up and running on the embedded Arm processor then moving to embedded C and then finally onto some HDL. Well worth a watch for those wanting to get started on an Arty Z7 or similar.

My two pence.

This might be a bridge too far.  MicroBlaze doesn't support the Arduino execution environment out of the box.  So right away there is a big bump in setting up a default processor environment and connecting I/O to the Arduino compatible hat interface. There is no library support.   When they say bare metal they mean bare metal.   Most Arduino savvy makers don't really understand that the Arduino platform is a runtime environment and a suite of specialized libraries that run in that environment.  I think it would be better to approach the Arty as a new platform with a more simplistic development environment.  There are rudimentary libraries for the I/O devices in the IP catalog, but the learner is going to need instruction in the basics of a bare metal C/C++ environment to get any useful learning done.

First steps are getting a Microblaze system to say Hello World over a serial link.  This is what the Digilent tutorials offer.  But if the student doesn't have a grasp of what the object layout editor is doing they are not going to understand the problems that can occur as they try to customize the basic MicroBlaze design to meet their own goals.

I too think that starting with MicroBlaze is a distraction from what you're trying to learn: FPGA development.

A great module to work with, but if you start with that, you spend brain cells on a (for beginners or for those that want to learn cross-platform) side track in the training, that doesn't bring the goal closer. You need to make the elbows and hands dirty to begin with FPGA. By designing FPGA designs , doing FPGA exercises. Not loading a predefined block and hopping over to GCC.

I agree with Jan. Looking at it from the perspective of a JAVA programmer, which is what I do in my professional life. If someone asks me how to learn to program, I recommend that they start by learning to implement the basic sorting, search, graph, and string algorithms on their own, and then delve into the main design patterns. Let him do it by implementing them from scratch without the help of libraries. Later, when they have mastered the basics, I tell them the opposite, do not do anything from scratch, use the libraries and the well-known patterns that have thousands of hours of very intelligent people smarter than me behind them.

I am new to FPGAs but have a strong formal background in old digital electronics. Currently my interest in FPGAs is not digital design but curiosity about the complete embedded system design cycle. And for this reason I have designed a learning plan from a perspective away from logic gates or trying to master a certain HDL language. My interest is to know in a generic way a wide range of aspects about the design and flow of the current development of embedded systems using FPGAs.

Who knows, maybe I'll get hooked on the world of FPGAs and soon I'll go back on my words.

Learning a HDL language followed a strange curve in my case.
I have studied Boolean logic / digital circuit at school. But no hardware definition, or anything related to CPLD, FPGA.

I bought a Spartan-6 kit to learn HDL.

Understanding the language, and understanding designs, went  steady up. After a year I was able to understand someone's design. Often also why they did it a certain way.

Being able to design something myself was a sudden click. It took 7 years. My first VHDL design where I came up with an approach myself (not lifting someone's work and adapt it with trial and error), spontaneous, was last year. When I tried to make a quad pulse generator for shabaz's SDR.
It went fast from then on. From not being able to design a real thing, to coming up with several options, in a few days.
For me it was like learning to ride a bicycle. Lots of learning without result, without satisfaction. Then suddenly you manage to do it and there's no looking back. 

With programming languages, the ability to design things came very early, after I mastered just a few commands. That's closer to how my brain's thinking process works.