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

antonkurka said:

This is clearly an error in my version ISE14.7

Click to expand...

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.

barry said:

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.

Click to expand...

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

barry said:

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.

Click to expand...

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.

antonkurka said:

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 ---

Click to expand...

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.

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?

FvM said:

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?

Click to expand...

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

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.

FvM said:

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.

Click to expand...

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

FvM said:

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.

Click to expand...

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

FvM said:

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.

Click to expand...

For demonstration test mulFP with ND and RFD and simulation

FvM said:

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.

Click to expand...

not RFD , of course RDY