f



Spectre of Metastability Update

Good news: the "spectre of metastability" appears to be on the wane. I
live less than a mile from Xilinx HQ, yet on Halloween night, not a
single person dressed as metastability showed up at my door for candy
(the closest was a kid in a Napoleon Dynamite getup).

Of course, real metastability is still out there.  As Jack Nicholson
would say, act accordingly.

Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com
0
11/1/2006 5:14:01 AM
comp.arch.fpga 18587 articles. 2 followers. Post Follow

33 Replies
562 Views

Similar Articles

[PageSpeed] 5

Bob Perlman wrote:
>
> on Halloween night, not a single person dressed as metastability
> showed up at my door for candy
>

 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:

  http://www.cambriandesign.com/2006/02/synchronizing-fsm-inputs.html

Brian

0
Brian
11/1/2006 12:24:58 PM
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:
> Bob Perlman wrote:
> >
> > on Halloween night, not a single person dressed as metastability
> > showed up at my door for candy
> >
>
>  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:
>
>   http://www.cambriandesign.com/2006/02/synchronizing-fsm-inputs.html
> 
> Brian

0
Andy
11/1/2006 5:13:16 PM
Andy, neat idea...
Gray-coded counters are popular for the same reason.
Peter Alfke

On Nov 1, 9:13 am, "Andy" <jonesa...@comcast.net> wrote:
> 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:
> > Bob Perlman wrote:
>
> > > on Halloween night, not a single person dressed as metastability
> > > showed up at my door for candy
>
> >  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:
>
> >  http://www.cambriandesign.com/2006/02/synchronizing-fsm-inputs.html
> 
> > Brian

0
Peter
11/1/2006 5:24:04 PM
On 1 Nov 2006 09:13:16 -0800, "Andy" <jonesandy@comcast.net> wrote:

>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").

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.

<good stuff snipped>

>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.

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
http://www.cambriandesign.com
0
Bob
11/1/2006 5:58:32 PM
Andy wrote:
> 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.
> 


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.
0
Ray
11/1/2006 7:28:39 PM
Peter Alfke wrote:
> Andy, neat idea...
> Gray-coded counters are popular for the same reason.
> Peter Alfke

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


> 
> On Nov 1, 9:13 am, "Andy" <jonesa...@comcast.net> wrote:
>> 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:
>>> Bob Perlman wrote:
>>>> on Halloween night, not a single person dressed as metastability
>>>> showed up at my door for candy
>>>  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:
>>>  http://www.cambriandesign.com/2006/02/synchronizing-fsm-inputs.html
>>> Brian
> 
0
PeteS
11/1/2006 9:01:34 PM
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 <r...@andraka.com> wrote:
..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.

0
Peter
11/1/2006 10:08:15 PM
"Peter Alfke" <peter@xilinx.com> wrote in message 
news:1162418895.253069.240680@f16g2000cwb.googlegroups.com...
>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

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? 


0
KJ
11/2/2006 3:26:14 AM
On Thu, 02 Nov 2006 03:26:14 GMT, "KJ" 
<kkjennings@sbcglobal.net> wrote:

>"Peter Alfke" <peter@xilinx.com> wrote in message 
>news:1162418895.253069.240680@f16g2000cwb.googlegroups.com...
>>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
>
>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.
0
Jonathan
11/2/2006 9:36:17 AM
KJ wrote:
> "Peter Alfke" <peter@xilinx.com> wrote in message
> news:1162418895.253069.240680@f16g2000cwb.googlegroups.com...
> >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
>
> 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?

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...

0
rickman
11/2/2006 1:29:42 PM
rickman wrote:
> 
> 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.  

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 ?


> 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...

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

0
Jim
11/2/2006 7:13:02 PM
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
news:454a42f8$1@clear.net.nz...
>
> 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 ! :)

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

Will


0
Will
11/2/2006 9:15:24 PM
rickman wrote:
> KJ wrote:
>> "Peter Alfke" <peter@xilinx.com> wrote in message
>> news:1162418895.253069.240680@f16g2000cwb.googlegroups.com...
>>> 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
>> 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?
> 
> 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...
> 

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
0
PeteS
11/2/2006 10:05:24 PM
Jim Granville wrote:
> rickman wrote:
> >
> > 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.
>
> 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 ?

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.


> > 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...
>
> 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 ! :)

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...

0
rickman
11/3/2006 1:50:45 AM
Will Dean wrote:
> "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message
> news:454a42f8$1@clear.net.nz...
> >
> > 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 ! :)
>
> And I was interested in the 'eight or so' chips which fit into the space of
> the TQFP-100...
>
> Will

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.

0
rickman
11/3/2006 1:59:53 AM
Will Dean wrote:

> "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
> news:454a42f8$1@clear.net.nz...
> 
>>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 ! :)
> 
> 
> And I was interested in the 'eight or so' chips which fit into the space of 
> the TQFP-100...
> 
> Will
> 
> 

I was wondering the same thing.  Wafer scale?
0
Ray
11/3/2006 2:34:42 AM
rickman wrote:
>>>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...
>>
>>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 ! :)
> 
> 
> 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.

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 << 60%, so give them that number, or quote the mean of
Fuse-Blow and Cross-Point usage ?

-jg

0
Jim
11/3/2006 3:41:39 AM
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
news:454aba2d$1@clear.net.nz...
>
> When faced with these 'edicts' you need to get creative :)
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.

>
> 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.
This one actually can be a decent metric.

>
> 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 << 60%, so give them that number, or quote the mean of
> Fuse-Blow and Cross-Point usage ?
>
> -jg
>
KJ 


0
KJ
11/3/2006 10:42:20 AM
Ray Andraka wrote:
> Will Dean wrote:
>
> > "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message
> > news:454a42f8$1@clear.net.nz...
> >
> >>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 ! :)
> >
> >
> > And I was interested in the 'eight or so' chips which fit into the space of
> > the TQFP-100...
> >
> > Will
> >
> >
>
> I was wondering the same thing.  Wafer scale?

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.

0
rickman
11/3/2006 1:29:04 PM
rickman wrote:
> Ray Andraka wrote:
> 
>>Will Dean wrote:
>>
>>
>>>"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message
>>>news:454a42f8$1@clear.net.nz...
>>>
>>>
>>>>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 ! :)
>>>
>>>
>>>And I was interested in the 'eight or so' chips which fit into the space of
>>>the TQFP-100...
>>>
>>>Will
>>>
>>>
>>
>>I was wondering the same thing.  Wafer scale?
> 
> 
> 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.
> 

I admit, I haven't worked with discrete logic much lately.  On the other 
hand, I was considering not just the package, but the board area around 
the packages for routing.  I can see phsyically putting 8 packages in 
the space taken by the TQFP100, but I still don't see much room to route 
to those packages.

The issue with the smaller packages is insufficient cavity size, and in 
many cases I guess not enough pins to make it widely appealing.
0
Ray
11/3/2006 2:47:19 PM
Ray Andraka wrote:
> rickman wrote:
> > Ray Andraka wrote:
> >
> >>Will Dean wrote:
> >>
> >>
> >>>"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message
> >>>news:454a42f8$1@clear.net.nz...
> >>>
> >>>
> >>>>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 ! :)
> >>>
> >>>
> >>>And I was interested in the 'eight or so' chips which fit into the space of
> >>>the TQFP-100...
> >>>
> >>>Will
> >>>
> >>>
> >>
> >>I was wondering the same thing.  Wafer scale?
> >
> >
> > 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.
> >
>
> I admit, I haven't worked with discrete logic much lately.  On the other
> hand, I was considering not just the package, but the board area around
> the packages for routing.  I can see phsyically putting 8 packages in
> the space taken by the TQFP100, but I still don't see much room to route
> to those packages.
>
> The issue with the smaller packages is insufficient cavity size, and in
> many cases I guess not enough pins to make it widely appealing.

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?

0
rickman
11/3/2006 3:57:11 PM
PeteS wrote:
>
> The only engineering maxim is do it right in the minimum space and
> minimum cost, although those two can conflict.
>
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

0
KJ
11/3/2006 5:22:58 PM
I would say that:
function, performance, availability, cost, size and ease of use
are all considerations, the first three usually absolute.
The relative importance varies with the application. There can be cases
(like rickman's?) where pc-board size is a dominating requirement, more
important than anything else. But that is an unusual case...
Peter Alfke

On Nov 3, 9:22 am, "KJ" <Kevin.Jenni...@Unisys.com> wrote:
> PeteS wrote:
>
> > The only engineering maxim is do it right in the minimum space and
> > minimum cost, although those two can conflict.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

0
Peter
11/3/2006 5:33:56 PM
rickman wrote:
>>The issue with the smaller packages is insufficient cavity size, and in
>>many cases I guess not enough pins to make it widely appealing.
> 
> 
> 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?

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.


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

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

0
Jim
11/3/2006 8:13:54 PM
KJ wrote:
> "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
> news:454aba2d$1@clear.net.nz...
> 
>>When faced with these 'edicts' you need to get creative :)
> 
> 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.

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.


> 
> 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.
> 
> 
>>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.
> 
> This one actually can be a decent metric.

-jg

0
Jim
11/3/2006 8:47:09 PM
Jim Granville wrote:
> rickman wrote:
> >>The issue with the smaller packages is insufficient cavity size, and in
> >>many cases I guess not enough pins to make it widely appealing.
> >
> >
> > 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?
>
> There is certainly scope for CPLDs in smaller packages.
>
> What would be your preferred package and pin count for a
> compact 128 Macrocell device ?

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.


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

Exactly.


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

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.


> 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.

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.


> > I wonder if Xilinx would consider their pins to have 12.5% more
> > functionality than their competitor's pins?
>
> They might :)
> IIRC Atmel have Pinkeep/Pullup/Schmitt/OD/GND programmable on
> a per pin basis, whilst lattice have only global Pullup.

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


> 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)

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.

0
rickman
11/3/2006 9:57:51 PM
rickman wrote:

> Jim Granville wrote:
>>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.
> 
> 
> 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.  

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 ?


> Otherwise they would be selling 5000 more
> units a month for the next 7 years or so.

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

>>>I wonder if Xilinx would consider their pins to have 12.5% more
>>>functionality than their competitor's pins?
>>
>>They might :)
>>IIRC Atmel have Pinkeep/Pullup/Schmitt/OD/GND programmable on
>>a per pin basis, whilst lattice have only global Pullup.
> 
> 
> Atmel vs. Lattice?  What type of parts are you talking about?

The ATF1502BE vs ispMACH4032Z

>>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)
> 
> 
> 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.

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

0
Jim
11/3/2006 11:23:27 PM
rickman schrieb:
> Will Dean wrote:
> 
>>"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message
>>news:454a42f8$1@clear.net.nz...
>>
>>>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 ! :)
>>
>>And I was interested in the 'eight or so' chips which fit into the space of
>>the TQFP-100...
>>
>>Will
> 
> 
> 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.
Up to here, I count only 33 macrocells, probably less.
  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. 

Why not use a 64MC device in CS package?

Kolja Sulimma
0
Kolja
11/3/2006 11:46:19 PM
Kolja Sulimma wrote:
> rickman schrieb:
> > Will Dean wrote:
> >
> >>"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message
> >>news:454a42f8$1@clear.net.nz...
> >>
> >>>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 ! :)
> >>
> >>And I was interested in the 'eight or so' chips which fit into the space of
> >>the TQFP-100...
> >>
> >>Will
> >
> >
> > 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.
> Up to here, I count only 33 macrocells, probably less.

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.


>   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.
>
> Why not use a 64MC device in CS package?

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.

0
rickman
11/4/2006 1:54:57 PM
rickman wrote:
>>>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.
>>
>>Up to here, I count only 33 macrocells, probably less.
> 
> 
> 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.
> 
> 
> 
>>  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.
>>
>>Why not use a 64MC device in CS package?
> 
> 
> 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.

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

0
Jim
11/4/2006 8:57:07 PM
Jim Granville wrote:
> rickman wrote:
> >>>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.
> >>
> >>Up to here, I count only 33 macrocells, probably less.
> >
> >
> > 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.
> >
> >
> >
> >>  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.
> >>
> >>Why not use a 64MC device in CS package?
> >
> >
> > 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.
>
> 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.

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.

0
rickman
11/4/2006 10:26:58 PM
Jim Granville wrote:
> rickman wrote:
>
> > Jim Granville wrote:
> >>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.
> >
> >
> > 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.
>
> 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 :)

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


> 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.

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.

0
rickman
11/6/2006 1:03:16 PM
rickman wrote:
> Jim Granville wrote:
> 
>>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.
> 
> 
> 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

0
Jim
11/6/2006 7:16:08 PM
Reply: