Larry McGovern

Terrific product!

7 posts in this topic

What an outstanding board!  Thank you Jack & Co.!  My single goal in purchasing the Papilio Duo and Logic Start Shield was to learn about FPGAs and VHDL, and I would call this experience an unqualified success. 

I methodically went through Mike Field's PDF "Introducing the Spartan 3E FPGA and VHDL" and found it to be a very fast way to learn VHDL and the Xilinx tool sets. Mike Fields, if you are out there, thank you for that great guide!  Your final chapter requests a postcard, and one shall be coming to you from California.   Although the guide was written for the Papilio One development board, it works quite well with the Papilio Duo.  The only chapters I did not do were Ch. 22 (A high speed external interface) designed for the Digilent Basys2, and Ch. 24 (Using an ADC) which uses the ADC chip on the Papilio One Logic Start wing.  I probably could have interfaced with the AVR on the Duo with SPI, and might end up doing that anyway just for the learning experience.  One thing to note: although Mike states that Ch 25 (Tri-State Logic) cannot be done with the Papilio One Logic Start Wing, it can be done on the Duo using the GPIO pins (which I didn't see referenced in the Logic Start Shield Hardware Guide, but are clearly on the board and schematic).  Anyway, I highly suggest this guide to anyone else starting out who has either the One or the Duo.

I'm figuring the next step is to learn how to use DesignLab, now that I'm a VHDL expert (ha ha) thanks to Mike.  I'm no stranger to programming AVR microcontrollers, and the Arduino-like IDE is sure familiar, so it is now time to see what I can do with the two working together.  A few general questions for the community:

  • Are there any essential projects out there well suited for continuing my FPGA self-study?  At this stage of my education, I'm more interested in the journey than the destination, but it would be nice to find a more involved project.
  • I am fascinated by the ZPUino soft processor, but confess at this point I don't see the big picture here.  Why would I want to recreate a processor on an FPGA, with so many cheap microcontrollers out there that do the same thing?  Is it the novelty?  Is the purpose to ease the transition to programming FPGAs for those who are more comfortable with software?  Or is there some other larger purpose I'm missing?  It looks compelling, but given that there is already an AVR chip on the Duo board, I think I might be inclined to use that instead, and interface the AVR with the FPGA over SPI.
  • Speaking of interfacing with the AVR, I notice that the recommended way to interface is by setting it up as a Wishbone peripheral using the ZPU processor.  Suppose I wish to do this without using the ZPU...  Is there a recommended way to do this, without writing my own SPI interface from scratch?  I know this must be an ignorant question, but I am still very much a beginner in the world of FPGAs.

That's all for now.  Looking forward to using this board in many future projects!

Share this post


Link to post
Share on other sites

Larry, let me reply to you as a blog post, so others can understand what a SoC is and how it differs from "regular" microcontrollers. Will do shortly.

Second, but most important, thanks for your words. You do seem enthusiastic about this new FPGA world - we try to encourage people to learn, understand and explore - this gives us strenght to keep on working and providing as much as we can so that you, ultimately, can have a even better understanding and knowledge that we do :) Not impossible, and definitely not improbable.

With FPGAs, the clock speed is the limit :) Which is close to sky, actually. It's like either buying a car or designing the engine - guess which presents more fun. Even if the car cannot speed to 100mpg, it's still your engine, optimized for a lot of stuff (fuel and oil consumption, less emissions, temperature-variable compression or combustion, so on).

Alvie

 

Share this post


Link to post
Share on other sites

Regarding uses for soft-CPUs: Sending commands to / collecting results from your FPGA design (like for a user interface, or for debugging); being able to create a sort of custom microcontroller with selected (or newly created) peripherals; learning / experimenting with (small) computer architecture.

Regarding your questions about next projects, and about interfacing with AVR:  Why NOT do a SPI interface from scratch?  It doesn't sound that complicated, and you could adapt it for controlling your future FPGA designs from the AVR.  Make the FPGA act as SPI "slave", and the microcontroller as "master;" at first, just doing something simple like lighting LEDs or reading switches.

There are also probably plenty of SPI implementations out there you could try to adapt to your needs.  Although modifying someone else's code to fit a different purpose can be difficult in itself.

 

Share this post


Link to post
Share on other sites

Alvie, I'm looking forward to that blog post.  In looking over the Spartan documentation, I noticed that Xilinx also has its own soft processor IP called "MicroBlaze", so clearly these are important in the world of FPGAs.  I am curious how frequently a typical FPGA engineer will include one in his/her design.  Always?  Occasionally?  It certainly seems useful if one can afford the resources. 

Jaxartes, I agree that creating an SPI interface from scratch to communicate with the AVR looks like a useful learning opportunity.  I'm already digging into more of the many features included in the Duo and seeing plenty of potential. 

Share this post


Link to post
Share on other sites

Hello Larry,

Thank you for your encouraging words, it helps us keep going when we get positive feedback like this. :)

For you question about using a soft processor like the ZPUino. The example that I like to use is this:

Think of designing a circuit inside an FPGA just like you would design a circuit board. When you design a circuit board that does anything more then trivial tasks you are going to need to add some kind of control circuitry to manage all of the chips you put on the circuit board. You could use 7400 series chips to control your circuit but that becomes very tedious, instead most people will put a little microcontroller into the circuit to take care of controlling everything. In an FPGA you can control everything using VHDL/Verilog by defining Finite State Machines, it works, but just like using 7400 series chips to control a circuit board it becomes very tedious. The better solution is to have a microcontroller equivalent, a Soft Processor, that you can drop into your FPGA designs that makes it super easy and flexible to control everything going on inside your FPGA. If you are doing simple things, then a FSM works fine, but when you have something like the RetroCade where there are 3 different audio chips, a Midi controller, Delta-Sigma DAC outputs, LCD controller, and so on... That would be a nightmare to try to do in a FSM, so you need a soft processor that you can code the control logic up in C/C++.

Jack.

Share this post


Link to post
Share on other sites

Thanks Jack.  Your answer makes a lot of sense.  I've worked professionally with FPGA and ASIC engineers for years, but never really explored how they do their job until now.  There's nothing like digging in and doing it yourself to figure out how stuff works.  There is plenty here to keep me busy for a while.  Though I may need to pick up another board in the not too distant future!

Share this post


Link to post
Share on other sites
On 07/05/2016 at 10:26 PM, Jaxartes said:

Regarding your questions about next projects, and about interfacing with AVR:  Why NOT do a SPI interface from scratch?  It doesn't sound that complicated, and you could adapt it for controlling your future FPGA designs from the AVR.  Make the FPGA act as SPI "slave", and the microcontroller as "master;" at first, just doing something simple like lighting LEDs or reading switches.

There are also probably plenty of SPI implementations out there you could try to adapt to your needs.  Although modifying someone else's code to fit a different purpose can be difficult in itself.

Indeed, writing a SPI master/slave from scratch is a good exercise :) It's actually one of the easiest interfaces you can design (waay more simple than an UART, for example)

You can eventually use ZPUino SPI for this, you just need to drive it using wishbone signals.

Alvie

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now