Partial reconfig flow

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.

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.

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.

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

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

Hi Sean,

Thanks for your resp>

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

Us partial reconfigurators sure are a rare species. We should stick together, or have some "RA" (Reconfigurators Anonymous) meetings some time... :)

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?

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...

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! :)

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

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...

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....