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
Good job! You guys must be proud, an I hope many readers will pat you on the back. Question: How does the search work? "metastability" or "LFSR" should get many hits... I have a self-burnt "early-bird" copy of the 2001 data book plus lots of stuff (600 MB), and I think it is user-friendly, nothing to install etc. I'll mail it to you if you e-mail me your address. Greetings PeterArticle: 31476
Wer hat Erfahrung mit der Anbindung eines FPGA auf einem PCI - Board an den PCI - Bus. Dazu benutze ich den PLX Baustein PCI 9052. Ich möchte einen SRAM, das mit dem FPGA verbunden ist über den PCI -Bus auslesen. Wer hat Tipps oder auch Beispielprogramme in VHDL die dieses bewerkstelligen. Worauf muss ich beim programmieren des FPGA achten. Danke Mario GiffelArticle: 31477
Hi, I am using the Xilinx VirtexE and I would like to apply the dual channel NCO of the CORE Generator. But I can't reproduce the results in the Logic Simulator. I took the following parameters to generate this Core: Inc Width=16 ; Amp Width=10 ; Acc Width=16 ; Phase Width=10 ; CLK=20 MHz In Logic Simulator get this results (dec.): (every 50 ns; first nineteen clocks) sine: 3 ; 3 ; 6 ; 6 ; 9 ; 9 ; 13 ; 13 ; 16 ; 16 ; 19 ; 19 ; 22 ; 22 ; 25 ; 28 ; 28 ; 31 ; 31 ; ... cosine: 511 ; 511 ; 511 ; 511 ; 511 ; 511 ; 511 ; 511 ; 511 ; 511 ; 511 ; 511 ; 511 ; 511 ; 510 ; 510 ; 510 ; 510 ; 510 ; ... If I use the parameters [Inc Width=10 ; Amp Width=10 ; Acc Width=10 ; Phase Width=10 ; CLK=20 MHz] I am able to reproduce the sine and cosine values in MATLAB with the following equations: sin_nco = 2^(AmpWidth-1) * sin(2*pi*phi_word*m*1/2^AccWidth); cos_nco = 2^(AmpWidth-1) * cos(2*pi*phi_word*m*1/2^AccWidth); (m=loop index) Can anyone give me any suggestion on it? Thanks Regards Markus DobschallArticle: 31478
Peter Will copies be available at DAC? Peter Alfke wrote in message <3B109A36.1181949E@earthlink.net>... >Good job! You guys must be proud, an I hope many readers will pat you on the >back. >Question: How does the search work? "metastability" or "LFSR" should get many >hits... > >I have a self-burnt "early-bird" copy of the 2001 data book plus lots of stuff >(600 MB), and I think it is user-friendly, nothing to install etc. >I'll mail it to you if you e-mail me your address. > >Greetings >PeterArticle: 31479
Hi Jamil, Definitely keep using MUXs for implementing on-chip buses ! There are three main issues (maybe more, if anyone can add?....) (1) Potential Bus Contention: The obvious issue is that MUXs avoid the potential problem with tristate buses - bus contention, with multiple drivers active at the same time (increases power consumption, reduces reliablility of the chip). (2) Design Portability: If your design is HDL based, MUX based buses are technology independent, hence your design is more portable. Tristate resources are limited in FPGAs, and if you transfer your design to ASIC, tristate buses must never be allowed to float (FPGAs have weak-keepers on tristate resources, so floating doesn't occur). This is a "design for reuse" issue. (3) System Reset: This relates to point (1). If you use tristate buses in your design, you must use an asynchronous reset for your design. This is because with a synchronous reset, you may have contention on start-up, because your system will reset to the known start-up state only on the first system clock. It is almost always better to use a synchronous system reset, or at least synchronise/register your incoming system reset signal. So, don't use tristate buses if you have a synchronous reset. It follows that if you have tristate buses, you must use an asynchronous reset. However, at the board level, tristate buses are OK, of course - you can use tristate logic for the IOs of your top level design, but not for the internals of your FPGA or ASIC. Hope that helps :) Best regards Tony Burch http://www.BurchED.com.au Lowest cost, easiest-to-use FPGA prototyping kits! "Jamil Khatib" <khatib@ieee.org> wrote in message news:3B101A38.588AC93@ieee.org... > Is there any drawbacks for using internal tristate buffers to implement > busses? or should I keep using muxs? > > Thanks > Jamil >Article: 31480
Hello, the problem was traced down and has been cured now. (Peter, thanks again for your quick hints - however, the bone was buried somewere else). The Motorola MVME IP-bus has bidirectional data ports. In the design I used the OE-controlled BUFT8 tristate drivers. I always assumed the enable to be high active, since I didn't find any clue on it being low active. Curious enough did the problem not show up in the simulation runs. Luckily, this morning I saw a scope measurement showing exactly the data bus in tri-state while it should be active. The other time when only one driver should have been active only one "won" (had the much stronger driver), since the signals were definately really high or low - no in between. Thanks again, Best regards, Henning TrispelArticle: 31481
Here are some distributed comments by somebody who likes on-chip 3-state busses for their efficiency. Tony Burch wrote: > Hi Jamil, > > (1) Potential Bus Contention: > The obvious issue is that MUXs avoid the potential problem > with tristate buses - bus contention, with multiple drivers active > at the same time (increases power consumption, reduces reliablility > of the chip). For reliability problems to exist, there would have to be massive contention, lasting a long time, which can only happen in an faulty design. > > > (2) Design Portability: > If your design is HDL based, MUX based buses are technology > independent, hence your design is more portable. Tristate > resources are limited in FPGAs, and if you transfer your design > to ASIC, tristate buses must never be allowed to float > (FPGAs have weak-keepers on tristate resources, so floating > doesn't occur). This is a "design for reuse" issue. True, but then: Only certain FPGA designs ever get ported to an ASIC. > > > (3) System Reset: > This relates to point (1). If you use tristate buses in your > design, you must use an asynchronous reset for your > design. This is because with a synchronous reset, you > may have contention on start-up, The global reset that is active during the whole configuration process is asynchronous, and moreover, the user clock is actually coming in and is being distributed during the configuration time. ( Speaking for Xilinx, I don't know the Altera details enough). So, unless the whole design is done in a weird way, there is no problem during configuration and start-up. > because your system > will reset to the known start-up state only on the first system > clock. It is almost always better to use a synchronous > system reset, or at least synchronise/register your incoming > system reset signal. So, don't use tristate buses if you > have a synchronous reset. It follows that if you have > tristate buses, you must use an asynchronous reset. Have a good Memorial Day weekend ! Peter Alfke, Xilinx ApplicationsArticle: 31482
This is what Mario is asking (in German, which is not the lingua franca on this newsgroup): "Who knows something about connecting an FPGA on a PCI board to the PCI bus. I am using the PLX component PCI 9052. I would like to read an SRAM, connected to the FPGA, via the PCI bus. Who has some tips or even example programs in VHDL that do this? What do I have to be concerned about when programming the FPGA?" Mario Giffel. One-time translation services provided by Peter Alfke. ======================================================== T-Online wrote: > Wer hat Erfahrung mit der Anbindung eines FPGA auf einem PCI - Board an > den PCI - Bus. Dazu benutze ich den PLX Baustein PCI 9052. Ich möchte > einen SRAM, das mit dem FPGA verbunden ist über den PCI -Bus auslesen. > Wer hat Tipps oder auch Beispielprogramme in VHDL die dieses > bewerkstelligen. Worauf muss ich beim programmieren des FPGA achten. > > Danke > > Mario GiffelArticle: 31483
Who have the experience with the FPGA on a PCI-board to connect a PCI-bus, with using the PLX-device: PCI 9052. An SRAM is connect with the FPGA and this device should be read from the PCI-bus (32 Bit access) Who have tips or example-source/standard-source in VHDL, that this can manage ? What things I must observe ? Thanks ! MarioArticle: 31484
On Mon, 21 May 2001 18:18:47 +0100, "n#" <n@n.com> wrote: >Anyone know a tool that will do this? I have written scripts, used cores >etc. but I still wish I could do this. I was looking at this too and I think RLOC_RANGE is the solution. When it works (it doesn't work for me with Virtex-II netlists, it seems to expect old type RLOC specs as opposed to X,Y) you should be able to put an RLOC_RANGE like X0Y*:X0Y* so that all inferred FDCs of a register set should go to a stick. I am hoping that this should work reg [17:0] a/* synthesis RLOC_RANGE="X0Y*:X0Y*" */; Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 31485
ANyone have any Orcad Capture symbols for Virtex II. Particulatly in the BF957 package?Article: 31486
Hi, Does anyone here know where to find the LVDS circuit description for Virtex II? sincerely ------------- Kuan ZhouArticle: 31487
Eighth Asia Pacific Chip Design Languages Conference APChDL-2001, 10-12 December 2001 System Level Design Languages Workshop SLDL-2001, 12-13 December 2001 Adelaide University, South Australia Call for Papers, Tutorials and Panels Design languages play an important role in the development of integrated circuits and systems. Languages are used to express the behavior and structure of designs, and language processing tools are used for simulation, verification, synthesis and other forms of analysis. The abstractions provided by design languages make the design process more manageable and amenable to automation. The APChDL Conference organizers invite submission of papers and proposals for tutorials and panels addressing topics in language-based design of integrated circuits and systems, including (but not limited to): Systems on a Chip Switch, logic and high-level - Platform computing simulation - Embedded systems specification, - HW/SW co-simulation modeling, and validation - Mixed-mode simulation - FPGA design and reconfigurable - Formal Verification techniques computing - Logic and behavioral synthesis - Rapid prototyping - Datapath and control synthesis - Real-time systems - Interface synthesis - Intellectual property - HW/SW co-synthesis - Interoperability issues Analog, RF, and mixed signal behavioral modeling - Analog, RF, and mixed signal circuit synthesis, optimization, and layout - Analog, RF, and mixed signal simulation - Mixed technology design simulation - Analog and mixed signal test - Fault modeling and simulation - BIST and DFT For papers, a full-paper manuscript of at most eight single-spaced pages should be submitted to the APChDL Program Chair by email in Adobe PDF format. Papers may be submitted in printed form by regular mail only by arrangement with the Program Chair. Tutorial proposals should include an abstract of at least 500 words, a statement of learning objectives, target audience and prerequisite knowledge. Panel proposals should include an abstract of at least 500 words and a list of proposed panellists. Tutorial and panel proposals should be submitted by email to the APChDL Program Chair. The SLDL Workshop organizers also invite proposals for presentations and embedded tutorials on topics in language-based system-level design, including (but not limited to): - Systems Level Design Semantics and Representations - Systems Level Simulation and Analysis - Heterogeneous Specification and Analysis - Domain Modeling - Meta-Modeling and Model Integration - Requirements and Constraint Representation - Case Studies and Applications Proposals should include an abstract of at least 500 words, and should be submitted by email to the SLDL Program Chair. Important Dates: - Submissions deadline: 13 July 2001 - Acceptance notices: 14 September 2001 - Final papers due: 19 October 2001 Steering Committee General Chair: Dr. Peter Ashenden Ashenden Designs Pty Ltd PO Box 640 Stirling, SA 5152, Australia Phone: +61 414 709 106 Email: peter@ashenden.com.au APChDL Program Chair: Dr. Greg Peterson The University of Tennessee Elec. and Computer Engineering 411 Ferris Hall Knoxville, TN 37996-2100, USA Phone: +1 865 974 6352 Email: gdp@utk.edu SLDL Program Chair: Dr. Perry Alexander The University of Kansas, ITTC 2291 Irving Hill Rd. Lawrence, KS 66044, USA Phone: +1 785 864 7741 Email: alex@ittc.ukans.edu 2000 Chair Emeritus: Jean Mermet KeesDA, Parc Equation 2 avenue de Vignate 38610 Gieres, France Phone: +33 4 76 63 49 34 Email: jean@mermet.org Finance Chair: Dr. Robert Esser Dept. Computer Science, Adelaide University, SA 5005 Australia Phone: +61 8 8303 5198 Email: esser@cs.adelaide.edu.au Publicity Chair: Dr. Sri Parameswaran University of Queensland Dept. Comp. Sci. & Elec. Eng. Brisbane, QLD 4072, Australia Phone: +61 7 3365 4190 Email: sridevan@csee.uq.edu.auArticle: 31488
Hi, Dave.
A gated clock is when you have something like the following:
NewClk <= Clk and ClkEn;
This (in theory) gives you a clk signal derived from 'Clk', using 'ClkEn'
as an enable. It is called a 'gated' clock because it is derived from
Clk via some sort of logic gate, in this case an and gate.
Using a gated clock is generally considered a Very Bad Thing.
The first problem is if your ClkEn signal changes at some point when Clk
is not low. The signal on NewClk will include a glitch or poorly formed
pulse.
The second problem is that there is a delay through the and gate. If you
are using Clk anywhere else in your circuit, perhaps without an enable, or
with a different enable, you are going to get your clock edges at different
times, leading to race conditions and skew problems.
In short, using gated clocks causes a nice, reliable, synchronous design
to have all sorts of nasty asynchronous & skew-related problems.
Unfortunately, none of these problems will show themselves in your regular
functional simulation, since usually you simulate thihgs with zero-delay.
If you do post-place & route simulation with delays, you will probably see
problems.
when Xilinx's warning says to use the 'CE' pin, that is the enable pin on
the Flip-flop that can be used instead of modifying the clock itself.
To use the CE pin, at least in VHDL, you need to do something like this:
process( Clk ) is
begin
if Clk'event and Clk = '1' then -- Rising edge of Clk
if ClkEn = '1' then -- Synchronous enable. This causes ClkEn
-- to be connected to the FF's CE pin.
outsig <= insig;
end if; --enable
end if; --clk
end process;
Hope this helps.
-Kent
"Speedy Zero Two" <david@manorsway.freeserve.co.uk> writes:
> I have a large design which when targeting a 300 series devices gives
> several warning, (like below).
> As this is an internal node how do I find out what to change to correct it.
>
> Cheers
> Dave
>
>
> WARNING:DesignRules:372 - Netcheck: Gated clock. Clock net MUX_OBUF is
> sourced
> by a combinatorial pin. This is not good design practice. Use the CE pin
> to
> control the loading of data into the flip-flop.
Article: 31489"Dave Feustel" <dfeustel@mindspring.com> writes: > I had tried this a couple of times but I can't seem to get there from 'here'. > (I get dns/server error msg) > > "Ray Andraka" <ray@andraka.com> wrote in message news:3B09A644.6F8725C6@andraka.com... > > http://www.aldec.com > > > > Dave Feustel wrote: > > > > > > What is the URL for Aldec? > > > I just checked. www.aldec.com works fine from here. (I'm in Japan) But I *have* found the website to be a bit flaky . . kind of off again on again. Any time it was off, it came back on in a matter of hours. -kentArticle: 31490
Peter, a bit more followup, if you will.
Does that mean it is safe to do something like the following:
process(Clk) is
being
if rising_edge(Clk) then
if enable = '0' then
tri_bus <= value_a;
else
tri_bus <= (others => 'Z');
end if;
end if;
end process;
process(Clk) is
being
if rising_edge(Clk) then
if enable = '1' then
tri_bus <= value_b;
else
tri_bus <= (others => 'Z');
end if;
end if;
end process;
When enable changes, one set of drivers turn off at the clock edge, and
another set turn on at the clock edge (+/- skew). I've always avoided
this, because it seemed that there was a tiny bit of time when both
drivers were on. Is the 'small idle time between the two drivers
being active' greater than the skew on on a clock buffer? If it is, then
it's safe to replace all of my big sychronous muxes with tri-states,
without a heat/damage penalty? (Note: I'm using Spartan-II)
Thanks!
-Kent
Peter Alfke <palfke@earthlink.net> writes:
> Internal 3-states are great, but:
>
> If you use the longline with resistive pull-up, (DTL-fashion, wired AND)
> it is very safe, but slow.
> If you switch between active drivers, you are responsible for making sure
> that only one driver is on at any one time, otherwise you get contention.
> The drivers are deliberately designed to be faster in turn-off than in
> turn-on, so if you think you have a seemless change, there actually is a
> small idle time between the two drivers being active. Good! Short
> contentions are not destrucive, but generate a lot of noise, and
> unnecassary power consumption.
> On very large chips, the longlines represent a lot of capacitance, that's
> why Virtex implements 3-state buffering differently.
>
> Peter Alfke
> ==================================
> Jamil Khatib wrote:
>
> > Is there any drawbacks for using internal tristate buffers to implement
> > busses? or should I keep using muxs?
> >
> > Thanks
> > Jamil
Article: 31491If you use a global clock, known to have very little skew, (it's something like 100 ps) then it is definitely ok to use the same clock edge to turn off one 3-state driver and to turn on another. If you use local lines to distribute the clock, then this is very iffy and I would argue against the 3-state solution unless you can investigate the timing very carefully. Peter Alfke Xilinx is closed this week, but I may check my e-mail occasionally. ================================ Kent Orthner wrote: > Peter, a bit more followup, if you will. > > Does that mean it is safe to do something like the following: > > process(Clk) is > being > if rising_edge(Clk) then > if enable = '0' then > tri_bus <= value_a; > else > tri_bus <= (others => 'Z'); > end if; > end if; > end process; > > process(Clk) is > being > if rising_edge(Clk) then > if enable = '1' then > tri_bus <= value_b; > else > tri_bus <= (others => 'Z'); > end if; > end if; > end process; > > When enable changes, one set of drivers turn off at the clock edge, and > another set turn on at the clock edge (+/- skew). I've always avoided > this, because it seemed that there was a tiny bit of time when both > drivers were on. Is the 'small idle time between the two drivers > being active' greater than the skew on on a clock buffer? If it is, then > it's safe to replace all of my big sychronous muxes with tri-states, > without a heat/damage penalty? (Note: I'm using Spartan-II) > > Thanks! > -Kent > > Peter Alfke <palfke@earthlink.net> writes: > > > Internal 3-states are great, but: > > > > If you use the longline with resistive pull-up, (DTL-fashion, wired AND) > > it is very safe, but slow. > > If you switch between active drivers, you are responsible for making sure > > that only one driver is on at any one time, otherwise you get contention. > > The drivers are deliberately designed to be faster in turn-off than in > > turn-on, so if you think you have a seemless change, there actually is a > > small idle time between the two drivers being active. Good! Short > > contentions are not destrucive, but generate a lot of noise, and > > unnecassary power consumption. > > On very large chips, the longlines represent a lot of capacitance, that's > > why Virtex implements 3-state buffering differently. > > > > Peter Alfke > > ================================== > > Jamil Khatib wrote: > > > > > Is there any drawbacks for using internal tristate buffers to implement > > > busses? or should I keep using muxs? > > > > > > Thanks > > > JamilArticle: 31492
hi, I am trying to put this property on a set of registers in Verilog using this code: reg [17:0] a/* synthesis RLOC_RANGE="X0Y*:X0Y*" U_SET="SETabcdefgh" */; It seems that Synplicity messes up passing that property to the EDF file but that can be managed by editing the file. The main problem is that virtex-2 mapper doesn't seem to be updated for XaYb type of RLOC specification in RLOC_RANGE. Interestingly RLOC works. Here is the error: map -p xc2v1000-5-fg256 -o map.ncd addtree.ngd addtree.pcf Release 3.3.08i - Map D.27 Copyright (c) 1995-2000 Xilinx, Inc. All rights reserved. Using target part "2v1000fg256-5". ERROR:Map:3 - Illegal format for RLOC_RANGE attribute on "FDC symbol "a[0]" (output signal=a[0])". The format is "Rn1Cm1:Rn2Cm2", where n1, m1, n2 and m2 are numbers. It seem that mapper is still expecting old style RLOC_RANGE format for virtex-ii even though the docs say that XaYb coordinate style format is valid for RLOC_RANGE too. Any suggestions are welcome. Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 31493
Hi all, Well, I have learned something: Never tell someone who likes on-chip 3-state buses that they "definitely should use muxed buses" :) And if you do, chose your words very carefully :) :) What I really should have said, after pondering it again, is: "Definitely use muxes for on-chip buses, if you want your design to be portable and re-usable". By "portable", I mean that your design can be targeted to multiple technologies and vendors, without significant redesign for the architectural features of the target. By "re-usable", I mean that your design can be used again as a black box, or grey box, by designers in a future project. As an example, if you are a company that produces IP cores for FPGAs and ASICs, then you would definitely want to use technology-independent coding style as much as possible (which includes using on-chip muxed buses, not tri-state). I have been around for long enough to know that when someone widely known and well respected like Peter Alfke speaks, you will do well to take note and listen carefully (well, I do, anyway :) ). His points relating to Xilinx FPGAs, in response to my previous post, are perfectly valid. In particular, the responses relating to bus contention, reliablitlity, and the Xilinx FPGA global reset, are right-on. Peter, thankyou for making those points. > Have a good Memorial Day weekend ! Our Memorial Day (we have "Anzac Day") is on a different day here in Australia, but I appreciate the sentiment. Hope you have a good one. I'm interested to hear others' views on muxed vs tristate implementations of on-chip buses... Best regards Tony Burch http://www.BurchED.com.au Lowest cost, easiest-to-use FPGA prototyping kits! "Peter Alfke" <palfke@earthlink.net> wrote in message news:3B1131FC.75E854DC@earthlink.net... > Here are some distributed comments by somebody who likes on-chip 3-state > busses for their efficiency. > > Tony Burch wrote: > > > Hi Jamil, > > > > (1) Potential Bus Contention: > > The obvious issue is that MUXs avoid the potential problem > > with tristate buses - bus contention, with multiple drivers active > > at the same time (increases power consumption, reduces reliablility > > of the chip). > > For reliability problems to exist, there would have to be massive > contention, lasting a long time, which can only happen in an faulty design. > > > > > > > (2) Design Portability: > > If your design is HDL based, MUX based buses are technology > > independent, hence your design is more portable. Tristate > > resources are limited in FPGAs, and if you transfer your design > > to ASIC, tristate buses must never be allowed to float > > (FPGAs have weak-keepers on tristate resources, so floating > > doesn't occur). This is a "design for reuse" issue. > > True, but then: Only certain FPGA designs ever get ported to an ASIC. > > > > > > > (3) System Reset: > > This relates to point (1). If you use tristate buses in your > > design, you must use an asynchronous reset for your > > design. This is because with a synchronous reset, you > > may have contention on start-up, > > The global reset that is active during the whole configuration process is > asynchronous, and moreover, the user clock is actually coming in and is > being distributed during the configuration time. ( Speaking for Xilinx, I > don't know the Altera details enough). > So, unless the whole design is done in a weird way, there is no problem > during configuration and start-up. > > > because your system > > will reset to the known start-up state only on the first system > > clock. It is almost always better to use a synchronous > > system reset, or at least synchronise/register your incoming > > system reset signal. So, don't use tristate buses if you > > have a synchronous reset. It follows that if you have > > tristate buses, you must use an asynchronous reset. > > Have a good Memorial Day weekend ! > > Peter Alfke, Xilinx Applications >Article: 31494
I'm perhaps doing something really dumb, and trying to use an FPGA for something it's not meant to do. But to a guy with a hammer, everything looks like a nail, right? I'm implementing a redundant system. On each card, (There's about 6 cards in a chassis) there will be two nominally 52MHz clock inputs. The system controller will select which of the two clocks to use. I'm thinking of using an FPGA on each card to perform the clock switching. If I feed the switched clock into a DLL, then I imagine that the transition from one clock to the other has to be pretty smooth. I imagine the setup as follows (Using Spartan-II): Clk0 an Clk1 and Select are input pins, all going to a LUT3, which drives ClkSelected. I can not connect this to a DLL, so I drive it off-chip, and then back on-chip, to *then* connect it to a DLL. The output of the DLL then goes outside to the real world where it drives a 'zero delay clock buffer', which drives all of the devices on that card. I have a couple of questions that hopefully someone can help me with: 1. Is this a really stupid way of doing it? Should I simply forget about using a FPGA for this? 2. How well do the simulation models of the DLLs in the unisim library model the real DLLs? 3. If I use the same device in the same package with the same place & route for the FPGA on all line cards, what can I expect my worst case device-to-device clock skew to be? 4. Any other comments or suggestions would be greatly appreciated. Thanks in advance. -KentArticle: 31495
Hi, I get a simmilar message: WARNING:DesignRules:372 - Netcheck: Gated clock. Clock net N106 is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop. How may I find out wich net is N106? Looking into the PAR detailed report? I'm affraid it doesn't say anything. Thank you very much in advance, Gonzalo Arana Kent Orthner wrote: > > Hi, Dave. > > A gated clock is when you have something like the following: > > NewClk <= Clk and ClkEn; > > This (in theory) gives you a clk signal derived from 'Clk', using 'ClkEn' > as an enable. It is called a 'gated' clock because it is derived from > Clk via some sort of logic gate, in this case an and gate. > > Using a gated clock is generally considered a Very Bad Thing. > > The first problem is if your ClkEn signal changes at some point when Clk > is not low. The signal on NewClk will include a glitch or poorly formed > pulse. > > The second problem is that there is a delay through the and gate. If you > are using Clk anywhere else in your circuit, perhaps without an enable, or > with a different enable, you are going to get your clock edges at different > times, leading to race conditions and skew problems. > > In short, using gated clocks causes a nice, reliable, synchronous design > to have all sorts of nasty asynchronous & skew-related problems. > > Unfortunately, none of these problems will show themselves in your regular > functional simulation, since usually you simulate thihgs with zero-delay. > If you do post-place & route simulation with delays, you will probably see > problems. > > when Xilinx's warning says to use the 'CE' pin, that is the enable pin on > the Flip-flop that can be used instead of modifying the clock itself. > > To use the CE pin, at least in VHDL, you need to do something like this: > > process( Clk ) is > begin > if Clk'event and Clk = '1' then -- Rising edge of Clk > if ClkEn = '1' then -- Synchronous enable. This causes ClkEn > -- to be connected to the FF's CE pin. > outsig <= insig; > end if; --enable > end if; --clk > end process; > > Hope this helps. > -Kent > > "Speedy Zero Two" <david@manorsway.freeserve.co.uk> writes: > > I have a large design which when targeting a 300 series devices gives > > several warning, (like below). > > As this is an internal node how do I find out what to change to correct it. > > > > Cheers > > Dave > > > > > > WARNING:DesignRules:372 - Netcheck: Gated clock. Clock net MUX_OBUF is > > sourced > > by a combinatorial pin. This is not good design practice. Use the CE pin > > to > > control the loading of data into the flip-flop.Article: 31496
Hi, I'm using Xilinx WebPack, and I can't create the .msk file. Xilinx JTAG Programmer seems to fail programming the device if it doesn't have a .msk file. I had already done right-click on the 'Create Programming File' and checked the box 'Create Mask File', but the .msk file is not created. What else should I do? Thank you very much in advance, Gonzalo AranaArticle: 31497
Got an old copy of ABEL around? I need one for a project, the complete kit (ie, legal) with a key. Prefer version 6 but 5 might work. I might be able to use Minc Synario, but I'm not sure. Viewlogic viewpld/propld might work. Please drop me a line if you have one you would like to sell. Thanks, Aaron nabil@spiritone.comArticle: 31498
Hello Peter. I noticed last year that Coolrunner parts aren't selectable in the Foundation base software. Do you think they might be in the future? Thanks, Paul. (p.s. you posted HTML! I changed the Format to plain text.) > If you need CPLDs, CoolRunner is the way to go!Article: 31499
Aaron Nabil wrote:
>
> Got an old copy of ABEL around? I need one for a project,
> the complete kit (ie, legal) with a key. Prefer version 6
> but 5 might work.
>
> I might be able to use Minc Synario, but I'm not sure.
Minc disappeared a few years back! Xilinx purchased the assets
and incorporated ABEL into their WebPACK program (inside they
call it ABEL version 7.5, IIRC), which is a free download from
their website. WebPACK will compile and fit all simple PLDs,
plus most of the complex Xilinx line, but I suspect it won't
accept the various ABEL fitter plugins for complex PLDs offered
years ago first by DataIO, then Minc and other PLD vendors. At
any rate, not seeing any mention of this in the HELP files, I
haven't tried to use the ones I have. It seems an old out-of-date
path to follow now anyway, the modern pathway seems to be to use
each manufacture's own proprietary tools. Most of these tools do
recognize ABEL program statements.
The Xilinx Foundation series seems more powerful than WebPACK,
with schematic capture, timing analysis, etc., but one rumor is
that they are moving to a free WebPACK as their standard package.
Thanks,
- Win
Winfield Hill
Rowland Institute for Science
100 Edwin Land Blvd
Cambridge, MA 02142-1297
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