Return to Question

The design is no longer insane. I am not sure what happened, however. I made a lot of changes in order to implement new algorithms. One contributing factor was a 'ROM' of 111 15-bit elements. This consumed a modest number of macrocells but a lot of product terms - nearly all of those available on the xc2c64a. I look for this but had not noticed it. I believe my error was hidden by optimization. The 'levers' I'm talking about are used to select values from the ROM. I hypothesize that when I implemented the (busted) 1-bit priority encoder, ISE optimized away some of the ROM. That would be quite a trick, but it's the only think I can think of. This optimization reduced the resource usage markedly and lulled me into expecting a certain base-line. When I fixed the priority encoder (as per this thread,) I saw the overhead of the priority encoder and the ROM that had previously been optimized away and attributed this to the former exclusively.

The design is no longer insane. I am not sure what happened, however. I made a lot of changes in order to implement new algorithms. One contributing factor was a 'ROM' of 111 15-bit elements. This consumed a modest number of macrocells but a lot of product terms - nearly all of those available on the xc2c64a. I look for this but had not noticed it. I believe my error was hidden by optimization. The 'levers' I'm talking about are used to select values from the ROM. I hypothesize that when I implemented the (busted) 1-bit priority encoder, ISE optimized away some of the ROM. That would be quite a trick, but it's the only explanation I can think of. This optimization reduced the resource usage markedly and lulled me into expecting a certain base-line. When I fixed the priority encoder (as per this thread,) I saw the overhead of the priority encoder and the ROM that had previously been optimized away and attributed this to the former exclusively.

Final Edit

The design is no longer insane. I am not sure what happened, however. I made a lot of changes in order to implement new algorithms. One contributing factor was a 'ROM' of 111 15-bit elements. This consumed a modest number of macrocells but a lot of product terms - nearly all of those available on the xc2c64a. I look for this but had not noticed it. I believe my error was hidden by optimization. The 'levers' I'm talking about are used to select values from the ROM. I hypothesize that when I implemented the (busted) 1-bit priority encoder, ISE optimized away some of the ROM. That would be quite a trick, but it's the only think I can think of. This optimization reduced the resource usage markedly and lulled me into expecting a certain base-line. When I fixed the priority encoder (as per this thread,) I saw the overhead of the priority encoder and the ROM that had previously been optimized away and attributed this to the former exclusively.

After all this, I was good on macrocells but had depleted my product terms. Half of the ROM was a luxury, really, as it was just the 2's comp of the first half. I removed the negative values, replacing them elsewhere them with a simple calculation. This allowed me to trade macrocells for product terms.

For now, this thing fits into the xc2c64a; I've used 81% and 84% of my macrocells and product terms respectively. Of course, now I have to test it to ensure it does what I want...

Thanks to ThePhoton and Michael Karas for the assist. In addition to the moral support they lent to help me solve this, I've learned from the Xilinx document ThePhoton posted, and I implemented the priority encoder suggest by Michael.

EDIT 3 -

I made a new schematic including only the mux that @thePhoton recommended. Synthesis produced insignificant resource usage. I also synthesized the module recommended by @Michael Karas. This also produced insignificant usage. So some sanity is prevailing.

Clearly, my use of the lever values is causing consternation. More To Come.