FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 04-14-2006, 03:52 AM
John Larkin
Guest
 
Posts: n/a
Default humble suggestion for Xilinx



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.

John

Reply With Quote
  #2 (permalink)  
Old 04-14-2006, 06:53 AM
John_H
Guest
 
Posts: n/a
Default Re: humble suggestion for Xilinx

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


John,

Are your suggestions for the CCLK generated by the Xilinx device or the
CCLK received by the Xilinx device?

I think the max speed is up to 66 MHz these days in the Spartan3E. It
may not be LVDS rates but it's not 4000 series logic, either.

- John_H
Reply With Quote
  #3 (permalink)  
Old 04-14-2006, 11:03 AM
KJ
Guest
 
Posts: n/a
Default Re: humble suggestion for Xilinx

John Larkin wrote:
> 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.
>


What it's really saying is that when designing a PCB, CCLK should be
treated with as much care and respect as any other clock signal so you
won't have lots of loads, stubs and vias and such.

KJ

Reply With Quote
  #4 (permalink)  
Old 04-14-2006, 02:50 PM
John Larkin
Guest
 
Posts: n/a
Default Re: humble suggestion for Xilinx

On 14 Apr 2006 03:03:17 -0700, "KJ" <[email protected]> wrote:

>John Larkin wrote:
>> 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.
>>

>
>What it's really saying is that when designing a PCB, CCLK should be
>treated with as much care and respect as any other clock signal so you
>won't have lots of loads, stubs and vias and such.
>


And what I'm saying is that treating it as such shouldn't be
necessary.

John


Reply With Quote
  #5 (permalink)  
Old 04-14-2006, 02:53 PM
John Larkin
Guest
 
Posts: n/a
Default Re: humble suggestion for Xilinx

On Fri, 14 Apr 2006 05:53:30 GMT, John_H <[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.
>>
>> John

>
>John,
>
>Are your suggestions for the CCLK generated by the Xilinx device or the
>CCLK received by the Xilinx device?
>


In serial-slave mode, the FPGA receives CCLK.

>I think the max speed is up to 66 MHz these days in the Spartan3E. It
>may not be LVDS rates but it's not 4000 series logic, either.


Right. Improving the noise immunity of the CCLK receiver would have
exactly one practical result: more FPGAs would configure.

John


Reply With Quote
  #6 (permalink)  
Old 04-14-2006, 11:45 PM
Jim Granville
Guest
 
Posts: n/a
Default Re: humble suggestion for Xilinx


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

-jg

Reply With Quote
  #7 (permalink)  
Old 04-14-2006, 11:47 PM
Steve Knapp (Xilinx Spartan-3 Generation FPGAs)
Guest
 
Posts: n/a
Default Re: humble suggestion for Xilinx

Hi John,

Thank you for the feedback. Fortunately, this is already a planned
enhancement on future families.

---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/-3E FPGAs
http://www.xilinx.com/spartan3e
---------------------------------
The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.

Reply With Quote
  #8 (permalink)  
Old 04-15-2006, 12:10 AM
John Larkin
Guest
 
Posts: n/a
Default Re: humble suggestion for Xilinx

On 14 Apr 2006 15:47:28 -0700, "Steve Knapp (Xilinx Spartan-3
Generation FPGAs)" <[email protected]> wrote:

>Hi John,
>
>Thank you for the feedback. Fortunately, this is already a planned
>enhancement on future families.
>


Thank you! Thank you!

Maybe I'm not crazy after all. Maybe.

Next, how about making the real clock inputs programmable to be slower
and less noise sensitive? Yeah, some people are never satisfied.

John


Reply With Quote
  #9 (permalink)  
Old 04-15-2006, 04:03 AM
John Larkin
Guest
 
Posts: n/a
Default Re: humble suggestion for Xilinx

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.

John

Reply With Quote
  #10 (permalink)  
Old 04-15-2006, 06:09 AM
Jim Granville
Guest
 
Posts: n/a
Default Re: humble suggestion for Xilinx

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


Reply With Quote
  #11 (permalink)  
Old 04-15-2006, 06: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
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
software suggestion needed mk Verilog 1 11-16-2005 09:32 AM
Need suggestion abt FFs without RST for pipelined datapath. [email protected] FPGA 5 03-03-2005 02:45 PM
Need suggestion abt FFs without RST for pipelined datapath. [email protected] Verilog 5 03-03-2005 02:45 PM
Any suggestion for an IP project Ouadid FPGA 1 02-19-2005 08:48 PM
Suggestion for Xilinx parallel port cable replacement. T Lee FPGA 9 11-21-2004 11:08 PM


All times are GMT +1. The time now is 05:13 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved