strange behaviour of square root VHDL code

[Altera_Forum]

I need a plain VHDL-square root code for a special purpose and used "google code search".  

 I thus found the following code in their files, obviously written by Altera. http://www.google.com/codesearch/p?hl=de#twz1piy0-yo/trunk/fpc/mathlib/fp_sqrroot.vhd&q=fp_sqrroot%20lang:vhdl&sa=n&cd=1&ct=rc  (Also try "fp_sqrroot lang:vhdl" in google's search box.)   I tried to simulate it and found weird results shown in the attached graphics.  It seems to be a problem of the bit "N-1". I tried with 40bits and 52 bits as well.  As soon as this bit is "1" the output behaves like a root function - optically prooved. But if the bit is 0 with lower radicants, the output appears inverted like "x - root()".:confused:   Could someone pleae explain this behaviour??  I think there is a bug in the code or something is missing since e.g. the signal "onevec" is declared and also set but never used.  Any ideas?  Is that an Altera Code?  I have also the files themselves attached, to make it easier ti simulate it.

[Altera_Forum]

I have no idea. 

 Why dont you try the floating point square root core in the mega-core libraries provided with quartus?

[Altera_Forum]

Float is not acceptable because I have to be bit true and quick. 

 I know the Altera MF SqareRoot and used it more than once in projects. In fact I am very happy about this core because it gave my sqr results after only a few clocks fully pipelined also with the slow and small Cyclone devices.  But this time, I need fully portable code in plain VHDL whichs run everywhere and does not use vendor specific MegaFunctions or "CoreGen"s - even if I started with an Altera Implementation  I wouldn't even had asked this in the Altera Forum, if the code did not prentend to come from Altera. Altera might be interested if the code is really wrong, I think. :cool:   So the question is: What is there about the unused signal? Does this show, that the code is incompletely reported ?  It compiles and synthesizes and obviously shows square root behaviour, even if I am not fully sure about the bit slice to use as output at the moment.  What does the tag "restored" in the title mean?  I attached another screenshot with the generic 52 bit output and added the an swapped graph done with image manipulation. This leads to a perfect root.

[Altera_Forum]

My Appologies, I assumed you were talking about floating point. 

 The best thing to do may be to look into the floating point algorithm and use the new fixed point libraries from IEEE.   VHDL '93 compatible version available from http://www.vhdl.org/fphdl/ This does NOT contain a square root function, but tracking the integer/fractional bits is now SOOO much easier.  This code can be compiled by any compiler. And when all vendors catch up with the new VHDL 2008 standard, it will all be built in.

[Altera_Forum]

Thanks I will have a look at it. In the meanwhile I will correct the partial error manually, i think.

[Altera_Forum]

I think I saw an algorithm somewhere that would map well to an integer/fixed point square root. Basically you pull out all the powers of 2 of the input value until you get it down to larger than 0 and less than 4. Then you could use a lookup table to take care of the rest (you are not using floating point so I'm guessing accuracy doesn't matter to you). Really the lookup table makes more sense for fixed point or if you want to do some rounding of an integer answer. Some people use this method for floating point square roots only they use something a bit more accurate than a lookup table at the end.

[Altera_Forum]

An interesting solution: http://http://vhdlguru.blogspot.com/2010/03/vhdl-function-for-finding-square-root.html (http://http://vhdlguru.blogspot.com/2010/03/vhdl-function-for-finding-square-root.html) 

It synthesizes into a combinatorial function which will run quite slow (44 ns tpd on a Stratix II C3 speed grade) but pipelining it should be reasonably straightforward.

[Altera_Forum]

Thanks very much so far. The above mentioned code seems to be similar, I will investigate this. :) 

 In the meanwhile, I am correcting the error manually. It is tricky because of the delay but works: I am just switching the outut appropriately.  I really would like to understand, where this comes from. It is only the Bit N-1 causing an inverted calculation. I think there is somehow an overflow with the signed/unsigned during one of the substractions, causing parts of the algorithm to work in the "wrong direction". I tried to change the bits intuitively to find the reason, but was not able to figure it out, however.  A big german beer at the forthcoming octoberfest in munich is waiting for the man, explaining me this issue :-)

[Altera_Forum]

allthough the code works, I'd like to return to this. Can it be that I interpret the code in a wrong way? What are the higher bits intended to indicate? Is it only a sign? 

 I is because I see, that some bits are suppressed during code synthesis.:confused: