Core Generators...

To assist the designer who doesn't have the time/resources/experience/etc. to develop a core on their own. An example might be a DDR memory controller (there are many others).

Things like #1 that only work with Xilinx devices. All of the suppliers have their own stuff that is functionally identical (or nearly so) and yet tied to their devices.

For the designer, one advantage is that they can possibly get a design completed sooner than if they had to start from nothing.

For the supplier, one advantage is that they've locked in a customer to their devices.

There are other advantages and disadvantages that others will likely chime in with. As a general guide, skill in hooking up cores is less valuable on the resume than being able to produce cores and hook them up.

KJ

The big advantage of using the core generator is to get a logic function that is difficult to infer in a language like VHDL or difficult to attain the required performance. The last statement is very general and refers to someone of average knowledge using VHDL versus Core Generator. There are companies and people who specialise in targetted VHDL, like ourselves, where with some expert knowledge can "guide" the synthesis tool into a preferred result by the style of writting. Usually this targetted VHDL is also used with place and route constraints to achieve well above average results and can do better than the core generator tool in many cases.

So short statement is to use core generatot tools to achieve a result quickly for a given FPGA vendor and device family but do be aware that you may need to have a different implementation for a different device family or FPGA vendor.

John Adair Enterpo>

ller

on

I use them only for PLLs for which there is no HDL template.

If I use synthesis, the primitives are irrelevant.

None, if working vhdl code is available or I know how to write it.

The biggest *dis*advantage is that the simulation model is a primitive netlist instead of human-readable synthesis code.

-- Mike Treseler

Or which is easy to infer in a language like VHDL, but for which the synthesis tools don't support particularly well.

A recent case here was a 256-element lookup table, inferred as a constant array initialised via a function call (which called other functions to create the data, and others to manipulate it into fixed point format, round it, etc) A bit convoluted but too fast to see in Modelsim..

ISE 7.1 inferred three BlockRams where one would do; Webpack 9.2 improved on that (to two BlockRams).

But the interesting thing was the execution time. 544 seconds on ISE

7.1; yes, over nine minutes. There is something n^2 in its handling of initialisation functions. I added an assert for each value calculated; just to reassure me it was doing something. The first few "flashed" past at several per second; by the end, each value gnerated as taking over five seconds.

A 512 element LUT "just for a laugh" took almost exactly four times as long.

But surely, given years of continuous improvement, Webpack 9.2 can't take 9 minutes to do this? No it can't; it takes over twice as long.

Amazing.

(I ended up copying the "init" generics from the post-synth netlist and instantiating the BRAMS)

- Brian

For that kind of a task, I prefer to write C code that directly generates a VHDL package file with a constant array. I find it a lot easier to code and debug (and change), and the level of C knowledge required is not very high.

I avoid C wherever possible, though unfortunately it isn't always possible. If I had to do this again, I would also generate a package, but using VHDL.

As far as simulation was concerned, it worked beautifully; and changes were undoubtedly easier than dropping into C to re-create the package; and adding package output from VHDL would be easy.

There are limits to escaping from low-level hardware generation to higher level behavioural design creation; but mostly they are not inherent in the language, and they are slowly being pushed further back. This was partly an experiment to find out how far they have been pushed; not very far yet, unfortunately.

- Brian

Keep in mind though that those limits are most likely vendor dependent. I've used functions that manipulate reals to initialize constant arrays to produce lookup tables without any problems with vendor A...using vendor X or Syn, I'm still generating service requests to fix other deficiencies in their tool that breeze right through with A. Doesn't help you if you're commited to vendor X, but if you're not, it might.

KJ

Good to know; I expect the third party ($$$) tools are also better. Meanwhile, I expect we just have to keep up the pressure, via webcases or whatever.

This is certainly not the only way in which XST falls behind.

- Brian

Which Syn is that... "plify" or "opsys"? I assume the former, given this is an FPGA newsgroup, but...

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Synplify

KJ