Partial reconfig flow

[John Williams]

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

 

[Sean Durkin]

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])

 

[Kelvin @ SG]

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

 

[Tungsten-W]

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.

ERRORlace - 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])

 

[John Williams]

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

 

[Sean Durkin]

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])

 

[Sean Durkin]

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.

ERRORlace - 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])

 

[John Williams]

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

 

[Kelvin @ SG]

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])

 

[Sean Durkin]

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])