Project Navigator mapping problem with CLK and BRAM

Hi

I have a problem with using "IBUFG" and "RAMB16_S9" in Project Navigator (ISE 6,3), when implementing.

In VHDL, BRAM and IBUFG were just instantiated. When VHDL-simulating in modelsim, it was okay using UNISIM.

When synthesizing with XST, no errors are found but following warning messages are seen.

------------------------------------------- WARNING:Xst:766 - c:/xilinx/work/TOP.vhd line 79: Generating a Black Box for component . . . WARNING:Xst:790 - c:/xilinx/work/MODULE.vhd line 127: Index value(s) does not match array range, simulation mismatch. . .WARNING:Xst:766 - c:/xilinx/work/BLOCK.vhd line 81: Generating a Black Box for component . . . WARNING:Xst:753 - c:/xilinx/work/RAM.vhd line 176: Unconnected output port 'DOP' of component 'RAMB16_S9' . .

-------------------------------------------

Finally MAPPING errors are found as follows

------------------------------------------- ERROR:Pack:1234 - F5 mux symbol "AA_Mmux_data_inst_mux_f5_26111" drives more than one F6 mux symbol, including symbol "BB_Mmux__n0024_inst_mux_f6_10". An F5 mux may drive at most one F6. Please correct the design.

----- INFO:LIT:95 - All of the external outputs in this design are using slew rate limited output drivers. The delay on speed critical outputs can be dramatically reduced by designating them as fast outputs in the schematic. INFO:MapLib:562 - No environment variables are currently set. INFO:MapLib:535 - The following Virtex BUFG(s) is/are being retargetted to Virtex2 BUFGMUX(s) with input tied to I0 and Select pin tied to constant 0: BUFG symbol "CLK_bufg" (output signal=clk_int2)

-------------------------------------------

Can someone help me with this troubleshooting? Thankyou in advance

Reply to
pasacco
Loading thread data ...

Black

slew

retargetted

I would follow the hierarchy to the offending module. "AA" might be the instance name. It's unfortunate that the tools use underscore for hierarchy separators when most users also use the underscore within signal names...

It almost looks like you've instantiated a black box that was built for a different architecture (part family). Do you have COREgen macros in your design? These may need to be refreshed or regenerated under new project settings.

Good luck, Gabor

Reply to
Gabor

Hi

Thankyou for comment.... Now I am making effort fixing,,,,,,with no luck.... But I found that this problem is not related with BRAM.....

Is someone aware of the information below? I am doing XST synthesis (without special constraint and without UCF).....

Thankyou for comment again :)

----------------------------------------------------------------- INFO:LIT:95 - All of the external outputs in this design are using slew

rate limited output drivers. The delay on speed critical outputs can be dramatically reduced by designating them as fast outputs in the schematic. INFO:MapLib:562 - No environment variables are currently set. INFO:MapLib:535 - The following Virtex BUFG(s) is/are being retargetted

to Virtex2 BUFGMUX(s) with input tied to I0 and Select pin tied to constant 0: BUFG symbol "CLK_bufg" (output signal=3Dclk_int2)

------------------------------=AD------------- -------------------------

Reply to
pasacco

I'm guessing all of your outputs are defaulting to LVTTL, which also defaults to slow slew rate. If you are meeting your output timing (clock to out usually, or pad to pad), this can be ignored. If some outputs need to be faster this message is letting you know that you can change the slew rate to "FAST" to pick up a couple nanoseconds.

This just means that the mapper didn't see any system environment variables that would change its behaviour. Therefore only the command line arguments determine the mapper's behaviour. This is usually O.K. unless you need some fairly advanced options.

You've used the generic library BUFG in your design, which is no longer a primitive for Virtex 2 and Spartan 3. This just lets you know that the buffer is actually implemented with the BUFGMUX primitive with its select line grounded.

Generally speaking, "INFO:" lines are not warnings, but are there to let you know that you might have an opportunity to improve your design's performance. I wouldn't worry about making this kind of message go away. For example you could explicitly call out a BUFGMUX for your "CLK_bufg" to eliminate the last message, but I think using the more generic BUFG is more readable and portable, so I wouldn't do it.

If you're having trouble getting your design to work, I would suggest adding some timing constraints to ensure a better mapping, place and route.

Reply to
Gabor

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.