Spectre of Metastability Update

That is what Xilinx is always saying. But they put the XC2C128 and XC2C256 parts in very fine pitch, small packages (8x8 mm CP132), so clearly the die size vs. package size is not the issue. I just can't use parts with balls on 0.5 mm pitch. I can use a 48 pin QFP which is only 1 mm larger on the board at 9 mm sq or a LFBGA100 with 100 pins and 10 mm sq footprint. I don't need a pin for every macrocell. If Xilinx applied the same logic to the FPGAs with a pin per logic cell, would we need packages with 100,000 pins and up?

I wonder if Xilinx would consider their pins to have 12.5% more functionality than their competitor's pins?

Actually the engineer's goal is to nail function (get it to do the right thing), performance (perform the function at the right speed) and cost (be able to produce it for a price that it can the be sold at for a profit).

'Minimum space' (or any measure of space) is a design constraint that one must live with (among a whole slew of others) not a goal to be optomized.

KJ

is to nail function (get it to do the

There is certainly scope for CPLDs in smaller packages.

What would be your preferred package and pin count for a compact 128 Macrocell device ?

Xilinx have done some QFNs for the smaller CPLDs, but I think they stopped at 64MC ?.

Did you mention what you wanted, and why they lost the sale, to them?

Packages are relatively cheap (a new package is way cheaper than a new die development), give them a large enough volume target, and they will chase it.

They might :) IIRC Atmel have Pinkeep/Pullup/Schmitt/OD/GND programmable on a per pin basis, whilst lattice have only global Pullup. One could argue that makes the Atmel pin 20% smarter than the lattice one :) [Tho more likely, the lattice drawback would kill a very low power design stone dead, as one pins current pull-up is way higher thanthe Static Iq)

-jg

Close - I use 'fuse' terminology since that's what the programmer reports.

Typical examples: Blow Count: 8254, on a 16808 Sized device Largest I can find, is Blow Count: 15851, (94.3%) which is a somewhat rare design that has 100.0% PT usage.

This design reports a fanin usage of 85%.

In this case (device family/programmer), the Blow count roughly tracks (just under) PT% usage, I think because in these devices a free PT row, is 'do nothing' in the fuse array.

-jg

I am still hearing that "intellegence" is wanted on the module. So I might suggest that we can combine a small MCU with a small CPLD and keep the intelligence on board with a higher power consumption. But this just seems like such over kill. If I could get the 128 MC device in a 48 pin TQFP which is only 9 mm sq including the leads, that would do the entire job other than the IO conditioning and relay drive.

Exactly.

This is business that both Altera and Xilinx pursue agressively. They are totally in the loop on every project we do because the volumes are high and we don't really beat them too hard on price. I only found out about this particular win because I was there for a X presentation where they discussed the large packages with our system engineers.

That is not what X and A will tell you. They plan out the packaging when they design a product family. It seems to be a major issue to put a part in a new package. Otherwise they would be selling 5000 more units a month for the next 7 years or so.

Atmel vs. Lattice? What type of parts are you talking about?

I have not worked with the Altera Cyclone II parts yet, but the Spartan

3 parts have an interesting feature where you can kill all the pullups on the User IOs during configuration. But you can't eliminate the pullups on the configuration pins no matter what. Combine that with the stiffness (down to 1 kohm) and you have IOs that can't be programmed with a resistor to ground and then easily overdriven once the design is loaded. I think you need about a 330 ohm resistor to drive it low enough. Then driving it high with an output takes nearly 10 mA! Some CMOS outputs are only rated for 4 mA drive.

Of course, salesmen will always pitch what they have, and give all sorts of spin as to why anything else should be off your radar :)

When we spoke with infineon years ago, they said ~50K was enough to contemplate a new package. If it is one already in their flow, that helps as well. So, for Xilnix that means probably the QFN48. Then they think about OTHER customers, and something like this is NOT a blind alley, as there are many applications for CPLDs with more macrocells, but less IO.

Then, it's a simple die bonding question, but QFN packages have large paddle areas.

To help focus them, ask about bare die MOQs ?

so you mean appx 420,000 is the expected volume ?

The ATF1502BE vs ispMACH4032Z

yes, a small oversight can mess up a product. In Lattice's case I was surprised they made the 150uA pullups global, on a part that chases 10uA standbys!! - one pin the 'wrong-way', and that's 150uA!

-jg

Up to here, I count only 33 macrocells, probably less. The

Why not use a 64MC device in CS package?

Kolja Sulimma

This logic is only 15 or so MC. The part that controls the relays is a bit more complex. I don't recall the exact MC count, but it was in the low 50's for the whole shooting match, but that was not a formal, complete analysis and would likely grow a bit. Then we have a requirement for 40% spare capacity so that we can accommodate later revisions and updates. That puts the design clearly in the 128 MC part.

Actually, it has occured to me that I could do a combined approach using a 32 or 64 MC CPLD to replace the discrete logic only and not the relay drivers. An MCU could do the job of sorting out the SPI data and provide "intelligence" for driving the relays.

The MCU would have to be very low power, but that might be doable with adequate power management.

To be honest, the hard part of all this is the working atmosphere. The moment I suggested that we needed to change the basic design I was inundated with arguments. I am supposed to be the lead engineer on this module and I don't get to make any decisions without the approval of a ton of others - very, very frustrating. Now I am very hesitant to even consider any deviations just because of the gauntlet I will have to run again.

If the relay logic is that complex, why not use a uC and SPI relay drivers ?

Look at the Silabs C8051F41x/F53x family. When I asked them about the SPI port waking up the on chip OSC, they said "Oh yes, the osc starts in spec almost instantly" (couple of cycles), and they have some clk ratio requirement anyway, so the upshot was, this chip could sit in deep sleep, and wakeup on SPI ready to service the first byte, then go back to deep sleep again : ie behave rather like Logic or a low power CPLD.

-jg

The original idea was the CPLD was needed and could provide the logic for the relay control too. It was only in the last couple of weeks that I realized that I couldn't get the chip on the board with the size of the relays that were selected. Then I realized that there was no real need for the "complex" control logic since that is only an artifact of the SPI bus protocol which I didn't think was cast in concrete. It's not, but because we are a sub working with a prime, we don't do squat without asking "mother may I".

So we can treat the relay driver as a simple SPI relay driver and put the "intelligence" in existing processors on other boards. I think a Monahan should have enough horsepower to handle a relay drive when nothing else is going on.

Or we can add an MCU and offload this burden from the slow 400 MHz processor to a 4 MHz MCU.

My real concern is that the RF section can grow and squeeze the controller space even more.

My point was that not so much because it is needed, but as a compromise I could use a small MCU and a small CPLD with the small relay driver chips. This is only a bit larger than the "dumb" approach. But it will require a lot more development work (remember this is a very inefficient company) and I will have a very hard time getting the support I need to fully test the board.

The really sad part is that this is costing 10 to 100 times what it would cost in commercial work and it is being paid for by the Government.

It is kind of hard to spin the loss of a sale when the competition has what we need.

It may not be a blind alley for us, but for the FPGA vendors, they don't seem interested. The other issue with Xilinx is the family. They are all about the Coolrunner II parts while I much prefer the Coolrunner XPLA parts which only require a single power supply. At least the Lattice parts incorporate an LDO if you want the advantages of the newer process and are size limited.

Well, I can understand they are less enthused about XPLA devices, as they are not their 'hot new thing' :)

Some Semi suppliers will do a semi-custom easier than raise a new part number. The former only needs the volumes & packaging flows, and can even have subset testing, (and customers can do this themselves if they buy die ), whilst a new merchant part number needs more buy-in from marketing and product managers, ( as they might need to explain why sales for that line are lagging, two years down the track )

FPGA vendors already have their quasi-asic flows for FPGAs, this is just a small shift of that mindset into CPLDs, and they would PGM and test the die with your code, since this sounds like a fixed app ?

-jg