Porting from Xilinx to Altera

[Altera_Forum]

Hi everybody, 

 we just started with a new project which will use an Cyclone III. We ant to reuse as much of our previous code which was done for Xilinx FPGA. Most file are quite genric, but some contain components from xilinx library. We would replace this part with using if generate constructs, depending on FPGA types, but there is still the unisim library declaration at the top of the file.  As anybody had any expirience with that ? i thought about making a dummy unisim library which conatins the used components, to be able to actually compile the code. Is that the right approach ?

[Altera_Forum]

VHDL libraries are added via the tool(i.e. the VHDL says the name of the library but the Quartus .qsf or ISE file specifies what file to read in that has the library.) One idea might be to make an empty UNISIM library and add that to the Quartus project. Since nothing is neeeded out of it, it should work out all right. (I haven't tried it, but think it would work.)

[Altera_Forum]

It may be useful to add wrappers to Altera MegaFunctions for some UNISIM components, e.g. RAM-blocks, if they are frequently used in your design. See http://www.alteraforum.com/forum/showthread.php?t=1167

[Altera_Forum]

Hi 

 I've just started pretty well the same process as well. I am interested in knowing is there a datasheet for all the Altera "design elements" (ie Xilinx has DCM's, BRAMS etc etc) I have looked at the MegaWizard which seems to contain these sorts of things, but no datasheets seem to be avail...   Also is there an equivalent to the unisim library? With Xilinx you would just do:    library unisim; use unisim.vcomponents.all;   and would be able to instantiate any of the Xilinx design elements. I have found the altera_mf and seem to have successfully instantiated the alt_shift_taps into my design   library altera_mf; use work.altera_mf_components.all;   but I'm not confident that this is how Altera intended. Do you have to go through the MegaWizard and create all the components by hand? And if so then what happens when the next version of Quartus comes out and subtle changes are made to the design elements?? Do you have to do them all again??   Thanks

[Altera_Forum]

I would suggest using the MegaWizard, and using the recommended flow of just instantiating the created file(I've seen people use the Megawizard to create something like a PLL, then rip the primitive instantiation out of the megafunction and put it into their file. This is ugly because it creates something that can't be re-edited/analyzed/updated with the megawizard, and usually has a bunch of parameters the user starts mucking with yet doesn't understand them). 

My experience is that a lot of Xilinx designers use the low-level primitives and Altera designers use the high-level megafunctions(which in many cases, like a PLL or altsyncram, aren't that high-level). You could probably get a good message board of people going back and forth on it. I don't like the Xilinx methodology because you often end up spending too much time figuring out low-level parameters or ports to do a high-level function, and the final instantiation doesn't make any sense to a casual observer(where a megafunction can be re-opened and is usually pretty clear.) That being said, there are times when you want to know the low-level details and have trouble figuring it out in the megafunction. The Xilinx DSP blocks are a good case, where I've seen people basically put in op-codes to do something like a multiply-add. There was no way to figure out what it was doing without going to the datasheet and finding this op-code, so for the general case it was painful. But for someone who is changing those op-codes on the fly and doing some funky stuff with it, it was pretty cool. You'll also find Altera's low-leve primitive documentation isn't the best, while their megafunctions are usually quite good(and Xilinx tends to be the opposite, although I haven't looked in a while, and there are always cases that these aren't true). Altera's documentation is more the device handbook, which describes the PLL, the DSP block, the memory blocks, etc., and then the megafunctions are used to access those blocks.  Anyway, that's just my feeling, but hope it helps. (Not sure if I really answered your question rather than wax philosophical...)

[Altera_Forum]

Hi Rysc 

 Thanks for your response. I found the user guides section on the web, which is what I was looking for - has info on mem, pll etc so possibly my documentation needs have been forfilled.   I created a PLL through the megawizard and was happy to find that the resulting VHD file was referencing the altera_mf in the same way that I did it manually. The problem that I currently face in using the megawizard is that I have to use it each time I want to ie: create a PLL with a different mult/div ratio, as I cant bring those generics out of the wrapper entity. I would rather have one PLL file that has some flexiblilty rather than multiple 'dedicated' PLL's. I think I really only need to convert the DCM's and the BRAMs across as the rest is just VHDL. I'll probably use the megawizard output as a reference and then make my custom file, bringing out the generics that I want to keep flexible, plus maybe add a few comments to attempt to keep the confusion to a minimum :)

[Altera_Forum]

I believe you can run the megawizard as an executable(i.e. batch file) to create many variations, but I don't know much about it, and would be surprised at how straightforward it is. In general, when building a design, I'm fine with this method since you're really only creating a PLL at a time, it has a specific function, and it's nice to have access to all the menus to decide what you do and do not need. But when doing a bulk conversion, it can be cumbersome(especially when converting from an X design, where only one DCM primitive was used and you passed in parameters, so what you're doing makes sense.)

[Altera_Forum]

--- Quote Start ---  I have looked at the MegaWizard which seems to contain these sorts of things, but no datasheets seem to be avail...  --- Quote End ---  Basically wrong. There are detailed user guides for nearly all MegaFunctions, and the Megawizard has as link to it ("documentatcomponents ion on the web").  P.S.: Regarding manual instantiation of MegaFunctions respectively altera_mf components in HDL. I'm doing this often, for various reasons. The said user guides are providing complete interface and parameter information, so you are able to without ever starting the MegaWizard. But it's convenient to let the MegaWizard generate a template.   Rysc is also correct, that manual instantiation isn't compatible with maintaining the components through the MegaWizard. So if you intend to later edit it by the Wizard for some reason, you should avoid editing the components manually.  With simple components, e.g. RAM, but also basic PLLs, I prefer the manual method to have a full, readable HDL implementation of all project parts. It also allows to parameterize the components from generics or project wide constants, a feature not available with MegaWizard generated components.   Additional, sometimes the MegaWizard doesn't allow parameter settings that are basically meaningful but haven't been considered in the MegaWizard code.

[Altera_Forum]

Hi, 

 Not sure if you have seen this attached document. But I have found this to be very useful as well when I was migrating from Xilinx to Altera(not design reuse though).  Good Luck Binu

[Altera_Forum]

Will check it out, thanks

[Altera_Forum]

If this is in vhdl or verilog, I wouldn't try to wrap the altera libraries with xilinx stuff. Just put it under a revision control system like git or hg, check in your initial xilinx commit, and then rip the stuff out if you don't plan on going back to xilinx any time soon. The start in earnest on your new Altera stuff. Take this as a good opportunity to separate your xilinx/altera proprietary stuff in to nice libraries that you can easily include or uninclude in the future rather than mixing and matching your generic code with proprietary code.

[Altera_Forum]

I made dummy libraries from Xilinx and Altera stuff (unisim, altera_mf) containing the components declaration. If we can now compile our design on both plattform, during synthesis if just load the dummy xlinx lib in quartus, and it won't complain that it can't find unisim lib.

[Altera_Forum]

--- Quote Start ---  I made dummy libraries from Xilinx and Altera stuff (unisim, altera_mf) containing the components declaration. If we can now compile our design on both plattform, during synthesis if just load the dummy xlinx lib in quartus, and it won't complain that it can't find unisim lib.  --- Quote End ---    Would You ( or somene else ) please share dummy library from Xilinx (unisim )?  What if I will just comment out that line "use UNISIM.VComponents.all;" ? After commenting out that line everywhere it appeared Quartus compiled the project OK. Does this simple "use UNISIM.VComponents.all;" removal makes the same effect as using dummy library?

[Altera_Forum]

--- Quote Start ---  Would You ( or somene else ) please share dummy library from Xilinx (unisim )?  What if I will just comment out that line "use UNISIM.VComponents.all;" ? After commenting out that line everywhere it appeared Quartus compiled the project OK. Does this simple "use UNISIM.VComponents.all;" removal makes the same effect as using dummy library?  --- Quote End ---    No, I can't. Just take the unisim file from xilinx (it's called unisim.vhd or so), copy it somewhere, and remove all non component declaration. It took me an hour to so to do.