Example:
Let's assume there is a Nios running on a FPGA that sends randomly (or every second) a string to an attached display over the SPI interface. On the other hand there is the FPGA code that monitors a pushbutton. Every press on this button should send a string to the same attached display.
Question:
How works the interaction (or communication) between the FPGA and Nios in general or in such described case? How is it possible to 'inform' Nios that the pushbutton is pressed when this code is running under the FPGA code? Maybe there is a documentation about this topic to get an idea how it works...
Thanks in advance
Low speed or high speed?
For low speed, plug a GPIO core with enough I/O "pins" into the NIOS system and rebuild it. Wire your hardware to those pins, and use the GPIO driver code to access them. Done. Buttons count as low speed. SPI can too, though you'll probably find a much better SPI peripheral for NIOS, so I'd use that.
For high speed, you need to design a peripheral (IP core) that interfaces to whatever bus the NIOS system uses, and provides all the registers, memory, interrupt sources etc you need to interface to your VHDL hardware. There are plenty of example peripherals you can use as a starting point. Then you get to write the driver software to access that peripheral, again, starting from sample code.
This is a much more complex project, and while it's much faster than GPIO, you find "high speed" is relative; any embedded CPU is appallingly slow compared to custom hardware. We're not talking about factors of 2 here but orders of magnitude.
EDIT : Whichever approach you use, as described above, interacting with the hardware from the software side is best done through the driver software.
If you're in the situation where you have to write your own driver, then you declare variables to match each accessible register or memory block (represented by an array variable). Often the vendor tools can create a skeleton driver for you, from either the VHDL code or some other description. I don't know how Altera/Nios tools are set up but they surely have tutorials to teach you their approach.
If you have an Ada compiler you can declare these variables at package scope, to maintain proper abstraction and information hiding. But if you have to use C, with no packages, you are probably stuck with global variables.
You fix each variable at whatever physical address your hardware maps them to, and you must declare them "volatile" so that accesses to them are never optimised into registers.
If your hardware can interrupt the CPU, you have to write an interrupt handler function, with pragmas to tell the compiler which interrupt vector it should be connected to. You'll need to get the exact details from your own compiler documentation and examples of driver code for other peripherals.
I would start here:
https://www.altera.com/support/support-resources/design-examples/intellectual-property/embedded/nios-ii/exm-developing-hal-drivers.html
with sample code and a short "Guidelines" document
and use the NIOS software handbook for more depth.
To help find what you're looking for, apparently Altera use the terms "HAL" (Hardware Abstraction Layer) to describe the part of the driver that directly accesses the hardware, and "BSP" (Board Support Package) for the facilities that allow you to describe your hardware to the tools - and to your software team. Any tools to build a skeleton driver will be associated with the BSP : I see a section called "Creating a new BSP" in the software handbook.
Related
I am new to programming and FPGA. I like to run a program on my windows 10 PC and like to send input to the FPGA and when processing is done I like to receive output to the same program. Is it possible and how it can be achieved. I need some direction to start finding a way.
Thank you.
I recommend you to buy a Digilent Arty A7 board. It is low cost and very nice to work with.
To communicate with a PC/Windows you can use the USB to UART that you have on that board. However I think the best and easiest way to do it is to use an IP core that has support for Ethernet and TCP/IP. Using TCP/IP is very simple on the PC side using Python, Matlab, Telnet or any programming tool.
The best IP for the Xilinx FPGA that I have found so far is the ones from fpga-cores.com. There you only have to implement an AXI4 Stream to communicate with the client. I don't think it gets easier than that.
That core also include remote programming of the FPGA over Ethernet and a logic analyzer. All that is for free.
Good question. A lot of people ask about data processing on FPGA but never think about how to get the data to and from it. (Until it is too late)
The best way is to find an FPGA which has also has an SOC. That is: a processor, DDR interface and one or more high speed interfaces. Ethernet, USB, PCIe. Make sure they come with complete working example code, often some RTOS.
As to which FPGA to choose greatly depends on what you want it to do. You also need to have enough programmable gates to implement the function you want.
Nowadays all vendors have free HDL compilers up to a certain size FPGA.
Every FPGA manufacturer also has one or more prototyping boards, but the price of those varies a lot.
If you have some FPGA code which is capable of very high data throughput your interface is likely to become the bottleneck.
A PCIe board offers the highest data throughput, but for that you need to have matching drivers on both the FPGA board and the PC. In that case check that it has example drivers for the PC side too.
Yes, I fell into that trap a few years back
I understand how JTAG used to be used as boundary scanner (very clean explanation at http://www.fpga4fun.com/JTAG1.html). However I can't see how JTAG these days is used as a hardware level debugger (Somewhat similar to in-circuit emulators).
1. Can some-one explain how JTAG is used as a hardware level debugger?
My assumption is there has to be some extra hardware on-chip which helps in debugging while JTAG merely drives that hardware to get the debug information. If my understanding is correct -
2a. What is that hardware?
2b. Is there a standard for it?
I rather doubt the standard part since all implementations I've seen of JTAG based hardware level debuggers vary from each other.
Finally it's really confusing to have JTAG be called a hardware level debugger whereas the JTAG standard doesn't define anything of the sort. So is there a different name for when JTAG is used for this?
JTAG is simply a method for interfacing to the chips internals which works alongside the "usual" chip functionality. It's basically a multi-mode (synchronous) serial port.
One of the things this allows is boundary-scan, by accessing the pins directly.
As you surmise, another is to access extra hardware inside the chip. That hardware can be set up to provide (for example) hardware breakpoints, the ability to read registers and arbitrary memory locations, programming internal flash etc. Those are the sorts of things that a debugger application can use.
The JTAG standard provides space for device specific extensions which were always intended for the chip designers to use to provide these sorts of features. There is an attempt to standardise the interface, which covers JTAG and also higher-rate connections to debug hardware, which is called Nexus. However, I've only ever seen Freescale implement it, so it appears to not be as useful a standard as one might hope!
Regarding the terminology, yes, it is probably wrong to call "a JTAG" on its own a hardware debugger. I'm not entirely sure what "a JTAG" is (as used in the question title) - maybe "a JTAG pod" or "a JTAG interface module" would be better?
However phrases like "JTAG debug access" or even "JTAG debugger" (and indeed "JTAG programmer" for those users who are just using it to program the flash) are in common usage (in the UK at least!) and seem to me to be non-confusing, combining as they do the method of interface and the function provided.
fyi: I'm not sure if I understood you well, and you may already know/understand all I've written below, maybe better than me. Drop me a note, and I'll remove the answer.
1/2a: The hardware used is "just" some extra registers and logic circuits that form/inject additional (orthogonal!) states into the standard JTAG statemachine.
If you understand how the JTAG protocol performs the boundary-scan and how the bitstream is pushed/pulled from the device, you should be able to imagine how is it used to i.e. program on-chip memory banks. Imagine typical daisy-chaining, not between the chips but rather inside-a-chip.
Let's say that device has some programmable persistent memory. With a few more flops and gates, the device forms an extra buffer before or after the JTAG chain of the actual memory:
input -> xflops -> memory -> yflops -> output
let's say that x/mem/y = 16/1024/0. Now, the chain has 1040 bits. The preceding xflops does not directly affect memory nor vice-versa. The xflops might be now linked to the control lines of the builtin internal programmer that drives the memory.
input -> progcmd -> memory -> output
the logic circuit inside the chip can now react to some 16-bit 'magic number' a.k.a. "write command" that will trigger the procedure of writing/erasing of the persistent memory. Any other 16bits values are ignored and device behaves like 1024 r/o data followed by 16bit echo or zeroes.
Ok, so we have simple on-device 'controller' that performs operations on a 'real device'. If you extend the idea with i.e. the controller having states that can control what subdevices are attached to the chain, on the fly:
default chain after reset is:
input -> progcmd -> output
if now the controller gets ENABLE_WRITE it attaches MEM to chain
input -> progcmd -> memory -> output
then controller reacts to WRITE and ABORTs on everything else
input -> progcmd -> output
controller ges VERIFY, it reattaches MEM again but in READONLY mode
input -> progcmd -> memory -> output
etc
It is of course just an extra statemachine. In similar way you could do almost any fancy operations, including debugging like freezing, stepping, reading/writing registers etc. But all of this requires tons of extra logic to be built into the chip in question. Actually, it's having several devices in one chip.
2b: Unfortunatelly, I cannot say more, because I'm too green in the subject ;) I know that many manufacturers form their own internal standards, the 'controller's are simply shared between models and sometimes families of chips, but I've not heard of any 'global' standard common between manufacturers.
The JTAG has an unique interface which enables you to debug the hardware easily in real time. It can directly control the clock cycles of provided controller through software. Therefore, you can put hardware breakpoints in your code execution. You can start, pause, stop execution of code in the hardware as you want.
Whenever JTAG control is set to 1 oscillator clock will be connected to CPU, else CPU will not receive clock and cannot execute any instruction.This way you can control the execution of instructions in hardware.
I want to program an FPGA on a board that has a socket (zif etc or whatever is applicable) for said FPGA, from which it can be removed and reattached without soldering. I want to know where I can get a board suitable for programming an FPGA in this way?
Once the FPGAs have been programmed they will be attached to another different PCB via solder.
I wish to essentially program the FPGA in a similar way that it is possible to program an EPROM.
I wish to use VHDL if at all possible.
FPGAs are not programmed like an EPROM - their internals are completely volatile. In system use, they are 'configured' from some other non-volatile memory. For example, many can interface directly to a standard serial flash device to load that configuration.
This non-volatile memory is the device which you need to "program" in some fashion. For example:
before soldering, using some external agency
using JTAG (if it has such an interface).
Or, you can load a configuration into the FPGA over JTAG which then allows you to program the flash using the FPGA!
It sounds as if you've misunderstood a thing or two. An STM32F103 is a microcontroller, that is, a processor with built-in memory, I/O and similar, and is typically programmed in C or C++.
VHDL (a Hardware Description Language) is used to program FPGAs (amongst others). There is a fundamental difference in the two types of chips. A processor is a "static" chip, which executes a program instruction by instruction, whereas in an FPGA the chip hardware itself is programmable - you (by using for instance VHDL) describe the actual connectivity and functionality of the chip, and essentially create numerous small, customized and application-specific processors.
You should probably first of all learn a bit more about the differences between the two types of chips - then have a look at for instance some of Digilents FPGA boards.
Also, programming a chip in one board, unsoldering it, and soldering it to another is not a good idea. Both microcontrollers and FPGAs today should be soldered to their final board, and then programmed (for instance over JTAG) - I'm sorry to say that what you are proposing doesn't really make much sense - and if you look at the pin count and packages of today's chips you might see why.
I seem to be under the impression that FPGAs can be updated while the chip is running; and I need to know if that is correct or not.
It seems to be from what I've read that you can change the FPGA netlist on demand the same way you can change the program that's running on a processor. Yes I know that an FPGA is not a processor.
Is my assumption correct, and if not then how come?
Most of the time, you load the configuration for the entire FPGA in one go, and all logic stops running during the reconfiguration process.
It sounds like you want to reload a subset of the FPGA, while the remainder continues running. You would need a device with special support for partial reconfiguration. There's more information on Wikipedia.
==> EDIT: I stand corrected: EETimes article on partial reconfiguration
You will generally need to reset the FPGA so that it can be reprogrammed.
At a system level reconfiguration is possible. You can have a software application running on a PC or embedded system that reprograms the FPGA as needed. Depending on the application or software license, you can program different FPGA designs easily. You cannot, however, significantly alter the design structure, such I/Os, logic cells, DSP configs, memory blocks, etc.
FPGAs have a bunch of logic cells that need to be initialized by a stream of configuration bits. This stream of bits usually comes from a flash chip located off the device, although some devices have the flash memory on-board.
Partial Reconfiguration means the ability to configure just some of the logic cells while the rest are in use. This is specific to particular models.
Total reconfiguration is possible even if your device doesn't support it - you would need to reprogram the flash chip and then issue a Reset or reload command when done.
Some devices have more than one configuration image in the configuration flash. The device will load the first image, and if it doesn't like it, it will load the second (or subsequent) images. This can be for redundancy, or difference feature sets.
Some of the SOC FPGAs (like Xilinx Zynq) use the microprocessor core to load the FPGA. In this case, the microprocessor core can change the FPGA as much as it wants while running.
Yes I know that an FPGA is not a processor.
An FPGA is is a type of processor, but it is not a type of CPU.
Most FPGAs only have volatile storage so you have to update them whilst they're on. This doesn't mean that you can change their operation any time you want. That's dynamic reconfiguration and only supported by a subset of FPGAs.
We have a small embedded system without any video or serial ports (i.e. we can't output text via printf).
We would like to track the progress of our code through the initialization sequence.
Is there some simple things we can do to help with this.
It is not running any OS, and the hardware platform is somewhat customizable.
The simplest most scalable solution are state LEDs. Toggle LEDs based on actions, either in binary form or when certain actions occur if you can narrow your focus.
The most powerful will be a hardware JTAG device. You don't even need to set breakpoints - simply being able to stop the application and inspect the state of memory may be enough. Note that some hardware platforms do not support "fancy" options such as memory watches or hardware breakpoints. The former is usually worked around with constantly stopping the processor and reading memory (turns your 10MHz system into a 1kHz system), while the latter is sometimes performed using code replacement (replace the targeted instruction with a different jump), which sometimes masks other problems. Be aware of these issues and which embedded processors they apply to.
There are a few strategies you can employ to help with debugging:
If you have Output Pins available, you can hook them up to LEDs (or an oscilloscope) and toggle the output pins high/low to indicate that certain points have been reached in the code.
For example, 1 blink might be program loaded, 2 blink is foozbar initialized, 3 blink is accepting inputs...
If you have multiple output lines available, you can use a 7 segment LED to convey more information (numbers/letters instead of blinks).
If you have the capabilities to read memory and have some RAM available, you can use the sprint function to do printf-like debugging, but instead of going to a screen/serial port, it is written in memory.
It depends on the type of debugging that you're trying to do - in particular if you're after a temporary method of tracing or if you are trying to provide a tool that can be used as an indication of status during the life of the project (or product).
For one off, in depth source tracing and debugging an in-circuit debugger (eg. jtag) can be very helpful. However, they are most helpful where your debugging requires setting breakpoints and investigating memory and registers - which makes it of little benefit where you are dealing time critical problems.
Where you need to determine program state without having a significant impact on the execution of your system the use of LEDs connected to spare I/O pins will be helpful. These can also be used as the input to a digital storage oscilloscope (DSO) or logic analyzer.
This technique can be made more powerful by selecting unique patterns of pulses that will be identifiable on the DSO.
For a more versatile debugging tool, though, a serial port is a good solution. To save cost and PCB real-estate you may find it useful to use an plug-in module that contains the RS232 converters.
If you are trying to provide a longer term indication of status as part of the normal operation of your product, LEDs are again a cheap an simple method. However in this situation it is best to choose patterns of pulses that are slow enough to be easily identified by visual inspection. This will all you over time you will learn a particular pattern that represents "normal" behavior.
You can easily emulate serial communications (UARTs) using bit-banging from the IO pins of the system. Hook it to one of the card's pins and attach to a RS232 converter there (TTL to RS232 converters are easy to either buy or build), which goes to your PC's serial port.
A JTAG debugger is also an option, though cumbersome to set up.
If you don't have JTAG, the LEDs suggested by the others are a great idea - although you do tend to end up in a test/rebuild cycle to try to track down the issue.
If you've got more time, and spare hardware pins, and memory to spare, you could always bit-bash a low speed serial interface. I've found that pretty useful in the past.
Others have suggested some pretty good ideas using output pins, so I won't suggest that, although it can be a very good solution, and is very cost effective. If your budget and target processor support it, a hardware trace system, (either an old fashioned emulator, or a fancy BDM with bus snooping trace support) can be great for this type of thing. It's very expensive though.
The idea of using a bit-banged software UART is nice, but there's some effort required in writing one and also you need some free timers and interrupts. If your hardware has any other unused serial interface (SPI, I2C, ..), using them would be easier. With a small microcontroller you could convert the interface to RS-232.
If you have to go for the bit-banging, making a synchronous serial might be a simpler alternative as it wouldn't be critical to timing.