Webpack 6.1, ISEexamples, and CoreGen

[glen herrmannsfeldt]

Getting back to FPGA's after some years (Xact 6 days),
I downloaded the Webpack 6.1, and the ISE6 in depth tutorial.

Following along, everything seems fine, except when it
asks me to use CoreGen. After looking for a while it seems,
according to Xilinx web site, that CoreGen is not included
in the free version.

It would be nice if the tutorial explained that, but I
found the already generated files in the watchver directory,
so I could continue.

I am trying to do a "proof of concept" for a new design,
somewhat based on the previous one. If it works, the
company that will actually build it will have the full version,
but I don't have that. I am not sure yet if I will need
CoreGen or not.

One question now. Does CoreGen allow user supplied cores,
or only Xilinx supplied ones? For Xact, I used RPM's,
macros hand designed using the cell editor, and substituted
at place and route time for dummy cells in the verilog code.
Other than that, the most complicated logic block is a
RAM or ROM, though I don't know if I can do that without
CoreGen.

It would be nice if at least simple CoreGen cores were
included in the free version.

-- glen

 

[John_H]

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.


"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:NOvqc.113406$Ik.9242773@attbi_s53...

Getting back to FPGA's after some years (Xact 6 days),
I downloaded the Webpack 6.1, and the ISE6 in depth tutorial.

Following along, everything seems fine, except when it
asks me to use CoreGen. After looking for a while it seems,
according to Xilinx web site, that CoreGen is not included
in the free version.

It would be nice if the tutorial explained that, but I
found the already generated files in the watchver directory,
so I could continue.

I am trying to do a "proof of concept" for a new design,
somewhat based on the previous one. If it works, the
company that will actually build it will have the full version,
but I don't have that. I am not sure yet if I will need
CoreGen or not.

One question now. Does CoreGen allow user supplied cores,
or only Xilinx supplied ones? For Xact, I used RPM's,
macros hand designed using the cell editor, and substituted
at place and route time for dummy cells in the verilog code.
Other than that, the most complicated logic block is a
RAM or ROM, though I don't know if I can do that without
CoreGen.

It would be nice if at least simple CoreGen cores were
included in the free version.

-- glen

 

[glen herrmannsfeldt]

John_H wrote:

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

 

[Ray Andraka]

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:

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

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

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

 

[glen herrmannsfeldt]

Ray Andraka wrote:

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).

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

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.

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.

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.

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.

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.

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

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.
(snip)
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.

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

 

[Ray Andraka]

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 ray@andraka.com
http://www.andraka.com

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

 

[Gabor Szakacs]

"John_H" <johnhandwork@mail.com> wrote in message news:<K3wqc.13$zR5.205@news-west.eli.net>...

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.

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.