ICAP Virtex2

P

PanJuHwa

Guest
Hi,

I am very interested in exploring the use of ICAP for
self-reconfiguration of the Virtex2 fpga. XAPP 662 describes the
in-system reconfiguration of RocketIO attributes, and I have been
trying to understand the process of self-reconfiguration through this
application note as well as the reference design that comes with it.

It seems that we need to configure the FPGA with a bitstream
generated from hdl that includes an PLB bus arbitrator and controller,
as well as ICAP IPIF to the PLB. Does this mean the ICAP, possessing
access the configuration memory, would actually have access to parts
of the configuration memory that defines the arbitrator and ICAP IPIF
as well? Or are is the information used to configure the arbitrator
and IPIF somewhere else? Say for instance the fpga is to be configured
with a jpeg encoder. Would the configuration memory accessed by the
ICAP be solely occupied by the jpeg encoder configuration, or by the
ipif etc as well? If in the latter case, then ICAP should never modify
areas defining the IPIF, is this correct?

I would appreciate too if someone who has done this before can
provide some guidelines on how I can set the system up to use the
ICAP. Thanks in advance!:)

Ju Hwa
 
Hi JuHwa,

ICAP can also access the IPIF. But of course, you should avoid
moidfying the area defining the IPIF since it may introduce misbehavior
in the ICAP.

To set a system up, you can use the EDK to design an embedded system
supporting Linux port. Basically, the system consists of a processor
(Microblaze,
or PPC450 in Virtex-II Pro), some IP core peripherals and PLB/OPB/DCR buses
to connect the processor core to other cores. You can refer to the ML300
embedded
system reference deisgn to get an idea of it.

To use the ICAP in a system mentioned before is straightforward. You merely
need to
attach the "ipif_slv_sram" in XAPP 662 reference design to PLB/OPB.

Hope this helps,

tk


t depends on the device you use. If you are using
Virtex-II Pro, you can
"PanJuHwa" <panjuhwa_fpga@yahoo.com>
???????:89e30c0c.0310150853.415294f4@posting.google.com...
Hi,

I am very interested in exploring the use of ICAP for
self-reconfiguration of the Virtex2 fpga. XAPP 662 describes the
in-system reconfiguration of RocketIO attributes, and I have been
trying to understand the process of self-reconfiguration through this
application note as well as the reference design that comes with it.

It seems that we need to configure the FPGA with a bitstream
generated from hdl that includes an PLB bus arbitrator and controller,
as well as ICAP IPIF to the PLB. Does this mean the ICAP, possessing
access the configuration memory, would actually have access to parts
of the configuration memory that defines the arbitrator and ICAP IPIF
as well? Or are is the information used to configure the arbitrator
and IPIF somewhere else? Say for instance the fpga is to be configured
with a jpeg encoder. Would the configuration memory accessed by the
ICAP be solely occupied by the jpeg encoder configuration, or by the
ipif etc as well? If in the latter case, then ICAP should never modify
areas defining the IPIF, is this correct?

I would appreciate too if someone who has done this before can
provide some guidelines on how I can set the system up to use the
ICAP. Thanks in advance!:)

Ju Hwa
 
Hi, I was wondering if any of you have any numbers in terms of
configuration times ( micro seconds ?) using ICAP.

Do you think using ICAP adds more overhead than it does good?

In my application, I have DATA(Dynamic Part that needs to be
reconfigured), and the Processing Engine(PE, which will be the static
part) that works on the DATA. As ssoon as PE finishes working on DATA
set 1, I will need to change the LUT contents on the DATA block. And I
would like to generate this data internally using the hard core Power
PC of Virtex II pro.

I would appreciate your comments .
TIA,
Kode
"tk" <tokwok@hotmail.com> wrote in message news:<bmmcu8$g0q$1@hkueee5.eee.hku.hk>...
Hi JuHwa,

ICAP can also access the IPIF. But of course, you should avoid
moidfying the area defining the IPIF since it may introduce misbehavior
in the ICAP.

To set a system up, you can use the EDK to design an embedded system
supporting Linux port. Basically, the system consists of a processor
(Microblaze,
or PPC450 in Virtex-II Pro), some IP core peripherals and PLB/OPB/DCR buses
to connect the processor core to other cores. You can refer to the ML300
embedded
system reference deisgn to get an idea of it.

To use the ICAP in a system mentioned before is straightforward. You merely
need to
attach the "ipif_slv_sram" in XAPP 662 reference design to PLB/OPB.

Hope this helps,

tk


t depends on the device you use. If you are using
Virtex-II Pro, you can
"PanJuHwa" <panjuhwa_fpga@yahoo.com
???????:89e30c0c.0310150853.415294f4@posting.google.com...
Hi,

I am very interested in exploring the use of ICAP for
self-reconfiguration of the Virtex2 fpga. XAPP 662 describes the
in-system reconfiguration of RocketIO attributes, and I have been
trying to understand the process of self-reconfiguration through this
application note as well as the reference design that comes with it.

It seems that we need to configure the FPGA with a bitstream
generated from hdl that includes an PLB bus arbitrator and controller,
as well as ICAP IPIF to the PLB. Does this mean the ICAP, possessing
access the configuration memory, would actually have access to parts
of the configuration memory that defines the arbitrator and ICAP IPIF
as well? Or are is the information used to configure the arbitrator
and IPIF somewhere else? Say for instance the fpga is to be configured
with a jpeg encoder. Would the configuration memory accessed by the
ICAP be solely occupied by the jpeg encoder configuration, or by the
ipif etc as well? If in the latter case, then ICAP should never modify
areas defining the IPIF, is this correct?

I would appreciate too if someone who has done this before can
provide some guidelines on how I can set the system up to use the
ICAP. Thanks in advance!:)

Ju Hwa
 

Welcome to EDABoard.com

Sponsor

Back
Top