Spectre of Metastability Update

We had four houses' worth of candy-filled bowls lined up on one long table, which caused many of the evening's spectres to exhibit distinct signs of metastability during the confectionary selection process.

Unlike FPGA's, the resolution time seemed inversely proportional to the calendar age of the synchronizer :)

Also, I don't recall anyone mentioning it, but Bob's handy dandy guide to planetary landing FSM's seems quite topical of late:

Brian

In my younger days designing state machines in PALs, we did not have the luxury of pre-synchronizing every asyncrhonous input in its own flop.

So we handled asynchronous inputs slightly differently.

We constrained the state machine and state mapping such that there was only, ever two destination states based on an asynchronous input at any given time, and both of those destinations had to be adjacent on a K map (for those of you too young to know, that means the two states differed in only one bit, and that one bit becomes the "syncrhonizer"). Sometimes it was in a loop/branch scenario, where one destination was the current state, and one the adjacent next state, or sometimes it was two new destination states, both adjacent to each other. Oddly enough, those two destination states (so long as they are the only possible destinations) don't have to be adjacent to the current state.

The primary benefit of this was that the syncrhonizer register could pull extra duty in other parts of the state machine as just another state bit, or even as a syncrhonizer for another input. AND-OR arrays have their advantages when it comes to overcoming glitches due to simultaneous input changes that kill LUT based logic.

For example in the Mongo Lander FSM, if Idle and Fire_Retro_Rockets are adjacent states on the Kmap, then the one register that differs between them is the synchronizer, and so long as sufficient timing slack is reserved for MS settling, no separate synchronizer is needed. Note that because other transitions in the state machine are not based on async inputs, they need not be adjacent on the Kmap.

In an environment where we had to manually assign state encodings anyway, and registers were at a premium, this technique worked very reliably, so long as there was sufficient slack to allow for MS to settle out (i.e. we did not have the equivalent of a second flop behind the syncrhonizing flop) for a reasonable MTBF.

In today's design environment, we rarely manually assign states, and registers are plentiful, so this technique is rarely employed. Also, separately synchronizing asynchronous inputs is more easily auditable in code reviews than the old adjacent-state approach.

Andy

Brian Davis wrote:

I mentioned alternate coding techniques in the Q and A.

One of the problems with devising examples to illustrate a principle is that they have to be simple enough for the newcomer to comprehend, which means that they're likely to be amenable to alternate techniques that you might not want to use generally.

Agreed. And making the code more easily auditable (or just more comprehensible to the person who takes it over years from now) is a valuable safety tip. To paraphrase something Peter said a while back, flip-flops and gates are cheap, but problems are expensive.

Bob Perlman Cambrian Design Works

Yup, BTDT many times over back in the days when a 22V10 was an awesome part compared to the rest of what was available. It still occasionally comes in useful where latency is a concern.

K-map co-ordinates are gray coded anyway, so adjacent states on a K-map are by definition a single bit change apart for that very reason :)

I remember implementing a gray code counter to capture asynchronous events against an arbitrary timing window some *cough* time ago.

Cheers

PeteS

I remember the birth of the 22V10 (it's an AMD product, not MMI's) It had the gestation period of an elephant, and it almost killed the design engineers. Too complicated... Times have changed. Peter Alfke

On Nov 1, 11:28 am, Ray Andraka wrote: .Yup, BTDT many times over back in the days when a 22V10 was an awesome

Yes, those 'V' parts were pretty versatile (hence the 'V' in 16V8, 22V10) for those of us around at the birth of the 16R4, 16R6 and 16R8 when great thought had to be applied to decide whether an output should be clocked or combinatorial...and if you got it wrong you had to rewire the circuit board to move it to the appropriate pin....well, that and having to remove and pitch the part because it was fuse based one time programmable.

KJ...feeling ooooooold now....where's my hot cocoa?

Does he take sugar? Me too. The olde original PAL assembler was in FORTRAN, and MMI would give away the source code - it was only a few hundred lines of code, back in the days when PAL16R8s were high-tech. Two separate FORTRAN programs, one for the 20-pin and one for the 24-pin parts. I remember fixing a bug in the 24-pin version, but sadly I've lost all those old 9-track magtapes with the files on them... My VAX DCL script to drive the Data I/O device programmer was almost as long as the PAL assembler!

As Ray said, those PALs revolutionized what we could do - as an engineer working for a struggling startup, I couldn't believe my luck.

The amazing thing is that we engineers have gone on being at least that lucky, consistently, for the 25 years since then.

Betcha the source code for ISE don't fit in a single ring binder, though :-)

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Yes the 16R8 may seem like an incredibly simple device, but it was such an improvement over the TTL MSI devices we were otherwise using at the time. PALs seemed like a gift from the Gods.

Oddly enough I am currently working on a design where I am pushing the customer to let me do it in discrete logic rather than a CPLD. The functions are pretty simple and it only takes eight or so logic chips and a couple of relay drivers. But to do it in a CPLD and have the required 40% reserve space means I have to go to a relatively huge 100 pin TQFP which just won't fit in the allotted space on the board. I could split it into two chips which would fit better, but I still am not sure I would have the required 40% reserve capacitiy and would have to add a JTAG connector to allow updates and factory programming.

So discrete logic is not quite yet dead...

What's the '40% reserve space' mean ? Sounds like some miss-directed spec, from someone that thinks PLDs are software and thus likely to need 12 revisions in the life of the product ?

yes, but I'm really interested to see how you design with discrete logic, and still get 40% reserve capacity - I know, use a HEF4894, when a HEF4794 would do ! :)

-jg

And I was interested in the 'eight or so' chips which fit into the space of the TQFP-100...

Will

This is an area where books could be written ;)

The only engineering maxim is do it right in the minimum space and minimum cost, although those two can conflict.

Cheers

PeteS

Not just revisions, but changing requirements. That seems to be the big thing everyone here is concerned about, that a hardware only approach does not lend any flexibility to requirement growth. In reality, there are not many things that can change that will not require a hardware change regardless of the implementation. If you want to add signals to the mux, you will have to add those inputs to the module. If you change the number of relays, you will need to add the relays.

My point has been that it will not provide any less *useful* reconfigurability. I had the "big" presentation today and the two senior people who will have to "OK" the decision didn't even come. The guy who is our contact with the FPGA/CPLD department started kibizing at the end of the presentation saying that the discrete logic approach was not "clean". I had to call him on that BS.

I am honestly looking for another job. Between dealing with the ignorance and the extreme boredom and the snail pace design work, I have decided to leave. I feel like the guy in the commercial that comes in the door after the parrot who cries, "I can't take it!" I just don't care for the commute I will have to live with. The outfit was the closest job I could get. Everything else is a lot further a way or even if it is not a lot further, it is in a lot heavier traffic.

Maybe I should retire...

Three dual 4 input muxes (analog switch based), a 4 bit counter, a dual tri-state buffer, a dual NAND gate and a dual FF. Together with two 8 bit SPI port relay drivers, they all fit in a 10 x 20 mm area. The smallest CPLD I can easily use is a 128 macrocell part in a 100 pin TQFP at 16 mm sq package and still requires the two relay drivers plus a JTAG header. There is one package we can use that is smaller at 12 mm sq, but only one part is available in this package and it is still a very tight fit in the available space that is only 14 mm wide. This will be under a metal shield and 1 mm on each side may not be enough clearance with the manufacturing tolerances.

I was wondering the same thing. Wafer scale?

When faced with these 'edicts' you need to get creative :)

In a PLD vs full hardware implementation, then pin resource does not need 40% headroom, as clearly the connectors etc do not have that.

So, you can look at the product-terms and that should come better than

40% spare.

The fuse-blow count on loading into a programmer is also another yardstick, and that will also usually be < 60% (often slightly lower than PT usage)

If that fails, you can spec Cross-point usage, and in any CPLD design, that will be

And I'll give you that...you did get 'creative' suggesting number of unblown fuses as a metric of usage....on a device that probably doesn't have 'fuses' since it's likely EEPROM based, so what you're really suggesting is a metric of how many 'spare' '0's (or '1's) there are to be written into the device....not very useful, but no doubt creative. Would be interesting to try that metric and see how many people nod their head in agreement.

I agree with the gist of it, conjure up a metric that can dazzle the easily dazzled if they are the ones holding you back.

This one actually can be a decent metric.

KJ

Why would it need to be anything esoteric? MSI devices are still in popular use and have migrated to very small packaging. I'm not planning to use the tiniest of packages which are chipscale with 0.5 mm ball pitch. I am planning to use QFN or leaded packages which are all

4 x 4 mm or smaller. I believe the buffer and dual NAND chips are only 2 x 3 mm. I can get a lot of these parts in a 16 x 16 mm space.

I guess it has been awhile since you looked at discrete logic?

The difference is not because the MSI logic chips have shrunk a lot, but rather that the only small FPGA packages with anything but the smallest of devices are on 0.5 mm pitch. I would love to put a Coolrunner or ispMACH4k on the board. I need 128 MC device and they just don't put them in the smaller packages. I know that Xilinx has lost design wins with us to Altera because of packaging. In this case they all lost to discrete logic because of packaging.