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

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, Sim>

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

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.

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

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.

Regards, Bret