Re: [partial-reconfig] Spartan-3/3E partial reconfiguration

[Guillaume FORTAINE <gui.fortaine@xxxxxxxxx>]

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/