FPGA power-up and code relocation (basics)

Hi everybody, I'm a Ph.D. student on robotics and i'm *totally* new to the world of FPGA and i need little help understanding some (i think) standard procedures. I'm using a Xilinx Microblaze (32bit) microcontroller (with EDK) and i'm triyng to implement a special control algorithm for a robot. Now the problems. Since the FPGA are volatile devices, i need a PROM to configure them at start-up.

1) how do i fill the PROM? I know there are different section (configuration, SW, user Data) but how do I fill each such sections using xilinx tools? 2) since the program and the data are big, how can I relocate them to an external memory such as a RAM? I know that using an appropriate linker script I can do that but it's not so clear to me how all works. (Should the program fit in the internal RAM of FPGA or it can reside all or in part in external RAM? Using the linker script at start-up the code is automatically copied in the right portion of RAM?)

As you can see I'm totally new to this world. I've read about this issues (xapp482, xapp501, ds123,...) but all the documents are too much specific, what I need now is an idea on how all this stuff works, just to understand the flow and the tools I need.

I know that this issues are *well* known to most of you and maybe you'll find boring explain this basic things but I'll appreciate any hint you can gave me.

Thanks in advance, Andrea.

Reply to
Andrea05
Loading thread data ...

Hi Andrea,

Welcome to the world of FPGA! Don't panic, you are very close to getting where you want to go. All the questions you have asked are valid and sensible.

In fact, as you no doubt suspected all along, there aren't really any hard-and-fast "standard procedures" for what you're interested in doing. There are various standard techniques and approaches, but no One Right Way. The specifics really vary from project to project.

You have correctly identified that the FPGA needs to be configured somehow - this can be from a special PROM, or some other method, but ultimately the FPGA image must be stored in non-volatile memory somewhere. Note that this might be - but certainly doesn't have to be - the same non-volatile memory that contains the application program code for your control algorithm.

This will depend quite a lot on your board. Are you using a standard development board (i.e. off-the-shelf from Xilinx, Avnet etc) or is it a custom-built piece of robotics kit? Generally speaking the process of formatting and downloading the PROM image will differ quite a lot from board to board.

So, if your application can be made to fit entirely within the block RAM resources inside the FPGA, then there is no need for any separate external application code: the FPGA will start running your program as soon as it's configured. If it's bigger than that, then some sort of "bootloader" program is required. This will sit in a lump of BRAM and will be run as soon as the FPGA has configured. In the simplest case it would just jump directly to the location where the program is stored in external non-volatile memory; however, this is often quite slow. If there is SRAM or DRAM available, the bootloader can copy the program from non-volatile storage into faster volatile memory, and then execute it from there. It might also do some other things like clearing some region of memory, for example.

Of course, if your program is bigger than your non-volatile storage, then you can't really do much other than download it manually into SRAM/DRAM each time. Or get your bootloader to download the application over ethernet or something complicated like that.

Last time I did anything like this (which was a while ago), I had to write the bootloader myself. It's not very hard, and there is usually an existing reference point to start from. For some common cases and on "supported" development boards, the EDK may now automate this (perhaps someone more familiar with that side of things can fill in the blanks here).

The linker script merely tells the linker what memory address each section of the compiled program should live in. This information is propagated into the .elf file and can be used by bootloader-type applications, but the linker script itself doesn't really play a part in the bootloading process.

Hope something in all this waffle is useful. I'm sure you will find plenty of people on this newsgroup with helpful advice. You might also try comp.arch.embedded for any issues that are more processor-related than FPGA-related.

Good luck!

Cheers,

-Ben-

Reply to
Ben Jones

Thank you Ben!

now I've a little clearer vision on how the things works, I found useful your answer to point two.

Just few things are still not clear.

Herein I'll refer to the Xilinx world: EDK, Microblaze as microprocessor, XC2v1000 as FPGA and XC18V04 as ISP PROM.

Using EDK everything is easy because only pressing a button on the GUI it's possible to syshthetize the design, place&route, ... , download (using iImpact?) in the PROM. Then only pressing a button on the board, the FPGA is configured and everything works fine.

Thinking on the section on a PROM (configuration, SW, User Data), I wonder how these sections are filled. The definition of the "HW" (microprocessor + peripherals) is in the configuration section? The program that I coded in C is in the SW section? The variables/constants I declared in the code are in the User Data Section?

I think not... There is a way to exploit these sections (and an external volatile memory) to reduce the size of the FPGA I need for my application? I believe there is a way to use the FPGA resource almost only for the "HW" and to use other external devices for storing data/program.

I'm still a little bit confused...

Do you know some good site/book/document that can help me?

thanks,

Andrea

Reply to
Andrea05

Hi Andrea,

Thanks; that is useful to know.

First of all let's look at your system and how it works. The XC18V04 device is a specially-designed PROM that knows how to use the configuration data that's stored within it to initialize an FPGA. It doesn't know anything about what the FPGA does, whether the FPGA has a processor inside it, whether you are running software, or anything like that. It just "brings up" the FPGA at startup.

The second thing to note is that the FPGA is pretty much unaware that the XC18V04 exists in the system at all. By the time the FPGA is operational, i.e. the clocks are running and it's out of reset, the PROM has played its part and the FPGA cannot (and does not need to) access its contents.

So where is the software code that the Microblaze core is running, then? In your case, I think the answer is that it's inside some of the Block RAM resources of the FPGA. While the PROM is initializing the FPGA, one of the tasks it performs is to initialize the contents of all the memories inside it - the data for this is just another part of the FPGA configuration data. Assume then that your application code fits completely inside the BRAM resources in the FPGA. What EDK does in this case is to take the hardware bitstream (.bit) that is produced by the implementation tools, and take the application binary (.elf) produced by the compiler, and fill in the appropriate memories in the former with data from the latter. The resulting bitstream is "self-contained" and will run your application as soon as the FPGA is configured and running.

What happens if your application is bigger than the BRAM resources available in the FPGA? The technique described above won't quite work in that case; you will need some other non-volatile storage to hold the application program, or you'll have to find some other way to provide it to the FPGA. The XC18V04 isn't suitable for storing anything other than an FPGA ("HW") image alone.

Also, you will most likely require some external volatile storage attached to the FPGA, so there is sufficient space for the program's variables, stack, heap etc. Your system may already have such external memories attached to the FPGA - you'd have to check the manual/schematics or look around on the circuit board for chips that look like flash/SRAM/SDRAM.

It is certainly true that using external memories for your application will often allow you to use a smaller FPGA device, since the BRAM resources are probably the limiting factor (and buying and FPGA is a very expensive way to buy memory!). The XC2V1000 has 40 x 18kbit block RAMs, or 80KBytes. Assuming that all this memory is available to the Microblaze processor, this should be enough for a modest control algorithm. But for more sophisticated applications it might not be enough.

Unfortunately, I have to say no! Most people seem to learn all these things "on the job" as you're doing right now. I'm sure there are introductory texts on embedded systems which will talk about memory selection and system design issues for microprocessor and microcontroller applications, although they may not mention FPGAs explicitly. So, you are probably best off just asking lots of questions!

Hope this helps.

Cheers,

-Ben-

Reply to
Ben Jones

Thank you again Ben!

Your always very clear and now I'm starting to understand...

Now I'm working with a Memec V2MB1000 Development board but the goal is to design (or at least to write the pecifications to realize ) a small board devoted to the control of a single joint of a robot. If you are intrested in details you can find a paper in which i'm a co-author at

formatting link

Yeah! This is my nightmare!

Given that I have filled such non-volatile memory with the application (how to do that will be another question!) how should I tell to the FPGA that the program is in such memory? In this case the linker script has a role?

You got the point Ben! One of the goals of my research is to demonstrate that the self-coordinating technique we propose, and that form a mathematical point of view are correct, can be implemented with a relative low cost. So it's very important for me to choose the right components for my control board.

No problem Ben... I'll ask a lot, stay tuned!

Thanks, Andrea.

Reply to
Andrea05

hi andrea,

well i'm facing the exact same problem as you are. just started to work with the xilinx edk and a digilent spartan 3e board. i found this xapp

formatting link
from xilinx talking about using the platform flash for storing the configuration bitstream and the user software. seems to work with a bootloader. this would be a nice sollution in my eyes because you don't need anything else than the platformflash as non-volatile memory. i'm playing around with this right now but could't get it to work so far becuase the sample project isn't working... well thought you might be interested in this.

urban

Reply to
u_stadler

yes urban, i've read that document and I think my board will adopt the solution propsed in the application note. In this moment I don't have such kind of PROM so I can't try it. If you have some good results with it, please contact me and let me know your solution!

Thanks for the hint,

Andrea.

Reply to
Andrea05

Hi Andrea,

I'm glad this seems to be helping.

In that case, you are lucky. I have had much worse nightmares than that! :-)

Yes. When the Microblaze processor core is released from its reset state, it will jump to some pre-defined location in its memory space and start fetching and executing instructions from there. All (all!) that is necessary, therefore, is to attach this external memory to the FPGA in such a way that the processor can address it. Then, you can run some code. If the memory is of a standard type (as most off-the-shelf components will be) then there is a good chance that the EDK will already have an appropriate memory controller core that will handle the interfacing for you.

The linker script coordinates where the various sections of the program (main code, data, read-only data, boot code, etc) should be placed when the program is downloaded. It is usually auto-generated by EDK, although you might end up having to edit part of it yourself. Let's hope not!

There are various ways of arranging to run the code from the external memory, from the very simple to the very complex. You can map the NVRAM directly to this "reset vector" location, or you can have the reset vector point to some internal memory where the first instruction is simply a branch to the start of the instructions in external memory - or you can have some boot code to copy the whole program from NV RAM into volatile storage. Which one you choose depends a lot on your performance requirements, and how much volatile RAM you have in your system.

Sounds interesting (although the paper is very mathematical and I must confess that control systems was never my strong point!).

It sounds to me like you should perhaps look at the Spartan-3 FPGA series. They are much lower cost than the Virtex-series parts, but are still capable of implementing a MicroBlaze system with custom peripherals.

Once again, good luck with your project!

-Ben-

Reply to
Ben Jones

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.