Partial reconfig flow

Hi folks,

I'm trying to get the modular partial reconfig flow going (as per XAPP 
290).  Details below - if anyone has any suggestions I'm all ears!  I'm 
doing this all with ISE 6.1.02i (trying under both Linux and Windows XP, 
same behaviour/problems).

As a first test, I successfully modularised my design, and implemented 
it using the modular flow described in the ISE documentation (Chapter 4 
of the Development System Reference Guide).  This all worked as expected.

Next, I inserted the partial reconfig bus_macro between my two modules, 
and created a set of placement constraints that ngdbuild would be happy 
with.  My toplevel design complies with all of the guidelines and rules 
I can find in the various bits of documentation about the partial 
reconfig flow (my hard-copy of XAPP290 is very well worn!).

I can perform top level initial budgeting without errors or warnings 
(except the expected "assuming such-and-such is a module").

Doing active module implementation - I can MAP and PAR the individual 
modules, and export the PIMs.  PAR reports failure due to some signals 
being unrouted.  This concerned me, however I see that the same happens 
in the example distributed with XAPP290...

I can perform final assembly on the pims and my toplevel, and it MAPs 
and PARs succesfully (all signals routed in final assembly 
implementation).  There is one strange message in this final PAR during 
guide file processing:

WARNING:Guide:147 - Design contains an unroutable situation due to 
existing islands. This may be caused by having an invalid NCD as input. 
  Verify that the input NCD's were implemented correctly.

However eventually PAR completes without errors or more warnings.

Now here's the really wierd bit - if I try to load the placed and routed 
toplevel NCD file into either fpga_editor, or even bitgen, it causes 
that program to crash.  Doing it on Linux I get a segfault, and on 
windows I get the standard "error in this application".

So, somehow, the tools have build such a broken NCD file that it crashes 
the other tools.  The "progressive" NCDs produced during the various 
lead-up phases seem OK - I can load them into FPGA editor etc.

A couple of questions:

(1) should the active module implementation phase "fail" with unrouted 
signals?  I thought the purpose of the bus_macro was to lock all of them 
down, but seeing this behaviour in XAPP290 makes me wonder.

(2) Has anyone ever seen bitgen or fpga_editor choke on an NCD produced 
by the implementation tools?

(3) Is there some other step I need to take to get this going?

If anyone has any ideas, please let me know.

Thanks,

John

John Williams wrote:
> A couple of questions:
> (1) should the active module implementation phase "fail" with unrouted 
> signals?  I thought the purpose of the bus_macro was to lock all of them 
> down, but seeing this behaviour in XAPP290 makes me wonder.
This is normal. When you implement a single module with the routing 
restricted to module boundaries by the "MODE = RECONFIG"-constraint, you 
can't route signals that belong to other modules or to the toplevel. 
E.g., if you have bus macro communication from lets say the left module 
to the right, and try to implement the left module, you can't route the 
signals coming out of the bus macro on the right side, hence these are 
reported as unrouted. Same applies to open signals (like not connected 
busmacro pins) and top-level-logic signals, if any. So at least that is 
nothing to worry about.

You can open the corresponding .NCD in FPGA Editor and let it list the 
unrouted nets. You'll find that all these signals are either not 
connected, or belong to another module in some way.

> (2) Has anyone ever seen bitgen or fpga_editor choke on an NCD produced 
> by the implementation tools?
Yes, this happens to me regularly... the entire design flow runs through 
without any error messages or unusual warnings, but in the end I get an 
.NCD that can neither be opened in FPGA Editor nor be converted to a 
bitfile. The main problem is that I cannot reproduce this behaviour, so 
I haven't opened a webcase for this yet. I think that even though the 
Xilinx support guys are without a doubt very competent, it's best if you 
can give them a simple as possible test design to reproduce the problem 
reliably. That way, they can get into it more easily.

> (3) Is there some other step I need to take to get this going?
Yes: Pray to the gods of Virtex, and a human sacrifice every now and 
then has been known to help was well... :)

I've been working on partial reconfiguration for some months now, and 
run into new problems on a daily basis. I've seen so many "FATAL_ERROR" 
and "INTERNAL ERROR"-messages, that I could probably keep all of Xilinx 
support busy for a decade. The biggest problem is that there is no 
pattern behind this. Sometimes it works, most of the time it doesn't. If 
I find a combination of modules and cores inside the modules that works, 
it stops working as the moon shifts phases or I change the tiniest of 
things.

Let's just face it: Partial reconfiguration is a market niche, purely 
academical, and the support in the tools just plain sucks. It works for 
simple designs with few modules, but as soon as it gets a little 
interesting the tools simply can't cope. It gets a tiny little bit 
better from ISE to ISE, but unfortunately new bugs are introduced as 
well. Just found one in ISE6.1 that sometimes causes top level logic to 
be placed incorrectly und makes par fail in the final assembly stage. No 
workaround available, no general rules as to what you can do to avoid 
it. Will probably be fixed in one of the first service packs for ISE6.2, 
which isn't even released yet. Bugger...

But enough rambling and let's get back to your problem: The error 
message you get occured to me once. Basically it suggests that some 
components of a module have been placed outside of module boundaries 
somehow. I think this happened to me when I changed the area constraints 
of my modules causing the bus macros to be completely inside one of the 
modules. If that's not the problem in your case, I suggest you check the 
.NCD-files for each of the modules in PACE or Floorplanner and see if 
any components may have been misplaced.

Other than that, it might help to just start over. If you do exactly the 
same thing twice with the same settings, results will vary considerably.

-- 
Sean Durkin
Fraunhofer Institute for Integrated Circuits (IIS)
Am Wolfsmantel 33, 91058 Erlangen, Germany
http://www.iis.fraunhofer.de

mailto:23@iis.42.de
([23 , 42] <=> [durkinsn , fraunhofer])

Following are my opinion only...

I saw WARNING:Guide:147 in every trial but I neglected it...as long as the
final assembly was routed and there was no boundary crossing...

During active module implementation, some wires  & components outside the
active module will not get placed & routed...so the error is presumingly
fine.

During active module implementation, some other wires & components outside
the active module do get placed & routed...and in two reconfigurable
modules,
the placement & routing of these wires and components may be different from
those in the fixed module...maybe the final assembly will resolve these
conflicts...
maybe this is where the WARNING:Guide:147 comes in...

I think, all my NCD files were readable in fpga_editor...I only saw the
version conversion tool failed when I tried to convert the NCD in XAPP290 to
ise 6.1...

John I guess u may need to download service park 3...that will patch the ise
to 6.1.03i...


Kelvin




"John Williams" <jwilliams@itee.uq.edu.au> wrote in message
news:c09k8m$bj5$1@bunyip.cc.uq.edu.au...
> Hi folks,
>
> I'm trying to get the modular partial reconfig flow going (as per XAPP
> 290).  Details below - if anyone has any suggestions I'm all ears!  I'm
> doing this all with ISE 6.1.02i (trying under both Linux and Windows XP,
> same behaviour/problems).
>
> As a first test, I successfully modularised my design, and implemented
> it using the modular flow described in the ISE documentation (Chapter 4
> of the Development System Reference Guide).  This all worked as expected.
>
> Next, I inserted the partial reconfig bus_macro between my two modules,
> and created a set of placement constraints that ngdbuild would be happy
> with.  My toplevel design complies with all of the guidelines and rules
> I can find in the various bits of documentation about the partial
> reconfig flow (my hard-copy of XAPP290 is very well worn!).
>
> I can perform top level initial budgeting without errors or warnings
> (except the expected "assuming such-and-such is a module").
>
> Doing active module implementation - I can MAP and PAR the individual
> modules, and export the PIMs.  PAR reports failure due to some signals
> being unrouted.  This concerned me, however I see that the same happens
> in the example distributed with XAPP290...
>
> I can perform final assembly on the pims and my toplevel, and it MAPs
> and PARs succesfully (all signals routed in final assembly
> implementation).  There is one strange message in this final PAR during
> guide file processing:
>
> WARNING:Guide:147 - Design contains an unroutable situation due to
> existing islands. This may be caused by having an invalid NCD as input.
>   Verify that the input NCD's were implemented correctly.
>
> However eventually PAR completes without errors or more warnings.
>
> Now here's the really wierd bit - if I try to load the placed and routed
> toplevel NCD file into either fpga_editor, or even bitgen, it causes
> that program to crash.  Doing it on Linux I get a segfault, and on
> windows I get the standard "error in this application".
>
> So, somehow, the tools have build such a broken NCD file that it crashes
> the other tools.  The "progressive" NCDs produced during the various
> lead-up phases seem OK - I can load them into FPGA editor etc.
>
> A couple of questions:
>
> (1) should the active module implementation phase "fail" with unrouted
> signals?  I thought the purpose of the bus_macro was to lock all of them
> down, but seeing this behaviour in XAPP290 makes me wonder.
>
> (2) Has anyone ever seen bitgen or fpga_editor choke on an NCD produced
> by the implementation tools?
>
> (3) Is there some other step I need to take to get this going?
>
> If anyone has any ideas, please let me know.
>
> Thanks,
>
> John
>

Hi, Sean:

Have you seen this type of error or not? I call it Error Of Ghost...

My design is simple, A+B and A+C...A has 3000+ slices, A's AREA_GROUP has 1
DCM, 14 BUFG, plus A.
B & C uses two clocks from BUFG...

A, B, C were implemented and published...A+C was assembled, HOWEVER! A+B
gave me this error...I have
seen this errors every now and then but I simply can't find an answer.

ERROR:Place - The following 1 components are required to be placed in a
specific
   relative placement form. The required relative coordinates in the RPM
grid
   (that can be seen in the FPGA-editor) are shown in brackets next to the
   component names. Due to placement constraints it is impossible to place
the
   components in the required form.     SLICE modulator/_n0030 (0, 0)
            Constrained by statement: COMPGRP "MODULATE.SLICE" LOCATE = SITE
   "SLICE_X0Y191:SLICE_X43Y0" LEVEL 4 ;

Thank you for reading...

Best Regards,
Kelvin


Sean Durkin <23@iis.42.de> wrote in message news:40289598$1@news.fhg.de...
> John Williams wrote:
> > A couple of questions:
> > (1) should the active module implementation phase "fail" with unrouted
> > signals?  I thought the purpose of the bus_macro was to lock all of them
> > down, but seeing this behaviour in XAPP290 makes me wonder.
> This is normal. When you implement a single module with the routing
> restricted to module boundaries by the "MODE = RECONFIG"-constraint, you
> can't route signals that belong to other modules or to the toplevel.
> E.g., if you have bus macro communication from lets say the left module
> to the right, and try to implement the left module, you can't route the
> signals coming out of the bus macro on the right side, hence these are
> reported as unrouted. Same applies to open signals (like not connected
> busmacro pins) and top-level-logic signals, if any. So at least that is
> nothing to worry about.
>
> You can open the corresponding .NCD in FPGA Editor and let it list the
> unrouted nets. You'll find that all these signals are either not
> connected, or belong to another module in some way.
>
> > (2) Has anyone ever seen bitgen or fpga_editor choke on an NCD produced
> > by the implementation tools?
> Yes, this happens to me regularly... the entire design flow runs through
> without any error messages or unusual warnings, but in the end I get an
> .NCD that can neither be opened in FPGA Editor nor be converted to a
> bitfile. The main problem is that I cannot reproduce this behaviour, so
> I haven't opened a webcase for this yet. I think that even though the
> Xilinx support guys are without a doubt very competent, it's best if you
> can give them a simple as possible test design to reproduce the problem
> reliably. That way, they can get into it more easily.
>
> > (3) Is there some other step I need to take to get this going?
> Yes: Pray to the gods of Virtex, and a human sacrifice every now and
> then has been known to help was well... :)
>
> I've been working on partial reconfiguration for some months now, and
> run into new problems on a daily basis. I've seen so many "FATAL_ERROR"
> and "INTERNAL ERROR"-messages, that I could probably keep all of Xilinx
> support busy for a decade. The biggest problem is that there is no
> pattern behind this. Sometimes it works, most of the time it doesn't. If
> I find a combination of modules and cores inside the modules that works,
> it stops working as the moon shifts phases or I change the tiniest of
> things.
>
> Let's just face it: Partial reconfiguration is a market niche, purely
> academical, and the support in the tools just plain sucks. It works for
> simple designs with few modules, but as soon as it gets a little
> interesting the tools simply can't cope. It gets a tiny little bit
> better from ISE to ISE, but unfortunately new bugs are introduced as
> well. Just found one in ISE6.1 that sometimes causes top level logic to
> be placed incorrectly und makes par fail in the final assembly stage. No
> workaround available, no general rules as to what you can do to avoid
> it. Will probably be fixed in one of the first service packs for ISE6.2,
> which isn't even released yet. Bugger...
>
> But enough rambling and let's get back to your problem: The error
> message you get occured to me once. Basically it suggests that some
> components of a module have been placed outside of module boundaries
> somehow. I think this happened to me when I changed the area constraints
> of my modules causing the bus macros to be completely inside one of the
> modules. If that's not the problem in your case, I suggest you check the
> .NCD-files for each of the modules in PACE or Floorplanner and see if
> any components may have been misplaced.
>
> Other than that, it might help to just start over. If you do exactly the
> same thing twice with the same settings, results will vary considerably.
>
> --
> Sean Durkin
> Fraunhofer Institute for Integrated Circuits (IIS)
> Am Wolfsmantel 33, 91058 Erlangen, Germany
> http://www.iis.fraunhofer.de
>
> mailto:23@iis.42.de
> ([23 , 42] <=> [durkinsn , fraunhofer])

Hi Sean,

Thanks for your response.  It confirmed a few things I was starting to 
think, but it's nice to know I'm not alone!

Sean Durkin wrote:
> 
> But enough rambling and let's get back to your problem: The error 
> message you get occured to me once. Basically it suggests that some 
> components of a module have been placed outside of module boundaries 
> somehow. I think this happened to me when I changed the area constraints 
> of my modules causing the bus macros to be completely inside one of the 
> modules. If that's not the problem in your case, I suggest you check the 
> .NCD-files for each of the modules in PACE or Floorplanner and see if 
> any components may have been misplaced.

I found the problem - I had disobeyed golden rule #465 of having a 
non-module IOB "above" a module area location...  I was secretly hoping 
there might be some edge-following routing resources that would let me 
get away with it, but it seems not...

thanks again,

John

John Williams wrote:
> Hi Sean,
> 
> Thanks for your response.  It confirmed a few things I was starting to 
> think, but it's nice to know I'm not alone!
Us partial reconfigurators sure are a rare species. We should stick 
together, or have some "RA" (Reconfigurators Anonymous) meetings some 
time... :)

> I found the problem - I had disobeyed golden rule #465 of having a 
> non-module IOB "above" a module area location...  I was secretly hoping 
> there might be some edge-following routing resources that would let me 
> get away with it, but it seems not...
Yeah, should've thought about that, I think that must've been what 
caused it in my case, too... But I notice that this only produces errors 
when you use ISE6. ISE5 routes the thing without warning, which of 
course leaves you with a useless design.

So did that solve the problem with the corrupt .NCD as well?

-- 
Sean Durkin
Fraunhofer Institute for Integrated Circuits (IIS)
Am Wolfsmantel 33, 91058 Erlangen, Germany
http://www.iis.fraunhofer.de

mailto:23@iis.42.de
([23 , 42] <=> [durkinsn , fraunhofer])

Tungsten-W wrote:
> Hi, Sean:
> 
> Have you seen this type of error or not? I call it Error Of Ghost...
> 
> My design is simple, A+B and A+C...A has 3000+ slices, A's AREA_GROUP has 1
> DCM, 14 BUFG, plus A.
> B & C uses two clocks from BUFG...
> 
> A, B, C were implemented and published...A+C was assembled, HOWEVER! A+B
> gave me this error...I have
> seen this errors every now and then but I simply can't find an answer.
> 
> ERROR:Place - The following 1 components are required to be placed in a
> specific
>    relative placement form. The required relative coordinates in the RPM
> grid
>    (that can be seen in the FPGA-editor) are shown in brackets next to the
>    component names. Due to placement constraints it is impossible to place
> the
>    components in the required form.     SLICE modulator/_n0030 (0, 0)
>             Constrained by statement: COMPGRP "MODULATE.SLICE" LOCATE = SITE
>    "SLICE_X0Y191:SLICE_X43Y0" LEVEL 4 ;
> 
> Thank you for reading...
I've seen this when I tried to place a MicroBlaze inside a too narrow 
module. There was plenty of free logic space, but MB just places some 
components relatively and needs a specific number of slices vertically 
and horizontally, and that I didn't provide.

It looks like in your case module "B" is the problem, specifically the 
"MODULATE.SLICE"-group... I guess you use some pre-generated netlists in 
there... Do you have any special IP-cores inside that module? In my case 
it helped to disable some of MicroBlaze's features, hence the thing 
became small enough to fit. Maybe there's some things you can disable or 
something to make it shrink enough to fit reliably.

As to way it sometimes works and sometimes doesn't: I find that the 
tools produce very different results, even if you run them with the same 
settings and on the same design files. It starts with synthesis, where 
net names and such vary from run to run, and in the end you sometimes 
get completely different placed and routed designs. So it's not really a 
surprise that something like that can happen...

-- 
Sean Durkin
Fraunhofer Institute for Integrated Circuits (IIS)
Am Wolfsmantel 33, 91058 Erlangen, Germany
http://www.iis.fraunhofer.de

mailto:23@iis.42.de
([23 , 42] <=> [durkinsn , fraunhofer])

Sean Durkin wrote:
> John Williams wrote:
> 
>> Hi Sean,
>>
>> Thanks for your response.  It confirmed a few things I was starting to 
>> think, but it's nice to know I'm not alone!
> 
> Us partial reconfigurators sure are a rare species. We should stick 
> together, or have some "RA" (Reconfigurators Anonymous) meetings some 
> time... :)

I agree 100%   Hopefully I'll be at ERSA in Las Vegas June this year, it 
would be good to have a commiseration/counselling session! :)

>> I found the problem - I had disobeyed golden rule #465 of having a 
>> non-module IOB "above" a module area location...  I was secretly 
>> hoping there might be some edge-following routing resources that would 
>> let me get away with it, but it seems not...
> 
> Yeah, should've thought about that, I think that must've been what 
> caused it in my case, too... But I notice that this only produces errors 
> when you use ISE6. ISE5 routes the thing without warning, which of 
> course leaves you with a useless design.
> 
> So did that solve the problem with the corrupt .NCD as well?

Yes and no - I can generate a bitstream, but only if I turn off the DRC. 
  If I leave the DRC on, it generates errors (not warnings) deep in the 
microblaze core, which is odd since I'm not doing anything in there..

but, I still can't open the file in fpga_editor...  shrug...

I had to put that aside and move onto some other stuff, i'll be back on 
it when i get the chance.  But at least I have built a modular/partial 
microblaze system, so it's a proof of concept if nothing else.

Cheers,

John

Reconfigurable Anonymous is cool...It's a new concept...I am willing to
join.

We Singapore has the best environment for holding international
meetings...We have
tropical white beaches, world class meeting facilities, places of
interests...Tungsten-W
and Kelvin@SG welcome you to come and experience the Asian metropolitan
life...:)

I will experiment a trick to tackle my design, as the top-level is really
complicated...
When I try active module implementation on the reconfigurable modules (which
uses two
separate BUFGs), there are few hundred wires on the fixed module side,
basically DCM
and 12 BUGs...Now I am writing a "initial" top-module for the reconfigurable
modules
without any of the extra DCM & 12 BUFGs...basically make a top-level with
only RM
and Bus Macros inside...In this way I can create the two RMs clean without
any addition
routing of the DCM & 12 BUFGs...Vice versa, for fixed module, I only include
DCM & 12
BUFGs...

Now in assembly, the conflict of routing is minimized...

Kelvin




"Sean Durkin" <23@iis.42.de> wrote in message news:402ba490$1@news.fhg.de...
> John Williams wrote:
> > Hi Sean,
> >
> > Thanks for your response.  It confirmed a few things I was starting to
> > think, but it's nice to know I'm not alone!
> Us partial reconfigurators sure are a rare species. We should stick
> together, or have some "RA" (Reconfigurators Anonymous) meetings some
> time... :)
>
> > I found the problem - I had disobeyed golden rule #465 of having a
> > non-module IOB "above" a module area location...  I was secretly hoping
> > there might be some edge-following routing resources that would let me
> > get away with it, but it seems not...
> Yeah, should've thought about that, I think that must've been what
> caused it in my case, too... But I notice that this only produces errors
> when you use ISE6. ISE5 routes the thing without warning, which of
> course leaves you with a useless design.
>
> So did that solve the problem with the corrupt .NCD as well?
>
> --
> Sean Durkin
> Fraunhofer Institute for Integrated Circuits (IIS)
> Am Wolfsmantel 33, 91058 Erlangen, Germany
> http://www.iis.fraunhofer.de
>
> mailto:23@iis.42.de
> ([23 , 42] <=> [durkinsn , fraunhofer])

John Williams wrote:
> Yes and no - I can generate a bitstream, but only if I turn off the DRC. 
> If I leave the DRC on, it generates errors (not warnings) deep in the 
> microblaze core, which is odd since I'm not doing anything in there..
Yes, I have that problem, too. I'm beginning to think this is normal...
The FATAL_ERRORS and INTERNAL_ERRORS I get are also always inside the 
MicroBlaze-core, which I am not touching...

> I had to put that aside and move onto some other stuff, i'll be back on 
> it when i get the chance.  But at least I have built a modular/partial 
> microblaze system, so it's a proof of concept if nothing else.
So, do you use EDK to generate the module with the Microblaze? If so,
have you ever tried exporting the MicroBlaze-system with a flat netlist? 
That's another thing that will not work whatever I try, it's always got 
to be hierarchical, otherwise I get some error about "This forces two 
components to be combined into one, I will now go to hell and take you 
with me" or something. I would think this has something to do with 
equivalent registers or unused logic being optimized away, but even when 
I change the corresponding settings for XST/map, it still doesn't work.

Not that I really mind working with a hierarchical netlist, it just 
takes awhile to find out how to fix the problem....

-- 
Sean Durkin
Fraunhofer Institute for Integrated Circuits (IIS)
Am Wolfsmantel 33, 91058 Erlangen, Germany
http://www.iis.fraunhofer.de

mailto:23@iis.42.de
([23 , 42] <=> [durkinsn , fraunhofer])