building macros for Virtex-II with FPGA editor...

S

simon

Guest
Hello,
Is anyone out there experienced in building macros. As soon as my macros
contain external pins I cannot reopen them in "FPGA Editor". "FPGA
Editor" crashes displaying the following message:

FATAL_ERROR:Ncd:basncmacrodef.c:1470:1.31 - Mangled nmc file start
property read <0xfffcacc>. Process will terminate. To resolve this
error, please consult the Answers Databas and other online resources at
http://support.xilinx.com. If you need further assistance, please open a
Webcase by clicking on the "WebCase" link at http://support.xilinx.com

I'm a student, so I am not allowed to open a webcase...

Regards
Simon
 
simon <ssteineg@ee.ethz.ch> wrote in message news:<4016b07a$1@pfaff2.ethz.ch>...
Hello,
Is anyone out there experienced in building macros. As soon as my macros
contain external pins I cannot reopen them in "FPGA Editor". "FPGA
Editor" crashes displaying the following message:

FATAL_ERROR:Ncd:basncmacrodef.c:1470:1.31 - Mangled nmc file start
property read <0xfffcacc>. Process will terminate. To resolve this
error, please consult the Answers Databas and other online resources at
http://support.xilinx.com. If you need further assistance, please open a
Webcase by clicking on the "WebCase" link at http://support.xilinx.com

I'm a student, so I am not allowed to open a webcase...

Regards
Simon
Click to expand...
Hello Simon,

I have found a known problem that appears to be a good match for your
problem. This problem only occurs when more than one save operation is
performed per FPGA Editor session. Try defining all of your external
pins at once without intermediate saves. If there are too many of them
for that to be practical, I suggest that you close the editor after
saves before continuing.

BTW, if you are using our current tools, you may want to consider
using RPM Macros combined with Directed Routing constraints instead of
Hard Macros. It depends on what you are trying to accomplish with the
macro.

Regards,
Bret
 
Hello Bret,
I just read some xilinx documents about RPMs and Directed routing. I'm
not quite sure if these are useful in my case. I'm working on a
dynamically partial reconfigurable design and I want to model
communication lines across reconfigurable modules as hard macros. I
assume that this will prevent (or rather minimize) discontinuation of
the signal flow when the module is reconfigured.

Regards,
Simon

Bret Wade wrote:

simon <ssteineg@ee.ethz.ch> wrote in message news:<4016b07a$1@pfaff2.ethz.ch>...

Hello,
Is anyone out there experienced in building macros. As soon as my macros
contain external pins I cannot reopen them in "FPGA Editor". "FPGA
Editor" crashes displaying the following message:

FATAL_ERROR:Ncd:basncmacrodef.c:1470:1.31 - Mangled nmc file start
property read <0xfffcacc>. Process will terminate. To resolve this
error, please consult the Answers Databas and other online resources at
http://support.xilinx.com. If you need further assistance, please open a
Webcase by clicking on the "WebCase" link at http://support.xilinx.com

I'm a student, so I am not allowed to open a webcase...

Regards
Simon


Hello Simon,

I have found a known problem that appears to be a good match for your
problem. This problem only occurs when more than one save operation is
performed per FPGA Editor session. Try defining all of your external
pins at once without intermediate saves. If there are too many of them
for that to be practical, I suggest that you close the editor after
saves before continuing.

BTW, if you are using our current tools, you may want to consider
using RPM Macros combined with Directed Routing constraints instead of
Hard Macros. It depends on what you are trying to accomplish with the
macro.

Regards,
Bret
Click to expand...
 
simon <ssteineg@ee.ethz.ch> wrote in message news:<40177bdc$1@pfaff2.ethz.ch>...
Hello Bret,
I just read some xilinx documents about RPMs and Directed routing. I'm
not quite sure if these are useful in my case. I'm working on a
dynamically partial reconfigurable design and I want to model
communication lines across reconfigurable modules as hard macros. I
assume that this will prevent (or rather minimize) discontinuation of
the signal flow when the module is reconfigured.

Regards,
Simon
Click to expand...
Hello Simon,

I don't see why Directed Routing constraints couldn't replace the
functionality of the Bus Macro in the partial reconfig flow, but since
the penalty for not doing exactly the right thing is higher there, I
recommend staying with the documented hard macro flow. If you do try
the Directed Routing method, pay attention to the section in the .par
file that tells you if all the DIRT constraints were successfull.

Regards,
Bret
 
Bret
may I know the "documented hard macro flow"? Is it an application note or
what?
Does the RPMs allow going parameteric? I guess a Bus Macro with a variable
bus width is better than the current 4-bit bus...

Otherwise I may merge a lot of bus macros to make 32-bit or 64-bit Bus
Macros...
It's really troublesome to instantiate many Bus Macros...


Kelvin





Bret Wade <bret.wade@xilinx.com> wrote in message
news:465bd4b1.0401281033.6e9d867e@posting.google.com...
simon <ssteineg@ee.ethz.ch> wrote in message
news:<40177bdc$1@pfaff2.ethz.ch>...
Hello Bret,
I just read some xilinx documents about RPMs and Directed routing. I'm
not quite sure if these are useful in my case. I'm working on a
dynamically partial reconfigurable design and I want to model
communication lines across reconfigurable modules as hard macros. I
assume that this will prevent (or rather minimize) discontinuation of
the signal flow when the module is reconfigured.

Regards,
Simon

Hello Simon,

I don't see why Directed Routing constraints couldn't replace the
functionality of the Bus Macro in the partial reconfig flow, but since
the penalty for not doing exactly the right thing is higher there, I
recommend staying with the documented hard macro flow. If you do try
the Directed Routing method, pay attention to the section in the .par
file that tells you if all the DIRT constraints were successfull.

Regards,
Bret
Click to expand...
 
Not sure if this helps, as I'mnot entirely clear on what you are attempting to
do: You might try the more conventional RPM approach where you put RLOCs on
the instances (Tbufs in your case?) to place but not route the primitives.
Given a good placement, the router will usually find a solution that meets
timing. Prior to ISE 4, given a good placement, the router did a great job.
versions 4 and 5 had some laziness in the router that led to less than optimal
routes. I have not fully evaluated the results in version 6, but it does seem
to be doing considerably better. In any event, doing placement only lets you
do the macro layout using the conventional, well documented tools flow. RLOCs
can either be entered in the ucf either manually or using the floorplanner, or
they can be embedded in your source code. I prefer to embed them in the
source because it lets you build the macros, including placement,
hierarchically. The ucf treats the design as flat, so you don't get the
reuse. If you use VHDL, the ability to use the index variable in a
for..generate statement in the constant declarations lets you easily do step
and repeat type layouts. Verilog doesn't have a mechanism to include the
generate index in the rloc strings.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
 
"Kelvin @ SG" <kelvin8157@hotmail.com> wrote in message news:<4018a051$1@news.starhub.net.sg>...
Bret
may I know the "documented hard macro flow"? Is it an application note or
what?
Does the RPMs allow going parameteric? I guess a Bus Macro with a variable
bus width is better than the current 4-bit bus...

Otherwise I may merge a lot of bus macros to make 32-bit or 64-bit Bus
Macros...
It's really troublesome to instantiate many Bus Macros...


Kelvin
Click to expand...
Hi Kevin,

I was refering to XAPP290 where it mentions the use of Bus Macros. No,
the RPMs would not be parameteric. The advantages of using RPMs with
Directed Routing over hard macros in general is that they exist in the
logical design where timing constraints can be applied. Also, since
hard macros are not a mainstream flow, they are more likely to run
into a tool problem as the OP found.

http://www.xilinx.com/bvdocs/appnotes/xapp290.pdf

Regards,
Bret
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top