Hi,
I wonder if an updating of FPGA Flash (but cannot reload) could be
implemented as fpga-mgr?
I have the pcie based FPGA card. The bitstream for FPGA static region is
stored on flash chip. Board will load the bitstream to FPGA on system
power cycle. The flash chip could be accessed through "PCIE -> ... ->
Flash update engine -> Flash". So the update of the FPGA static region is
basicly updating the flash chip through PCIE and rebooting system.
Should I implement the flash update engine as a fpga-mgr device? On one
hand it is just a flash write, FPGA functionality is actually not
changed before reboot. Does fpga-mgr requires bitstream takes function
immediately after write_complete()? On the other hand, the flash write
do affects FPGA static region on next boot. Operating on the
corresponding fpga region makes kernel fully aware of what is being
done.
Actually the FPGA card do has the capability to reload bitstream at
runtime. But it will cause the whole PCIE device lost, static region is
also destroyed. We need to rescan PCI to get it back. So I think
basically this is the same case as system reboot from FPGA's
perspective.
Thanks
Yilun
Hi Yilun,
You raise some very interesting questions. Please see
my comments below.
Matthew
On Tue, 28 Apr 2020, Xu Yilun wrote:
> Hi,
>
> I wonder if an updating of FPGA Flash (but cannot reload) could be
> implemented as fpga-mgr?
>
> I have the pcie based FPGA card. The bitstream for FPGA static region is
> stored on flash chip. Board will load the bitstream to FPGA on system
> power cycle. The flash chip could be accessed through "PCIE -> ... ->
> Flash update engine -> Flash". So the update of the FPGA static region is
> basicly updating the flash chip through PCIE and rebooting system.
I think you mean power cycle when you say "rebooting system" above, but
your point is worth highlighting. During this flash update the
FPGA is actually fully configured and running its application. Typically,
during a fpga-mgr update of the static region or partial reconfiguration
region, the actual contents of the fpga region is "changing" during the
update.
>
> Should I implement the flash update engine as a fpga-mgr device? On one
> hand it is just a flash write, FPGA functionality is actually not
> changed before reboot. Does fpga-mgr requires bitstream takes function
> immediately after write_complete()? On the other hand, the flash write
> do affects FPGA static region on next boot. Operating on the
> corresponding fpga region makes kernel fully aware of what is being
> done.
When an fpga-mgr is used in a device tree overlay flow, one gains
the benefit the enumeration of the nodes in the overlay after the
update has completed.
>
> Actually the FPGA card do has the capability to reload bitstream at
> runtime. But it will cause the whole PCIE device lost, static region is
> also destroyed. We need to rescan PCI to get it back. So I think
> basically this is the same case as system reboot from FPGA's
> perspective.
Yes, on those cards that have the ability to power cycle themselves (i.e.
fully reconfigure the FPGA from flash), the PCIe connection to the card
is broken because of a surprise link down PCIe error. As you say a PCI
rescan (i.e. re-enumeration of the entire card) is required. Since
the card has to be re-scanned at the PCI level anyway, there may not be
much benefit to using the fpga-mgr in this flow.
I wonder if these kinds of more disruptive updates are better suited to
something firmware updates rather than fpga updates?
>
> Thanks
> Yilun
>
Hi Matthew, Yilun
On Tue, Apr 28, 2020 at 03:06:07PM -0700, [email protected] wrote:
> Hi Yilun,
>
> You raise some very interesting questions. Please see
> my comments below.
>
> Matthew
>
> On Tue, 28 Apr 2020, Xu Yilun wrote:
>
> > Hi,
> >
> > I wonder if an updating of FPGA Flash (but cannot reload) could be
> > implemented as fpga-mgr?
> >
> > I have the pcie based FPGA card. The bitstream for FPGA static region is
> > stored on flash chip. Board will load the bitstream to FPGA on system
> > power cycle. The flash chip could be accessed through "PCIE -> ... ->
> > Flash update engine -> Flash". So the update of the FPGA static region is
> > basicly updating the flash chip through PCIE and rebooting system.
>
> I think you mean power cycle when you say "rebooting system" above, but
> your point is worth highlighting. During this flash update the
> FPGA is actually fully configured and running its application. Typically,
> during a fpga-mgr update of the static region or partial reconfiguration
> region, the actual contents of the fpga region is "changing" during the
> update.
Yeah, this sounds more like a flash driver with MTD or maybe NVMEM?
That's probably how I'd do it. Depending on your (Q)SPI controller you
might already have a driver for that, and you'd just have to instantiate
it as a sub-device.
>
> >
> > Should I implement the flash update engine as a fpga-mgr device? On one
> > hand it is just a flash write, FPGA functionality is actually not
> > changed before reboot. Does fpga-mgr requires bitstream takes function
> > immediately after write_complete()? On the other hand, the flash write
> > do affects FPGA static region on next boot. Operating on the
> > corresponding fpga region makes kernel fully aware of what is being
> > done.
>
> When an fpga-mgr is used in a device tree overlay flow, one gains
> the benefit the enumeration of the nodes in the overlay after the
> update has completed.
I'm not sure how to model 'on next reboot' part.
>
> >
> > Actually the FPGA card do has the capability to reload bitstream at
> > runtime. But it will cause the whole PCIE device lost, static region is
> > also destroyed. We need to rescan PCI to get it back. So I think
> > basically this is the same case as system reboot from FPGA's
> > perspective.
>
> Yes, on those cards that have the ability to power cycle themselves (i.e.
> fully reconfigure the FPGA from flash), the PCIe connection to the card
> is broken because of a surprise link down PCIe error. As you say a PCI
> rescan (i.e. re-enumeration of the entire card) is required. Since
> the card has to be re-scanned at the PCI level anyway, there may not be much
> benefit to using the fpga-mgr in this flow.
Agreed.
>
> I wonder if these kinds of more disruptive updates are better suited to
> something firmware updates rather than fpga updates?
Yeah.
Cheers,
Moritz
Hi Moritz & Matthew:
Thanks a lot for the comments! It helps a lot so we could keep working on
right direction.
For "next boot" or "rescan" case, it cause rebuild the fpga-region. So
maybe we don't have to model it in fpga class.
Yilun
On Wed, Apr 29, 2020 at 08:12:10PM -0700, Moritz Fischer wrote:
> Hi Matthew, Yilun
>
> On Tue, Apr 28, 2020 at 03:06:07PM -0700, [email protected] wrote:
> > Hi Yilun,
> >
> > You raise some very interesting questions. Please see
> > my comments below.
> >
> > Matthew
> >
> > On Tue, 28 Apr 2020, Xu Yilun wrote:
> >
> > > Hi,
> > >
> > > I wonder if an updating of FPGA Flash (but cannot reload) could be
> > > implemented as fpga-mgr?
> > >
> > > I have the pcie based FPGA card. The bitstream for FPGA static region is
> > > stored on flash chip. Board will load the bitstream to FPGA on system
> > > power cycle. The flash chip could be accessed through "PCIE -> ... ->
> > > Flash update engine -> Flash". So the update of the FPGA static region is
> > > basicly updating the flash chip through PCIE and rebooting system.
> >
> > I think you mean power cycle when you say "rebooting system" above, but
> > your point is worth highlighting. During this flash update the
> > FPGA is actually fully configured and running its application. Typically,
> > during a fpga-mgr update of the static region or partial reconfiguration
> > region, the actual contents of the fpga region is "changing" during the
> > update.
>
> Yeah, this sounds more like a flash driver with MTD or maybe NVMEM?
> That's probably how I'd do it. Depending on your (Q)SPI controller you
> might already have a driver for that, and you'd just have to instantiate
> it as a sub-device.
>
> >
> > >
> > > Should I implement the flash update engine as a fpga-mgr device? On one
> > > hand it is just a flash write, FPGA functionality is actually not
> > > changed before reboot. Does fpga-mgr requires bitstream takes function
> > > immediately after write_complete()? On the other hand, the flash write
> > > do affects FPGA static region on next boot. Operating on the
> > > corresponding fpga region makes kernel fully aware of what is being
> > > done.
> >
> > When an fpga-mgr is used in a device tree overlay flow, one gains
> > the benefit the enumeration of the nodes in the overlay after the
> > update has completed.
>
> I'm not sure how to model 'on next reboot' part.
> >
> > >
> > > Actually the FPGA card do has the capability to reload bitstream at
> > > runtime. But it will cause the whole PCIE device lost, static region is
> > > also destroyed. We need to rescan PCI to get it back. So I think
> > > basically this is the same case as system reboot from FPGA's
> > > perspective.
> >
> > Yes, on those cards that have the ability to power cycle themselves (i.e.
> > fully reconfigure the FPGA from flash), the PCIe connection to the card
> > is broken because of a surprise link down PCIe error. As you say a PCI
> > rescan (i.e. re-enumeration of the entire card) is required. Since
> > the card has to be re-scanned at the PCI level anyway, there may not be much
> > benefit to using the fpga-mgr in this flow.
>
> Agreed.
> >
> > I wonder if these kinds of more disruptive updates are better suited to
> > something firmware updates rather than fpga updates?
>
> Yeah.
>
> Cheers,
> Moritz