Anyone else need bigger parts in small (low pin count) packages
in [FPGA]
|
Prev: Programming Digilent Nexys 2 from Linux
Next: Estimating resource utilization of cores (from Xilinx CoreGen)
From: rickman on 2 Jun 2010 18:05 On Jun 2, 5:29 pm, -jg <jim.granvi...(a)gmail.com> wrote: > On Jun 3, 3:59 am, rickman <gnu...(a)gmail.com> wrote: > > > > > The problem with using a small CPLD is that the register set is up to > > 32, 8-bit registers. With a 100 ns address to output time, there is > > little chance of the read being done unless a copy of all registers > > exists in the CPLD. Also, some of the bits to be read are real time > > status bits. If the processor can get an interrupt, read the address > > and write the readback data to the CPLD, then it could work, but it > > has to happen in 100 ns. If they had just used a standard SPI > > interface it would have been a lot easier... > > If this interface is so incompatible with SPI that you need 32 bytes > of local memory, then you are bumped into the 'smallest CPLD with RAM' > territory, - and the choice there is not great. Maybe Actel or > SiliconBlue ? > > I've hit this wall myself, and it raises a point: > > Rather than the uC+CPLD the marketing types are chasing, I would find > a CPLD+RAM more useful, as there are LOTS of uC out there already, and > if they can make 32KB SRAM for sub $1, they should be able to include > it almost for free, in a medium CPLD. > > -jg I won't argue with that for a moment. But deciding what to put in a part and which flavors to offer in what packages is decided in the land of marketing. As much as I whine and complain, I guess I have to assume they know *something* about their jobs. I am just very, very frustrated because my designs always seem to be limited by the available devices. In some areas they produce a thousand variations on a theme, I suppose because it is easy. In other areas, like FPGAs, we are told it is exquisitely expensive to add any additional features and the variations seem to be limited to a small focused range. I haven't looked at SiBlue in quite a while. I wasn't even aware that they were shipping product. I have looked at Actel, but they tend to have the same limitations in combining "more than a CPLD" in CPLD type packages... they just don't have the same top-heavy product line which would make you think they would branch out more at the low end. When I get more free time, I'll take another look at both of these. One more complaint... selection guides are your friend. I wish more companies understood how useful a good, ***simple***, PDF file selection guide can be. We all know what the salient features of PLDs are. It is actually rather easy to put them all in a simple set of tables showing the important aspects including package types and I/O counts. Yet this info can be hard to find on most PLD vendor's web sites. Rick
From: -jg on 2 Jun 2010 19:35 On Jun 3, 10:05 am, rickman <gnu...(a)gmail.com> wrote: > > Rather than the uC+CPLD the marketing types are chasing, I would find > > a CPLD+RAM more useful, as there are LOTS of uC out there already, and > > if they can make 32KB SRAM for sub $1, they should be able to include > > it almost for free, in a medium CPLD. > > > -jg > > I won't argue with that for a moment. But deciding what to put in a > part and which flavors to offer in what packages is decided in the > land of marketing. As much as I whine and complain, I guess I have to > assume they know *something* about their jobs. The product managers are understandably blinkered by what has gone before, and what they sell now, so in the CPLD market it is very rare to see a bold step. The CoolRunner was the last bold step I recall, and that was not made by a traditional vendor product manager, but by some new blood. Altera, Atmel, Lattice and Xilinx have slowed right down on CPLD releases, to almost be in 'run out' mode. -jg
From: rickman on 3 Jun 2010 11:24 On Jun 2, 7:35 pm, -jg <jim.granvi...(a)gmail.com> wrote: > On Jun 3, 10:05 am, rickman <gnu...(a)gmail.com> wrote: > > > > Rather than the uC+CPLD the marketing types are chasing, I would find > > > a CPLD+RAM more useful, as there are LOTS of uC out there already, and > > > if they can make 32KB SRAM for sub $1, they should be able to include > > > it almost for free, in a medium CPLD. > > > > -jg > > > I won't argue with that for a moment. But deciding what to put in a > > part and which flavors to offer in what packages is decided in the > > land of marketing. As much as I whine and complain, I guess I have to > > assume they know *something* about their jobs. > > The product managers are understandably blinkered by what has gone > before, and what they sell now, so in the CPLD market it is very rare > to see a bold step. > > The CoolRunner was the last bold step I recall, and that was not made > by a traditional vendor product manager, but by some new blood. > > Altera, Atmel, Lattice and Xilinx have slowed right down on CPLD > releases, to almost be in 'run out' mode. I've been busy with work the last few months so I tend to forget what I read about trends. I seem to recall that Xilinx has announced something with an MCU in it and not the PPC they used in the past. Do I remember right? Is X coming out with an FPGA with an ARM? Personally, I prefer something other than an ARM inside an FPGA. I want a CPU that executes each instruction in a single clock cycle and has very seriously low interrupt latency. That is why I designed my own CPU at one point. ARM CPUs with FPGAs seem to be oriented to people who want to use lots of memory and run a real time OS. Not that that an ARM or a real time OS is a bad thing, I just want something closer to the metal. If I could get a good MCU in an FPGA (which would certainly have some adequate memory) in a "convenient" package, that would really make my day. I don't have to have the analog stuff, but 5 volt tolerance would certainly be useful. That alone would take two chips off my board and maybe more. Rick
From: -jg on 3 Jun 2010 17:42 On Jun 4, 3:24 am, rickman <gnu...(a)gmail.com> wrote: > I remember right? Is X coming out with an FPGA with an ARM? Yes, but not at the "convenient" package end of the spectrum!!. This is an ARM9, and mentions 28nm It will STILL need Code memory, so only moves the problem. > Personally, I prefer something other than an ARM inside an FPGA. I > want a CPU that executes each instruction in a single clock cycle and > has very seriously low interrupt latency. That is why I designed my > own CPU at one point. ARM CPUs with FPGAs seem to be oriented to > people who want to use lots of memory and run a real time OS. Not > that that an ARM or a real time OS is a bad thing, I just want > something closer to the metal. Nice here would be what I'd call an Asymmetric-multi-core - a CPU that is deliberately split into a smaller hard real time portion, and a more general OS level portion. Usually the bits you want hard real time, are NOT large, and it helps to ring fence them from a moreo general layer. The XMOS hard thread-slices are one way to achieve this. > > If I could get a good MCU in an FPGA (which would certainly have some > adequate memory) in a "convenient" package, that would really make my > day. I don't have to have the analog stuff, but 5 volt tolerance > would certainly be useful. That alone would take two chips off my > board and maybe more. 5V tolerance is now way off FPGA's radar, and barely on CPLD radar. AFAIK, only Lattice mention 5V on a modern CPLD, and Atmel's newest CPLDs have measured ESD breakover at ~5.4V, but spec only to 4.6(MAX) It IS more on uC vendors Radar, and growing : The new Cypress PSoC are 5V, as is the Nuvoton M0 series. This allows direct drive of PowerFETS, and better ADC S/N. Code memory remains a large PLD chestnut, but I did see this news : http://www.eeproductcenter.com/memory/brief/showArticle.jhtml?articleID=225300289 ["Kilopass Technology Inc. Wednesday (June 2) unveiled a one-time programmable 4-Mb non-volatile memory IP product large enough to store the firmware and boot code that is traditionally stored in external serial-flash EEPROM chips. "] Importantly, this reaches from 180-nm to 40-nm, so can get to many of the FPGAs, but has only just been announced, so any PLD use will be 2+ years off... -jg
From: rickman on 3 Jun 2010 18:08
On Jun 3, 5:42 pm, -jg <jim.granvi...(a)gmail.com> wrote: > On Jun 4, 3:24 am, rickman <gnu...(a)gmail.com> wrote: > > > I remember right? Is X coming out with an FPGA with an ARM? > > Yes, but not at the "convenient" package end of the spectrum!!. This > is an ARM9, and mentions 28nm > > It will STILL need Code memory, so only moves the problem. How do you know what end of the package spectrum it will be? I seem to recall that the V2P parts had a smaller part with just one processor, I don't recall the min package size. As to the code memory, I am not trying to run Linux, so I can use the internal block rams for what I do. 16 kB would be tons of room. My current part has only 6 kB, 2 kB are taken up for a delay buffer and another is used for the internal stacks. > > Personally, I prefer something other than an ARM inside an FPGA. I > > want a CPU that executes each instruction in a single clock cycle and > > has very seriously low interrupt latency. That is why I designed my > > own CPU at one point. ARM CPUs with FPGAs seem to be oriented to > > people who want to use lots of memory and run a real time OS. Not > > that that an ARM or a real time OS is a bad thing, I just want > > something closer to the metal. > > Nice here would be what I'd call an Asymmetric-multi-core - a CPU > that is deliberately split into a smaller hard real time portion, and > a more general OS level portion. > Usually the bits you want hard real time, are NOT large, and it helps > to ring fence them from a moreo general layer. > The XMOS hard thread-slices are one way to achieve this. Assuming you *need* the OS level portion. If I understand the XMOS device, they have pipelined their design, but instead of trying to use that to speed up a single processor, they treat it as a time sliced multi-processor. Zero overhead other than the muxing of the multiple registers. The trade off is that each of the N processors run as if they are not pipelined at 1/N of the clock rate. I guess there may be some complexity in the interrupt controller too. So for the cost of 1 processor in terms of logic, they get N processors running concurrently. I may take a look at doing that in my processor. The code space could even be shared. > > If I could get a good MCU in an FPGA (which would certainly have some > > adequate memory) in a "convenient" package, that would really make my > > day. I don't have to have the analog stuff, but 5 volt tolerance > > would certainly be useful. That alone would take two chips off my > > board and maybe more. > > 5V tolerance is now way off FPGA's radar, and barely on CPLD radar. But for no good reason. They can make any of the new processes 5 volt tolerant if they have the will. MCUs still have it at small geometries that are the same as FPGAs from a couple of years back when they said the same thing about it being way past the horizon. Besides, if you keep shrinking the logic, what the heck are you going to put in there when the logic uses a quarter of the space between the pads? It is only the high end parts that need the geometries to continue to shrink. FPGAs are a product driven by the technology as much as by the market. The makers only serve a portion of the market they could because they don't want to spend any time or effort beyond the low hanging fruit. At some point, especially if the economy continues in the crapper, they will need to reach a little higher to find profit in areas that take a bit more work. Either than or start down that slope of becoming a commodity product. > AFAIK, only Lattice mention 5V on a modern CPLD, and Atmel's newest > CPLDs have measured ESD breakover at ~5.4V, but spec only to 4.6(MAX) > > It IS more on uC vendors Radar, and growing : > The new Cypress PSoC are 5V, as is the Nuvoton M0 series. This allows > direct drive of PowerFETS, and better ADC S/N. Exactly! If the MCU makers can do it, the FPGAs can as well. The big difference between FPGAs and MCUs as I see it is that MCUs tend to have significant analog while FPGAs remain purely digital. That excludes FPGAs from a portion of the market. When the FPGA companies decide they can't ignore that market anymore (perhaps spurred by success of combo parts like PSoC and Fusion) the processing compromises should allow 5 volt tolerance to be easy if not free. > Code memory remains a large PLD chestnut, but I did see this news : > > http://www.eeproductcenter.com/memory/brief/showArticle.jhtml?article... > > ["Kilopass Technology Inc. Wednesday (June 2) unveiled a one-time > programmable 4-Mb non-volatile memory IP product large enough to store > the firmware and boot code that is traditionally stored in external > serial-flash EEPROM chips. "] > > Importantly, this reaches from 180-nm to 40-nm, so can get to many of > the FPGAs, but has only just been announced, so any PLD use will be 2+ > years off... I'm not sure I follow. What is significant about this part? FPGAs currently have lots of ram that can be used for code storage. I seem to recall that in one of the newer families the block ram has even been partitioned into smaller blocks for logic type use and larger blocks which would be more for CPU type apps. Is that the high end Altera parts? I know they have 6 input LUTs now and I may be getting mixed up with that. Rick |