Problem with real data type

I am using using the Xilinx project navigator Version 6.2i for writing the VHDL code and synthesize it .I am facing a problem with the signals defined with the real data type.The navigator indicates that the code (with some signals defined as real ) is syntactically correct but it gives an error during synthesis.It states this feature is not supported. After checkin out for a solution we ended up finding that a math_real package in ieee.std_logic_1164.all is copyright protected.So actually am unable to understand wat to do to get teh package.

Reply to
Hrishi
Loading thread data ...

I am using using the Xilinx project navigator Version 6.2i for writing the VHDL code and synthesize it .I am facing a problem with the signals defined with the real data type.The navigator indicates that the code (with some signals defined as real ) is syntactically correct but it gives an error during synthesis.It states this feature is not supported. After checkin out for a solution we ended up finding that a math_real package in ieee.std_logic_1164.all is copyright protected.So actually am unable to understand wat to do to get teh package.

Reply to
Hrishi

And how do you think it should work? VHDL is a hardware description language, not a programming language. More likely than not your problem can be solved in fixed-point arithmetic. If it can't then you need to create some sort of a floating-point hardware in your FPGA to work with real numbers. This topic was discussed here in the past. Google the group for floating point...

/Mikhail

Reply to
MM

"Real" is not supported for synthesis. As simple as that. There is a floating point logi core available that you can use instead.

Kolja Sulimma

Reply to
comp.arch.fpga

Well, it could work exactly as for integers. Alle the real operators have well defined single cycle implementations that could be instantiated by the high level synthesis. This would be very easy to support as a synthesis tool vendor.

The reason why it is not implemented is, that single cycle floating point operations are rarely a good design point. If next to all users want a different implementation anyway there is not much point in supporting it. OTOH chips are getting bigger and multi cycle floating point with a throughput of one result per cycle are not uncommon. High level synthesis could try to gather enough flip-flops by retiming to instantiate an operator with a higher latency.

I at least find it strange that so much progress is happening in SystemC and other high level synthesis languages while at the same time the VHDL synthesis vendors stick to the same language subset that synopsis defined eons ago.

XST even discourages the use of arrays and records, for gods sake. This is not the 90s anymore.

Kolja Sulimma

Reply to
comp.arch.fpga

Hrishi posted: "[..]I am facing a problem with the signals defined with the real data type.The navigator indicates that the code (with some signals defined as real ) is syntactically correct but it gives an error during synthesis.It states this feature is not supported."

This is because typically by default synthesis tools will not compile numbers with non-zero vulgar fractions because the amount of hardware which would be needed would be much more for whole numbers.

If you are certain that you are willing to sacrifice so much hardware, then you could use something like

formatting link
(I have not used this and you can expect commercial alternatives to be better) for synthesis.

" After checkin out for a solution we ended up finding that a math_real package in ieee.std_logic_1164.all is copyright protected.[..]"

The reason ISE does not synthesize this is not because of the copyright of the package you have tried.

Reply to
Colin Paul Gloster

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.