Strange problem with okWireOut and Xilinx optimization

hi all,

In my first attempt at a design, which is a modified version of the “First.vhd” example, I have ep25 setup as an okWireOut and I have a 32-bit counter connected to it, so that ep25 returns to the PC the lower 16 bits of the count.

During the mapping phase of the “Implement design” procedure, I get a strange error message, like this:

ERROR:MapLib:661 - BUFT symbol “ep20/ti_data_wirehold_0” (output
signal=ti_data, enable signal=ep20/ti_data_wirehold_N0) has input
signal “ep25/wirehold” which will be trimmed. See the trim report for
details about why the input signal will become undriven.

I couldn’t make head or tail of this, so I started searching on the Xilinx website, and as advised in answer record #23990, I had a look at the trim report. Everything seems OK in the trim report except for one line that I can’t explain:

The signal “ep25/wirehold” is sourceless and has been removed.

What does this mean? Since I don’t have the vhdl code for the okWireOut module (it comes as an NGC I think), I’m unable to come up with any further theories. Can someone more knowledgeable please come to my rescue?

Note: The message about “ep25/wirehold” appears in the initial section of the trim report and is not indented. Underneath in the second section, indented, it then proceeds to optimize away most of my design… but it looks like the problem with “ep25/wirehold” signal is the underlying cause.


Hm. While I doubt it will make much difference, can you post the code that produces the error? It would be helpful for you to post the entire VHDL file.

ISE produces all sorts of warnings about trimming logic and such, but there obviously should not be any errors.

Just a bit more info… I’m using Xilinx ISE 8.2i and I attach my vhdl source code and the map report that I referred to above. I’m able to build the First.vhd and Counters.vhd samples without problems, so I don’t think the problem is my setup or the ISE version. It’s probably something wrong with my code…???


Nick.txt (4.8 KB) (3003 Bytes)


I haven’t been able to find anything wrong with your code. Can you start with First and make small changes until you break it? What change, exactly, causes the build to break?

I did do something similar to what you suggested, if you look in my code you can see the commented line:

– addrOut s internals, so maybe you could file the bug on my behalf?



I took your source code (as-posted) and built a new project. I added okLibrary.vhd to the project and placed the NGC files in the project folder. I then built the project and it completed successfully.

I’m using Project Navigator release 8.2.03i.

Can you try creating a new project and doing this again? I’m not sure what could have gone haywire, but I have seen this behavior with ISE before. Not exactly with the error you indicate, but strange, unrepeatable behavior.

Many thanks, I will do as you suggested. One question, though - what version of FrontPanel are you using? I’ve sent a request to OK support that I be allowed to download FP 3.0, as I started to suspect the “NGC” files might have been compiled with an earlier version of ISE and contain subtle incompatibilities? Could this be an explanation for the behaviour?


When I built your sample, I used FP-1.4.1. The code you provided will not work as-is on FP-3 because some of the pin names have changed on the HDL modules.

Many thanks for your help, I have resolved the problem by installing ISE service pack 3, therefore upgrading my ISE version to 8.2.03i as you are using.

I was a bit of an idiot for not reading the Xilinx webpage properly, which explicitly states that you must always install the latest service pack. For example the recent 9.1i release comes with a service pack, even though both were only released in January 2007.

If I hadn’t been such a VHDL novice I might have picked up this error, but as it was, I assumed there must be something wrong with my code. Thanks again.


Wow. I’m still surprised that this occurred with ISE – even without the service pack. I would think that simple synthesis problems are all part of their routine regression tests.

Anyway, glad you’re up and running again!