Area Optimization

Christopher Head · 2011-06-11T05:54:38+00:00

Hi all,I have a design (written in VHDL) targetting the Spartan 6 series, andit's oversubscribed for LUTs. Can anyone recommend good resources toread? I've already spent a little time looking around the design inISE's schematic viewer, but with tens of thousands of LUTs it's notexactly a fast process going from that angle, and if possible I'drather avoid getting into a lot of explicit instantiation of primitives.I've already read the ISE documentation on how to write expressionsthat the synthesizer can recognize as particular patterns, butunfortunately most of my design is just brute-force combinational logic(a lot of basic boolean operations and additions on fairly wide values)arranged into a pipeline, so the special patterns don't really apply (Idon't have counters, or RAMs, or shift registers, or what have you).This is with ISE 13.1, in case it matters, the most recent AFAIK.I do have the option of moving to a larger chip if necessary, but wouldstrongly prefer not to as the one I'm using is the largest supported byWebPack. I've looked at chips in other families, and WebPack seems totop out at similar LUT counts in all the families.Thanks!Chris

Jun 11, 2011 24 Replies

Rate this thread:

jt_eaton 15 years ago

You can't avoid 100% of all async reset flops but you can easily do the

99.999% where sync will give you a smaller, faster design and your design is still a black box equivalent to using the async reset.

With xilinx parts every flop with an async reset wastes 1 lut over a sync reset. In asic design every async reset flop doubles the number of endpoints needing timing closure from 1 to 2. If you do a really lousy job in designing your reset distribution then these async paths could become critical paths and start taking routing resources away from your other more important paths.

Async resets on flops are nothing but trouble.

John

--------------------------------------- Posted through

formatting link

Vote

glen herrmannsfeldt 15 years ago

(snip)

I thought (at least for some) if you do a global async reset that it used the same reset as for configuration. If you reset from a LUT output, then it needs something different. I am not sure now which family that is for, though.

-- glen

Vote

Christopher Head 15 years ago

After tweaking my pipeline a bit and discovering that even after getting it down to well under 100% LUT utilization, it still utterly fails to PAR, I'm going to reassess the overall algorithm.

Vote

Brian Drummond 15 years ago

At this point, try to PAR with a ridiculously slow target clock. If that works, increase the clock until it fails, and let the timing report tell you which part of the pipeline is failing. Re-engineer that, and repeat...

- Brian

Vote

rickman 15 years ago

Actually you miss the point. There is no 99.999% issue. When you hit the PROGRAM pin, it is an async input and your entire design stops while the chips reconfigures. So any "analog" issues you may have with async reset inputs applies to the PROGRAM pin. Not much you can do but tie it off hard, but according to your description of the problems an async input has this won't address your concerns.

Also, your analysis of the LUT utilization is flawed. There is only a LUT savings in some cases where using the set and/or reset inputs to the FF as sync inputs will save you a LUT. There are plenty of logic cases where this is not true. Heck, there are plenty of cases where no LUTs are used with a FF. So how can you save a LUT then?

Rick

Vote

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required