XST sythesizes fifos instead of creating black boxes

Hello,

I have a weird issue with a Virtex-4 design. The problem is that xst somehow manages to find the coregen fifos vhd files in my design and synthesizes them (I'm using a command line flow). This effectively deletes the fifo because the vhd wrapper is full of translate_off statement. XST shouldn't find any fifo vhd files at all (just the ngc at the ngdbuild stage).

The weirdest thing is that xst finds the path to my fifos although they are NOT listed in the prj source file and I am not specifying a path to find cores with the -sd flag.

Here's the relevant part of the log:

Synthesizing Unit . Related source file is "D:/Telops/common_hdl/coregen_v4/ s_fifo_w8_d16.vhd". WARNING:Xst:647 - Input is never used. WARNING:Xst:647 - Input is never used. WARNING:Xst:647 - Input is never used. WARNING:Xst:1305 - Output is never assigned. Tied to value 0. WARNING:Xst:647 - Input is never used. WARNING:Xst:1305 - Output is never assigned. Tied to value 0. WARNING:Xst:647 - Input is never used. WARNING:Xst:1305 - Output is never assigned. Tied to value 0. WARNING:Xst:1305 - Output is never assigned. Tied to value

  1. WARNING:Xst:1305 - Output is never assigned. Tied to value 0. WARNING:Xst:1305 - Output is never assigned. Tied to value 0. WARNING:Xst:1305 - Output is never assigned. Tied to value
00000000. Unit synthesized.

How can xst find the path to the "Related source file"??? There's some magic going on that I don't understand.

I might as well include the prj and xst files, sorry for the bloat:

top_level_v4.xst: set -tmpdir . set -xsthdpdir d:/Telops/CAMEL/uc2/synthesis/xst run

-ifn top_level_V4.prj

-ifmt mixed

-ofn top_level_V4

-ofmt NGC

-p xc4vfx12sf363-10

-top top_level_V4

-opt_mode speed

-opt_level 1

-iuc yes

-glob_opt allclocknets

-write_timing_constraints no

-verilog2001 yes

-keep_hierarchy yes

-hierarchy_separator /

-bus_delimiter

-case maintain

-cross_clock_analysis no

-slice_utilization_ratio 100

-dsp_utilization_ratio 100

-read_cores no

-fsm_extract yes -fsm_encoding Auto

-vlgcase full-parallel

-resource_sharing yes

-fsm_style lut

-ram_extract yes

-ram_style auto

-rom_extract yes

-rom_style auto

-mux_extract yes

-mux_style auto

-decoder_extract yes

-priority_extract yes

-shreg_extract yes

-shift_extract yes

-xor_collapse yes

-use_dsp48 auto

-iobuf yes

-max_fanout 500

-bufg 32

-bufr 16

-register_duplication yes

-equivalent_register_removal yes

-register_balancing no

-iob auto

-slice_packing yes

-optimize_primitives no

-safe_implementation no

-use_clock_enable yes

-use_sync_set yes

-use_sync_reset yes

-slice_utilization_ratio_maxmargin 5

top_level_v4.prj: vhdl Common_HDL D:/Telops/Common_HDL/telops.vhd vhdl work D:/Telops/Common_HDL/Utilities/ram_dist.vhd vhdl work D:/Telops/Common_HDL/RS232/uarts.vhd vhdl work D:/Telops/Common_HDL/Utilities/sync_reset.vhd vhdl work D:/Telops/Common_HDL/Utilities/double_sync.vhd vhdl work D:/Telops/Common_HDL/Wishbone/uc2_wb_master.vhd vhdl work D:/Telops/Common_HDL/Wishbone/wb_8i8o.VHD vhdl work D:/Telops/Common_HDL/Wishbone/ARB0001a.VHD vhdl work D:/Telops/Common_HDL/Wishbone/MEM0001a.VHD verilog work D:/Telops/Common_HDL/Wishbone/rs232_syscon/ auto_baud_with_tracking.v verilog work D:/Telops/Common_HDL/Wishbone/rs232_syscon/serial.v verilog work D:/Telops/Common_HDL/Wishbone/rs232_syscon/rs232_syscon.v vhdl work D:/Telops/Common_HDL/Wishbone/wb_intercon_8s.vhd vhdl work ..\src\defines.vhd vhdl work ..\compile\top_level_v4.vhd vhdl work ..\..\common_hdl\ultracontroller-ii/jtagppc_wrapper.vhd vhdl work ..\compile\simple_dcm_v4.vhd vhdl work ..\src\rs232/config_decoder.vhd vhdl work ..\src\rs232/rs232_dispatcher.vhd vhdl work ..\compile\dpb_rs232_manager_v4.vhd vhdl work ..\compile\uc2_block_8s.vhd vhdl work ..\..\common_hdl\ultracontroller-ii/virtex-4/uc2.vhd vhdl work ..\compile\uc2_block_8s_prom.vhd vhdl work ..\..\common_hdl\ultracontroller-ii/prom2jtag.vhd vhdl work ..\..\common_hdl\ultracontroller-ii/prom2uar.vhd verilog work ..\..\common_hdl\ultracontroller-ii/uar_load.v vhdl work ..\compile\uc2_block_8s.vhd

Does anyone understand what is going on here? I tried with ISE v8.2.03 and v9.1.03, same problem.

Thanks.

Patrick

Reply to
Patrick Dubois
Loading thread data ...

Just a little update, I tried on a colleague computer and the bug doesn't show up. So it really seems like there is a hidden environment variable or something on my computer only, that guides xst to the Coregen_V4 directory.

Even more strange, I deleted the file s_fifo_w8_d16.vhd completely, emptied the recycle bin, and yet xst still manages to find the file and compile it!!

I'm using a truecrypt partition for my source files, I wonder if it is related.

Yet another Xilinx tool issue (maybe), .

Patrick

Reply to
Patrick Dubois

Problem solved. The mystery lied in the xst temporary directory, which had been set automatically by Active-HDL to a strange location. I had not noticed its existence because it was not in the same file hierarchy as the rest of the design.

Clearing the temporary directory solved the problem. Yet, I find it troubling that xst relied on old data in its temporary directory. It should always give the same result (given a certain set of input files), no matter what lies in its temp directory. If it can find precompiled stuff in there, fine, as long as it doesn't use OLD outdated stuff!

If the temp directory in unreliable, xst should clear it completely before starting a compilation then. It shouldn't be the user's problem.

Patrick

Reply to
Patrick Dubois

Patrick Dubois wrote: ...

Unfortunately, it is. There are lots of synthesis settings, and any one of them can be wrong. I could write a script or makefile to control simulation and synthesis and use source control tools to keep track of versions.

-- Mike Treseler

Reply to
Mike Treseler

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.