Hi everybody,
http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=18416
Problem Description:
Keywords: ISE, 5.1i, 5.2i, reconfig, configuration, modular, BitGen, ICAP
Urgency: Standard
General Description:
Can I perform partial reconfiguration on Spartan-3/-3E devices?
Solution 1:
Yes, partial reconfiguration is supported in Spartan-3/-3E, but only
through the use of the BitGen -r command. This command allows you to
compare two designs and create a bitstream that contains only the
column differences between the two.
However, unmodified bits in a partially reconfigured column in
Spartan-3/-3E devices are temporarily reset during the reconfiguration
process. Therefore, if this method is used, you must make sure to
manage these glitches by using handshaking for design communication.
An example command line is:
bitgen -g ActiveReconfig:Yes -g Persist:Yes -r design1.bit design2.ncd
and_test2_partial.bit
Some other issues to note are:
- Spartan-3/-3E does not support partial reconfiguration using ICAP.
- Because the Spartan-3/-3E architecture does not contain TBUFs, there
is currently no existing bus macro solution that can be used for
module-based partial reconfiguration.
- Partial reconfiguration is only supported through the JTAG and
SelectMap interface. If using the SelectMAP interface, the -g Persist
option needs to be set when generating the initial bitstream. For more
information on partial reconfiguration, see (Xilinx XAPP290
<http://www.xilinx.com/bvdocs/appnotes/xapp290.pdf>): "Two Flows for
Partial Reconfiguration: Module-Based or Difference-Based."
Personally, I advise to everybody this new website :
http://www.dresd.org/
DRESD Home Page
Over the last years, considerable interest has risen towards the field
of reconfigurable hardware systems, with noteworthy research efforts
in this direction. Especially interesting is the scenario in which
this reconfiguration of the hardware is carried out without
necessarily having to cease execution of those parts of the system
that are not involved. The successful deployment of such complex and
reconfigurable embedded systems to the market requires the
identification, formalization, and implementation of concepts,
methods, and tools for embedded software design that are able to ease
the development of software components and the implementation of the
system architecture. This scenario is the one in which the *DRESD*,
/Dynamic Reconfigurability in Embedded Systems Design/, research
project takes place. Aims of the DRESD community are:
*.::* The creation of an active discussion forum where all the people
involved in the reconfigurable computing area can find a place where
to post their ideas, ask for problems and hopefully find solutions.
*.::* The definition of a community fond of knowledge and discoveries.
A community full of live and interested not only in the reconfigurable
computing area, but also in all those areas that are connected to that
one i.e. Operating Systems, Compiler Design, Computer Architecture
etc. etc.
*.::* The definition of a methodology, called *Earendil*,
accomplishing the design and development of a particular kind of
embedded systems that exploit the advantages of dynamic
reconfigurability.
*.::* The creation of a strong connection between research and
curricula in the academic world.
Something more about us? ... Take a look to our *DRESD in a Nutshell*
presentation! <http://www.dresd.org/?q=dian>
Best Regards,
Guillaume FORTAINE
Justin Braun wrote:
This group seems relatively inactive recently but I thought I would
try to post a few questions about partial reconfiguration on the
Spartan-3/3E series devices.
I recently went through the design flow as described in the Early
Access Partial Reconfiguration User Guide. I had no problems making a
small demo work on two separate Virtex-4 development boards but I
could not successfully generate working bitstreams for the a
Spartan-3E device. There were no errors until I started to generate
the bitsreams. The pr_verifydesign step would generate "frame
boundary errors" in the ".summary" output file which Xilinx states:
"Frame boundary errors are likely due to illegal range constraints
for the PR region. For
example, this error occurs if the BRAM range does not match the CLB
range. Check to
ensure that the BRAM range includes all the block RAM elements within
the CLB range."
My PR region only contains CLBs and there were no other errors
throughout the process.
Is anybody doing partial reconfiguration on Spartan 3/3E devices?
How can I fix these "frame boundary errors"?
Some information on Xilinx's site about partial reconfiguration on
Spartan-3/3E devices has stated, "unmodified bits in a partially
reconfigured column in Spartan-3/-3E devices are temporarily reset
during the reconfiguration process." Is this valid?
Thanks,
Justin Braun
___________________________
partial-reconfig mailing list
partial-reconfig@xxxxxxxxxxxxxx
Mailing List Archive :
http://www.itee.uq.edu.au/~listarch/partial-reconfig/
___________________________
partial-reconfig mailing list
partial-reconfig@xxxxxxxxxxxxxx
Mailing List Archive :
http://www.itee.uq.edu.au/~listarch/partial-reconfig/