On Wed, 23 Sep 2015 00:58:28 -0400, rickman wrote:> 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.That sounds like John Larkin. After some bad experiences he claimed that it was nigh on impossible to interface to AXI. By comparison, I wrote a shim to convert AXI to our in-house soft SoC bus in an afternoon. Worked first time and is in our Zynq products to this day. I cheated and used the ARM AXI documentation rather than the Xilinx AXI documentation though. Allan
Digital Power Control
Started by ●September 21, 2015
Reply by ●September 23, 20152015-09-23
Reply by ●September 23, 20152015-09-23
On 9/23/2015 9:24 AM, Allan Herriman wrote:> On Wed, 23 Sep 2015 00:58:28 -0400, rickman wrote: > >> 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. > > That sounds like John Larkin. After some bad experiences he claimed that > it was nigh on impossible to interface to AXI. > By comparison, I wrote a shim to convert AXI to our in-house soft SoC bus > in an afternoon. Worked first time and is in our Zynq products to this > day. > I cheated and used the ARM AXI documentation rather than the Xilinx AXI > documentation though.Yes, that was JL. I seem to recall his complaint was either the docs or the tools, but not the interface itself, but I'm not entirely certain. I just thought it was funny how he raved about what great products the chip and board were but how worthless the tool was as if you could separate them in a meaningful way. That is one of the problems with complex devices. You have to like every aspect of a very complex device and development environment. -- Rick
Reply by ●September 23, 20152015-09-23
On Tue, 22 Sep 2015 13:56:57 -0400, rickman wrote:> On 9/22/2015 1:46 PM, 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. > > Saving area is only useful if you *use* the IP.No, saving area is only useful if it makes the chip less expensive or (assuming I care) consume less power. If 10 peripherals, together, are smaller and less expensive than the generic fabric I need to implement the one I actually use, then I don't give a crap about the unused 9 -- I'll just chortle happily every time I review the BOM. If I'm trying to minimize power consumption and the one peripheral I use takes 1/3 the power (I'm just inventing numbers in my head here, BTW) that I'd need to implement it in the fabric, then I may be willing to pay _more_ for the chip, even. So, I disagree.> Adding a CPU pays a > large dividend and would be a selection criterion for buying that chip. > Adding an SPI interface would pay relatively little compared to a soft > IP module and very unlikely to be a factor in selecting that FPGA. The > other reason to use hard IP is if the performance improvement is > significant. I'm not certain, but Gb Ethernet might be hard to do in > soft IP. I2C not so much.I suspect that either the chips that are so rich in peripherals are a Bad Idea, or they're going into a market that is known to use most of them. Time will tell.> All of that is aside from the issues being discussed elsewhere in this > thread. A pair of ARM A9s and Ethernet interface are not needed for a > motor controller while the analog peripherals are.Well, yes. You can implement whatever digital bits you want to in the fabric, but AFAIK you can't implement a decent ADC in the usual FPGA fabric. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●September 23, 20152015-09-23
On 9/23/2015 1:42 PM, Tim Wescott wrote:> On Tue, 22 Sep 2015 13:56:57 -0400, rickman wrote: > >> On 9/22/2015 1:46 PM, 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. >> >> Saving area is only useful if you *use* the IP. > > No, saving area is only useful if it makes the chip less expensive or > (assuming I care) consume less power. If 10 peripherals, together, are > smaller and less expensive than the generic fabric I need to implement > the one I actually use, then I don't give a crap about the unused 9 -- > I'll just chortle happily every time I review the BOM.What does the BOM have to do with it? None of this will add any parts or is at all likely to require a larger part. If this was the guiding principle to adding hard IP, there would be a lot more hard IP on a lot more FPGAs.> If I'm trying to > minimize power consumption and the one peripheral I use takes 1/3 the > power (I'm just inventing numbers in my head here, BTW) that I'd need to > implement it in the fabric, then I may be willing to pay _more_ for the > chip, even. > > So, I disagree.Trouble is all your numbers are made up and it assumes that all designs using that FPGA will use *any* of the added hard IP.>> Adding a CPU pays a >> large dividend and would be a selection criterion for buying that chip. >> Adding an SPI interface would pay relatively little compared to a soft >> IP module and very unlikely to be a factor in selecting that FPGA. The >> other reason to use hard IP is if the performance improvement is >> significant. I'm not certain, but Gb Ethernet might be hard to do in >> soft IP. I2C not so much. > > I suspect that either the chips that are so rich in peripherals are a Bad > Idea, or they're going into a market that is known to use most of them. > Time will tell.I think someone else mentioned what might be the real reason that IP is there, so the CPU can boot up fully useful without requiring the FPGA fabric to be loaded. That takes time. Not much compared to booting Linux, but certainly a lot more than just booting the CPU.>> All of that is aside from the issues being discussed elsewhere in this >> thread. A pair of ARM A9s and Ethernet interface are not needed for a >> motor controller while the analog peripherals are. > > Well, yes. You can implement whatever digital bits you want to in the > fabric, but AFAIK you can't implement a decent ADC in the usual FPGA > fabric.Not totally true. It depends on your definition of "decent". Most ADCs are largely digital anyway. FPGAs come with differential I/Os which can work as a comparator so no added parts needed. -- Rick
Reply by ●September 23, 20152015-09-23
On Wed, 23 Sep 2015 14:18:15 -0400, rickman wrote:> On 9/23/2015 1:42 PM, Tim Wescott wrote: >> On Tue, 22 Sep 2015 13:56:57 -0400, rickman wrote: >> >>> On 9/22/2015 1:46 PM, 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. >>> >>> Saving area is only useful if you *use* the IP. >> >> No, saving area is only useful if it makes the chip less expensive or >> (assuming I care) consume less power. If 10 peripherals, together, are >> smaller and less expensive than the generic fabric I need to implement >> the one I actually use, then I don't give a crap about the unused 9 -- >> I'll just chortle happily every time I review the BOM. > > What does the BOM have to do with it? None of this will add any parts > or is at all likely to require a larger part. If this was the guiding > principle to adding hard IP, there would be a lot more hard IP on a lot > more FPGAs.Man, if I said "what does the BOM have to do with it" to a customer for whom I was designing a board, I would only have myself to blame if they hung up on me and expunged me from their files. BOM "has to do with it" because BOM cost matters. It just does.>> If I'm trying to minimize power consumption and the one peripheral I >> use takes 1/3 the power (I'm just inventing numbers in my head here, >> BTW) that I'd need to implement it in the fabric, then I may be willing >> to pay _more_ for the chip, even. >> >> So, I disagree. > > Trouble is all your numbers are made up and it assumes that all designs > using that FPGA will use *any* of the added hard IP.Well, yes, my numbers are made up, for illustrative purposes. I'm assuming that -- being an engineer -- you know how to get the gist of what I'm saying without getting hung up on the specific numbers. My point is made even if not all designs using an FPGA use any of the added IP. If Xilinx can make one chip with added hard IP for cheaper than it can make two chips, one with the added IP and one without, and if it passes that savings on to its customers, then the people who use the chips without ever turning on the hard IP benefit from having a chip to use in the first place. Since you don't want me to use made-up numbers, I'll just use inequalities. If X > Y > Z represent three dollar amounts, would you Xilinx sold chip x (with hard IP that you don't have to use) and chip y (without), at costs X and Y, or would you rather Xilinx sold only chip x at cost Z, or would you rather pay a premium for chip y so that you can use it without offending your sensibilities? -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●September 23, 20152015-09-23
On 9/23/2015 2:50 PM, Tim Wescott wrote:> On Wed, 23 Sep 2015 14:18:15 -0400, rickman wrote: > >> On 9/23/2015 1:42 PM, Tim Wescott wrote: >>> On Tue, 22 Sep 2015 13:56:57 -0400, rickman wrote: >>> >>>> On 9/22/2015 1:46 PM, 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. >>>> >>>> Saving area is only useful if you *use* the IP. >>> >>> No, saving area is only useful if it makes the chip less expensive or >>> (assuming I care) consume less power. If 10 peripherals, together, are >>> smaller and less expensive than the generic fabric I need to implement >>> the one I actually use, then I don't give a crap about the unused 9 -- >>> I'll just chortle happily every time I review the BOM. >> >> What does the BOM have to do with it? None of this will add any parts >> or is at all likely to require a larger part. If this was the guiding >> principle to adding hard IP, there would be a lot more hard IP on a lot >> more FPGAs. > > Man, if I said "what does the BOM have to do with it" to a customer for > whom I was designing a board, I would only have myself to blame if they > hung up on me and expunged me from their files. > > BOM "has to do with it" because BOM cost matters. It just does.Ok, this conversation is going off to loony land. Customer deaths are also important, but have nothing to do with the issue being discussed.>>> If I'm trying to minimize power consumption and the one peripheral I >>> use takes 1/3 the power (I'm just inventing numbers in my head here, >>> BTW) that I'd need to implement it in the fabric, then I may be willing >>> to pay _more_ for the chip, even. >>> >>> So, I disagree. >> >> Trouble is all your numbers are made up and it assumes that all designs >> using that FPGA will use *any* of the added hard IP. > > Well, yes, my numbers are made up, for illustrative purposes. I'm > assuming that -- being an engineer -- you know how to get the gist of > what I'm saying without getting hung up on the specific numbers. > > My point is made even if not all designs using an FPGA use any of the > added IP. If Xilinx can make one chip with added hard IP for cheaper > than it can make two chips, one with the added IP and one without, and if > it passes that savings on to its customers, then the people who use the > chips without ever turning on the hard IP benefit from having a chip to > use in the first place.IF.... you are making assumptions about all of this.> Since you don't want me to use made-up numbers, I'll just use > inequalities. If X > Y > Z represent three dollar amounts, would you > Xilinx sold chip x (with hard IP that you don't have to use) and chip y > (without), at costs X and Y, or would you rather Xilinx sold only chip x > at cost Z, or would you rather pay a premium for chip y so that you can > use it without offending your sensibilities?Why does Xilinx sell more than one chip then? -- Rick
Reply by ●September 23, 20152015-09-23
On 9/23/2015 2:50 PM, Tim Wescott wrote:> On Wed, 23 Sep 2015 14:18:15 -0400, rickman wrote: > >> On 9/23/2015 1:42 PM, Tim Wescott wrote: >>> On Tue, 22 Sep 2015 13:56:57 -0400, rickman wrote: >>> >>>> On 9/22/2015 1:46 PM, 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. >>>> >>>> Saving area is only useful if you *use* the IP. >>> >>> No, saving area is only useful if it makes the chip less expensive or >>> (assuming I care) consume less power. If 10 peripherals, together, are >>> smaller and less expensive than the generic fabric I need to implement >>> the one I actually use, then I don't give a crap about the unused 9 -- >>> I'll just chortle happily every time I review the BOM. >> >> What does the BOM have to do with it? None of this will add any parts >> or is at all likely to require a larger part. If this was the guiding >> principle to adding hard IP, there would be a lot more hard IP on a lot >> more FPGAs. > > Man, if I said "what does the BOM have to do with it" to a customer for > whom I was designing a board, I would only have myself to blame if they > hung up on me and expunged me from their files. > > BOM "has to do with it" because BOM cost matters. It just does. > >>> If I'm trying to minimize power consumption and the one peripheral I >>> use takes 1/3 the power (I'm just inventing numbers in my head here, >>> BTW) that I'd need to implement it in the fabric, then I may be willing >>> to pay _more_ for the chip, even. >>> >>> So, I disagree. >> >> Trouble is all your numbers are made up and it assumes that all designs >> using that FPGA will use *any* of the added hard IP. > > Well, yes, my numbers are made up, for illustrative purposes. I'm > assuming that -- being an engineer -- you know how to get the gist of > what I'm saying without getting hung up on the specific numbers. > > My point is made even if not all designs using an FPGA use any of the > added IP. If Xilinx can make one chip with added hard IP for cheaper > than it can make two chips, one with the added IP and one without, and if > it passes that savings on to its customers, then the people who use the > chips without ever turning on the hard IP benefit from having a chip to > use in the first place. > > Since you don't want me to use made-up numbers, I'll just use > inequalities. If X > Y > Z represent three dollar amounts, would you > Xilinx sold chip x (with hard IP that you don't have to use) and chip y > (without), at costs X and Y, or would you rather Xilinx sold only chip x > at cost Z, or would you rather pay a premium for chip y so that you can > use it without offending your sensibilities?Actually this is not the comparison. If chip Y is cheaper than chip X and also cheaper than chip Z, then offer the SPI, I2C, etc as soft IP and be done with it. Quit making stuff up! -- Rick
Reply by ●September 23, 20152015-09-23
On Tuesday, September 22, 2015 at 6:51:30 AM UTC+12, 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? > > -- > Rob Gaddi, Highland Technology -- www.highlandtechnology.com > Email address domain is currently out of order. See above to fix.I think you need FPGAs. You will always have nano seconds latency since your code executes serially.
Reply by ●September 23, 20152015-09-23
On Wed, 23 Sep 2015 14:28:52 -0700, gyansorova wrote:> On Tuesday, September 22, 2015 at 6:51:30 AM UTC+12, 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? >> >> -- >> Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email >> address domain is currently out of order. See above to fix. > > I think you need FPGAs. You will always have nano seconds latency since > your code executes serially.Rob mentions elsewhere that he's looking at a 1MHz sampling rate and a 20us ramp from zero to full-on. I think that could be done if you could get your control-law computations done in less than sampling interval. That means something on the order of 100 clocks if you want to do other stuff, and 200 if you don't -- so it's pretty freaking tight, but it may be doable. Using an FPGA would, certainly, ease things, but if you need to do other stuff you'd need to have a processor somewhere. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●September 23, 20152015-09-23
On 9/23/15 5:40 PM, Tim Wescott wrote:> On Wed, 23 Sep 2015 14:28:52 -0700, gyansorova wrote: > >> On Tuesday, September 22, 2015 at 6:51:30 AM UTC+12, 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? >>> >>> -- >>> Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email >>> address domain is currently out of order. See above to fix. >> >> I think you need FPGAs. You will always have nano seconds latency since >> your code executes serially. > > Rob mentions elsewhere that he's looking at a 1MHz sampling ratecan someone explain why or what the device is that draws power from some DSP-controlled power source (say PWM or PDM, which seems to me to be about the same as sigma-delta) that needs a sample rate of 1MHz?> and a 20us ramp from zero to full-on.i fail to see why that ramp needs to be sampled 20 times from zero to rails. i admit that i am outa my element, but i'm having trouble visualizing this. what power controller needs such a spec? what's it powering? is it step response envelope delay? -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
