Synthesisable Fixed/Floating points in VHDL's IEEE Library - vhdl

I'm creating a VHDL project (Xilinx ISE for Spartan-6) that will be required to use decimal "real-style" numbers in either fixed/floating point (I'm hoping fixed point will be sufficient).
Being quite new to VHDL, I found out the hard way that the non-constant real types are not supported for synthesis, so I set about searching for a IP core or library to redress this.
So far I've found 3 options;
1) A floating point IP core provided by Xilinx
2) A downloadable "ieee_proposed" library written by a David Bishop found here
3) After spending a fair while attempting to work out how to "create" a new library with David Bishops files in, I took a quick look through the default IEEE library and saw it contains ieee.fixed_generic_pkg and ieee.fixed_pkg packages.
My question is - of the two libraries - which one would be sensible to use? Is one adapted for synthesis and one not, or one older than the other? And then if floating point is provided, is there any real point to the floating point IP core provided by Xilinx?
I've trawled through many questions of people attempting to add the ieee_proposed libraries, but none seem to have referenced the fact they they already seem to exist in the existing IEEE.
Thanks very much for any help!
============UPDATE (Essentially my own efforts to resolve)==================
I can't actually use the ieee.fixed_pkg - and attempting to do so gives me the error Cannot find <fixed_pkg> in library <ieee>.
After finding the ieee library at C:\Xilinx\14.7\ISE_DS\ISE\vhdl\xst\nt I've found that the fixed_pkg actually resides in ieee_proposed. However, this still throws up the same errors!

Dumb question, but when you downloaded the ieee_proposed did you also remember to compile it?
edit: And also remember to map the library to you simulation as well. Maybe you did all this already but these are the mistakes I make often.

I've been battling with the same problems for days.
The way I solved it is:
1. Add fixed_float_types_c, fixed_pkg_c and float_pkg_c vhdl files to project.
2. Declare them as belonging to work library (Properties in Quartus files window)
3. Compile project and call library using:
Library work;
use work.fixed_pkg.all;
To my annoyance, they don't come up in the nice red writing I want them to but it works!

Related

Including ComplexExpr and ComplexFunc classes in Halide API

The ComplexExpr and ComplexFunc classes in the links below seem very convenient to work with complex numbers. Is there a plan to include them into the official Halide API? Or is there a reason why they are not included?
https://github.com/halide/Halide/blob/master/apps/fft/complex.h
https://github.com/halide/Halide/blob/be1269b15f4ba8b83df5fa0ef1ae507017fe1a69/apps/fft/funct.h
Speaking as a Halide developer...
Or is there a reason why they are not included?
We haven't included these historically since we didn't want to bless a particular representation for complex numbers. There are a few valid ways of dealing with them and the headers in question are just one.
Is there a plan to include them into the official Halide API?
We've started talking about packaging some of this type of code into a set of header-only "Halide tools" libraries, so named to avoid the normative implication of calling it something like "stdlib". So as of right now, there is no concrete plan, but the odds are nonzero.
In the meantime, the code is MIT licensed, so you should feel free to use those files, regardless.

C++ library: .hpp + .inl (separate definitions and declarations) vs .hpp only (in-class body code)

I'm rewriting my Windows C++ Native Library (an ongoing effort since 2002) with public release in mind. For the past 10 years I've been the sole beneficiary of those 150+ KLOC and I feel others might find good uses for it also.
Currently the entire library is quite-templated and header only. That means all code is in the body of the classes. It's not very easy to manage but it's OK.
I'm VERY tempted, after reading several C++ library coding guidelines, to break it into .hpp + .inl files. Experimentally done so for a few classes and it does increase readability and makes it easier for others to deal with. I know where everything is at any given time. But other users might want to a quick overview of a classes declaration... and the definition only if necessary (debugging).
QUESTION:
What are the pros/cons of splitting the member definitions from the class' definition for a class template? Is there a commonly accepted practice.
This is important for me because it's a one way road. I can't refactor it the other way later on so any feedback matters...
I've found my answer in another question.
Question: When should I consider making a library header-only? - and answer is here^.
And the answer is I will break it into .cpp and .hpp files and make it ready to compiler both as header only and static library or DLL.
#Steve Jessop:
If you think your non-template library could be header-only, consider dividing it into two files anyway, then providing a third file that includes both the .h and the .cpp (with an include guard).
Then anyone who uses your library in a lot of different TUs, and suspects that this might be costing a lot of compile time, can easily make the change to test it.
^ this is an awesome idea. It will take a bit more work but it's SO versatile.
UPDATE
It's important to explicitly instantiate^ the templated classes in the .cpp files.

On the use of of Internal`Bag, and any official documentation?

(Mathematica version: 8.0.4)
lst = Names["Internal`*"];
Length[lst]
Pick[lst, StringMatchQ[lst, "*Bag*"]]
gives
293
{"Internal`Bag", "Internal`BagLength", "Internal`BagPart", "Internal`StuffBag"}
The Mathematica guidebook for programming By Michael Trott, page 494 says on the Internal context
"But similar to Experimental` context, no guarantee exists that the behavior and syntax of the functions will still be available in later versions of Mathematica"
Also, here is a mention of Bag functions:
Implementing a Quadtree in Mathematica
But since I've seen number of Mathematica experts here suggest Internal`Bag functions and use them themselves, I am assuming it would be sort of safe to use them in actual code? and if so, I have the following question:
Where can I find a more official description of these functions (the API, etc..) like one finds in documenation center? There is nothing now about them now
??Internal`Bag
Internal`Bag
Attributes[Internal`Bag]={Protected}
If I am to start using them, I find it hard to learn about new functions by just looking at some examples and trial and error to see what they do. I wonder if someone here might have a more complete and self contained document on the use of these, describe the API and such more than what is out there already or a link to such place.
The Internal context is exactly what its name says: Meant for internal use by Wolfram developers.
This means, among other things, the following things hold about anything you might find in there:
You most likely won't be able to find any official documentation on it, as it's not meant to be used by the public.
It's not necessarily as robust about invalid arguments. (Crashing the kernel can easily happen on some of them.)
The API may change without notice.
The function may disappear completely without notice.
Now, in practice some of them may be reasonably stable, but I would strongly advise you to steer away from them. Using undocumented APIs can easily leave you in for a lot of pain and a nasty surprise in the future.

Load package in Scheme48, how to get first, word variable, etc

I just installed the scheme48 package from macports and have started experiencing. I was watching this youtube video, link here and was attempting to perform some of the examples. In the lecture the professor is running scheme on a Sun terminal. For example, I attempt to do '(first 473)' and get 'Error: undefined variable first'. Now, I'm assuming I haven't loaded the correct package / library or what ever it is called in scheme but am not sure what the syntax and library is. I believe that scheme48 and the scheme version on that sun terminal in the video are not the same and could be part of the problem.
So, what library do I need to use and how do I load it?
Those lecture notes are based on a book called Simply Scheme, and you can find the library code that is used in the book here. Specifically, you need simply.scm.
(But whether it is a good idea to have these kind of overloading functions is debatable. Specifically, note that first is used in a way that is different from many other languages.)

In What Windows Library is glCreateProgramObjectARB Defined?

I'm trying to do some shader programming on windows. All the code I've been able to find online says you have to use wglGetProcAddress to figure out where these functions are, but i'm not sure what library to link against.
Ben Voigt's answer is nearly correct, with two exceptions:
All OpenGL 1.0 and 1.1 functionality is inlcuded in opengl32.lib, only 1.3 and upwards and all extension must be loaded dynamically.
WGL guarantees that all contexts sharing the same pixel format share identical function pointers. This is an important detail, as otherwise any application using either OpenGL 3.x/4.x or multisampling would necessarily be malformed.
However, in short, forget all this blah blah. Download GLEW and be done in 5 minutes. It just works and you need not care about petty implementation details. Call one init function at program start, and everything is good.
You link against opengl32.lib to get wglGetProcAddress. All the rest must be dynamically obtained via wglGetProcAddress after you have made a context current, since different contexts can use different implementations of the various functions.
An extension loader such as GLee or GLEW can do the function-pointer details for you, but you still need to be linking opengl32.lib.

Resources