Digital Power Control

On Tue, 22 Sep 2015 18:29:29 -0400, Randy Yates wrote:

> Tim Wescott <seemywebsite@myfooter.really> writes:
>> [...]
>> This is starting to sound like we're designing either a lab queen, or a
>> system that can only ever be used by one person.
> 
> What's a "lab queen?"

That's a system that works just grand in the lab, but never seems to 
function properly in the field, or when it's been put together by 
manufacturing personnel.

Queen of the lab -- and only the lab.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Rob Gaddi <rgaddi@technologyhighland.invalid> writes:
> [...]
> The C2000s came to mind because they've got 150ps high-resolution PWMs 

Rob,

I've been trying to make some sense of all these fancy ideas you guys
have been volleying about. I wound up going to the TI site and reading
the actually datasheets, specifically SPRUG77B on their "high-resolution
pulse width modulator" in the Delfino series (TMS320x2834x).

A little "reverse calculation" of their Table 1 there yields a
T_{SYSCLK} of about 62ps. Is this the parameter you are referring to
above with 150ps?

If so it looks like these HRPWMs are a bit better.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

Tim Wescott <seemywebsite@myfooter.really> writes:

> On Tue, 22 Sep 2015 18:29:29 -0400, Randy Yates wrote:
>
>> Tim Wescott <seemywebsite@myfooter.really> writes:
>>> [...]
>>> This is starting to sound like we're designing either a lab queen, or a
>>> system that can only ever be used by one person.
>> 
>> What's a "lab queen?"
>
> That's a system that works just grand in the lab, but never seems to 
> function properly in the field, or when it's been put together by 
> manufacturing personnel.
>
> Queen of the lab -- and only the lab.

Ha! 
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

Randy Yates <yates@digitalsignallabs.com> writes:

> Rob Gaddi <rgaddi@technologyhighland.invalid> writes:
>> [...]
>> The C2000s came to mind because they've got 150ps high-resolution PWMs 
>
> Rob,
>
> I've been trying to make some sense of all these fancy ideas you guys
> have been volleying about. I wound up going to the TI site and reading
> the actually datasheets, specifically SPRUG77B on their "high-resolution
> pulse width modulator" in the Delfino series (TMS320x2834x).
>
> A little "reverse calculation" of their Table 1 there yields a
> T_{SYSCLK} of about 62ps. Is this the parameter you are referring to
> above with 150ps?
>
> If so it looks like these HRPWMs are a bit better.

PS: I noticed in snooping around their site that the CLAs are now up 
to 200 MHz instead of the older 150 MHz ones. I haven't double-checked,
but I believe these have direct access to the ADCs and PWMs, so they
would be just tits for your app, it seems. 

When I was contracting for TI we were using a related processor to do
some demodulation. We needed to decimate a complex data stream coming in
at 2 M samples/sec and I did some on-paper-only coding and MIPS
estimates, but I never actually got to write the code.

--Foaming at the mouth to write some CLA code like this

-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

Den tirsdag den 22. september 2015 kl. 19.09.43 UTC+2 skrev Rob Gaddi:
> On Tue, 22 Sep 2015 10:33:20 -0400, rickman wrote:
> 
> > To date, the two large FPGA companies are sticking to the path that got
> > them where they are, catering to the large comms companies needs which
> > is bigger, faster FPGAs.  There is a lot more margin at the high end
> > than at the low end.  Motor control would definitely be the low end.
> > Someone has already complained about FPGA prices in this thread.
> > 
> > There is nothing stopping FPGAs from being built like MCUs with all
> > manner of accessories built in.  But the big guys aren't going to do it.
> >   The new market for FPGAs is in very high volume handheld devices.  The
> > new push is to low end FPGAs in very small packages and price will be a
> > major issue.  So far there aren't many pushing in that direction.  The
> > processes are still digital.  But once they broach this market more they
> > will be more inclined to break out of their mold and explore more
> > innovative areas like motor control with analog subsystems.
> 
> Actually, both X and A have SoC offerings now that integrate ARM Cortex 
> A9s with a mess of peripherals alongside the fabric.
> 
> I'm actually really surprised at the balance they struck; they both 
> decided to put a LOT of hard IP in.  Gb Ethneret MAC, DRAM controller, 
> all that stuff makes sense to me to harden.  But they're also putting 
> SPI, I2C, counter/timers, all the sort of stuff that seems like it would 
> be just as easily implemented on the fabric.  Beats me what the logic was.
> 

the learned from the past and made it an MCU with an FPGA, instead of an FPGA with a CPU

With a Zynq you can boot up a standard linux to DDR RAM from an SD card, 
have gigabit ethernet, mac from SPI eeprom, RTC on I2C to keep time 
with out even touching the programmable logic, and once you get to the 
logic you concentrate one that.  

if it didn't have all the hard ip, you'd be dead in the water until you have figured out the huge task of getting all the stuff into logic and working 


-Lasse

On 9/22/2015 6:05 PM, Tim Wescott wrote:
> On Tue, 22 Sep 2015 17:42:33 -0400, rickman wrote:
>
>> On 9/22/2015 3:18 PM, Tim Wescott wrote:
>>> On Tue, 22 Sep 2015 14:38:17 -0400, rickman wrote:
>>>
>>>> On 9/22/2015 1:49 PM, Tim Wescott wrote:
>>>>> On Tue, 22 Sep 2015 10:21:35 -0400, rickman wrote:
>>>>>
>>>>>> On 9/21/2015 11:15 PM, Tim Wescott wrote:
>>>>>>> On Mon, 21 Sep 2015 22:55:19 -0400, rickman wrote:
>>>>>>>
>>>>>>>> On 9/21/2015 8:46 PM, boB wrote:
>>>>>>>>> On Mon, 21 Sep 2015 19:10:11 -0400, rickman <gnuarm@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On 9/21/2015 6:38 PM, Rob Gaddi wrote:
>>>>>>>>>>> On Mon, 21 Sep 2015 18:08:34 -0400, robert bristow-johnson
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 9/21/15 4:28 PM, rickman wrote:
>>>>>>>>>>>>> On 9/21/2015 2:49 PM, Rob Gaddi wrote:
>>>>>>>>>>>>>> Got an application coming up for a high-efficiency,
>>>>>>>>>>>>>> multikilowatt polyphase power supply that needs scarily fast
>>>>>>>>>>>>>> responses to external requests. I'm thinking about maybe
>>>>>>>>>>>>>> throwing a C2000 at the problem. It could really simplify
>>>>>>>>>>>>>> keeping my phases in alignment and getting the feedforward
>>>>>>>>>>>>>> through all the paths to match.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> TI sure makes it look easy, almost as if it's their job to
>>>>>>>>>>>>>> do so.
>>>>>>>>>>>>>> Anyone got any stories to share from that war?
>>>>>>>>>>>>>
>>>>>>>>>>>>> How complex are your calculations? I can see using a
>>>>>>>>>>>>> processor if the calculations are lengthy. But if the calcs
>>>>>>>>>>>>> are simple with a demand for speed, I think FPGA. Even if the
>>>>>>>>>>>>> calcs are not so simple, *I* would think FPGA most likely.
>>>>>>>>>>>>> Processors are great, but the inherently sequential nature
>>>>>>>>>>>>> creates problems, mainly when you need to be doing several
>>>>>>>>>>>>> things at one time and have to time share the processor.
>>>>>>>>>>>>>
>>>>>>>>>>>>> One of the things I like about FPGA work is that I can do
>>>>>>>>>>>>> nearly perfect simulation. I hardly ever have any difficult
>>>>>>>>>>>>> problems to debug in the hardware. I find software to be a
>>>>>>>>>>>>> bit harder to test well before heading to the bench.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So would an HDL/FPGA design suit the requirements?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> confession: i never ever designed an FPGA (but i once
>>>>>>>>>>>> developed some note-processing algs that someone else put into
>>>>>>>>>>>> the FPGA) and i have never been paid for anything regarding
>>>>>>>>>>>> control of power.
>>>>>>>>>>>>
>>>>>>>>>>>> how "scarily fast" do you need to be?  i wonder how a
>>>>>>>>>>>> power-control app would need a faster sampling rate than audio
>>>>>>>>>>>> and, if the calculation is complicated (with lotsa
>>>>>>>>>>>> conditionals and math), i wonder how a DSP would not be
>>>>>>>>>>>> adequate.  and i doubt an arduino would suffice.
>>>>>>>>>>>>
>>>>>>>>>>>> it just seems to me that using a development system and a
>>>>>>>>>>>> familiar programming language would be the easiest and most
>>>>>>>>>>>> cost-effective way to do it.
>>>>>>>>>>>
>>>>>>>>>>> Scary fast is 20 us 0 to fullscale, which means having to keep
>>>>>>>>>>> the inductances fairly low, which means having to get the
>>>>>>>>>>> switching frequency in the 1 MHz ballpark.  It ain't RF, but by
>>>>>>>>>>> power supply standards it's a lift, and will put me north of
>>>>>>>>>>> 10A/us.
>>>>>>>>>>>
>>>>>>>>>>> I think the calculations should be borderline trivial; probably
>>>>>>>>>>> nothing more than a stupid PID on the PWM duty cycles along
>>>>>>>>>>> with some bounding logic to slam the duty to 0 or 100% when I
>>>>>>>>>>> need to slew hard without winding up any integrators.
>>>>>>>>>>>
>>>>>>>>>>> The C2000s came to mind because they've got 150ps
>>>>>>>>>>> high-resolution PWMs and some multi-Msps, low-latency ADCs
>>>>>>>>>>> built in.  I've never tried programming them before; and I'm
>>>>>>>>>>> definitely more comfortable writing VHDL these days.  But those
>>>>>>>>>>> fancy PWMs are really tempting;
>>>>>>>>>>> even if you run an FPGA core clock of 500 MHz and DDR the
>>>>>>>>>>> outputs you've STILL got only 1 part per thousand PWM control.
>>>>>>>>>>> Or you do it outboard with DACs and comparators and dedicated
>>>>>>>>>>> gating logic and the BOM explodes.
>>>>>>>>>>
>>>>>>>>>> How do they do the PWM in the C2000s?
>>>>>>>>>>
>>>>>>>>>> I'm not really recommending it, but there is a *very*
>>>>>>>>>> interesting chip with 144 - 700 MIPS peak rate processors, 5
>>>>>>>>>> ADCs, 5 - 9 bit DACs... and low power.  But talk about
>>>>>>>>>> "unfamiliarity", they are programmed natively in something
>>>>>>>>>> similar to Forth.  But it is a very interesting part and control
>>>>>>>>>> is one of the potential apps where it may do well.  I can't
>>>>>>>>>> think of a way to get 150 ps resolution PWM.
>>>>>>>>>
>>>>>>>>> High Resolution PWM is usually done by adding a series of delay
>>>>>>>>> taps and selecting I think, at least for one of the HRPWM endowed
>>>>>>>>> micros I am using works (ST)
>>>>>>>>
>>>>>>>> I think Xilinx used a tapped delay line for part of their clock
>>>>>>>> distribution circuits.
>>>>>>>
>>>>>>> But could they be used to get the necessary clock resolution?
>>>>>>
>>>>>> A PLL might be able to do that.  Adjusting the ratio of the two
>>>>>> dividers would provide a high resolution clock rate.
>>>>>>
>>>>>> I don't think a delay line is used to adjust the clock frequency for
>>>>>> the PWM.  I expect the leading edge of the PWM is controlled from
>>>>>> the clock directly and the trailing edge is controlled by the
>>>>>> delayed clock.  Is this wrong?  I can see where temperature drift
>>>>>> would be a significant factor in making a delay line circuit work
>>>>>> correctly.  The number of steps per clock cycle would change widely.
>>>>>>   When lengthening the pulse width, at what point are the steps
>>>>>> zeroed and the clock count incremented instead?
>>>>>
>>>>> For there to be any point to extending the PWM resolution, you'd need
>>>>> to be able to do it on a cycle-by-cycle basis.  If you're using a
>>>>> PLL,
>>>>> it'd have to come into it's new lock pretty damned fast.
>>>>
>>>> I think that's not what the OP asked for.  The two numbers he provided
>>>> were 1 MHz PWM rate and 20 uS rail to rail changes.  Maybe you can
>>>> extract more useful info from that than I can.  I'm not a motor
>>>> controller designer.  I see it analogous to the spec on a DAC.  An
>>>> input change has a significant change very quickly, but the full
>>>> settling time would be longer to the specified resolution.
>>>
>>> The rule of thumb for control systems is that you want to have at least
>>> ten clocks within the settling time of the loop after it has come out
>>> of nonlinear operation.  20us is 20 clock ticks at 1MHz, so even if the
>>> loop doesn't go nonlinear in the first place you're not out of line to
>>> ask for a 1MHz sample clock.
>>>
>>> If you did use a PLL (and you did mention using a PLL) then it would
>>> need to be fast enough to not contribute much phase shift at 1MHz.
>>
>> On a PLL that is just a matter of the low pass filter.  The design issue
>> is making it stable.
>>
>>
>>>> Besides, what I am describing above is not a PLL at all.  The idea is
>>>> to use a conventional PWM with a fixed clock to set a pulse width and
>>>> a delay line tap to fine tune only the trailing edge of the pulse.  So
>>>> generate a pulse with the PWM and OR it with a version passing through
>>>> the tapped delay line.  Immediate adjustment capability and high
>>>> resolution although the fine adjustment is now subject to temperature
>>>> influences.
>>>>
>>>> A friend designed a similar circuit for the USNO to generate a 1 pps
>>>> signal and provide a time of day display for their latest and greatest
>>>> atomic clock.  It had a 10 &micro;s delay line with 1024 taps to let the 1
>>>> pps be synced to the master 1 pps signal.  I forget the details of how
>>>> it worked actually.  That was more than a couple of years ago.
>>>>
>>>>
>>>>>>>>> I would love to be able to use an FPGA but they are so fricking
>>>>>>>>> expensive compared to a microcontroroller.   CPLDs are fast and
>>>>>>>>> cheap but not enough blocks and the typical FPGA that I see have
>>>>>>>>> more blocks than I need and therefore too expensive.  Would love
>>>>>>>>> to find something in-between.
>>>>>>>>
>>>>>>>> FPGAs are pretty cheap at the low end.  Xilinx has devices under
>>>>>>>> $10 and Lattice has units under $4, maybe a lot less in real
>>>>>>>> quantities.
>>>>>>>> Partly it depends on how much space you need for your design.
>>>>>>>> Lots of them have multipliers or DSP units.
>>>>>>>
>>>>>>> With or without the high-resolution PWM?
>>>>>>
>>>>>> There is no special hardware called "high resolution DWM".  A PLL is
>>>>>> standard on most parts and could be used to provide good resolution
>>>>>> to a PWM by adjusting the clock rate.
>>>>>
>>>>> Fine.  With or without the necessary hardware to implement a PWM
>>>>> controller with less than one clock cycle resolution.
>>>>
>>>> A PLL would work by adjusting the clock to suit the PWM so the term
>>>> "less than one clock cycle resolution" would be a bit hard to
>>>> interpret.
>>>>     It might be problematic if you needed wide, fast swings.  I'm sure
>>>>     you
>>>> can tell me more about that than I can tell you, or perhaps others
>>>> here would know more.
>>>>
>>>> I think it would not be hard to implement a tapped delay line even in
>>>> FPGA fabric.  It may require specific placement control and detailed
>>>> knowledge of the internal organization of the part, but I'm pretty
>>>> sure it can be done.  This level of FPGA usage is not common and often
>>>> discouraged.  It is the equivalent of assembly language programming or
>>>> taking advantage of "tricks" in a higher level language which could be
>>>> hard to port to other processors or tools.  It would be reliable and
>>>> repeatable within the same device and could easily be verified by the
>>>> standard tools such as timing verification or post routing simulation.
>>>
>>> I would be more inclined to say it's like using assembly language to
>>> access some undocumented feature of the processor, even.
>>
>> Not very valid.  The structure and timing of all the components have to
>> be set in stone or *any* design will not continue to work.  So these are
>> not features that can change appreciably, nor are the truly
>> undocumented.  The chip editor shows all the structure and the timing
>> analyzer has all the timing info.
>>
>>
>>> I'd be suspicious as hell if someone presented the idea of using the
>>> FPGA fabric for this purpose.  However, I could see it working if you
>>> had some sort of continual calibration -- perhaps a chain of gates down
>>> which you launch a clock pulse, with each gate's output latched each
>>> clock.  Then you could read how far down the chain the pulse gets and
>>> use that to deduce the speed at that moment and adjust your PWM trim to
>>> match.
>>
>> Your suspicions are not relevant to how well an FPGA design works.  What
>> is important is how well it actually works.  Yes, some calibration would
>> help and should be fairly simple to implement.  Two chains in parallel,
>> one for calibration and the other for signal delay should work.  The
>> physically closer they are, the better matched they will be, but process
>> variation across the chip should be very small and voltage/temperature
>> variation should also be unimportant for anything but a large chip.
>>
>>
>>> This is starting to sound like we're designing either a lab queen, or a
>>> system that can only ever be used by one person.
>>
>> That is not a founded statement.  I think just the opposite, it has more
>> potential as further explored.
>>
>>
>>> Keeping in mind that I'm not an FPGA guy, I wonder if you couldn't
>>> extend a counter by having two sections with two clocks: one is a
>>> traditional counter with a magnitude comparator to generate the "main"
>>> PWM, and the other is just a string of D flip-flops that (I believe)
>>> can be clocked at a faster rate because there's only one gate of delay
>>> between sections.
>>
>> The limitation in the clock rate is not really because of logic.  As
>> someone mentioned 500 MHz is an approximate upper limit for nearly any
>> logic in an FPGA other than perhaps a SERDES which brings up another
>> approach.  But there is nothing to say the output couldn't be a
>> combination of coarse and fine PWMs where each one runs from the same
>> clock, but the fine PWM is given a low weight by an analog summer.  Sort
>> of a combination of PWM and DAC.  That should give as much resolution as
>> you can get from the analog circuit.
>
> I'm not sure what you think is being done, here, but in this sort of
> control circuit the PWM pin is connected to a gate driver which is
> connected to a transistor gate.  The only analog that's happening is
> steering many amps at many volts -- "low level" is not to be found on
> that side of the design.

Yes, I guess I was thinking the PWM was being converted to an analog 
signal at some point.

Still the SERDES approach has merit.  I vaguely remember that being 
mentioned in another thread, but I'm not that familiar with how they 
work.  There may be some sort of encoding added to the digital signal 
rather than it just being a shift register.  If I have time tomorrow 
I'll dig into that, I'm a bit curious now.

-- 

Rick

On 9/22/2015 6:29 PM, Randy Yates wrote:
> Tim Wescott <seemywebsite@myfooter.really> writes:
>> [...]
>> This is starting to sound like we're designing either a lab queen, or a
>> system that can only ever be used by one person.
>
> What's a "lab queen?"

Something that is built to work in the lab but may not work well in 
production.

-- 

Rick

On 9/22/2015 7:46 PM, lasselangwadtchristensen@gmail.com wrote:
> Den tirsdag den 22. september 2015 kl. 19.09.43 UTC+2 skrev Rob Gaddi:
>> On Tue, 22 Sep 2015 10:33:20 -0400, rickman wrote:
>>
>>> To date, the two large FPGA companies are sticking to the path that got
>>> them where they are, catering to the large comms companies needs which
>>> is bigger, faster FPGAs.  There is a lot more margin at the high end
>>> than at the low end.  Motor control would definitely be the low end.
>>> Someone has already complained about FPGA prices in this thread.
>>>
>>> There is nothing stopping FPGAs from being built like MCUs with all
>>> manner of accessories built in.  But the big guys aren't going to do it.
>>>    The new market for FPGAs is in very high volume handheld devices.  The
>>> new push is to low end FPGAs in very small packages and price will be a
>>> major issue.  So far there aren't many pushing in that direction.  The
>>> processes are still digital.  But once they broach this market more they
>>> will be more inclined to break out of their mold and explore more
>>> innovative areas like motor control with analog subsystems.
>>
>> Actually, both X and A have SoC offerings now that integrate ARM Cortex
>> A9s with a mess of peripherals alongside the fabric.
>>
>> I'm actually really surprised at the balance they struck; they both
>> decided to put a LOT of hard IP in.  Gb Ethneret MAC, DRAM controller,
>> all that stuff makes sense to me to harden.  But they're also putting
>> SPI, I2C, counter/timers, all the sort of stuff that seems like it would
>> be just as easily implemented on the fabric.  Beats me what the logic was.
>>
>
> the learned from the past and made it an MCU with an FPGA, instead of an FPGA with a CPU
>
> With a Zynq you can boot up a standard linux to DDR RAM from an SD card,
> have gigabit ethernet, mac from SPI eeprom, RTC on I2C to keep time
> with out even touching the programmable logic, and once you get to the
> logic you concentrate one that.
>
> if it didn't have all the hard ip, you'd be dead in the water until you have figured out the huge task of getting all the stuff into logic and working

Or they could just make it easier to use the programmable logic in 
conjunction with the CPU.  Someone in the s.e.d group swears *at* Xilinx 
for making the Zynq FPGA fabric so hard to access from the ARM.  I've 
never looked at it so I have no opinion on this.  I get the impression 
it is one of those things you only learn about when you actually try to 
use it.

-- 

Rick

On Tue, 22 Sep 2015 14:18:47 -0500, Tim Wescott
<seemywebsite@myfooter.really> wrote:

<snip>

>And -- thank you for spelling "bated" correctly.  I've been inundated 
>with a lot of "baited breaths" and "mute points" and other such spell-
>checkerisms lately.  Reading the Ones that Got It Right is an ongoing 
>relief.

The most popular one, for many years now, seems to be
"loose" instead of "lose", as in "I'm trying not to loose my
cool over grammar issues".  <g>

Best regards,


Bob Masta
 
              DAQARTA  v8.00
   Data AcQuisition And Real-Time Analysis
              www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
 Frequency Counter, Pitch Track, Pitch-to-MIDI 
FREE 8-channel Signal Generator, DaqMusiq generator    
          Science with your sound card!

On Tue, 22 Sep 2015 12:46:40 -0500, Tim Wescott wrote:

> On Tue, 22 Sep 2015 17:07:42 +0000, Rob Gaddi wrote:
> 
>> On Tue, 22 Sep 2015 10:33:20 -0400, rickman wrote:
>> 
>>> To date, the two large FPGA companies are sticking to the path that
>>> got them where they are, catering to the large comms companies needs
>>> which is bigger, faster FPGAs.  There is a lot more margin at the high
>>> end than at the low end.  Motor control would definitely be the low
>>> end. Someone has already complained about FPGA prices in this thread.
>>> 
>>> There is nothing stopping FPGAs from being built like MCUs with all
>>> manner of accessories built in.  But the big guys aren't going to do
>>> it.
>>>   The new market for FPGAs is in very high volume handheld devices.
>>>   The
>>> new push is to low end FPGAs in very small packages and price will be
>>> a major issue.  So far there aren't many pushing in that direction. 
>>> The processes are still digital.  But once they broach this market
>>> more they will be more inclined to break out of their mold and explore
>>> more innovative areas like motor control with analog subsystems.
>> 
>> Actually, both X and A have SoC offerings now that integrate ARM Cortex
>> A9s with a mess of peripherals alongside the fabric.
>> 
>> I'm actually really surprised at the balance they struck; they both
>> decided to put a LOT of hard IP in.  Gb Ethneret MAC, DRAM controller,
>> all that stuff makes sense to me to harden.  But they're also putting
>> SPI, I2C, counter/timers, all the sort of stuff that seems like it
>> would be just as easily implemented on the fabric.  Beats me what the
>> logic was.
> 
> You can implement stuff in much less space (and probably power) if it's
> hard-coded rather than implemented in the FPGA fabric -- that's why
> there's a processor core in there and not just available IP.  The logic
> extends to peripherals: if it's something that's used a lot, then it's
> worthwhile putting in.  I suspect that the area difference is 10:1,
> which would mean (roughly) that if you put in 10 different peripherals
> and each customer used one and let the other 9 lie idle, that you'd
> break even on area and come out ahead on power consumption.

The hard IP will also have bugs that can't be fixed.  Here's the 
impressive errata list for the Xilinx Zynq 7 series (FPGA + Dual ARM ).

http://www.xilinx.com/support/answers/47916.html

Some of the bugs have software workarounds.

Regards,
Allan