Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 15025

Article: 15025
Subject: Re: Clock divider
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 03 Mar 1999 11:21:29 -0800
Links: << >>  << T >>  << A >>
Yves Savard wrote:

> I need for clocks out, one at  236,16Khz, a other at
> 245Khz, thirth
> 254,8Khz and the last 269,5kHz from reference crystal at
> 10Mhz i need a PLD
> or PFGA to make a counter with 4 output for each frequency
> !!
> My question what the best I can use for this ?
>  
>  

It is inherently impossible to derive the frequencies
mentioned from a 10 MHz crystal, if you expect jitter-free
output clocks. The reason is simple: Any edge derived from a
10 MHz input will be on boundaries that are n times 100 ns
apart, but the frequencies mentioned have periods that are
not integer multiples of 100 ns.

Now, you can cheat and generate average freuencies that come
very close to your desired values, by using direct digital
synthesis or phase accumulators, but you must first decide
how much systematic jitter you can accept.

Peter Alfke, Xilinx Applications
  

Article: 15026
Subject: Re: Asynchronous resets: How tricky?
From: bob@nospam.thanks (Bob Perlman)
Date: Wed, 03 Mar 1999 19:27:52 GMT
Links: << >>  << T >>  << A >>
On Wed, 3 Mar 1999 09:48:57 -0800, "Joel Kolstad"
<JKolstad@Electroglas.Com> wrote:

>Assume you have a state machine that has some "interesting" state
>encoding... say the reset state encodes to 1010, and then the state machine
>always steps to a state encoded by 0101.  This state machine has an
>asynchronous reset input, which comes from a pin on a CPLD or FPGA.  The
>clock to this synchronous state machine also comes from a pin.
>
>Isn't a completely asynchronous reset input just asking for trouble?  While
>reset is active, the state machine is sitting at 1010.  If I now assume that
>reset goes inactive just a split (nano)-second before the active clock edge,
>I don't have any guarantees at all that some of the state encoding bits are
>going to transition to their expected new values, whereas some won't
>transition at all, correct?

Absolutely correct.  If the reset is deasserted asynchronously at or
near the active clock edge, your next state may be hash.

>If this is really an issue, it would appear that the correct way to apply an
>asynchronous reset is to first run it through a synchronizer before applying
>it to the asynchronous reset input of the state machine.

The rule I follow is to assert reset asynchronously and deassert it
synchronously.  Resetting asynchronously ensures that the state
machine initializes correctly even in the absence of a good clock;
this can be important if, say, the state machine is controlling
TriState buffers that must not contend (and that might contend if the
state machine is in an illegal state).   Deasseting reset
synchronously circumvents the problem you described.

There are situations in which asynchronous assertion/deassertion is
OK, though.  If you can guarantee that the state machine isn't going
to transition states immediately after reset is deasserted, then
asynchronous deassertion should work (counter-examples, anyone?).
Clearly, this doesn't work for the state machine you've described,
which transitions to the next state immediately, rather than waiting
for an input.  I prefer to always synchronize deassertion, so as not
to have to guard against all possible cases of immediate state change.

Bob Perlman


-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.best.com/~bobperl/cdw.htm
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------
Article: 15027
Subject: Re: Asynchronous resets: How tricky?
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 03 Mar 1999 11:30:28 -0800
Links: << >>  << T >>  << A >>
Joel Kolstad wrote:

> Isn't a completely asynchronous reset input just asking
> for trouble?

> snip

> If this is really an issue, it would appear that the
> correct way to apply an
> asynchronous reset is to first run it through a
> synchronizer before applying
> it to the asynchronous reset input of the state machine.
>
> ---Joel Kolstad

 You got it. There was a spirited discussion here about this
subject in late Dec 98.
Peter Alfke, Xilinx Applications 

Article: 15028
Subject: Re: graphic Lcd control core
From: "saffary" <saffary@club-internet.fr>
Date: Wed, 3 Mar 1999 20:37:48 +0100
Links: << >>  << T >>  << A >>

Davide Rizzo a écrit dans le message <7bjm50$io$1@nslave1.tin.it>...
>"saffary" <saffary@club-internet.fr> wrote:
>
>>Does anyone have a lcd cntrol core, and ,or info about this.
>
>>Thanks
>
>
>Please be more specific, which kind of LCD ? Static, multiplexed, or
>grafic? How many segments (/pixels) ?
>
>

Grafic (128*64 )

Thanks



Article: 15029
Subject: Re: Clock divider: 100MHz->40MHz
From: "Joel Kolstad" <JKolstad@Electroglas.Com>
Date: Wed, 3 Mar 1999 11:47:09 -0800
Links: << >>  << T >>  << A >>
Bob Sefton wrote in message <36DD861A.5B0EF4A9@home.com>...
>Create a divide_by_5 circuit, delay it by 2.5 cycles, then OR the
>original and delayed versions together.

OK, but how do I reliably create a "delay by half a cycle" circuit?  At the
rising edge of the 100MHz clock, say my divide_by_circuit circuit fires an
output active.  To delay by half a clock, another register has to pick up
this active output on the falling edge of that same clock, 5ns later,
correct?  Hence you need a CPLD that could internally clock at 200MHz, no?

Thanks for the the response.

---Joel Kolstad


 Any CPLD that can clock on
>both edges of the 100MHz clock should be able to do this. You may
>then want to register the ORed result again with 100MHz.
>
>Bob S.
>
>Joel Kolstad wrote:
>>
>> Does anyone have a clever circuit that can divide an input clock by two
and
>> a half?  We're looking to go from 100MHz down to 40MHz.  I've thought of
a
>> couple of ways to do this, but they all had some asynchronous parts to
them
>> that required that I could guarantee minimum propagation delays.  In a
>> 100MHz part I didn't really want to have to guess at the minimum
propagation
>> delays (neither Xilinx nor Cypress nor Vantis -- vendors whose CPLDs
we're
>> thinking of implementing this in -- mention their minimum propagation
delays
>> in the data sheets that I looked at).
>>
>> Additionally I don't want to buy a faster speed grade device -- any
change
>> in speed grade would cost more than the ~$3 of an external PLL.  (In
which
>> case I'd divide by 5 and multiply by 2.)
>>
>> Most CPLDs these days can clock on either edge of the incoming clock, and
it
>> initially seemed that a design that had two "divide by fives" and then
>> combinatorially ORed the results together would work.  Getting the two
>> circuits synchronized is the problem.  Either they have to rely on each
>> other's output, which effectively means the design is running at 200MHz
>> internally, or they have to rely on an external result pulse, and
generating
>> it at the exact time point required appeared difficult.
>>
>> ---Joel Kolstad


Article: 15030
Subject: Re: experience with Xilinx 4K series I/Os
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Wed, 03 Mar 1999 11:54:35 -0800
Links: << >>  << T >>  << A >>
"FPGA system clock speed" usually refers to the maximum rate at which
an output flip-flop can reliably drive an input flip-flop on
another device of the same type. The SUM of the clock-to-output and
input setup times must be less than the clock cycle time, i.e.
12.5 ns for 80 MHz. The '98 Xilinx book shows the smaller -09
parts meeting this spec (4005XL: 5.4ns Tickof + 5.6 ns Tpsd = 11ns)
using fast outputs, but add 1.7 ns for slew-rate limited outputs.
And subtract 0.8 ns if the capacitive loading is 20pf instead of 50 pf.
The bigger parts have slower I/O: 9 + 8.4 = 17.4 ns or 57 MHz for
the 4085. Various tricks with fast clocks, using no-delay IFF's etc.
can help somewhat, but reliable 100 MHz system clock rates are still a
challenge with these parts. The XLA and Spartan look better for
100 MHz operation.



Pierre Langlois wrote:
> 
> Hello all,
> 
> I find that the Xilinx documentation is vague on this subject.  For
> example, for a certain design I have, the TRACE tool reports that all
> constraints are met for a clock frequency of 100 MHz in a X4000XL-09
> chip.  This includes 10ns constraints on "from pads to INFF" and "from
> OUTFF to pads".  This is consistent with "IOB Input and Output Switching
> Characteristic Guidelines" for the family, which list propagation delays
> all well under 5ns for the XL-09 family.
> 
> However, the generic Xilinx document "XC4000E and XC4000X Series FPGAs",
> dated Nov 10, 1997, says that the devices " ... can run at synchronous
> system clock rates of up to 80 MHz, and internal performance can exceed
> 150 MHz."
> 
> Is there some limitation that kicks in at 80 MHz for the I/Os?  What is
> it?  Any suggestions on how to get around it?  Thanks in advance.
> 

-- 
Tom Burgess
Email:        tom.burgess@hia.nrc.ca
Article: 15031
Subject: Bidirectional buffers with Orca?
From: allen@hpfcacn.fc.hp.com (Allen Norskog)
Date: 3 Mar 1999 20:13:36 GMT
Links: << >>  << T >>  << A >>
I was having problems with inserting bi-directional buffers with
an Orca FPGA.  I have tried both using the "insert_pads" command
with Synopsys and instantiating directly a "BTZ6" cell.  From
what I can tell, it looks like the output buffer side is staying
tri-stated.

Previously, I had been using two pins tied together (one in, and 
the other a simple tri-state out) and this has worked fine.  But,
I would like to not have to do this for a larger set of signals
that I now need to use.

Curious if there are any "tricks" or bugs that I'm not aware of.

Thanks for any help.

--
--
Allen Norskog
Hewlett-Packard
allen@fc.hp.com  (970) 898-9120    FAX: (970) 898-6580
Article: 15032
Subject: Re: Clock divider
From: robert.schoerghuber@home.ins.removethis.de (Robert Schoerghuber)
Date: Wed, 03 Mar 1999 20:16:53 GMT
Links: << >>  << T >>  << A >>
Hi Yves,
 as counters cannot provide the fractional divisions you need, you'll
have to use another method. Search the web for "direct digital
synthesis" to get more information about a recommendable one than i
could write here.

On Wed, 03 Mar 1999 15:33:57 GMT, "Yves Savard" <ysavard@riq.qc.ca>
wrote:
>I need for clocks out, one at  236,16Khz, a other at 245Khz, thirth
>254,8Khz and the last 269,5kHz from reference crystal at 10Mhz i need a PLD
>or PFGA to make a counter with 4 output for each frequency !!
>My question what the best I can use for this ?
>
>Thank you !!

Article: 15033
Subject: Embedded jobs - Ipswich/Cambridge - UK
From: "Murray Newlands" <mrn@tngrec.com>
Date: Wed, 3 Mar 1999 20:55:03 -0000
Links: << >>  << T >>  << A >>
TNG associates
301 Histon Road
Cambridge
CB4  3NF
Tel  01223 358988
Fax 01223 358970
web site  http://tngrec.com
e-mail     mrn@tngrec.com


Hello!

I hope that this communication does not breach newsgroup etiquette. We are
placing it (manually) on a small number of specialist sites.

We are keen to hear from any embedded engineers who would like to look at
other job opportunities.  The type of positions we are dealing with can be
seen on our Website.

We guarantee that CVs are never sent out without the permission of the
individual on each separate occasion, and even then are only sent to
specific companies who have expressed interest in receiving such details
from us.  Indeed, the majority of the positions we are handling are
exclusive to us.

We hope to hear from you.

Yours,


Murray Newlands


Example

Senior Software Design Engineer.
Idyllic rural location near Ipswich.
Salary negotiable
The company designs, develops and manufactures systems for subtitle
generation, storage and transmission, for sale to the Broadcasting Industry.
Strong ‘C’ programming in embedded real-time systems are the core skills
required.
Ref 1739n Contact Michael Wyatt at mjw@tngrec.com



Article: 15034
Subject: Re: Clock divider: 100MHz->40MHz
From: Bob Sefton <rsefton@home.com>
Date: Wed, 03 Mar 1999 21:22:11 GMT
Links: << >>  << T >>  << A >>
True. I should have read your entire post. You don't want to pay
the premium for that much speed.

If you can handle 5ns (1/2 of a 100MHz cycle) of jitter on the
40MHz clock you can alternately div_by_2/div_by_3. Otherwise it
sounds like the PLL is your best (and most flexible) bet.

Good luck.

Bob S.

Joel Kolstad wrote:
> 
> Bob Sefton wrote in message <36DD861A.5B0EF4A9@home.com>...
> >Create a divide_by_5 circuit, delay it by 2.5 cycles, then OR the
> >original and delayed versions together.
> 
> OK, but how do I reliably create a "delay by half a cycle" circuit?  At the
> rising edge of the 100MHz clock, say my divide_by_circuit circuit fires an
> output active.  To delay by half a clock, another register has to pick up
> this active output on the falling edge of that same clock, 5ns later,
> correct?  Hence you need a CPLD that could internally clock at 200MHz, no?
> 
> Thanks for the the response.
> 
> ---Joel Kolstad
Article: 15035
Subject: Re: Clock divider: 100MHz->40MHz
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 03 Mar 1999 13:32:13 -0800
Links: << >>  << T >>  << A >>
Joel Kolstad wrote:

> Does anyone have a clever circuit that can divide an input
> clock by two and
> a half?  We're looking to go from 100MHz down to 40MHz.

The easiest, simplest and safest method is to cheat and
build a circuit that divides alternatingly by 2 and by 3. So
it generates two output periods for every five input
periods. You have your 40 MHz average output frequency, but
the two adjacent output periods are of unequal length, one
of them 20 ns, the other one 30 ns.  That circuit is trivial
to implement in two CLBs.

The price you pay is that, worst-case, the output is as
demanding as 50 MHz, and the spectrum is not pure.
May be good enough in many applications.

Peter Alfke, Xilinx
 

>   

Article: 15036
Subject: Re: Getting started in programmable logic
From: Steve@s-deweynospam.demon.co.uk (Steve Dewey)
Date: Wed, 03 Mar 99 21:33:48 GMT
Links: << >>  << T >>  << A >>

Hi Robert

About a couple of years ago I was at the point you describe, and went with 
Altera. Their MaxplusII software includes a library of TTL macrofunctions that 
can easily be included in your design. However once you get the hang of their
LPMs (Library of Parameterised Megafunctions) I doubt you'll use them very much.

A good example is the 10 bit counter you need. Typically you might have to wire 
that up using 3 4-bit counters, if restricted to TTL 74 series style functions. 
The alternative is just to use a LPM_COUNTER WITH (LPM_WIDTH=9). If your 
requirment changes, then just change the LPM_WIDTH value. If you choose to 
design in Altera Hardware Design Language (AHDL) you can define a parameter 
early in the design file, and declare your counter and any other datapath 
elements in terms of that parameter. This parameter can be passed down to
whatever level of hierarcy nesting you like.

I know of no other HDLs that provide this facility - allowing that VHDL & 
Verilog are synthesis languages rather than simple hardware description 
languages. Please correct me if I'm wrong.

Initially I'd say stay away from VHDL & Verilog - their way too complicated for
what you describe. 

Hardware wise look at Altera's MAX7000S series, the schematic for a parallel 
port programmer is on their website. 5 volt family.

Other useful sites are www.freecore.com - a collection of utilities, modules &
tutorials for Altera parts. www.optimagic.com has a whole bunch of useful stuff.

Disclaimer: I speak as a satisfied Altera customer who uses their parts for 
low speed (<20 MHz) designs. I have no other relationship with Altera. 


In article <19990302151902.13531.00003629@ng-ch1.aol.com>
           robert4422@aol.com "Robert4422" writes:

> Hello folks,
> 
> I am trying to get started in programmable logic, but so far having somewhat of
> a hard time.  I have a simple project sitting in my digital circuit emulator
> program, and I would like to realize it using some kind of programmable logic
> device.  Actually, I had been planning to realize the design in discrete 74xx
> TTL's (it's that simple--just a 10-bit counter, some AND gates, some flip
> flops, and some NAND gates), but I thought this might be a good time to get
> into the world of programmable logic devices.  So far, however, I'm having a
> lot of trouble sorting through all the different kinds of devices that are
> available, and was wondering if anyone here could help me out.
> 
> Specifically, perhaps someone could help me with the following questions:
> 
> 1.  What kind of programmable devices should I be looking into to implement the
> design mentioned above?  I assume the presence of flip-flops and an n-bit
> counter is a little beyond the level of PALs and GALs, but perhaps I'm wrong? 
> Is FPGA what I need/want, or something else entirely?
> 
> 2.  Moreover, can someone give a brief description of the differences between
> the major families of programmable devices?  e.g., PAL vs. GAL vs FPGA etc. 
> (if there's a FAQ or other reference that does this, please just point me to
> it.)
> 
> 3.  Which families of devices have TTL-level inputs/outputs?
> 
> 4.  What are some good introductory reference materials?  Books, websites, etc.
> 
> Thank you for your time and help in getting a beginner started!
> 
> Rob
> 
> 
> 

-- 
Steve Dewey
Steve@s-deweynospam.demon.co.uk
Too boring to have an interesting or witty .sig file.

Article: 15037
Subject: Re: Clock divider: 100MHz->40MHz
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 03 Mar 1999 14:16:48 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> JThe easiest, simplest and safest method is to cheat and
> build a circuit that divides alternatingly by 2 and by 3.
> So
> it generates two output periods for every five input
> periods. You have your 40 MHz average output frequency,
> but
> the two adjacent output periods are of unequal length, one
>
> of them 20 ns, the other one 30 ns.  That circuit is
> trivial
> to implement in two CLBs.
>
> The price you pay is that, worst-case, the output is as
> demanding as 50 MHz, and the spectrum is not pure.
> May be good enough in many applications.

Joel told me that he cannot tolerate the jitter.So here is
the real solution:
Do as described above, then add one more flip-flop, clocked
on the opposite edge and straddling the boundary between the
two output periods. Then use an OR gate to force the output
Low for an additional half period of the incoming clock.

Advantage: no possible glitches, no flip-flop with tight
timing requirements.
Disadvantage: one unavoidable additional gate delay behind
the flip-flop.

Cost: 2 or max 3 CLBs.
Incremental cost of a CLB is often zero, when it's just
there, sitting unused.
The statistical average cost of a CLB is around 10 cents. So
this beats the external $3.- extra component by a long shot.

Fun stuff.
Peter Alfke, Xilinx

>  
>
> Peter Alfke, Xilinx
>  
>
> >

  

Article: 15038
Subject: Re: Clock divider: 100MHz->40MHz
From: Catalin <no@spam.com>
Date: Wed, 03 Mar 1999 17:30:58 -0500
Links: << >>  << T >>  << A >>
Joel Kolstad wrote:

> Does anyone have a clever circuit that can divide an input clock by two and
> a half?  We're looking to go from 100MHz down to 40MHz.  I've thought of a
> couple of ways to do this, but they all had some asynchronous parts to them
> that required that I could guarantee minimum propagation delays.  In a
> 100MHz part I didn't really want to have to guess at the minimum propagation
> delays (neither Xilinx nor Cypress nor Vantis -- vendors whose CPLDs we're
> thinking of implementing this in -- mention their minimum propagation delays
> in the data sheets that I looked at).
>
> Additionally I don't want to buy a faster speed grade device -- any change
> in speed grade would cost more than the ~$3 of an external PLL.  (In which
> case I'd divide by 5 and multiply by 2.)
>
> Most CPLDs these days can clock on either edge of the incoming clock, and it
> initially seemed that a design that had two "divide by fives" and then
> combinatorially ORed the results together would work.  Getting the two
> circuits synchronized is the problem.  Either they have to rely on each
> other's output, which effectively means the design is running at 200MHz
> internally, or they have to rely on an external result pulse, and generating
> it at the exact time point required appeared difficult.
>
> ---Joel Kolstad

The Vantis CPLD family MACH5 has FFs that can toggle on both clock edges (and
with two clock enables, one for each edge). If you use a divide by 5 binary
counter that counts on both 100MHz clock edges you will get a 40MHz output (with
40%-60% duty factor on Q1 and 20%-80% on Q2). Since this solution is completely
synchronous you do not have minimum delay problems.

Catalin Baetoniu


Article: 15039
Subject: Re: Asynchronous resets: How tricky?
From: Bob Sefton <rsefton@home.com>
Date: Wed, 03 Mar 1999 22:49:59 GMT
Links: << >>  << T >>  << A >>
The other way to go is to have everything reset to a passive
state. When the async reset is removed the circuit stays put until
some synchronous event which you control triggers it. The
synchronous event could be a timeout, a microcontroller register
write, or even a synchronized version of your async reset used as
an input to the state machine vs. as an async reset. Much better
way to go IMO and allows you to make use of the built-in global
reset logic in the device.

Bob S.

Joel Kolstad wrote:
> 
> Assume you have a state machine that has some "interesting" state
> encoding... say the reset state encodes to 1010, and then the state machine
> always steps to a state encoded by 0101.  This state machine has an
> asynchronous reset input, which comes from a pin on a CPLD or FPGA.  The
> clock to this synchronous state machine also comes from a pin.
> 
> Isn't a completely asynchronous reset input just asking for trouble?  While
> reset is active, the state machine is sitting at 1010.  If I now assume that
> reset goes inactive just a split (nano)-second before the active clock edge,
> I don't have any guarantees at all that some of the state encoding bits are
> going to transition to their expected new values, whereas some won't
> transition at all, correct?
> 
> If this is really an issue, it would appear that the correct way to apply an
> asynchronous reset is to first run it through a synchronizer before applying
> it to the asynchronous reset input of the state machine.
> 
> ---Joel Kolstad
Article: 15040
Subject: Looking for advice on CPLD's
From: mesenich@t-online.de (Gerhard Mesenich)
Date: Thu, 4 Mar 1999 00:13:25 +0100
Links: << >>  << T >>  << A >>
Hi
I intend to start to start with isp CPLD designs.

My designs are usually quite simple. They are mainly intended for simple
state machines,  address decoding, input/output buffering of analog
converters and input capture of digital signals. They will mainly be used
with 16bit DSP's. Packages should ideally be PLCC 44/84 (easy handling on
experimental boards). I am already familiar with small PAL's (20v8 etc.).

I have looked already at several chips. These are:

Xilinx - XC 95xx
Altera - MAX 7000
Lattice - ispl..

My applications are low volume/ research type. I do design work only very
infrequently, so the design software should be as simple as possible and
somewhat foolproof. A simple homebrewed parallel port cable should hopefully
do the programming.

Are there any suitable free integrated software packages?

Which family/ software package is best suited to my need? What are the
approx. prices and how is availability? How well does schematic capture
work - is it useful?

Thanks a lot for any help, opinion and recommendation.


Article: 15041
Subject: Re: Clock divider: 100MHz->40MHz
From: Lasse Langwadt Christensen <fuz@kom.auc.dk>
Date: Thu, 04 Mar 1999 00:03:23 GMT
Links: << >>  << T >>  << A >>
Catalin wrote:
> 
snip
> 
> The Vantis CPLD family MACH5 has FFs that can toggle on both clock edges (and
> with two clock enables, one for each edge). If you use a divide by 5 binary
> counter that counts on both 100MHz clock edges you will get a 40MHz output (with
> 40%-60% duty factor on Q1 and 20%-80% on Q2). Since this solution is completely
> synchronous you do not have minimum delay problems.
> 
> Catalin Baetoniu

how about using the divided clock to enable/disable the edges? 

count three rising edges, invert clk_out, count three
falling edges invert clk_out.....  

increment counter here:(on rising when clk_out = 1, on falling when
clk_out = 0)
        |   |   | |   |   | |   |   | |
        v   v   v v   v   v v   v   v v    
         _   _   _   _   _   _   _   _   _   
clk    _| |_| |_| |_| |_| |_| |_| |_| |_| |
        ________           _________  
clk_out         \_________/         \____ 
 
is it possible ?

--L2C                 
--___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
Lasse Langwadt Christensen, MSEE (to be in 1999) 
Aalborg University, Department of communication tech.    
Applied Signal Processing and Implementation (ASPI)      
http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org
Article: 15042
Subject: Re: Asynchronous resets: How tricky?
From: bob@nospam.thanks (Bob Perlman)
Date: Thu, 04 Mar 1999 00:29:30 GMT
Links: << >>  << T >>  << A >>
On Wed, 03 Mar 1999 22:49:59 GMT, Bob Sefton <rsefton@home.com> wrote:

>The other way to go is to have everything reset to a passive
>state. When the async reset is removed the circuit stays put until
>some synchronous event which you control triggers it. The
>synchronous event could be a timeout, a microcontroller register
>write, or even a synchronized version of your async reset used as
>an input to the state machine vs. as an async reset. Much better
>way to go IMO and allows you to make use of the built-in global
>reset logic in the device.

I should have elaborated further.  I sent the following to Joel a few
hours ago:

----------
I work mostly with Xilinx chips, so I tend to do something a bit 
different [than creating a single reset that asserts synchronously and
deasserts synchronously].  The global reset nets in Xilinx parts can
be pretty slow; for some of the larger 4KXL devices, delays can be as
long as 35ns.  (To complicate matters even more, I can't find reset
recovery times for the CLB flip-flops.)  With a reset net this slow,
it may not be possible to guarantee that even a synchronized reset
deasserts in a single state machine clock cycle.

To get around these problems, I feed my state machines both an 
asynchronous reset and a synchronous reset.  The async reset is 
usually just the global chip reset.  The synchronous reset is 
created with two or three flip-flops wired in series, with the D of
the first flip-flop wired HIGH.  The flip-flops are reset by global
reset; when global reset is deasserted, a HIGH propagates through the
flip-flops; the output of the last flip-flop is inverted and fed to
the state machine flip-flops as a synchronous input.  One advantage of
this approach is that if your design contains state machines operating
at different frequencies, they can still share the global asynchronous
reset net.
----------

By the way, the comment about slow global reset nets is not a knock
against Xilinx.  I suspect that other vendors' parts are comparable.

Bob Perlman


-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.best.com/~bobperl/cdw.htm
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------
Article: 15043
Subject: Re: Clock divider: 100MHz->40MHz
From: "Joel Kolstad" <JKolstad@Electroglas.Com>
Date: Wed, 3 Mar 1999 17:22:02 -0800
Links: << >>  << T >>  << A >>
Catalin wrote in message <36DDB822.DD4263E3@spam.com>...
>The Vantis CPLD family MACH5 has FFs that can toggle on both clock edges
(and
>with two clock enables, one for each edge). If you use a divide by 5 binary
>counter that counts on both 100MHz clock edges you will get a 40MHz output
(with
>40%-60% duty factor on Q1 and 20%-80% on Q2). Since this solution is
completely
>synchronous you do not have minimum delay problems.

This requires you to buy a device with a "counting" frequency of 200MHz
though, doesn't it?

BTW, for other people who have offered suggestions -- thanks.  Since there's
been some confusion as to what the requirements of the output are, I'll
explain further.  The 40MHz output is a pixel clock to a frame grabber.  The
frame grabber has a PLL on-board, so it wants a 40MHz input that has
relatively low jitter from one cycle to the next (the PLL happens to be a
Cypress CY7C992 RoboClock).  The output doesn't have to be precisely 40MHz;
something within +5%/-10% would be OK as well.

---Joel Kolstad



Article: 15044
Subject: Re: Asynchronous resets: How tricky?
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 03 Mar 1999 18:10:04 -0800
Links: << >>  << T >>  << A >>

--------------CC6F767DDE0CB83F33914371
Content-Type: text/plain; charset=iso-8859-1; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 8bit

Bob Perlman wrote:

> The global reset nets in Xilinx parts can
> be pretty slow; for some of the larger 4KXL devices,
> delays can be as
> long as 35ns.  (To complicate matters even more, I can't
> find reset
> recovery times for the CLB flip-flops.)  With a reset net
> this slow,
> it may not be possible to guarantee that even a
> synchronized reset
> deasserts in a single state machine clock cycle.
>
> To get around these problems, I feed my state machines
> both an
> asynchronous reset and a synchronous reset.  The async
> reset is
> usually just the global chip reset.  The synchronous reset
> is
> created with two or three flip-flops wired in series, with
> the D of
> the first flip-flop wired HIGH.  The flip-flops are reset
> by global
> reset; when global reset is deasserted, a HIGH propagates
> through the
> flip-flops; the output of the last flip-flop is inverted
> and fed to
> the state machine flip-flops as a synchronous input.  One
> advantage of
> this approach is that if your design contains state
> machines operating
> at different frequencies, they can still share the global
> asynchronous
> reset net.
> ----------
>  

This is what I posted on my internal information page, for
use by Xilinx applications engineers. It agrees with Bob's
idea.
 

Beware of the Asynchronous Global Reset.

GSR is a nice and efficient feature, since it consumes no
available routing resources. But it also is slow, which can
lead to ugly problems.

When the design includes a state machine, GSR will make sure

that it is automatically reset during configuration, and
also any time GSR is activated. The problem is the slow
routing, and thus the slow trailing edge of this signal. It
can take more than 30 ns to reach all flip-flops.
It is thus quite probable that one user clock edge occurs
during this time, while some flip-flops are still being held

reset, but others have already been released. As a result,
the state machine might do strange things, even go into
never-never land.

The work-around is to give the critical flip-flops an
additional synchronous (!) reset input that stays active for

a few clock ticks after GSR has been released. That assures
that the state machine will wake up properly and not stumble

on its first step “out-of-bed”.

Peter Alfke
 
 

--------------CC6F767DDE0CB83F33914371
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<HTML>
<BODY BGCOLOR="#FFFFFF">
Bob Perlman wrote:
<BLOCKQUOTE TYPE=CITE>The global reset nets in Xilinx parts can
<BR>be pretty slow; for some of the larger 4KXL devices, delays can be
as
<BR>long as 35ns.&nbsp; (To complicate matters even more, I can't find
reset
<BR>recovery times for the CLB flip-flops.)&nbsp; With a reset net this
slow,
<BR>it may not be possible to guarantee that even a synchronized reset
<BR>deasserts in a single state machine clock cycle.

<P>To get around these problems, I feed my state machines both an
<BR>asynchronous reset and a synchronous reset.&nbsp; The async reset is
<BR>usually just the global chip reset.&nbsp; The synchronous reset is
<BR>created with two or three flip-flops wired in series, with the D of
<BR>the first flip-flop wired HIGH.&nbsp; The flip-flops are reset by global
<BR>reset; when global reset is deasserted, a HIGH propagates through the
<BR>flip-flops; the output of the last flip-flop is inverted and fed to
<BR>the state machine flip-flops as a synchronous input.&nbsp; One advantage
of
<BR>this approach is that if your design contains state machines operating
<BR>at different frequencies, they can still share the global asynchronous
<BR>reset net.
<BR>----------
<BR>&nbsp;</BLOCKQUOTE>
This is what I posted on my internal information page, for use by Xilinx
applications engineers. It agrees with Bob's idea.
<BR>&nbsp;
<H3>
Beware of the Asynchronous Global Reset.</H3>


<P>GSR is a nice and efficient feature, since it consumes no
<BR>available routing resources. But it also is slow, which can
<BR>lead to ugly problems.

<P>When the design includes a state machine, GSR will make sure
<BR>that it is automatically reset during configuration, and
<BR>also any time GSR is activated. The problem is the slow
<BR>routing, and thus the slow trailing edge of this signal. It
<BR>can take more than 30 ns to reach all flip-flops.
<BR>It is thus quite probable that one user clock edge occurs
<BR>during this time, while some flip-flops are still being held
<BR>reset, but others have already been released. As a result,
<BR>the state machine might do strange things, even go into
<BR>never-never land.

<P>The work-around is to give the critical flip-flops an
<BR>additional synchronous (!) reset input that stays active for
<BR>a few clock ticks after GSR has been released. That assures
<BR>that the state machine will wake up properly and not stumble
<BR>on its first step “out-of-bed”.

<P>Peter Alfke
<BR>&nbsp;
<BR>&nbsp;
</BODY>
</HTML>

--------------CC6F767DDE0CB83F33914371--

Article: 15045
Subject: Re: Clock divider: 100MHz->40MHz
From: Bob Sefton <rsefton@home.com>
Date: Thu, 04 Mar 1999 04:10:47 GMT
Links: << >>  << T >>  << A >>
Joel -

A trick the RF guys like to play is to filter and amplify an odd
harmonic from a lower frequency square-wave clock, e.g., you could
divide 100MHz by 15 and pick out the third harmonic of that
signal. I think this can be done for much less than $3 and will
give you a very clean clock. You filter a sine wave from a square
wave and then convert it back to a square wave using a CMOS gate.

I've always had the luxury of being able to spend the cash for a
faster PLD, but problems like this can be fun to solve. Please
post your final solution.

Bob S.

Joel Kolstad wrote:
> 
> Catalin wrote in message <36DDB822.DD4263E3@spam.com>...
> >The Vantis CPLD family MACH5 has FFs that can toggle on both clock edges
> (and
> >with two clock enables, one for each edge). If you use a divide by 5 binary
> >counter that counts on both 100MHz clock edges you will get a 40MHz output
> (with
> >40%-60% duty factor on Q1 and 20%-80% on Q2). Since this solution is
> completely
> >synchronous you do not have minimum delay problems.
> 
> This requires you to buy a device with a "counting" frequency of 200MHz
> though, doesn't it?
> 
> BTW, for other people who have offered suggestions -- thanks.  Since there's
> been some confusion as to what the requirements of the output are, I'll
> explain further.  The 40MHz output is a pixel clock to a frame grabber.  The
> frame grabber has a PLL on-board, so it wants a 40MHz input that has
> relatively low jitter from one cycle to the next (the PLL happens to be a
> Cypress CY7C992 RoboClock).  The output doesn't have to be precisely 40MHz;
> something within +5%/-10% would be OK as well.
> 
> ---Joel Kolstad
Article: 15046
Subject: Re: Selt-Timed circuit
From: Lasse Langwadt Christensen <fuz@kom.auc.dk>
Date: Thu, 04 Mar 1999 08:00:10 GMT
Links: << >>  << T >>  << A >>
alex_schreiber@my-dejanews.com wrote:
> 
> Hi,
> 
snip
> 
> In traditional (synchronous) design techniques you always have
> the problems of wiring delays. This becomes even more problematic
> when you are moving towards smaller gate length (Very Deep SubMicron).
> The transistor switching time becomes less important in comparison
> to the wire delay. Additionally the amount of gates per area becomes
> higher as well, which leads to longer clock nets as well.

smaller chips leading to longer nets, that doesn't make sense ?

> 
> In a synchronous system you need to guarantee that there is not too
> much skew between the each clock input of the same clock net. The
> effort to achieve this becomes higher and higher.
> 
> Exactly here is the advantage of self-timed logic. Because a
> proceeding action is triggered by the completion of the previous
> one, you do not have such distribution problems.

won't you have more or less the same problems, just on the signals
timing instead of the clock?

> 
> You can have a look on articles of the following authors:
> 
>   Robert Broderson (Berkeley University, early 90s)
>   Eric Brunvand (Carnegy Mellon University, early 90s)
> 
> As far as I remember the approach of E. Brunvand is not
> delay insensitive, but he implemented it into FPGAs.
> 
> The whole topic is not just a theoretic playing. Philips
> implemented an error correction algorithm using this
> technique.
> 
snip


 
--L2C                 
--___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
Lasse Langwadt Christensen, MSEE (to be in 1999) 
Aalborg University, Department of communication tech.    
Applied Signal Processing and Implementation (ASPI)      
http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org
Article: 15047
Subject: Re: Selt-Timed circuit
From: davewang@cslab.kecl.ntt.co.jp.DELETE.delete.DELETE@Glue.umd.edu (David T. Wang)
Date: 4 Mar 1999 08:15:06 GMT
Links: << >>  << T >>  << A >>
alex_schreiber@my-dejanews.com wrote:
: Hi,

: in self-timed logic there is no global clock existing, i.e.
: from this point of view it's an asynchronous design technique.
: But it's not at all based on race conditions and wiring delays
: as it is the case when you have asynchronous parts in a
: synchronous design.

: Usually a very strict 4-phase-full handshake protocoll is
: implemented, which is based on 'request' and 'acknowledge'
: signals (to be a bit faster you can also use a 2-phase
: handshake protocoll). This protocoll implies two things:

:   - control overhead
:   - special kind of logic gates (SSDL)

: To be able to generate an acknowledge signal as a result
: of the evaluation of the logic, special logic gates with
: differential outputs are needed like Sample Set Differential
: Logic (SSDL).

: In traditional (synchronous) design techniques you always have
: the problems of wiring delays. This becomes even more problematic
: when you are moving towards smaller gate length (Very Deep SubMicron).
: The transistor switching time becomes less important in comparison
: to the wire delay. Additionally the amount of gates per area becomes
: higher as well, which leads to longer clock nets as well.

: In a synchronous system you need to guarantee that there is not too
: much skew between the each clock input of the same clock net. The
: effort to achieve this becomes higher and higher.

: Exactly here is the advantage of self-timed logic. Because a
: proceeding action is triggered by the completion of the previous
: one, you do not have such distribution problems.

IMO, the world is moving toward a model of "locally synchronous",
globally asynchronous" model.  You can subdivide the clock nets,
and only distribute within a relatively small area.  Communications
with another net will have to be passed through an interface
that can absorbe the differential in local clock signals.  
Perhaps even by self timed circuits!  I still think that async
design is too hard for a large project, and keeping locally sync
blocks, and just deal with async interface would be a lot easier.

: You can have a look on articles of the following authors:

:   Robert Broderson (Berkeley University, early 90s)
:   Eric Brunvand (Carnegy Mellon University, early 90s)

: As far as I remember the approach of E. Brunvand is not
: delay insensitive, but he implemented it into FPGAs.

: The whole topic is not just a theoretic playing. Philips
: implemented an error correction algorithm using this
: technique.

: Have fun,

:   Alex Schreiber



: In article <36DCDC1C.C1817CD7@ieee.org>,
:   khatib@ieee.org wrote:
: > Hi
: > Please what is the Self-Timed circuit design technique? Is it
: > synchronous, asynchronous or something different?
: >
: > What its advantage over the traditional design techniques?
: >
: > Thanks in advance
: >

: -----------== Posted via Deja News, The Discussion Network ==----------
: http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

--
No SPAM or email wholly without substance please
davewang@cslab.kecl.ntt.co.jp.I.like.green.eggs.and.ham,not.spam
All statements are personal opinions
Not speaking for NTT or University of Maryland
Kyoto, Japan.
Article: 15048
Subject: Re: Selt-Timed circuit
From: davewang@cslab.kecl.ntt.co.jp.DELETE.delete.DELETE@Glue.umd.edu (David T. Wang)
Date: 4 Mar 1999 08:19:42 GMT
Links: << >>  << T >>  << A >>
Lasse Langwadt Christensen (fuz@kom.auc.dk) wrote:
: alex_schreiber@my-dejanews.com wrote:
: > 
: > Hi,
: > 
: > In traditional (synchronous) design techniques you always have
: > the problems of wiring delays. This becomes even more problematic
: > when you are moving towards smaller gate length (Very Deep SubMicron).
: > The transistor switching time becomes less important in comparison
: > to the wire delay. Additionally the amount of gates per area becomes
: > higher as well, which leads to longer clock nets as well.

: smaller chips leading to longer nets, that doesn't make sense ?

smaller transistors leads to an imbalance, as gate delay continues to
drop, but wire delay stays mostly constant, eventually come to dominate.
plot the graph on a percentage basis, it looks like the clock net is
"longer", on chips of the same size, but smaller/faster transistors.

--
No SPAM or email wholly without substance please
davewang@cslab.kecl.ntt.co.jp.I.like.green.eggs.and.ham,not.spam
All statements are personal opinions
Not speaking for NTT or University of Maryland
Kyoto, Japan.
Article: 15049
Subject: Re: Clock divider: 100MHz->40MHz
From: mushh@jps.net (David Decker)
Date: Thu, 04 Mar 1999 08:37:38 GMT
Links: << >>  << T >>  << A >>
"Joel Kolstad" <JKolstad@Electroglas.Com> wrote:

>Does anyone have a clever circuit that can divide an input clock by two and
>a half?  We're looking to go from 100MHz down to 40MHz.  

Here's one additional idea on how to fix the asymmetric problem, if
you have CMOS output pin drivers with fairly symmetrical drive. 

Peter Alfke suggested that it's easy to alternate a divide by two with
a divide by three. Do that and send the output out through a pin. Call
it pin 'A' Couple that back into another pin 'B' via a series
capacitor, perhaps 100 pF. Invert that with an FPGA inverter and send
that back out on a third pin, 'C'. Couple pin 'C' to pin 'B' with a 1M
Ohm resistor. 

The 2/3 signal is the correct frequency, but it's not quite 50% duty
cycle. The non symmetrical duty cycle problem is like a DC offset
problem, and could be fixed if the edges are sloppy enough, and we can
just shift the DC. The cap and resistor is a way to automatically
shift the DC so that the signal entering pin 'B' has its DC exactly at
the Voltage that the inverter will flip. If that's true, the output of
the FPGA inverter should be 50%. Buffer it and have a ball.

The edges of the signal on pin 'A' must be slow enough so that you
could draw a straight line through the signal such that all points,
where the line intersects the signal, are equally spaced. If this is
not so, because the output drivers are just too good, and the edges
are straight up and down,  you might have to slow the edges down with
a series R and a cap to ground between 'A' and the series 100pF Cap.

I haven't tried this with a signal being sourced from the FPGA, but I
have, many times, stolen a little energy from a crystal on a micro,
and coupled it to an FPGA through a CAP using an inverter and 1M to
set the DC. Works every time.

Dave Decker
Diablo Research Co LLC

Dave Decker
Diablo Research Co. LLC

Please use only one 'h' in mush. I'm trying to reduce the spam.



"Animals .  .  . are not brethren they are not 
underlings;  they are other nations, 
caught with ourselves in the net of life and time, 
fellow prisoners of the splendor and travail of 
the earth."
Henry Beston -  The Outermost House


Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search