A good MAC is fairly complicated, and as a soft MAC takes up lots of FPGA real estate, so it makes sense to stick one or two on the die of larger parts since it's then a fairly small percentage of the part. Not all the customers benefit, but some benefit a lot, and the others aren't penalized much.
But counter-timers don't take up much room in an FPGA, so if you go to hardwiring those, you don't gain anything, and you lose tons of flexibility. Inevitably the features of the hardwired timer-counter would never be quite what you need for any given design. There would be only a small penalty, but it would be borne by all customers. Very few would get any advantage, and the advantage would be very modest. The cost/benefit analysis is much worse than with a MAC.
If you want them to build some other hardwired logic into their FPGAs, you'll need to come up with a *much* better example than that.
But the additional circuitry required to drive the MOSFET from an FPGA is so small and cheap compared to the power MOSFET that I do not see the economic advantage of selecting the FPGA based on that criterion. A driver in sc70-package will be hardly noticed in the layout next to a power MOSFET and the additional cost of 3ct doesn't matter at all.
Inputs can be made 5V tolerant by a single resistors. These are available at virtually no cost in 0.5mm pitch 8x arrays.
Schmitt-Triggers are only a little more cumbersome: You need a second FPGA-pin and a single resistor. Or no additional pin and a driver in sc70-package.
If you dot need more than a few dozens of these pins the cost will not even add up to the price difference between a 3.3V and 5V part. And you are much more flexibale because you can also support all the other voltages that show up in the control industry: 5.2V (PECL), 6V, 6.2V,
you are right ... not every application needs a high end FPGA! we even use some of the old Spartan XCS40 - you can still buy them but ISE support was dropped long time ago :-(
Yes, you can get the old parts. I have even seen XC30xx parts on Digikey. But I don't think it is a good use of $$$ using old, expensive parts to get 5 volt tolerance. There are a few current parts that are 5 volt tolerant to some extent. The Xilinx Coolrunner CPLD parts (not II) have a limited number of 5 volt tolerant IO and Lattice has some 5 volt tolerant parts (again a limited number of IO) that just came out in the last couple of years or so. But these are not great parts in other ways.
The FPGA market follows the telecom world, which is where their bread and butter come from. They can sell their really large parts there with all the exorbitant markup of the state of the art parts and telecom needs the flexibility of FPGAs to get state of the art designs on their boards with a short turn around. Telecom also drives the speed of the FPGAs which is what makes them use the latest processes without the mods that the ARM CPU makers use to retain 5 volt tolerance. So in the end telecom "owns" the FPGA vendors and the rest of us are just a secondary market.
On a sunny day (13 Mar 2006 19:11:19 -0800) it happened "rickman" wrote in :
I was reading about new Intel research and they mentioned 200mV processor cores...... It means a lower noise margin, but maybe the low impedances will prevent spikes... or at least external influences. Think this was about indium-antimonide. So, when we get 200mV (100GHz) FPGA then yes, [always drivers] but then perhaps we will have to go optical from the chip.
thanks Jim, that's exactly correct. I think Eric missed my point; which was specifically about the industrial/mixed-signal market; relative to the ongoing discussion of 5v i/o.
Eric, I also believe you're mistaken about timer/counters; which have been hardwired into virtually -every- microcontroller made since the dawn of time; and nobody has had a problem using them in their fixed configurations.
And I think at least one or two engineers have found them to be an "advantage"... LOL
Perhaps you are focused on "computing"; judging by your comment that a MAC is more "useful" than a timer-counter. I couldn't care less whether my chip has a MAC....I don't -do- massive high-speed computing with my logic.
Sounds like you do....but there are many many MANY uses for logic in the world, besides running embedded linux...
ps; jim is right, I had specifically mentioned a 64-128 cell part; not a 3,000 register fpga. In which case, using cells for timers eats up a $10 chip REAL fast....while the silicon cost for a few 16b hard counters on a chip like that would be near-zero...
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
formatting link
The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
Kolja, please tell me where to get these FET-drivers for 3 cents...
Further, you have just -doubled- my parts count per function. I'm mad now...
Also, I think you are wrong to blithely dismiss a -doubling- of i/o pin usage. Perhaps you are thinking in terms of 500-pin chips; but most of these apps use 40-128 pin chips. I/O is -expensive-.
And I'm not sure how you see that technique achieving the same noise-immunity of a true 5v schmitt input anyway. And how do you use the pins bidirectionally? It just doesn't sound like a practical thing to me.
Your technique of using resistors on the inputs, and feeding them with
5-24v signals is not a good technique, imho. It can cause a lot of current flow; and can actually float the fpga supply up out of spec under certain conditions.
Every additional connection is a reliability issue...and every additional part carries a penalty in board-space, assembly-cost, and inventory-costs.
Basically, using a 5v logic chip is just far easier, cleaner, more robust; and it's almost always worth the price-difference in order to reduce parts-count, and size.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
formatting link
The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
In the current CPLD area, there are two lower cost solutios to this.
Xilinx's larger CoolRunner2 (but NOT the 32/64MC ones IIRC) have a tapped dedicated divider, so you can get a simple CLK/n without loosing macrocells.
Atmel's macrocells allow you to logic double, so you can bury simple counter registers, and still use the OR portion or the IO pins. Not quite free, but does allow you to use a smaller CPLD.
There is no question that such FPGAs or CPLDs can be designed and manufactured. And you can be assured that there are smart people at Xilinx and Altera (and elsewhere) who have analyzed this scenario. The challenging question is: How large is the potential market, and is this a meaningful area to invest our design, manufacturing, marketing and sales resources in ? And there is the "opportunity cost: "What other area do we have to neglect, in order to jump onto this allegedly juicy opportunity?" People, talent and money are not unlimited, neither is the focus of management and of the sales force. If the market is -just to pick a number- $ 50 M per year, that does not look tempting for the two big guys who each have between 1 and 2 billion dollar revenue per year. 2 to 5 percent of potential but not guaranteed extra revenue will not create great excitement. It might look more tempting to a smaller (or shrinking) manufacturer. I have personally suggested several interesting product ideas (along the lines of this thread) and several times had to admit defeat... Peter Alfke, from home
Every time I've tried to use a timer built into a microcontroller, I've run up against arbitrary limitations. Most commonly, the inability to gate the timer on and off with an external signal, which using either a second signal or the CPU clock as the timer clock. Often the prescaler choices leave a lot to be desired. I dispute any claim that "nobody has had a problem using them".
Sure. But having some simple-minded hardwired counter in an FPGA won't be an advantage, because it won't do exactly what you want, so you'll end up designing your own anyhow.
No, I do a whole lot of embedded design, including a lot of stuff with timer-counters. I use MACs sometimes to interface embedded systems to computer networks. If I had a choice between having a hardwired MAC in the FPGA, or a hardwired counter-timer, I'd definitely take the MAC, even though I would use it in less than 10% of my designs, because I'd probably use the hardwired counter-timer in 0% of my designs.
For instance, I wrote the firmware for the Precision Navigation TCM1 tilt-compensated electronic compass OEM module back in 1994, using a Mitsubishi M740 series 8-bit microcontroller (6502-like core). I was brought in after an expensive consulting firm billed them for a few months work, then told them that it was impossible to do it on that part, partly because the timers weren't good enough, and partly because there weren't enough CPU cycles to do both the measurements and the computations at the desired sample rate. I got it all to work, but I had to go through bizarre contortions with the timers and the interrupt logic. If the timers had been just a little bit different, it would have been easy, and we could have gotten at least 50% higher sample rate.
I've also designed things where due to inadequate timers, I had to write sections of code that were cycle-counted through all paths in order to squeeze out a bit more performance than the hardware timers provided.
So no, I definitely wouldn't say that "nobody has had a problem using them". Maybe "nobody doing trivial things has had a problem with them."
Sometimes I do, sometimes I don't.
Obviously I'm not proposing putting a MAC on your 64-128 cell part.
It's not near-zero. The counters themselves may not use up much die area, but they have to interface to the routing matrix just like macrocells do, and the routing area is where much of your die area goes. Add 16 more signals to the routing matrix, and it gets a LOT bigger. That translates into real dollars. I'd rather spend 1.1x dollars on 16 macrocells that do whatever I want,than 1.0x dollars on 16 bits of hardwired stuff (which is more than just 16 flops, since it may have input and output holding registers, etc.) that almost certainly doesn't do what I want, because I'll end up having to buy more macrocells for my own counters anyhow.
"If only it had 17 bits"
"If only it had a gate input"
"If only the prescaler could be set to divide by 17"
"If only the prescaler would reset when the counter is reset" or "If only the prescaler *wouldn't" reset when the counter is reset"
"If only the PWM mode had complementary outputs to drive my H bridge"
"If only the PWM mode had an adjustable dead band"
etc.
No matter what features you pick, they'll be wrong most of the time. And if you put ALL the features in, then it will use up a lot of silicon, and it will STILL be wrong a lot of the time.
When I use counter-timers in microcontrollers, they rarely do what I want, so I often end up adding external logic anyhow. And when they do what I want, or close enough to it that I can do the rest in firmware, it's because the requirements I'm making of the counter-timer are really simple. Not the kind of stuff I'm going to put in an FPGA anyhow. If my requirements can be met by a microcontroller, I'll use that rather than an FPGA.
By contrast, a MAC does a very well-defined function, and it's possible to design one that will be useful to >99% of people that need a MAC. (Of course, it's still no use to the people that don't need a MAC.)
The point is to do it selectively - like your MAC. If you look at the Xc2C128, the timer-chain there does not have a wide matrix cost, they are intended to do simple /N tasks, freeing up macrocells for more complex roles. So the cost is a few MUX fuses.
True, many uC timers are too-simple, and never quite have the right gating paths. But the counter itself with SFR mapping is usefull.
Many of our designs use a uC + CPLD, to do 'peripheral IQ extension'
A good, simple, example is a Quadrature Conditioner for a 89C52 Timer2. The Timer2 has Up/Dn, but cannot count all 4 quadrants, so a PLD takes a Quad signal IN, and outputs a CLK.DIRN the timer can use. Result is efficent use of HW, and MUCH faster than a SW solution.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.