Webpack 6.1, ISEexamples, and CoreGen

The Coregen tool - in my humble opinion - is generally a dummies guide to the Xilinx Library primitives. I find that instantiating my own memories, DCMs and the such are much better done by reading up on the primitives and doing a manual instantiation.

You shouldn't need Coregen - which currently only produces Xilinx-specific modules if I recall correctly - to do a proof of concept for the design.

The design is pretty specifically Xilinx, so I am not so sure about that, yet.

If I can manually get to the library primitives, that should be enough. I haven't reached that point in the manual yet.

Can I make my own primitives, like RPMs in Xact? That is more important.

-- glen

The biggest problems with coregen are that they don't let you see under the hood, and there isn't really a way for you to put your own IP into it. For memories and other primitives, you are better off just instantiating the primitive out of the unisims library. I think unisims were new in XACT-6, so you may vaguely remember them. They replaced the old primitive library. Where coregen has value is in more complex macros like various DSP cores....that is if you can live with what they give you (you can't get under the hood to see how they work or make changes to them).

The terminology is a little bit wrong. The primitives are the basic components that have a 1:1 mapping to things on the die. You can use primitives to build macros, which I believe you are calling your own primitives. If you include placement on the primitives in a macro, you can make it into an RPM (relatively placed macro). The RLOCs are still there, although changed somewhat in format from what you knew in xact 6. RLOCs are in xy form rather than RC form, but are more or less the same idea. You can put RLOCs on primitives instantiated in an HDL, VHDL works a little better for this because you can easily put RLOCs that depend on a loop variable on a generated macro. It is still very awkward to do that with Verilog even with the verilog2000 extensions. I use RPMs generated by parameterized VHDL extensively. You can see floorplans for some of my designs on the gallery page of my website. That said, you don't necessarily have to use RLOCs on primitives. You can also floorplan (although it is on the flat design in these cases) using the floorplanner tool or using text in a .ucf constraints file. The floorplanner will look familiar if you used the one in XACT6. There are some newer features (relative to XACT 6) like area groups that you may find useful. One thing you may find frustrating is that in XACT6, if you gave it a good placement you got a good route, and you'd get pretty much the same routing solution everytime you ran it, even after incremental changes. The router in the ISE6 tool doesn't work the same way. Instead, it starts off with a seemingly random route and only moves routes if they violate timing or are in the way of another route. It stops running as soon as all routes meet timing without doing any kind of clean-up. This is perhaps fine for slow designs, but if you are floorplanning you are probably trying to milk the maximum performance you can get. With this routing strategy, you'll find that essentially all the routes in the design are critical routes, and short connections are often routed in a not so direct manner. It is apparently the price for faster time to completion.

glen herrmannsfeldt wrote:

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

if

Those I don't need, so I should be safe.

Well, things like adders. Well, with XACT6 I had RPM's for a saturating adder (If the result would be less than zero the output would be zero). That was easy to do in XC4000, as there is one more input to the CLB's than needed for the adder logic. I could sense underflow from the carry chain and signal all the CLBs to output zero. The other one is MAX(a,b), where the carry chain was used to detect which was greater, and the CLB to select the appropriate input. As I understand it, the logic is different now so I will have to look through the manual and see how to do those.

It seems that counters are generated by CoreGen, so I thought adders might also be.

I never needed RLOCs. The design was full of 16 bit adders and

16 bit max, which had to follow the carry chain. There weren't many places to put them.

do

by

I did mine in LCAedit, I think that is what it was called.

use

(snip) > The router in the ISE6 tool doesn't work the same way. > Instead, it starts off with a

performance

routed

In the design before, I was trying to maximize the number of unit cells multiplied by the clock frequency. Because of the way P&R did it, it turned out to be much faster with three units (in an XC4013) than four, even though four fit just fine.

The first thing I will work on is to see how well the previous logic works in the new FPGAs. (The design is a linear systolic array processor.)

thanks for the hints,

-- glen

Glen,

First off, what is your entry method? An HDL?

You can use the adders and other small macros in coregen, but I wouldn't. If you don't need placement, let synthesis infer these, but check on the results to make sure you aren't getting two levels of logic. Synthesis has come a long way in the past 5 or so years. Used to be tht you had to do considerable 'pushing on a rope' to get the adder structure right. Now, it has gotten much better at recognizing and inferring the structure. Watch out for add followed by a mux though, tht one still occasionally trips up the synthesizer.

You are correct, the structure has changed, and you don't get to use the carry chain in isolation like you could with the 4000 stuff. The 4000 has the carry chain in front of the LUT which let you use the carry chain as a compare and then use the LUT as a mux. The virtex architecture has the carry chain after the LUT, and you need the LUT to connect into the carry chain, so you cannot use the two separately. There are some cute things you can do with the DI input to the carry mux, but the fact that the carry mux select is controlled by the LUT is limiting when you try to do other than straight forward arithmetic.

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

COREgen actually contains some very useful items that are far from primitives. I use the FIFO's all the time and they work. It is a great way to implement simpler functions, too. When I work in Schematic entry I find it saves time over generating simple bus functions by placing a lot of individual primitives. Using HDL's this is less useful, but even then it can be more convenient for things like memories of odd bit widths that require multiple RAM components or ROM functions when you want to initialise them from a .coe file.

There are other high level functions like distributed arithmetic FIR filters that come with the ISE tools, and of course theres all the IP listed on the Xilinx website under "IP Center" listed as "LogiCORE" or "AllianceCORE" which require COREgen to customise.

Of course you can make all these functions without COREgen if you like to roll your own, but in many cases it saves time and effort to use COREgen.