[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [partial-reconfig] Spartan-3/3E partial reconfiguration
Hi Justin,
I know almost nothing about the Spartan devices and I'm not
sure if Xilinx has gone into detail documenting these things.
But here's my take on the situation and some of it is speculative.
The Spartan devices are similar but not the same as Virtex
devices. I believe the idea was to make smaller, higher yield
devices. This allows Xilinx to sell them cheaper. That means
removing some transistors and some functionality. My guess
is that "glitchless" partial reconfiguration was one of those
functionalities that was sacraficed. Basically, configurations
are streamed in serially as they go up a column of the device
and you can save transistors if you assume that column is not
actively doing any useful. (I.e., every configuration transistor
can toggle arbitrarily as long as it is in the proper state when
the device becomes active.) "Useful" includes simply propagating
a signal through a switchbox.
So if one conservatively assumed that a set of columns was
isolated from the rest of the design -- for example, the left
half of the chip -- then partial reconfiguration is possible on
a Spartan. However, partially reconfiguring a smaller region
will almost certainly lead to random failures that would be
impossibly hard to identify. This assumption is why the Erlang
people suggest that to do partial reconfiguration, you need to
have configurability in the PCB design: a column includes IOBs
on the top and bottom which control exernal pins.
So having bus macros for the Spartan is not unreasonable. In a
limited sense partial reconfiguration is possible. I suspect
that the error message means exactly what says: you are trying to
reconfigure something less than the smallest reconfigurable unit.
(In this case, I am guessing you are trying to reconfigure less
than the whole column on a Spartan device.)
Does this make sense? Anyone else have something more fact-based
than my guesses?
Good luck, Justin! And, please share your successes!
Ron
> That is the information I read on Xilinx's site about the glitches. I am=20
> a little weary of the information they provide.
>
> I realize that Xilinx states:
>
> "These software tools only support the Virtex=99-4, Virtex-II and=20
> Virtex-II Pro architectures."
>
> Why do they provide bus macros for the Spartan-3/3E?
>
> Thanks,
> Justin Braun
>
>
>
> Guillaume FORTAINE wrote:
> > Hi everybody,
> >
> >
> > http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=3D18416
> >
> >
> > Problem Description:
> >
> > Keywords: ISE, 5.1i, 5.2i, reconfig, configuration, modular, BitGen, IC=
> AP
> >
> > 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=20
> > through the use of the BitGen -r command. This command allows you to=20
> > compare two designs and create a bitstream that contains only the=20
> > column differences between the two.
> >
> > However, unmodified bits in a partially reconfigured column in=20
> > Spartan-3/-3E devices are temporarily reset during the reconfiguration=20
> > process. Therefore, if this method is used, you must make sure to=20
> > 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=20
> > 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=20
> > is currently no existing bus macro solution that can be used for=20
> > module-based partial reconfiguration.
> > - Partial reconfiguration is only supported through the JTAG and=20
> > SelectMap interface. If using the SelectMAP interface, the -g Persist=20
> > option needs to be set when generating the initial bitstream. For more=20
> > information on partial reconfiguration, see (Xilinx XAPP290=20
> > <http://www.xilinx.com/bvdocs/appnotes/xapp290.pdf>): "Two Flows for=20
> > 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=20
> > of reconfigurable hardware systems, with noteworthy research efforts=20
> > in this direction. Especially interesting is the scenario in which=20
> > this reconfiguration of the hardware is carried out without=20
> > necessarily having to cease execution of those parts of the system=20
> > that are not involved. The successful deployment of such complex and=20
> > reconfigurable embedded systems to the market requires the=20
> > identification, formalization, and implementation of concepts,=20
> > methods, and tools for embedded software design that are able to ease=20
> > the development of software components and the implementation of the=20
> > system architecture. This scenario is the one in which the *DRESD*,=20
> > /Dynamic Reconfigurability in Embedded Systems Design/, research=20
> > project takes place. Aims of the DRESD community are:
> >
> >
> > *.::* The creation of an active discussion forum where all the people=20
> > involved in the reconfigurable computing area can find a place where=20
> > to post their ideas, ask for problems and hopefully find solutions.
> >
> >
> > *.::* The definition of a community fond of knowledge and discoveries.=20
> > A community full of live and interested not only in the reconfigurable=20
> > computing area, but also in all those areas that are connected to that=20
> > one i.e. Operating Systems, Compiler Design, Computer Architecture=20
> > etc. etc.
> >
> >
> > *.::* The definition of a methodology, called *Earendil*,=20
> > accomplishing the design and development of a particular kind of=20
> > embedded systems that exploit the advantages of dynamic=20
> > reconfigurability.
> >
> >
> > *.::* The creation of a strong connection between research and=20
> > curricula in the academic world.
> >
> > Something more about us? ... Take a look to our *DRESD in a Nutshell*=20
> > presentation! <http://www.dresd.org/?q=3Ddian>
> >
> >
> > Best Regards,
> >
> > Guillaume FORTAINE
> >
> > Justin Braun wrote:
> >> This group seems relatively inactive recently but I thought I would=20
> >> try to post a few questions about partial reconfiguration on the=20
> >> Spartan-3/3E series devices.
> >>
> >> I recently went through the design flow as described in the Early=20
> >> Access Partial Reconfiguration User Guide. I had no problems making a=20
> >> small demo work on two separate Virtex-4 development boards but I=20
> >> could not successfully generate working bitstreams for the a=20
> >> Spartan-3E device. There were no errors until I started to generate=20
> >> the bitsreams. The pr_verifydesign step would generate "frame=20
> >> boundary errors" in the ".summary" output file which Xilinx states:
> >>
> >> "Frame boundary errors are likely due to illegal range constraints=20
> >> for the PR region. For
> >> example, this error occurs if the BRAM range does not match the CLB=20
> >> range. Check to
> >> ensure that the BRAM range includes all the block RAM elements within=20
> >> the CLB range."
> >>
> >> My PR region only contains CLBs and there were no other errors=20
> >> 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=20
> >> Spartan-3/3E devices has stated, "unmodified bits in a partially=20
> >> reconfigured column in Spartan-3/-3E devices are temporarily reset=20
> >> during the reconfiguration process." Is this valid?
> >>
> >> Thanks,
> >> Justin Braun
> >>
> >>
> >>
> >> ___________________________
> >> partial-reconfig mailing list
> >> partial-reconfig@xxxxxxxxxxxxxx
> >> Mailing List Archive :=20
> >> http://www.itee.uq.edu.au/~listarch/partial-reconfig/
> >>
> >>
> >
> >
> > ___________________________
> > partial-reconfig mailing list
> > partial-reconfig@xxxxxxxxxxxxxx
> > Mailing List Archive :=20
> > 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-reconf=
> ig/
___________________________
partial-reconfig mailing list
partial-reconfig@xxxxxxxxxxxxxx
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/partial-reconfig/