Error in ISE14.7 IP-coregen(61) FloatingPoint components

[antonkurka]

Hi
After I discovered errors in my project when
using IP-Coregen(6.1) FloatingPoint components, I have a very simple test for just floating point multiplication.

: TestOutp = InpA * InpB

after compilation, the entire multiplication block was removed in the MAP report.

Loadless block "cmulFP1/blk00000001/blk00000024" (XOR) removed.
The signal "cmulFP1/blk00000001/blk0000001c/sig0000017b" is sourceless and has been removed.
The signal "cmulFP1/blk00000001/blk0000001c/sig0000017c" is sourceless and has been removed.
The signal "cmulFP1/blk00000001/blk0000001c/sig0000017d" is sourceless and has
... etc

see attachment
...
This is clearly an error in my version ISE14.7
My tool: ISE 14.7(nt) version P.20131013
Is there a newer/older ISE version in which this error does not occur in IP-Coregen.

Porting to Vivado is out of the question because the IP components are completely different and would therefore require very large changes in my project

Pleace can You help me, I don't know where to look any further.

 

[barry]

This is clearly an error in my version ISE14.7

That's a pretty bold statement. if you know for sure that the problem is in ISE, then how can anyone besides Xilinx/AMD fix it?
This is a 13 year old project. Are you saying it hasnt worked in 13 years? Or it used to work but now it doesnt? Its not clear whats going in here.

 

[antonkurka]

That's a pretty bold statement. if you know for sure that the problem is in ISE, then how can anyone besides Xilinx/AMD fix it?
This is a 13 year old project. Are you saying it hasnt worked in 13 years? Or it used to work but now it doesnt? Its not clear whats going in here.

yes, this is a very old, unfinished project that I'm trying to finish again. Do you want to help me or just criticize?

--- Updated Sep 7, 2024 ---

That's a pretty bold statement. if you know for sure that the problem is in ISE, then how can anyone besides Xilinx/AMD fix it?
This is a 13 year old project. Are you saying it hasnt worked in 13 years? Or it used to work but now it doesnt? Its not clear whats going in here.

Another explanation: The project (from 2016) that I am trying to finish contains a module (runAngle: inverse transformation calculation) with a total of
55 implementations of IP-coregen(6.1) Floating Point Components(FP:add,sub,mul,Div,sqrt).
This calculation runs correctly in the simulation (modelsim).
As there were a lot of errors and warnings during the compilation, I created a very simple test with just one FP multiplication.
This was compiled without errors, but in the map the block mulFP1 is removed (IP multiplication component) with
the corresponding explanation => "Loadless block" which is definitely not the case in this case (the result of the mulFP1 goes directly to the entity output).
I did not find any errors in the test program, but I am happy to be corrected.

 

[barry]

yes, this is a very old, unfinished project that I'm trying to finish again. Do you want to help me or just criticize?

--- Updated Sep 7, 2024 ---

There was no criticism in my answer, I WAS trying to help you by asking questions that would clarify the problem.
Your attitude sucks.
I’m suspicious of your use of the variable cntrclk in state “2”. I’d try changing it to a signal instead.
But your attitude still sucks.

 

[FvM]

I reviewed DS335 (coregen 13.1), it seems to me that your mulFP instantiation is missing essential signal OPERATION_ND. Also RDY should be used to register result output. CE is clock enable and not suited to start operation, usually it's permanently enabled. It could be that OPERATION_ND is also permanently enabled and result sampled with fixed latency, but we don't know if it's supported by your IP. Can you provide a data sheet/manual of coregen 6.1?

 

[antonkurka]

I reviewed DS335 (coregen 13.1), it seems to me that your mulFP instantiation is missing essential signal OPERATION_ND. Also RDY should be used to register result output. CE is clock enable and not suited to start operation, usually it's permanently enabled. It could be that OPERATION_ND is also permanently enabled and result sampled with fixed latency, but we don't know if it's supported by your IP. Can you provide a data sheet/manual of coregen 6.1?

Thank you very much for the tips, but the ND and RDY signals were possible with COREGEN version 5.0
They are no longer available with Coregen version 6.1.
With version 6.1 there is only the signal Tvalid for each input (see attachment), I think the CE1(=Tvalid A and B) is active for 2 clk
, that should be enough for the set latency of 1.
Another question:
As I understand it, you are using the ISE 13.1 version. Have you ever used the IP-Coregen Floating Point components
and did it work?
Greetings Anton

 

[FvM]

I didn't understand at first sight that you are using recent FP IP with AXI-4 interface and ce is mapped to AXI datavalid.

The state machine is unlikely to work with AXI, input data valid doesn't need to be asserted for more than one clock cycle, result has to sampled according to result valid signal. Reason for discarding mulFP in compilation isn't clear, agree with barry about better not using variable for registered state info.

I don't think that mulFP has different interface in Vivado, it should be AXI-4 as well.

 

[antonkurka]

I didn't understand at first sight that you are using recent FP IP with AXI-4 interface and ce is mapped to AXI datavalid.

The state machine is unlikely to work with AXI, input data valid doesn't need to be asserted for more than one clock cycle, result has to sampled according to result valid signal. Reason for discarding mulFP in compilation isn't clear, agree with barry about better not using variable for registered state info.

I don't think that mulFP has different interface in Vivado, it should be AXI-4 as well.

Thank you for the answer.
That was an attempt with IP version 6.1, which is possible in ISE14.7, but it didn't help.
I would rather stick with IP version 5.0 but
when I use it in ISE14.7, I get the following warning during the simulation:
...
# ** Warning: (vsim-8683) Uninitialized out port /testbnch/UUT/cfuncmul/U0/FP_OP/EXCEPTION has no driver.
# This port will contribute value (U) to the signal network.
...
and that means, that it will be removed later during compilation.
I don't understand why this warning comes up because the result goes directly to Entity OUT atanFPo, so does it have a "driver"?
I also tried to copy the result from mulFP to signal TestOutput and then in the last state
to Entity Out atanFPo, and the same warning came up here too.
Should I try to install an earlier ISE version, e.g. 14.1??.
Regards Anton

--- Updated Sep 8, 2024 ---

I didn't understand at first sight that you are using recent FP IP with AXI-4 interface and ce is mapped to AXI datavalid.

The state machine is unlikely to work with AXI, input data valid doesn't need to be asserted for more than one clock cycle, result has to sampled according to result valid signal. Reason for discarding mulFP in compilation isn't clear, agree with barry about better not using variable for registered state info.

I don't think that mulFP has different interface in Vivado, it should be AXI-4 as well.

forgot this:
I also tried using IP component mulFP(5.0) with operation_nd as suggested but that didn't help either

 

[antonkurka]

I didn't understand at first sight that you are using recent FP IP with AXI-4 interface and ce is mapped to AXI datavalid.

The state machine is unlikely to work with AXI, input data valid doesn't need to be asserted for more than one clock cycle, result has to sampled according to result valid signal. Reason for discarding mulFP in compilation isn't clear, agree with barry about better not using variable for registered state info.

I don't think that mulFP has different interface in Vivado, it should be AXI-4 as well.

For demonstration test mulFP with ND and RFD and simulation

--- Updated Sep 8, 2024 ---

I didn't understand at first sight that you are using recent FP IP with AXI-4 interface and ce is mapped to AXI datavalid.

The state machine is unlikely to work with AXI, input data valid doesn't need to be asserted for more than one clock cycle, result has to sampled according to result valid signal. Reason for discarding mulFP in compilation isn't clear, agree with barry about better not using variable for registered state info.

I don't think that mulFP has different interface in Vivado, it should be AXI-4 as well.

not RFD , of course RDY