Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
> 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-0817Article: 11851
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? EvanArticle: 11852
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. EvanArticle: 11853
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
> > 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.comArticle: 11855
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, EricArticle: 11856
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
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.pdfArticle: 11858
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: 11859Wade 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 ChienArticle: 11860
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 ChienArticle: 11861
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-0817Article: 11862
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.comArticle: 11863
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 ChienArticle: 11864
> 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? AustinArticle: 11865
> 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.comArticle: 11866
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
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: 11868In 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 ForumArticle: 11869
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
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). ? evanArticle: 11871
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
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 ForumArticle: 11873
> > 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. AustinArticle: 11874
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:
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