View Single Post
  #11 (permalink)  
Old 04-15-2006, 07:10 PM
John Larkin
Guest
 
Posts: n/a
Default Re: humble suggestion for Xilinx

On Sat, 15 Apr 2006 17:09:11 +1200, Jim Granville
<[email protected]> wrote:

>John Larkin wrote:
>> On Sat, 15 Apr 2006 10:45:06 +1200, Jim Granville
>> <[email protected]> wrote:
>>
>>
>>>John Larkin wrote:
>>>
>>>>Since the max serial-slave configuration rate on things like Spartan3
>>>>chips is, what, 20 MHz or something, you might consider slowing down
>>>>the CCLK input path, and/or adding some serious hysteresis on future
>>>>parts. On a pcb, CCLK is often a shared SPI clock, with lots of loads
>>>>and stubs and vias and such, so may not be as pristine as a system
>>>>clock. CCLK seems to be every bit as touchy as main clock pins, and it
>>>>really needn't be.
>>>
>>>Wouldn't one expect this to be 'normal design practise' ?
>>>
>>>I suppose Xilinx missed that obvious feature, becasue there are no
>>>other Schmitt cells on the die, and even tho the CPLDs have this,
>>>I'm sure their inter-department sharing is like most large companies
>>>

>>
>>
>> I have it secondhand (one of my guys tells me) that all S3 inputs have
>> about 100 mV of hysteresis. But that's not enough to improve noise
>> immunity in most practical situations.
>>
>> It's good that FPGAs keep getting faster, but not all applications
>> need all that speed, and pickiness about clock edge quality can be a
>> real liability in a lot of slower applications.

>
> True - there is also a slight speed penalty for the full schmitt cells,
>so that's a reason why the speed-at-all-costs FPGA sector ignores the
>benefits.
> Still, the news from Steve K is good
>
>-jg
>


Right. As noted in another thread, one can always add a deglitch
circuit to any input, including clock pins, except for CCLK. So if
that's the only one they slow down, we may elect to routinely deglitch
system clock inputs except when we really need the speed.

I suppose they'll schmitt the jtag pins, too; I don't use them, but
they seem like great candidates for noise problems.

Purists will argue that once the sacred word "clock" is voiced, we are
obliged to drive it appropriately. But it's getting so that a 5 ns
rise with a couple hundred mV of noise is not a reliable clock any
more, and designing brutally fast, star-distributed clocks into a slow
industrial-environment product really doesn't make a lot of sense.

I'd hazard that the majority of FPGAs are used at a fraction of their
speed capability.

John

Reply With Quote