This design contains an RPM macro bm_0 which is to be automa

O

One Day & A Knight

Guest
Hi, there:

I want to know how to fix this kind of problem?


Phase 1.1
ERROR:place:205 - This design contains an RPM macro bm_0 which is to be
automatically placed, but it contains TBUF elelements that are not allowed
during automatic placement of RPMs. You must either pick an absolute
location for the macro using a LOC constraint, or remove the TBUF element
from the macro.

ERROR:place:205 - This design contains an RPM macro bm_1 which is to be
automatically placed, but it contains TBUF elelements that are not
allowed
during automatic placement of RPMs. You must either pick an absolute
location for the macro using a LOC constraint, or remove the TBUF element
from the macro.

WARNING:place:204 - Routed macros (nmc's) have been found in this design.
The
placer will need to verify that routing does not attempt to use already
used
resources every time these macros are moved. This may significantly slow
down run time. If the macros are designed such that it is impossible to
place the routed macros in a way that will cause the routing to overlap
then
set the environment variable "PAR_NOMACROROUTECHECKING" and the placer
will
run much faster. The routing will still be checked at the end of the run
and
if the same routing resourse is required by multiple macros then a fatal
error will occur.
 
One Day & A Knight wrote:

Hi, there:
I want to know how to fix this kind of problem?

Phase 1.1
ERROR:place:205 - This design contains an RPM macro bm_0 which is to be
automatically placed, but it contains TBUF elelements that are not allowed
during automatic placement of RPMs. You must either pick an absolute
location for the macro using a LOC constraint, or remove the TBUF element
from the macro.
It tells you right there: "You must pick an absolute location for the
macro"...

Looks like you're using a bus macro here. Those will not be placed
automatically, you have to position them manually with
floorplanner/PACE. Or you can just put a corresponding location
constraint into your .UCF, something like this:

INST "bm_0" LOC = "TBUF_X0Y0" ;

This would place the busmacro with the instance name "bm_0" in the lower
left corner of the FPGA. Of course you have to do this for every
instance, with different locations.

Where you have to put it depends on what you want to do with it.
Usually, you use bus macros to communicate between two modules of a
design, so you place the macro so it straddles the border between the
two modules it's supposed to connect.

--
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])
 
Thanks, Durkin.

However that is the thing I don't understand. In my UCF file I put
constraints like these in the UCF file.
1) INST "bm_0" LOC = "TBUF_X0Y0" ;
2) INST "bm_0" LOC = "TBUF_X0Y0:TBUF_X0Y7" ; # Since I use all four
pins.
I tried both cases but I always end up in this error 205, and Xilinx Answers
don't have this error :(

I have another question. How come the XST GUI's Properties ask for a .XCF
file? Is that similar
to .UCF? How do I compile my verilog codes with XST GUI while control the
bus-delimiter with
() instead of the default <>?

Also, how come in the GUI, the UCF&XCF is in XST, while in commandline mode,
the UCF is in NGDBuild?
Why so many exceptions and so much inconsistency in ISE 6.1! :(

In my procedure, I have only XST (ISE6.1.03) in my PC, so I used command
line XST to make
sure that the bus delimiter is (), then in commandline to run the NGDBuild
with -uc my_top.ucf...then
return back to GUI to do MAP and P&R...

Only P&R doesn't work!

I think I need to try out the manual placement.

Best Regards,



"Sean Durkin" <23@iis.42.de> wrote in message news:3ff00882$1@news.fhg.de...
One Day & A Knight wrote:

Hi, there:
I want to know how to fix this kind of problem?

Phase 1.1
ERROR:place:205 - This design contains an RPM macro bm_0 which is to be
automatically placed, but it contains TBUF elelements that are not
allowed
during automatic placement of RPMs. You must either pick an absolute
location for the macro using a LOC constraint, or remove the TBUF
element
from the macro.
It tells you right there: "You must pick an absolute location for the
macro"...

Looks like you're using a bus macro here. Those will not be placed
automatically, you have to position them manually with
floorplanner/PACE. Or you can just put a corresponding location
constraint into your .UCF, something like this:

INST "bm_0" LOC = "TBUF_X0Y0" ;

This would place the busmacro with the instance name "bm_0" in the lower
left corner of the FPGA. Of course you have to do this for every
instance, with different locations.

Where you have to put it depends on what you want to do with it.
Usually, you use bus macros to communicate between two modules of a
design, so you place the macro so it straddles the border between the
two modules it's supposed to connect.

--
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])
 
A Day & A Knight wrote:

Thanks, Durkin.
However that is the thing I don't understand. In my UCF file I put
constraints like these in the UCF file.
1) INST "bm_0" LOC = "TBUF_X0Y0" ;
2) INST "bm_0" LOC = "TBUF_X0Y0:TBUF_X0Y7" ; # Since I use all four
pins.
I tried both cases but I always end up in this error 205, and Xilinx Answers
don't have this error :(
Version 1) should suffice. For each macro there is one pin defined as
the reference, and that pin is used to place the macro. All the other
pins of the macro are then fixed, because the routing and placement is
specified in the macro itself, relative to the reference pin.

Version 2) should give you an error, since TBUF_X0Y0:TBUF_X0Y7 is an
ambiguous location, so that should not work at all, as I understand it.

Since you don't get an error other than 205 when using version 2, and it
still says "RPM macro bm_0 which is to be AUTOMATICALLY placed", even
though you have placed it manually in the .UCF, I suspect that ISE
doesn't really use your .UCF-file at all.

How did you add the .UCF to your design? You should just add it as a
source file (just like your verilog source codes), and assign it to your
top-level design file when asked.

I have another question. How come the XST GUI's Properties ask for a .XCF
file? Is that similar to .UCF?
The .XCF is for synthesis, the .UCF is for mapping and the place and
route process. In the .XCF you can put special constraints for XST, like
if it should optimize away equivalent registers, automatically add
IO-buffers and things like that. The .XCF is for use with XST,
exclusively and does not work with FPGA Express and other synthesis
tools (at least as far as I know).

In the .UCF you put more global things, like which IOBs to use, timing
constraints for your clock signals, area constraints for modules etc.,
i.e. things that relate to the implementation of your design, that is
mapping, placing and routing. A .UCF can be used with tools from other
vendoers as well.

How do I compile my verilog codes with XST GUI while control the
bus-delimiter with () instead of the default <>?
In Project Navigator, select your top-level design file, right-click on
"Synthesize", and chose "Properties". After scrolling down (!) you can
specify the "Bus delimiter" in the "Synthesis Options" tab.

Also, how come in the GUI, the UCF&XCF is in XST, while in commandline mode,
the UCF is in NGDBuild?
As I stated above, the .UCF should be added to the design just like your
verilog source codes, not in the XST settings. It's possible that your
..UCF is simply ignored when added in the XST settings, which would
explain your problem.

Why so many exceptions and so much inconsistency in ISE 6.1! :(
In my procedure, I have only XST (ISE6.1.03) in my PC, so I used command
line XST to make
sure that the bus delimiter is (), then in commandline to run the NGDBuild
with -uc my_top.ucf...then
return back to GUI to do MAP and P&R...
Only P&R doesn't work!
P&R needs a .PCF (physical constraints file) to work. This .PCF is
generated automatically from your .UCF during mapping. Normally, par
looks for a file named <your_design>.pcf or <your_design_map>.pcf in the
working directory, and uses that automatically. If it's not there, it
tries to place everything itself. I suspect that this is what happens in
your case. Check and see if a .PCF file is generated somewhere along the
way.

But I guess if you run the entire flow in the GUI (after changing the
bus delimiter like described above), everything will work fine
automatically.

--
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])
 
Thank you Durkin!

The BUS Delimiter/Hierarchy separater/etc. can only be found Advanced
mode...I was not aware of this mode in ISE6.1...

I managed to place & route a bus macro...it seems to me, a BM is a 4SX2S
rectangular box, but previously I
placed them in a gap with 1 slices wide between my two modules, so it caused
some mistakes. I treated it like
a 1SX8S verticle pole...

Now I managed to run a synthesis and P&R successfully all in GUI. Thank you
for your reply.

Lastly, is there any options to limit the amount of RAM in ISE? My PC has
only 256MB and is not sufficient for a
50K ASIC gate design. ISE tends to eat as much as that is available.

Best Regards,
Kelvin





Sean Durkin <23@iis.42.de> wrote in message news:3ff03b8d$1@news.fhg.de...
A Day & A Knight wrote:

Thanks, Durkin.
However that is the thing I don't understand. In my UCF file I put
constraints like these in the UCF file.
1) INST "bm_0" LOC = "TBUF_X0Y0" ;
2) INST "bm_0" LOC = "TBUF_X0Y0:TBUF_X0Y7" ; # Since I use all four
pins.
I tried both cases but I always end up in this error 205, and Xilinx
Answers
don't have this error :(
Version 1) should suffice. For each macro there is one pin defined as
the reference, and that pin is used to place the macro. All the other
pins of the macro are then fixed, because the routing and placement is
specified in the macro itself, relative to the reference pin.

Version 2) should give you an error, since TBUF_X0Y0:TBUF_X0Y7 is an
ambiguous location, so that should not work at all, as I understand it.

Since you don't get an error other than 205 when using version 2, and it
still says "RPM macro bm_0 which is to be AUTOMATICALLY placed", even
though you have placed it manually in the .UCF, I suspect that ISE
doesn't really use your .UCF-file at all.

How did you add the .UCF to your design? You should just add it as a
source file (just like your verilog source codes), and assign it to your
top-level design file when asked.

I have another question. How come the XST GUI's Properties ask for a
..XCF
file? Is that similar to .UCF?
The .XCF is for synthesis, the .UCF is for mapping and the place and
route process. In the .XCF you can put special constraints for XST, like
if it should optimize away equivalent registers, automatically add
IO-buffers and things like that. The .XCF is for use with XST,
exclusively and does not work with FPGA Express and other synthesis
tools (at least as far as I know).

In the .UCF you put more global things, like which IOBs to use, timing
constraints for your clock signals, area constraints for modules etc.,
i.e. things that relate to the implementation of your design, that is
mapping, placing and routing. A .UCF can be used with tools from other
vendoers as well.

How do I compile my verilog codes with XST GUI while control the
bus-delimiter with () instead of the default <>?
In Project Navigator, select your top-level design file, right-click on
"Synthesize", and chose "Properties". After scrolling down (!) you can
specify the "Bus delimiter" in the "Synthesis Options" tab.

Also, how come in the GUI, the UCF&XCF is in XST, while in commandline
mode,
the UCF is in NGDBuild?
As I stated above, the .UCF should be added to the design just like your
verilog source codes, not in the XST settings. It's possible that your
.UCF is simply ignored when added in the XST settings, which would
explain your problem.

Why so many exceptions and so much inconsistency in ISE 6.1! :(
In my procedure, I have only XST (ISE6.1.03) in my PC, so I used command
line XST to make
sure that the bus delimiter is (), then in commandline to run the
NGDBuild
with -uc my_top.ucf...then
return back to GUI to do MAP and P&R...
Only P&R doesn't work!
P&R needs a .PCF (physical constraints file) to work. This .PCF is
generated automatically from your .UCF during mapping. Normally, par
looks for a file named <your_design>.pcf or <your_design_map>.pcf in the
working directory, and uses that automatically. If it's not there, it
tries to place everything itself. I suspect that this is what happens in
your case. Check and see if a .PCF file is generated somewhere along the
way.

But I guess if you run the entire flow in the GUI (after changing the
bus delimiter like described above), everything will work fine
automatically.

--
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])
 
One Day & A Knight wrote:
Thank you Durkin!
The BUS Delimiter/Hierarchy separater/etc. can only be found Advanced
mode...I was not aware of this mode in ISE6.1...
Ah, yes, I should've thought about that. But that's always the first
option you set after installing... :)

I managed to place & route a bus macro...it seems to me, a BM is a 4SX2S
rectangular box, but previously I
placed them in a gap with 1 slices wide between my two modules, so it caused
some mistakes. I treated it like
a 1SX8S verticle pole...
You can just load it into FPGAEditor and look at it.

Lastly, is there any options to limit the amount of RAM in ISE? My PC has
only 256MB and is not sufficient for a
50K ASIC gate design. ISE tends to eat as much as that is available.
Not that I know of...

--
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, Durkin:

I am a little confused with the partial reconfiguration flow.

In the Active module implementation, I found that I must use the *.NGO file.
However .NGO file is only
available when I use EDIF file as input, and XST cannot produce EDIF file.

Does it mean I have no choice but to use something other than XST (e.g.
Synplicity) to synthesize my designs?

ngdbuild -p xc2v250-fg256-4 -modular module -active iq_gen
.../../top1/initial/sig_gen.ngo

Best Regards,
Kelvin





"Sean Durkin" <23@iis.42.de> wrote in message news:3ff00882$1@news.fhg.de...
One Day & A Knight wrote:

Hi, there:
I want to know how to fix this kind of problem?

Phase 1.1
ERROR:place:205 - This design contains an RPM macro bm_0 which is to be
automatically placed, but it contains TBUF elelements that are not
allowed
during automatic placement of RPMs. You must either pick an absolute
location for the macro using a LOC constraint, or remove the TBUF
element
from the macro.
It tells you right there: "You must pick an absolute location for the
macro"...

Looks like you're using a bus macro here. Those will not be placed
automatically, you have to position them manually with
floorplanner/PACE. Or you can just put a corresponding location
constraint into your .UCF, something like this:

INST "bm_0" LOC = "TBUF_X0Y0" ;

This would place the busmacro with the instance name "bm_0" in the lower
left corner of the FPGA. Of course you have to do this for every
instance, with different locations.

Where you have to put it depends on what you want to do with it.
Usually, you use bus macros to communicate between two modules of a
design, so you place the macro so it straddles the border between the
two modules it's supposed to connect.

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

Welcome to EDABoard.com

Sponsor

Back
Top