On 10/09/2013 11:21 AM, Sharad Sinha wrote: > Hi Jim, > > I guess that brings up the question if the package itself has been > verified and validated carefully and if so what are its limitations in > terms of accuracy of results and whether they have been quantified. > The associated documentation says: "These algorithms are not > exhaustively debugged....use at your own risk..". > Did this two ways. First, I checked various numbers, then I ran a loop of random numbers. > Besides, I am not sure why I would want to validate a hardware > implementation of these functions if I am using pre-verified > implementations of these in my overall design which is generally the > case in complex designs. I understand that if I do an implementation > of my own, then I would like to verify it. But do I really need to > verify my implementation this way? If verification is indeed an > objective of including such packages, then the documentation should be > more rigorous with more insight into how the package code works. > Basically, all of the functions in this package call out "real" functions. Since most of the REAL type functions actually call out the C (from math.h) versions of these functions, I don't see an issue with functionality. > The reason I am a bit picky about such parts of packages like these > is that it makes me feel that probably VHDL equivalent packages of > BLAS, LINPACK etc. would be better. Of course based on how packages > are being proposed now, it is possible that we can have packages for > statistical calculations and likewise. > I like to think of it as "math.h" for fixed and floating point. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Oct 9 08:46:33 2013
This archive was generated by hypermail 2.1.8 : Wed Oct 09 2013 - 08:46:34 PDT