On trying to generate the 'Virtex 5 Embedded Tri-mode Ethernet MAC wrapper v1.3', an error 'A Core Generator generated file xxxx.ucf does not exist in the project directory' is detected. Although the .xco file is generated, I am unable to view the HDL functional model. Anyone out there with any idea?
I have yet to install an IP update (for v1.3) and know that v1.2 works fine in ISE 9.2.04i. You can always use this IP version as a workaround for now. Let me get the IP updated and see what happens on my end. In the meantime, let me know what version of ISE you are using.
I was able to run the Embedded V5 TEMAC core (v1.3) and had no issues as what you described. Both UCF and functional simulation files were generated and viewable. How have things progressed on your end?
I was using ISE webpack 9.2i with service pack 3 installed. I tried updating to service pack 4 but the same error occured. The project is currently empty, with only this ip core created. Is there anything which I have to do before creating this ip core which might have lead to this error?
To start off, my working directory does not have any white spaces.
I am unable to view the picture you attached, but I will give you more details.
Basically, I am implementing the Virtex-5 Embedded Tri-mode Ethernet MAC wrapper v1.3 IP core. I set the configuration to: - 'None' for interfacing to host - Enabled EMAC0 and EMAC1 - GMII and tri-mode for both
Then on generating of the IP core, the following messages are seen:
Customizing IP... 9.2.04i - Xilinx CORE Generator IP GUI Launcher J.40(c) 1995-2007 Xilinx, Inc. All rights reserved.Finished Customizing. Generating IP... WARNING:sim:89 - A core named <emac_wrap> already exists in the output directory. Output products for this core may be overwritten. WARNING:sim:93 - NGC output will not be generated for this core. Finished Generating. Successfully generated emac_wrap. ERROR: A Core Generator generated file emac_wrap/example_design/emac_wrap_block.ucf does not exist in the project directory!
Under the "Sources" window, there is no instance of the core being generated and added to the project. However, the .xco file has been generated and I am able to add this source manually. However, it is impossible to view the HDL instance of this core.
I do not believe that this core is intended to be generated within an open ISE project. Try launching CoreGen standalone (in another directory) and generate the core. Use explorer to see if a directory structure is formed similar to this:
tri_mode_test (your CoreGen project name)
|_v5_emac_v1_3(default core name)
From here you will want to go to the implementation directory and use one of the scripts (in your case the .bat) and generate the design. When completed, it will create another directory (in the implement directory) called results. This directory will contain your implementation and programming files. The Getting Started Guide (v5_emac_gsg340.pdf) in the docs directory should cover this.
If you wanted to bring this into the ISE environment, you could copy the example design files into the sources area and run through the GUI that way. You would have to be careful to set the correct implementation options (as listed in the scripts). I do not think this is the intended (or supported) method, but probably doable.
Sorry for the very late reply as I only had the time to get back to this issue only recently.
Anyways, I followed your advice and amid some effort in creating the .ucf file, had successfully implemented the tri-mode MAC wrapper on a development board by adding the source files found in the "example_design" directory. The vhd files included mac_wrapper_locallink, mac_wrapper_block, eth_fifo_8, rx_client_fifo_8, tx_client_fifo_8. Basically I am using the FIFO created by Xilinx to gather data from the EMAC.
However, I came to realize that there is a comment found in rx_client_fifo_8,vhd and tx_client_fifo_8,vhd that the requirement in using this FIFO is to have at least 64 clock cycles between frame. I believed this requirement is a design obstacle for gigabit ethernet because the interval for GE is 96ns. For a clock of 125MHz, 64 clock cycles will tally to 512 ns which is definitely much longer than the interval between frames for GE. Please correct me if I am wrong.
Can you advise on the areas of the code which can be amended to solve this issue? If not, does this mean a new FIFO have to be written from scratch?