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
2017JanFebMarApr2017

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 11850

Article: 11850
Subject: Re: ASIC -> FPGA async issues
From: Ed McCauley <emccauley@bltinc.com>
Date: Mon, 14 Sep 1998 09:44:05 -0400
Links: << >>  << T >>  << A >>
> Anyway, here's my $0.02 worth: In the Xilinx 4000E parts, the flops have
> clock enables, which are nothing more than AND-gated clocks. 

Actually this is not correct..... at least from the designers standpoint.  The best way to 'picture'
the clock enable provided in the CLB is a 2->1 Mux steered by enable clock (EC).  When EC is low,
the existing FF data (Q) is used as the D input the the flop.  When EC is high, new data is used at
the D input.  The clock timing NEVER changes.... that's a key to synchronous design combined with
the matched performance of all clocked elements.

One MAJOR point to keep in mind is that when your clocks go off the global (read: LOW SKEW) clock
distribution networks of the Xilinx FPGAs, each net segment's delay will vary from one another AND
from route to route (usually).  IF you're planning on using general interconnect to route clock
lines, and unless you REALLY know what you're doing, I'd advise having your resume up to date!

Async logic MORE than has its place.  (Unfortunately?) FPGA architectures, design and verification
tools are targeted at synchronous implementations (for now).

-- 
Ed McCauley
Bottom Line Technologies Inc.
http://www.bltinc.com
Specializing Exclusively in Xilinx Design, Development and Training
Voice: (500) 447-FPGA, (908) 996-0817
FAX:   (908) 996-0817
Article: 11851
Subject: Re: Xilinx Spartan vs. 4K series
From: ems@nospam.riverside-machines.com
Date: Mon, 14 Sep 1998 15:25:18 GMT
Links: << >>  << T >>  << A >>
On Thu, 10 Sep 1998 22:41:06 -0400, Ray Andraka
<no_spam_randraka@ids.net> wrote:

>Spartan is a die shrink of the 4KE ...

Is this actually true? The only marketing stuff I've seen refers to a
0.35um UMC process, for 3.3V parts, and the standard (what fab?) 0.5um
process, with a tweak for -1 parts (presumably used for everything
now). Do you know any more?

Evan

Article: 11852
Subject: Re: ASIC -> FPGA async issues
From: ems@nospam.riverside-machines.com
Date: Mon, 14 Sep 1998 15:29:01 GMT
Links: << >>  << T >>  << A >>
On 12 Sep 1998 23:32:21 GMT, ese002@news9.exile.org (Eric Edwards)
wrote:

>The trouble is, the design is filled with gated clocks and complicated
>logicly divided clocks.  There are also a small but non-trivial number
>of more blatantly asynchronous design features.  My FPGA experience is
>limited was with almost purely synchronous designs.  This was
>deliberate.  But this time I don't have that option.  What I would like
>to know is: How bad is it?  And, is it really worth doing?  Some points
>of how to handle the gated clocks would be helpful too.

You don't say which FPGAs, but here are some Xilinx pointers. In
short, you're probably letting yourself in for a lot of hard work.
Gated clocks, per se, aren't a problem - you just generate your logic
and run it through a BUFG. If you've only got a few clocks, then you
may be able to get everything onto a clock network. The problems start
when you have to generate your timespecs. In principle, you just
partition your design into different clock domains, timespec the clock
within that domain, and then explicitly timespec any signals which
pass between the domains. All you have to know, for signal X, is how
long after an edge on clock A you have before X is sampled by an edge
on clock B (it helps if you designed the circuit!).

In practice, there are lots of problems. For example, if clock (A) is
produced by BUFG(A) and is at some later point used to gate clock (B),
which then goes through BUFG(B), then you'll find that you can't do
any timespecs on clock B, because of the forward-tracing mechanisms,
and so on. There are ways around these problems, but they involve you
explicitly specifying timing on lots of signals which should have been
covered by global timespecs. The worst problem is that you can never
be sure that your timespecs did what you expected - you occasionally
have to go to the timing analyser and confirm that the timing of a
given signal is correct for the current route.

There are all sorts of variations on this - you can generate F/F
enables, instead of clocks, but you may have to use a BUFG on the
enable if it has a high fan-out. This gives you the same timespec
problems as you had before, related to tracing through multiple BUFGs.

This all means that the static timing reports are pretty useless, so
you have to do proper timing simulations.

Async bits - the problem is again verification. Static analysis won't
work, so you again need a good simulation.

The next problem is your ASIC vendor. You could go to a lot of trouble
verifying your FPGA, and then discover than your vendor won't let you
do any of this in their ASIC anyway, so you're going to have to talk
to him early on. 

Evan
Article: 11853
Subject: Re: ASIC -> FPGA async issues
From: msimon@tefbbs.com
Date: Mon, 14 Sep 1998 21:24:07 GMT
Links: << >>  << T >>  << A >>
Its bad don't do it.

Simon
===========================================

ese002@news9.exile.org (Eric Edwards) wrote:

>We are in the process of a major rework of an aging ASIC design that has
>been moderately reworked before.   Given the magnitude of the changes,
>and the fact the base design is not completely understood, we are 
>considering doing an FPGA first.  And as the only member of the team 
>with any FPGA experience, they're looking at me.  
>
>The trouble is, the design is filled with gated clocks and complicated
>logicly divided clocks.  There are also a small but non-trivial number
>of more blatantly asynchronous design features.  My FPGA experience is
>limited was with almost purely synchronous designs.  This was
>deliberate.  But this time I don't have that option.  What I would like
>to know is: How bad is it?  And, is it really worth doing?  Some points
>of how to handle the gated clocks would be helpful too.
>
>-- 
>Real courtesy requires human effort and understanding.  
>Never let your machine or your habit send courtesy copies.

Opinions expressed herein are solely my own and may or may not reflect my opinion at this particular time or any other.
Article: 11854
Subject: Re: ASIC -> FPGA async issues
From: "Austin Franklin" <darkroo3m@ix.netcom.com>
Date: 14 Sep 1998 21:40:03 GMT
Links: << >>  << T >>  << A >>
> 
> Async logic MORE than has its place.  (Unfortunately?) FPGA
architectures, design and verification
> tools are targeted at synchronous implementations (for now).
> 

Hum.  I don't know exactly what you mean, but it really isn't that
difficult to implement asynchronous logic in an FPGA.  All the delays
through gates and routes track linearly, ie, all logic will be within some
small percent of the same time for the same function (routing excluded that
is), one will not be at it's high end, and another same function be at it's
low end.

Given this, one FMAP delay will ALWAYS be larger than two FMAP delays.

I don't know what asynchronous logic you believe is difficult to implement,
but I haven't had much trouble with the asynchronous logic I've implemented
in a Xilinx.

Personally, I do prefer synchronous designs though ;-)

Austin Franklin
darkroom@ix.netcom.com

Article: 11855
Subject: PCI Initiator/Target questions
From: "Eric W Braeden" <braeden@erinet.com>
Date: Mon, 14 Sep 1998 23:49:16 -0400
Links: << >>  << T >>  << A >>
I'm designing a PCI card that does a modest amount
of computing and may operate on data streams several
hundred MB long.

I'm studying several PCI books, but I have yet to find a
reference that talks about the tradeoffs between a
Master(Initiator)/Slave(Target) and just a Target.

It seems either way would work for my design, but I
don't have enough experience to see where I may be
making a big mistake by going Target only. Any and
all suggestions and pointers are welcome.

One other thing: My design will need the Open Firmware
stuff because the card will be used in Suns and other
non-Intel machines. Where is a good reference on this
Forth stuff?

Thanks,
Eric



Article: 11856
Subject: Re: ASIC -> FPGA async issues
From: allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman)
Date: Tue, 15 Sep 1998 03:54:41 GMT
Links: << >>  << T >>  << A >>
We just had a visit from a Xilinx field application engineer.  He told
us that one of the features of the M1.5 software (we're currently
using M1.4 here) is that it will report *guaranteed minimum* delays.
Initially, this will only be for the 4000XL parts, but will eventually
extend to all parts, presumably because they have to characterise the
parts first or something.

This will make the asynchronousphiles happy.

Allan.
Article: 11857
Subject: Re: Design Security Question
From: Daniel K Elftmann <elftmann@ix.netcom.com>
Date: Tue, 15 Sep 1998 04:55:59 GMT
Links: << >>  << T >>  << A >>
In article <6t73nl$nj0@nntp1.erinet.com>,
	"Eric W Braeden" <braeden@erinet.com> wrote:

>Q: Lets say I were going to use a Xilinx Spartan XCS40 in a design.
>     That would probably mean I would use the XC17S40 SPROM.
>     How would you keep anyone who want to from cloning your design?
>     I don't see any mention of security in the Xilinx pages. How do you
>     load your FPGA without exposing your loadable image to hardware
>     hackers?
>
>TIA
>
>Eric
>
>
>

The following is a very good article on protecting your designs.  Antifuse is the most secure
technology for protecting your design.

 http://www.actel.com/events/protect_copyright.pdf
Article: 11858
Subject: Job: Researcher, Oxford Univ.
From: Andrew.Bailey@comlab.ox.ac.uk (Andrew Bailey)
Date: Tue, 15 Sep 1998 08:42:38 +0100
Links: << >>  << T >>  << A >>
			 Research Officer

                    Hardware Compilation Group

The Hardware Compilation Group at Oxford University has a vacancy for a =

researcher to work on a new industrially funded
project starting as soon as possible after 1st November 1998. The aim of =
this =

project is to research the use of FPGAs and the
hardware acceleration of algorithms for high-speed network security =

applications, and the development of a demonstrator of
these techniques using a PC-hosted FPGA board. The project combines the =

flexibility for the researcher to pursue
groundbreaking background research in these areas, and the use of this wo=
rk to =

develop a challenging application.

The successful applicant will have a good first degree in Computer Scienc=
e or =

Electronic Engineering, programming
expertise, and is likely to have a PhD or research experience.

Expertise in one or more of the following areas would be beneficial: algo=
rithm =

design, FPGAs, digital design, C, networks,
VHDL, content addressable memories, hardware compilation, parallel =

programming, real-time system design.

More details of the group are available at the Hardware Compilation Group=
 home =

page: http://www.comlab.ox.ac.uk/oucl/hwcomp.html

Salary will be on the age and experience related RS1A grade (currently =A3=
15,735 =

to =A323,651 per annum).

Applications should clearly state the post title and be in the form of a =
full =

curriculum vitae plus application letter, together with
the names of two referees.

Further details and selection criteria are available on request to the =

Administrator of the Computing Laboratory.

The completed application should be sent to arrive before the closing dat=
e of =

Friday 2nd October 1998 and be addressed to:
The Administrator, Oxford University Computing Laboratory, Wolfson Buildi=
ng, =

Parks Road, Oxford OX1 3QD. (Email:
Mike.Field@comlab.ox.ac.uk).

Oxford University is an Equal Opportunities Employer.


Article: 11859
Subject: Re: ASIC -> FPGA async issues
From: Paul Chien <paul@mecalc.co.za>
Date: Tue, 15 Sep 1998 13:50:14 +0200
Links: << >>  << T >>  << A >>
Wade D. Peterson wrote:
 
> ansynchrouous circuit.  For example, all high performance VMEbus
> interfaces are asynchronous.

Yes, VMEbus is asynchronous. But which devices are you refering to here
that implements the VMEbus interface asynchrnously and within a FPGA ?

We are busy designing a VMEbus interface within an FPGA, and as far as I
can see, the Tundra Universe chip (ASIC, not FPGA) implements the
VME-PCI bridge synchronously.  The Universe Timing spec always refers to
the PCI clock and Universe uses this clock to gaurantee the VMEbus
timing requirements. I recall that Universe II requires a PCI clock
between 25-33MHz for correct VMEbus timing.

Regards
Paul Chien
Article: 11860
Subject: Re: ASIC -> FPGA async issues
From: Paul Chien <paul@mecalc.co.za>
Date: Tue, 15 Sep 1998 13:52:19 +0200
Links: << >>  << T >>  << A >>
Wade D. Peterson wrote:
 
> ansynchrouous circuit.  For example, all high performance VMEbus
> interfaces are asynchronous.

Yes, VMEbus is asynchronous. But which devices are you refering to here
that implements the VMEbus interface asynchrnously and within a FPGA ?

We are busy designing a VMEbus interface within an FPGA, and as far as I
can see, the Tundra Universe chip (ASIC, not FPGA) implements the
VME-PCI bridge synchronously.  The Universe Timing spec always refers to
the PCI clock and Universe uses this clock to gaurantee the VMEbus
timing requirements. I recall that Universe II requires a PCI clock
between 25-33MHz for correct VMEbus timing.

Regards
Paul Chien
Article: 11861
Subject: Re: ASIC -> FPGA async issues
From: Ed McCauley <emccauley@bltinc.com>
Date: Tue, 15 Sep 1998 09:29:57 -0400
Links: << >>  << T >>  << A >>
Hi Group:

> This all means that the static timing reports are pretty useless, so
> you have to do proper timing simulations.

Back annotated timing could also fail........  Keep in mind that the FPGAs are speced worst case
(process, temp and voltage) ONLY.... to do an accurate Timing simulation requires introducing
variances in the above numbers.... also referred to as Montycarlo (sp?) simulation wherein one
specifies the range and resolution of variance of each timing parameter and number of permutations
to evaluate..... not a job for PCs.  One can visualize this result by thinking of the waveforms in
databooks that have a 'gray' area during signal transitions.... they don't specify exactly when
they'll transition, just a range.  


-- 
Ed McCauley
Bottom Line Technologies Inc.
http://www.bltinc.com
Specializing Exclusively in Xilinx Design, Development and Training
Voice: (500) 447-FPGA, (908) 996-0817
FAX:   (908) 996-0817
Article: 11862
Subject: Re: ASIC -> FPGA async issues
From: Ed McCauley <emccauley@bltinc.com>
Date: Tue, 15 Sep 1998 09:45:26 -0400
Links: << >>  << T >>  << A >>
Austin,

I refer to repeatable performance characteristics.  From route to route, the delays associated in an
FPGA will vary. (Unless potentially extraordinary measures are taken).  Tracking the subtle
variances and verifying conformance to specification becomes a daunting task for anything but the
smallest circuits.  One can not "Exclude" the routing aspect of the problem.

Again, its not so much the ease of conceptual design but the limitations on silicon and within the
timing verification tools.

Perhaps a simple example.... One implements a 20 bit ripple counter... Time from inbound clock to
Q[1..19] changing is totally unpredictable because of the varying times from each Q to the following
C input introduced by routing delays.  Unless the circuit was running VERY slow - ala under a few
MHz, if one were to attempt to simultaneously derive meaning from multiple bits of this counter they
would fail.  The bugger is that the "How long will it take to stabilize?" question will vary from
route to route.

Another example, if one were to use general interconnect to route clock lines, the skew to the loads
would make shift registers and potentially counters and state machines fail.... regardless of clock
speed.  This is what happens when someone gates a clock in Xilinx and doesn't put the gated output
through a clock buffer.  Keep in mind there are relatively few global buffers so liberal gating of
clocks would rapidly consume these resources.

I gather that you know all this.  I elaborate for those that may not.  Happy Designing!

-- 
Ed McCauley
Bottom Line Technologies Inc.
http://www.bltinc.com
Specializing Exclusively in Xilinx Design, Development and Training
Voice: (500) 447-FPGA, (908) 996-0817
FAX:   (908) 996-0817


Austin Franklin wrote:
> 
> >
> > Async logic MORE than has its place.  (Unfortunately?) FPGA
> architectures, design and verification
> > tools are targeted at synchronous implementations (for now).
> >
> 
> Hum.  I don't know exactly what you mean, but it really isn't that
> difficult to implement asynchronous logic in an FPGA.  All the delays
> through gates and routes track linearly, ie, all logic will be within some
> small percent of the same time for the same function (routing excluded that
> is), one will not be at it's high end, and another same function be at it's
> low end.
> 
> Given this, one FMAP delay will ALWAYS be larger than two FMAP delays.
> 
> I don't know what asynchronous logic you believe is difficult to implement,
> but I haven't had much trouble with the asynchronous logic I've implemented
> in a Xilinx.
> 
> Personally, I do prefer synchronous designs though ;-)
> 
> Austin Franklin
> darkroom@ix.netcom.com
Article: 11863
Subject: Re: ASIC -> FPGA async issues
From: Ed McCauley <emccauley@bltinc.com>
Date: Tue, 15 Sep 1998 09:50:14 -0400
Links: << >>  << T >>  << A >>
I think there are two definitions that apply here:

Asynchronous Events - ala VME/ISA bus activity

and

Asynchronous vs Synchronous Circuitry to handle asynchronous events.  Clearly one can archetect the
latter.


-- 
Ed McCauley
Bottom Line Technologies Inc.
http://www.bltinc.com
Specializing Exclusively in Xilinx Design, Development and Training
Voice: (500) 447-FPGA, (908) 996-0817
FAX:   (908) 996-0817


Paul Chien wrote:
> 
> Wade D. Peterson wrote:
> 
> > ansynchrouous circuit.  For example, all high performance VMEbus
> > interfaces are asynchronous.
> 
> Yes, VMEbus is asynchronous. But which devices are you refering to here
> that implements the VMEbus interface asynchrnously and within a FPGA ?
> 
> We are busy designing a VMEbus interface within an FPGA, and as far as I
> can see, the Tundra Universe chip (ASIC, not FPGA) implements the
> VME-PCI bridge synchronously.  The Universe Timing spec always refers to
> the PCI clock and Universe uses this clock to gaurantee the VMEbus
> timing requirements. I recall that Universe II requires a PCI clock
> between 25-33MHz for correct VMEbus timing.
> 
> Regards
> Paul Chien
Article: 11864
Subject: Re: ASIC -> FPGA async issues
From: "Austin Franklin" <darkroo3m@ix.netcom.com>
Date: 15 Sep 1998 14:30:41 GMT
Links: << >>  << T >>  << A >>
> I refer to repeatable performance characteristics.  From route to route,
the delays associated in an
> FPGA will vary. (Unless potentially extraordinary measures are taken).

I really don't believe you'd have to take extraordinary measures....but
then, what is not extraordinary (using timespecs and placing things
manually) to me, may be to others...but you're right, it does take a very
good understanding of the chip, architecture of the chip, and its
characteristics.  Generally, what I'd call good engineering ;-)

> Another example, if one were to use general interconnect to route clock
lines, the skew to the loads
> would make shift registers and potentially counters and state machines
fail.... regardless of clock
> speed.  This is what happens when someone gates a clock in Xilinx and
doesn't put the gated output
> through a clock buffer.  Keep in mind there are relatively few global
buffers so liberal gating of
> clocks would rapidly consume these resources.

Hum.  Gated clocks.  Personally, I'd eliminate the gated clocks by
redesign, and use CEs.  Gated clocks are generally a very very very bad
design practice done by very inexperienced 'designers' who don't know any
better (sorry to offend anyone...but that's been my experience).  I don't
know of any circuit that one could do WITH gated clocks that couldn't be
designed (what I'd call correctly ;-) WITHOUT gated clocks.  Can anyone
think of one?

Austin



Article: 11865
Subject: Re: PCI Initiator/Target questions
From: "Austin Franklin" <darkroo3m@ix.netcom.com>
Date: 15 Sep 1998 14:54:49 GMT
Links: << >>  << T >>  << A >>
> I'm studying several PCI books, but I have yet to find a
> reference that talks about the tradeoffs between a
> Master(Initiator)/Slave(Target) and just a Target.

Target means the board accepts read and write accesses, either single or
burst FROM someone else, ie, does not initiate the transfer.  Master means
your board initiates the transfer.

There are also a few other things you want to take into consideration.  The
x86 only bursts 4 lines (64 bits per line) at a time, so it only transfers
8 32 bit PCI data cycles max in a single burst transfer, and takes up 100%
of the CPU to do it.   Also, not all targets support burst, so even if your
master (x86) bursts, you may not accept the burst, and they will be done as
single transfers (address, data, address, data etc.).  Also, not all
masters burst...unless designed to do so.  Master bursting is the hardest
thing to implement in an FPGA due to the timing requirements.
 
> It seems either way would work for my design, but I
> don't have enough experience to see where I may be
> making a big mistake by going Target only.

If you have a high data rate, then target only would be a big mistake.  You
are first off taking pure CPU time to do the transfer, and again, it can
only do a limited amount of data per transfer.  A master can transfer up to
its latency timer (if implemented, else you SHOULD default to 16)
transfers, or until it gets /GNT pulled, which ever is longer, though
you're guaranteed your latency timer number as a minimum.

The bandwidth calculations are pretty simple, and I suggest you do them to
see what your requirements are.  For example, if you need to transfer
100MBytes/sec, you will be saturating the PCI bus, and the PCI bus may
prove too slow for your application.  You mentioned hundreds of MBs, but
not a frequency.  You need the frequency to calculate the bandwidth
requirements.

Austin Franklin
darkroom@ix.netcom.com

Article: 11866
Subject: Re: ASIC -> FPGA async issues
From: "John L. Smith" <jsmith@visicom.com>
Date: Tue, 15 Sep 1998 13:45:33 -0400
Links: << >>  << T >>  << A >>



Ed McCauley wrote:

> Back annotated timing could also fail........  Keep in mind that the FPGAs are speced worst case
> (process, temp and voltage) ONLY.... to do an accurate Timing simulation requires introducing
> variances in the above numbers.... also referred to as Montycarlo (sp?) simulation

That's Monte Carlo, the city famous for its casinos and occasional race conditions ;o)

> wherein one
> specifies the range and resolution of variance of each timing parameter and number of permutations
> to evaluate..... not a job for PCs.



Article: 11867
Subject: Re: ASIC -> FPGA async issues
From: "John L. Smith" <jsmith@visicom.com>
Date: Tue, 15 Sep 1998 14:14:16 -0400
Links: << >>  << T >>  << A >>




Austin Franklin wrote:

>   I don't
> know of any circuit that one could do WITH gated clocks that couldn't be
> designed (what I'd call correctly ;-) WITHOUT gated clocks.  Can anyone
> think of one?
>

A data source _inside_ an FPGA with 40MHz global clock produces data
at a rate that varies from once every clock to once every three clocks,
usually
1/clock. The source provides a signal that indicates data valid.
The data sink _outside_ the FPGA has two inputs, clock and data; but no
clock enable (data valid) signal is available for the sink, which must not
recieve invalid data. The _only_ way to sync the sink is to stop the clock,
no alternative is available because the sink is a large ASIC designed by
someone else who cannot be persuaded to change their circuit. The
maximum clock rate the sink is spec'd for is 40MHz.

Option 1:
   Run the FPGA at 80MHz, and produce the (40MHz sometimes stopped)
   clock to the sink using source data valid signal as CE on a FF.
   But then most of the circuitry that worked at 40MHz
   no longer runs, as timing cannot be tightened from 25ns  to 12.5 ns.
   A global CE of 40MHz could be used, but most of the FFs inside
   the FPGA already have CE used for other purposes. More pipelining
   could be used, at a cost of doubling the number of FFs, doubling the
   required size of the FPGA, doubling the cost.

Option 2:
   Gate the clock to the sink with the source data valid signal.

Option 2 takes about 20 minutes to implement and verify.
Option 1 takes about 2 weeks to implement and verify.

    Are there other options? Yes, but I'm typing this on my
lunch hour. Given the above, though, does one choose
option 1 or 2?
I think it depends on other information not provided: schedules,
expected size of production run, cost sensitivity, etc. Perhaps
it is necessary to go with 2 to get a quick demonstration going,
cuz a salesman says if a customer doesn't see such and such
functionality demonstrated tomorrow, he'll go away. Later
option 1 can be implemented. Not the most efficient way
of doing things, but customers often don't care.
   Some might say that the FPGA circuit was designed wrong
to begin with, 80MHz should have been the target from the
start, but such are real world situations. One doesn't always
have the luxury of producing ideal designs (first pass anyway).
   My $.02 boils down to: it is best to understand clock
gating circuits, know the potential pitfalls, but still have
them as an available tool. My example doesn't completely
match the original post, which dealt with strictly internal
circuitry. I agree that the CE should generally be
strongly preferred if it is available.
   I haven't seen a post generate this much traffic in a
while, I think lots of folks have had experience here.
   Are gated clocks common in ASIC design?



Article: 11868
Subject: Re: A Linear Feedback Shiftregister
From: Joseph Van der ree <jvander@biosys.net>
Date: Tue, 15 Sep 1998 19:53:00 GMT
Links: << >>  << T >>  << A >>
In article <35fa59c3.0@grendel.df.lth.se>,
  "Reza Bohrani" <Reza.Bohrani@timespace.se> wrote:
> The problem stated is as follows:
>
> xxxx ...x01 is the content of a 32-bit LFSR . It normally takes two
> clockcycles to output the last two bits.  I want the them output in parallel
> after just one clockcycle. What is the best way to do it. I was thinking of
> making 2 parallel shiftregisters each 16 bits wide, that outputs every other
> bit in the original sequence, but how is that done. The generator polynomial
> used is x^32+ x^22+x^2+1.
>
> Sincerely
> Reza

It has been said that LFSRs are good to generate pseudo-random bits, not
pseudo-random n-bit integers. If pseudo-random integer generation is required
from an LFSR, one would expect to clock n times the LFSR in order to produce
the  n-bit integer. However there's a way around this, in fact, it's quite
possible  to generate the same n-bit integer by clocking the LFSR just once.
However for  this to be possible, taps need to be rearranged and new XNOR
feedback paths must be added. You also need to move from the usual many-to-one
arrangement to a one-to-many implementation instead. This yields an aditional
tap word (for the XNOR feedbacks) which changes the usual tap combination for
maximal-length sequence. With this approach we now have two tap words instead
of one so they need to be properly chosen for m-sequence. Fortunately the new
tap combinations are related to the original one. If you are interested in the
algorithm, let me know.

Regards,
Joseph Van der ree.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
Article: 11869
Subject: XC4000: config. EPROM usable for dynamic reconfiguration / data storage?
From: Stefan Rave <rave@LS12.cs.uni-dortmund.de>
Date: Tue, 15 Sep 1998 22:00:26 +0200
Links: << >>  << T >>  << A >>
Hi all,

I'm planning to build an FPGA prototype board, but I have little
experience with electrical concerns. The board will contain four
XC4028XL devices, a flash EPROM for configuration data, and some other
stuff like SRAM memory. (Dual-ported SRAM in order to facilitate
communication between pairs of FPGAs on the board; does this sound
sensible?)

The board shall provide as much flexibility as possible for any
application. For this reason, I wonder if I can use the EPROM to hold
more than only the configuration data of the four FPGA devices. I'd like
to use one designated FPGA as a master which can re-configure the others
dynamically and/or access the EPROM for things like a sine table, for
example. Do you think the following is a practicable approach?

* use parallel flash EPROM for random access, connected to master FPGA
the usual way
* connect /INIT signals of all FPGAs, as usual, as well as all DONE
signals; provide DOUT/DIN daisy chain as usual (DOUT is user I/O after
configuration, so I can output the data for dynamic reconfiguration
there), but
* provide a means to pull down slaves' /PROGRAM inputs by a dedicated
master pin, say, /USR_PROGRAM, using an AND gate: 
/PROGRAM(slave) := /PROGRAM(master) AND /USR_PROGRAM(master)
(of course, /USR_PROGRAM must never go low unless intended;
/PROGRAM_master can be triggered manually by a switch)
* provide a means to drive slaves' CCLK inputs by a dedicated master pin
"USR_CCLK", again with an AND gate (external pull-up resistor on
USR_CCLK; can I drive a clock input this way?)
CCLK(slave) := CCLK(master) AND USR_CCLK(master)
* provide a means to activate the configuration EPROM after
configuration has completed: drive its /CE input by /LDC (which is user
I/O after configuration) instead of DONE (which seems to be the usual
way)

Any comments are appreciated. Thanks in advance.
Article: 11870
Subject: Re: ASIC -> FPGA async issues
From: ems@nospam.riverside-machines.com
Date: Tue, 15 Sep 1998 20:16:45 GMT
Links: << >>  << T >>  << A >>
On 15 Sep 1998 14:30:41 GMT, "Austin Franklin"
<darkroo3m@ix.netcom.com> wrote:

>I don't
>know of any circuit that one could do WITH gated clocks that couldn't be
>designed (what I'd call correctly ;-) WITHOUT gated clocks.  Can anyone
>think of one?

1) any low power circuit
2) generation of non-overlapping 2-phase clocks
3) circuit elements that don't have 'clock enables', ie. I/O registers
   or rams (or even F/Fs) in some architectures, for which you don't
   want to/cant build your own recirculating mux (ie. the clock is
   too fast, or you don't have the routing resources, or whatever)
4) situations in which you don't have a periodic signal, and
   have to generate a clock of some sort
5) situations in which you have a periodic clock, but it's too
   slow to load/synchronise your inputs
6) situations in which you have two clocks, and have to combine
   them to carry out some action - a TTL example came up in this
   group recently
7) clock doubling - peter alfke says it's ok... :)
8) clock regenerators
9) what exactly is a non-gated clock anyway? most clocks start
   life at a gate somewhere. you can make the inputs to the
   gate whatever you want.

>Gated clocks are generally a very very very bad
>design practice done by very inexperienced 'designers' who don't know any
>better (sorry to offend anyone...but that's been my experience).

 ?

evan

Article: 11871
Subject: Free Newsletter and VHDL/FPGA tutorial tech notes
From: APS <resp@associatedpro.com>
Date: Tue, 15 Sep 1998 17:21:27 -0400
Links: << >>  << T >>  << A >>
The next APS EDA NEWSLETTER is about to be released. It is full of VHDL
and FPGA tech news and notes as well as other information. You can
subscribe to the newsletter from this page: http://www.associatedpro.com

Also take a lok at the APS series of FPGA TEST BOARDS. These boards are
ideal for testing IP and general algorithms. The boards can be gotten
with on board Direct Digital Syntheiszers, SRAM and other features.

Also be aware that APS sells the Foundation Series kits with and with
out Synopsys VHDL Compilers. You can currently get the full blown
Foundation Suite with our test boards for $3700.00 !!!! This is a
special that is not yet reflected on our web site. Respond via email for
more information!!

--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 11872
Subject: measuring junction temperature
From: asieving@my-dejanews.com
Date: Tue, 15 Sep 1998 21:49:53 GMT
Links: << >>  << T >>  << A >>
I am designing a system using a Xilinx XC4K-XL part, and have a
few unused pins.  I remember that there is some way to measure the junction
temperature using an unused pin, but I cannot find the reference.  I thought
that Peter Alfke had posted something, but I could not find the post.

Thanks for any replies-

Alan Sieving
ars@quickware.com

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
Article: 11873
Subject: Re: ASIC -> FPGA async issues
From: "Austin Franklin" <darkroo3m@ix.netcom.com>
Date: 15 Sep 1998 22:12:34 GMT
Links: << >>  << T >>  << A >>
> >   I don't
> > know of any circuit that one could do WITH gated clocks that couldn't
be
> > designed (what I'd call correctly ;-) WITHOUT gated clocks.  Can anyone
> > think of one?
> >
> 
> A data source _inside_ an FPGA with 40MHz global clock produces data
> at a rate that varies from once every clock to once every three clocks,
> usually
> 1/clock. The source provides a signal that indicates data valid.
> The data sink _outside_ the FPGA has two inputs, clock and data; but no
> clock enable (data valid) signal is available for the sink, which must
not
> recieve invalid data. The _only_ way to sync the sink is to stop the
clock,
> no alternative is available because the sink is a large ASIC designed by
> someone else who cannot be persuaded to change their circuit. The
> maximum clock rate the sink is spec'd for is 40MHz.
> 
> Option 1:
>    Run the FPGA at 80MHz, and produce the (40MHz sometimes stopped)
>    clock to the sink using source data valid signal as CE on a FF.
>    But then most of the circuitry that worked at 40MHz
>    no longer runs, as timing cannot be tightened from 25ns  to 12.5 ns.
>    A global CE of 40MHz could be used, but most of the FFs inside
>    the FPGA already have CE used for other purposes. More pipelining
>    could be used, at a cost of doubling the number of FFs, doubling the
>    required size of the FPGA, doubling the cost.

You can supply two clocks to the FPGA, one 40 and one 80 that are
guaranteed synchronized by using a PLL...like the one Motorola
makes....that provides a clock/2 output that is skewed within ps of the
80MHz clock output.  Then you don't have to 80ns for the logic that doesn't
need to.

Austin

Article: 11874
Subject: Re: ASIC -> FPGA async issues
From: jhallen@world.std.com (Joseph H Allen)
Date: Tue, 15 Sep 1998 22:29:10 GMT
Links: << >>  << T >>  << A >>
In article <35FEAE78.6220813@visicom.com>,
John L. Smith <jsmith@visicom.com> wrote:

>The data sink _outside_ the FPGA has two inputs, clock and data; but no
>clock enable (data valid) signal is available for the sink, which must not
>recieve invalid data. The _only_ way to sync the sink is to stop the clock,
>no alternative is available because the sink is a large ASIC designed by
>someone else who cannot be persuaded to change their circuit. The
>maximum clock rate the sink is spec'd for is 40MHz.

>Option 1:
>   Run the FPGA at 80MHz, and produce the (40MHz sometimes stopped)
>   clock to the sink using source data valid signal as CE on a FF.
>   But then most of the circuitry that worked at 40MHz
>   no longer runs, as timing cannot be tightened from 25ns  to 12.5 ns.
>   A global CE of 40MHz could be used, but most of the FFs inside
>   the FPGA already have CE used for other purposes. More pipelining
>   could be used, at a cost of doubling the number of FFs, doubling the
>   required size of the FPGA, doubling the cost.

>Option 2:
>   Gate the clock to the sink with the source data valid signal.

>Option 2 takes about 20 minutes to implement and verify.
>Option 1 takes about 2 weeks to implement and verify.

Is it even possible to verify Option 2?  How do you do it?  My FPGA
datasheet does not give guaranteed minimum delays or even typical delays so
there is no way to know if:

- you are going to cause a glitch on the clock going to the other chip

- the clock through the gate delay vs. the data delay

One solution I've found for this is to generate a two-phase overlapped clock
system (clk and q) from an 80MHz clock.  The gate signal is synchronized to
q with a FF before it gates clk.  Anyway still runs at 40MHz and you can
lower the clock to DC and everything still works.

-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}


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
2017JanFebMarApr2017

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