Thanks for the suggestions.

As Brian pointed out, in simple cases it _could be feasible_ to crawl

all possible combinations to get a truth table a_in =to> b_out.

That's not what Brian said at all. He said you can use reals to

compute constants that, in the end, vanish in the resulting function

output.

But in more complex cases the result might be too complex to fit in to

the target (or to optimize the truth table).

Such as what? Your example is not such an example if that's what you

had in mind. For starters, the comparison with 0 is not needed, the

input is unsigned, therefore could never be less than 0. Second,

rather than taking the input and multiplying by 1.2 and comparing that

to 65535.0, one could instead compare r with the computed constant

65535.0 / 1.2 converted to an unsigned. That is what Brian general

case suggestion would be for your specific example by the way.

There may indeed be more complex examples as you stated, but give an

example of such that cannot be trivially changed to be equivalent as

is the case with your original posting.

Anyway I still don't know/understand why the synthesizer companies

have opted out from supporting "discrete input =to> discrete output

mapping, even if there are non-trivial intermediate phased".

Most likely because there is little market demand from users. Even

real constants didn't use to be supported. Now (and for the past

several years) they are. Given a compelling reason the synthesis

vendors do support user requests although usually not nearly as fast

as some might like.

If you can come up with a compelling use case then you should submit

it to all the vendors as a feature suggestion. However, you would

have to do better than your example where the only motivation you

could provide is that you don't like the looks of "65535.0 / 1.2" as

compared to "r * 1.2".

I could easily make a vhdl to vhdl preprosessor to crawl through all

possible input combinations and to produce truth table from input to

output.

OK. And then compare what you get with that approach versus computing

the constant as suggested here. The metrics of importance to most

people would be amount of logic resources used and performance. If

your approach is an improvement you're on to something. If not, maybe

the synthesis vendors aren't doing such a bad job after all.

Wonder what the synthesizers would think, if e.g. I would replace 8 x

8 multiplier by 65536 entry table. Would it utilize DSP-block (in

FPGA) to implement the function?

I would find it highly unlikely that any synthesis tool would take a

truth table specification in the source code and infer a multiply

operation from it and then use a DSP block to implement the

multiply...not to say that it couldn't, I would just be very surprised

if it did.

Kevin Jennings