3 ms·

Might be silly question but is there a technique to rapidly program FPGA's without interrupting other processes. Say I have multiple soft-CPU's and only want to

Might be silly question but is there a technique to rapidly program FPGA's without interrupting other processes. Say I have multiple soft-CPU's and only want to use my gates to enable ethernet once its needed or the user plugs in?

hamiltonkibbe 7y ago
“Partial reconfiguration” is the term you’re looking for
aylons 7y ago
Not a silly question and actually a very powerful, seldom used feature: partial reconfiguration. There are, however, several limitations to it. Clock cannot be changed, for example, and usually neither can I/O, specially high-speed transceivers. This has been improving (Ultrascale Xilinx allows for reconfiguring I/O), but you still have to reserve area for reconfiguring (meaning literal area, as in a geographic region in the FPGA). However, I/O versatility as you suggested has very few advantages to it. You need the reserved logic for ethernet to be programmed at when you plugin. Why would you leve it unprogrammed? If is simply disabled, it won't use any extra power resources, and your soft-CPU's won't be able to take advantage of these resources while you are working. Maybe you could use the area for new soft-cpus, but then you'll hit the problem of over segmenting your design and allowing for less optimization. This would inevitably impact timing constraints and area usage. Also, FPGA programming may take minutes to finish, and always at least a few seconds. This will be very noticeable by an user and not very efficient if it has to be done frequently. There are, of courses, good uses for that. But there is also a lot of effort on doing it right and you always risk overdoing it.
- aseipp 7y ago
  Is programming speed really that bad for the ultra high-end devices? Minutes? I don't remember it being that bad for the Amazon F1 when I ported a Xilinx build to use the F1 SDK (I didn't spend lots of time with our prior one, so I wouldn't know.) Of course, their programming strategy is extremely customized, but even for very high-utilization images, it was only ever on the order of seconds. Vivado is absolutely terribly slow though, no matter what you do, or what device you use. (Not to mention if you want to use the ILA support over the internet...) Also, for some designs you can mitigate the reconfiguration time issue by having two regions and draining requests to one of them, before doing an update. Most of the Xilinx tooling for OpenCL does this kind of thing by default (4-6 "opencl kernel" regions.) But of course it's not always an option to give up that much space...
  - alexforencich 7y ago
    It depends on the programming interface. JTAG is bit serial and rather slow, so it can take quite a while to load a large FPGA via JTAG. However, there are several other interfaces that can be used, including QSPI, dual QSPI, parallel flash, and a simple parallel interface from some other controller. These can run at many MHz and can load a configuration into a large FPGA in less than a second.
therealcamino 7y ago
Tabula had an FPGA that could switch between configurations in a single cycle (it could be time-sliced among up to 8 configurations). Not sure if their actual product would have supported what you propose -- it was more a way of trading off design size against clock speed. A large design could use 8X the logic and run at 1/8th the clock speed of a small design.

hamiltonkibbe 7y ago

“Partial reconfiguration” is the term you’re looking for

aylons 7y ago

Not a silly question and actually a very powerful, seldom used feature: partial reconfiguration. There are, however, several limitations to it. Clock cannot be changed, for example, and usually neither can I/O, specially high-speed transceivers. This has been improving (Ultrascale Xilinx allows for reconfiguring I/O), but you still have to reserve area for reconfiguring (meaning literal area, as in a geographic region in the FPGA). However, I/O versatility as you suggested has very few advantages to it. You need the reserved logic for ethernet to be programmed at when you plugin. Why would you leve it unprogrammed? If is simply disabled, it won't use any extra power resources, and your soft-CPU's won't be able to take advantage of these resources while you are working. Maybe you could use the area for new soft-cpus, but then you'll hit the problem of over segmenting your design and allowing for less optimization. This would inevitably impact timing constraints and area usage. Also, FPGA programming may take minutes to finish, and always at least a few seconds. This will be very noticeable by an user and not very efficient if it has to be done frequently. There are, of courses, good uses for that. But there is also a lot of effort on doing it right and you always risk overdoing it.

aseipp 7y ago
Is programming speed really that bad for the ultra high-end devices? Minutes? I don't remember it being that bad for the Amazon F1 when I ported a Xilinx build to use the F1 SDK (I didn't spend lots of time with our prior one, so I wouldn't know.) Of course, their programming strategy is extremely customized, but even for very high-utilization images, it was only ever on the order of seconds. Vivado is absolutely terribly slow though, no matter what you do, or what device you use. (Not to mention if you want to use the ILA support over the internet...) Also, for some designs you can mitigate the reconfiguration time issue by having two regions and draining requests to one of them, before doing an update. Most of the Xilinx tooling for OpenCL does this kind of thing by default (4-6 "opencl kernel" regions.) But of course it's not always an option to give up that much space...
- alexforencich 7y ago
  It depends on the programming interface. JTAG is bit serial and rather slow, so it can take quite a while to load a large FPGA via JTAG. However, there are several other interfaces that can be used, including QSPI, dual QSPI, parallel flash, and a simple parallel interface from some other controller. These can run at many MHz and can load a configuration into a large FPGA in less than a second.

therealcamino 7y ago

Tabula had an FPGA that could switch between configurations in a single cycle (it could be time-sliced among up to 8 configurations). Not sure if their actual product would have supported what you propose -- it was more a way of trading off design size against clock speed. A large design could use 8X the logic and run at 1/8th the clock speed of a small design.