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
If I follow f x C x Vsquared = 100 MHz x 20 pF x 3V x 3V = 20 mW the current would be about I = P / U ~= 7 mA But 7mA is much better as 20mA regular Crystal ! I don't find any Crystal with this spec. Maybe you know where to find that? Thanks for any advice. Larry Peter Alfke wrote: > Don't get your hopes too high: > f x C x Vsquared = > 100 MHz x 20 pF x 3V x 3V = 20 mW > Do you need crystal precision and stability? > Peter Alfke > > >>From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com> >>Newsgroups: comp.arch.fpga >>Date: Mon, 15 Mar 2004 19:49:13 +0100 >>Subject: low power Oscillator for Xilinx CoolrunnerII >> >>Hi all, >> >>We are doing a low power product and we need to have an 100Mhz onboard. >>Regular 20mA crystal oscillator will be too high current. >> >>Do you have any idea about the how to generate 100MHz, low current, for >>an collrunnerII based product? >> >>Thanks >>Larry >>www.amontec.com >> > > ------------ And now a word from our sponsor ---------------------- For a quality mail server, try SurgeMail, easy to install, fast, efficient and reliable. Run a million users on a standard PC running NT or Unix without running out of power, use the best! ---- See http://netwinsite.com/sponsor/sponsor_surgemail.htm ----Article: 67601
You won't be any better off programming unused pins to ground, and I think you might burn more power that way since TTL type logic burns less power pulled up than down. Let them float (don't program them at all).Article: 67602
50 ppm means garden-variety cheap xtal. Nothing else gets you that quality... Peter Alfke > From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com> > Newsgroups: comp.arch.fpga > Date: Mon, 15 Mar 2004 21:51:58 +0100 > To: Peter Alfke <peter@xilinx.com> > Subject: Re: low power Oscillator for Xilinx CoolrunnerII > > Peter Alfke wrote: >> Don't get your hopes too high: >> f x C x Vsquared = >> 100 MHz x 20 pF x 3V x 3V = 20 mW >> Do you need crystal precision and stability? >> Peter Alfke >> >> >>> From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com> >>> Newsgroups: comp.arch.fpga >>> Date: Mon, 15 Mar 2004 19:49:13 +0100 >>> Subject: low power Oscillator for Xilinx CoolrunnerII >>> >>> Hi all, >>> >>> We are doing a low power product and we need to have an 100Mhz onboard. >>> Regular 20mA crystal oscillator will be too high current. >>> >>> Do you have any idea about the how to generate 100MHz, low current, for >>> an collrunnerII based product? >>> >>> Thanks >>> Larry >>> www.amontec.com >>> >> >> > Hi and thanks Peter, > > No, we don't need any special precision or stability, +-50ppm schould be > enough. > Do you have any idea or advice ? > > Laurent >Article: 67603
I was just pointing out that ultra-low power and 100 MHz do not go together, unless you run very small voltage swing. Peter > From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com> > Newsgroups: comp.arch.fpga > Date: Mon, 15 Mar 2004 21:59:07 +0100 > To: Peter Alfke <peter@xilinx.com> > Subject: Re: low power Oscillator for Xilinx CoolrunnerII > > If I follow f x C x Vsquared = 100 MHz x 20 pF x 3V x 3V = 20 mW > the current would be about I = P / U ~= 7 mA > But 7mA is much better as 20mA regular Crystal ! > > I don't find any Crystal with this spec. > Maybe you know where to find that? > > Thanks for any advice. > Larry > > Peter Alfke wrote: > >> Don't get your hopes too high: >> f x C x Vsquared = >> 100 MHz x 20 pF x 3V x 3V = 20 mW >> Do you need crystal precision and stability? >> Peter Alfke >> >> >>> From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com> >>> Newsgroups: comp.arch.fpga >>> Date: Mon, 15 Mar 2004 19:49:13 +0100 >>> Subject: low power Oscillator for Xilinx CoolrunnerII >>> >>> Hi all, >>> >>> We are doing a low power product and we need to have an 100Mhz onboard. >>> Regular 20mA crystal oscillator will be too high current. >>> >>> Do you have any idea about the how to generate 100MHz, low current, for >>> an collrunnerII based product? >>> >>> Thanks >>> Larry >>> www.amontec.com >>> >> >> > > ------------ And now a word from our sponsor ---------------------- > For a quality mail server, try SurgeMail, easy to install, > fast, efficient and reliable. Run a million users on a standard > PC running NT or Unix without running out of power, use the best! > ---- See http://netwinsite.com/sponsor/sponsor_surgemail.htm ----Article: 67604
Amontec Team, Laurent Gauch <laurent.gauch@amontecdeleteallcaps.com> wrote: : If I follow f x C x Vsquared = 100 MHz x 20 pF x 3V x 3V = 20 mW : the current would be about I = P / U ~= 7 mA : But 7mA is much better as 20mA regular Crystal ! : I don't find any Crystal with this spec. : Maybe you know where to find that? Use 1.8 Volt VCCO for the oscillator and use the clock doubling meachnisme to run with 50 MHz. With the LVCMOS18_ANY attribute, the 1.8 Volt VCCO should be achievable on any bank... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 67605
Vitual ground by means of a strong (the strongest possible) output, externally and internally tied to ground, does not consume any power at all. Zilch. Remember, these are CMOS driversn even when they are called "LVTTL"! Peter Alfke > From: chris <> > Organization: (none) > Newsgroups: comp.arch.fpga > Date: Mon, 15 Mar 2004 13:10:49 -0800 > Subject: Re: Programmed ground pins v physical grounding (Xilinx CPLD) > > > You won't be any better off programming unused pins to ground, and I think > you might burn more power that way since TTL type logic burns less power > pulled up than down. Let them float (don't program them at all).Article: 67606
We are coupling Philips LPC22114 ARM7TDMI-s with a coolrunnerII. All the IOs bus (3.3V) of the LPC2114 will be connected to the Coolrunner, so we cannot reserve 1.8V for any bank on the CoolRunnerII (we will lose too many IOs on the coolrunnerII). LPC2114 is used for algorithm part and nakia 3310 LCD interface part (via spi), and EEPROM access (I2C). CoolrunnerII will be use for high frequency custom features, and for Compact Flash connection for data logger purpose in fat 12 or 16 format. We are thinking to have a 80-100MHz onboard, to control custom process at 160-200MHz. For that, we will use the dual-edge feature of the CoolrunnerII. Any advice about 80-100Mhz low power Crystal ? Larry Uwe Bonnes wrote: > Amontec Team, Laurent Gauch <laurent.gauch@amontecdeleteallcaps.com> wrote: > : If I follow f x C x Vsquared = 100 MHz x 20 pF x 3V x 3V = 20 mW > : the current would be about I = P / U ~= 7 mA > : But 7mA is much better as 20mA regular Crystal ! > > : I don't find any Crystal with this spec. > : Maybe you know where to find that? > > Use 1.8 Volt VCCO for the oscillator and use the clock doubling meachnisme > to run with 50 MHz. With the LVCMOS18_ANY attribute, the 1.8 Volt VCCO > should be achievable on any bank... > > ByeArticle: 67607
Amontec Team, Laurent Gauch wrote: > Hi all, > > We are doing a low power product and we need to have an 100Mhz onboard. > Regular 20mA crystal oscillator will be too high current. > > Do you have any idea about the how to generate 100MHz, low current, for > an collrunnerII based product? Look at something like the DS1087 clock generator ? Specs appx 5mA, and <= 66Mhz, so the clock double in CR2 would allow 100MHz. Osc Power is very Vcc dependant, so if you are mW-paranoid, I'd look at a separate low voltage logic device, run on minimal Vcc. This philips device is also interesting http://www.philipslogic.com/products/lvc/pdf/74lvc1gx04.pdf .. but the data does not show hysteresis in the buffer, nor linear-mode (Xtal usage) Icc/Vcc/Freq info, so you'd need to trial one. If Freq is not important, a tiny logic ring oscillator with trimmed min vcc would get close to minimum power. -jgArticle: 67608
Amontec Team, Laurent Gauch <laurent.gauch@amontecdeleteallcaps.com> wrote: : We are coupling Philips LPC22114 ARM7TDMI-s with a coolrunnerII. All the : IOs bus (3.3V) of the LPC2114 will be connected to the Coolrunner, so we : cannot reserve 1.8V for any bank on the CoolRunnerII (we will lose too : many IOs on the coolrunnerII). I gave you the hint with LVCMOS18_ANY... Here from the XILINX database: > All CoolRunner-II devices have the ability to share any I/O bank with 1.8V > LVCMOS inputs. The only limitation is that this pin may not utilize a > Schmitt Trigger. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 67609
Philip Freidin wrote: > There seem to be at least 6 ways of specifying area constraints > for a XC2V6000 design I am working on: > > 1) The constraints editor > > 2) My favorite editor UltraEdit, on the UCF file > > 3) The Floorplanner > > 4) PACE > > 5) FPGA editor > > 6) Embedded in the Verilog source My personal preference is usually to embed the constraints in the HDL source, but I use VHDL which allows for this sort of stuff to be derived by algorithm. You don't have that capability in Verilog, so I would write a small script to generate the UCF - I would use Perl but Python or whatever would do just as well. Of course the UCF syntax should have been defined as a TCL script in the first instance. Maybe now would be a good time for the X guys to add an optional UCF2 syntax?Article: 67610
"Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com> wrote in message news:4055fa0a$1@news.vsnet.ch... > Hi all, > > We are doing a low power product and we need to have an 100Mhz onboard. > Regular 20mA crystal oscillator will be too high current. > > Do you have any idea about the how to generate 100MHz, low current, for > an collrunnerII based product? How about a Butler oscillator using a 100 MHz overtone crystal? It should be possible to design this to take a lot less current. LeonArticle: 67611
> The easiest might be PCI104. The PC104 bus is based on the ISA > standard. They added a connector for PCI and called it PC104+. Although the specification is interesting it doesn't seem practical. I'm basically looking for something cheap which is compatible with off the shelf components. Standard PCI seems to be the easiest in that respect. > Otherwise you can do a search on passive PCI backplane. I don't have > info myself, but a google search turned up 18000 hits. Yea, I looked through google but most of the results were junk or companies I've never heard of. I was just wondering if anyone had any reccomendation. CPCI and PMC don't make sense for this (in my opinion) because they give up the whole benefit (in terms of this project) of using PCI. The idea here is low cost with compatibility with standard x86-PC-style components. > I almost forgot, don't let the mention of a PICMG slot fool you. That > is the designation of where your CPU card will plug in. This format is > set up to allow for both PCI and ISA coming off the CPU card, hence the > different name. Yes. I noticed that when looking for a backplane. It seems that most CPU cards use that format. Is this simply to interface with ISA slots on the backplane or does using both busses give some advantage? > I still think you will be better off making a CPU board to plug into a > socket 370 or socket A. That gives you a lot of very low cost options > and is still supported widely. It will be a lot less work making a > board with fewer chips too. Could you explain your reasoning here? It seems that integrating into a socket like those above would be more difficult than simply using PCI. I browsed the site you linked to and it seems that the only standard socket that they offer (without doing custom work) is Socket 7. What would the board gain by plugging into a CPU socket as opposed to PCI? Are the components which are integrated into a motherboard (eg: Socket 7) well documented to the point where I could interface with them from an FPGA plugged directly into the CPU Socket? If so, then it might be more cost effective to manufacture a board which included just an FPGA and a package conversion to a popular socket format. However, I don't see any such products avaliable for purchase (meaning that it would have to be custom fabricated). It seems to me that FPGAs on PCI cards (complete with things such as memories and programming interfaces) are quite avaliable and can be had at a lower cost. The other thing is that it is much easier to find products for PCI than it is for Socket 7. Although Socket 7 has lasted for quite some while I doubt that it will be around as long as PCI. This would mean a new board when Socket 7 becomes hard to find (as it already is in the PC world). Thanks, your input is greatly appreciated!Article: 67612
john jakson wrote: > snip > > I have to wonder whether the circuit guys went to the trouble of > anticipating these sorts of attacks. This really would only concern a > certain agency in possesion of enemy crypto system using these parts, > but good JB movie material. > > back to reading Or those who intend to use it for creditcards or worse "rechargeble" plastic cards to replace cash .. -LasseArticle: 67613
In article <adb3971c.0403150030.306de652@posting.google.com>, john jakson <johnjakson@yahoo.com> wrote: >I have to wonder whether the circuit guys went to the trouble of >anticipating these sorts of attacks. This really would only concern a >certain agency in possesion of enemy crypto system using these parts, >but good JB movie material. There are a LOT of secrets billable at anywhere between $1k and $100k and $1M which might very well end up in hostile hands. In addition to teh other ones mentioned: Sattelite receivers SHOULD all have a unique secret which can be revoked. But an attacker who gets this could go clone-happy and make a dozen (or hundreds) of illegitimate receivers. If they have more common secrets (eg, shared key across a lot of units), they can't be revoked and an attacker who gets one can go really clone-happy. When dealing with security, one can't use absolutes, but $-costs and related issues. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 67614
Hello, Would anyone be able to provide me with some info on which constraints file format to use for Xilinx designs - UCF or XCF? Do I need to use both or just one will do for a design? Thanks Sudhir SinghArticle: 67615
erojr <janos.nojunk.nospam.ero@cern.nojunk.nospam.ch> wrote in message > > I think, if you declare in the Unused pin tab As inputs, tri-stated > > (This is the exact declaration! The other options are As outputs, > driving ground and As outputs, driving an unspecified signal - I > > would really like to know what is this later exactly!), you end up in > your hardware a large number of unconnected input pins. Just in the last > > thread about unconnected TRST pin several people pointed out, that > > input pins MUST NOT remain unconnected, as they might start to oscillate > > in high frequency, possibly destroying your FPGA. Or am I mistaken? > > I did not find any indication in Altera Datasheets if the input pins > have internal weak pullup resistors in general (the TRST pin should have > > one, by definition). This also means if the unused pins aren t connecte > d > at all they must not be declared As inputs, tri-stated . > > Could somebody explain here what is the correct procedure? > > Thanks, > > Janos Ero > CERN Div. EP Newer Altera FPGAs (APEX II, Cyclone, Stratix) have a programmable pull up on the IOs. This is turned on through the Quartus software. The typical value is 25 kohms. There's also an option for a bus hold. This weakly holds the IO in the last state, either high or low. It acts as a ~7 kohm resistor to VCCIO or GND, depending on what the pin was last driven to. The pullup/pulldown is weak enough that it can be overcome by an external driver. Sincerely, Greg Steinke gregs@altera.com Altera CorporationArticle: 67616
what technology is the mcnc.genlib in the SIS package and how do I come to know of this Is it 0.18, 0.35, 0.5 etc. pLEASE CAN ANYONE HELP PARAAG VAISHAMPAYAN UNC CHARLOTTEArticle: 67617
John wrote: > > Yea, I looked through google but most of the results were junk or > companies I've never heard of. I was just wondering if anyone had any > reccomendation. No, but the first page I found had several valid hits and three ads. Passive backplanes are very popular with industrial computers and a there lot of Asian makers which drive the prices down. > Yes. I noticed that when looking for a backplane. It seems that most CPU > cards use that format. Is this simply to interface with ISA slots on the > backplane or does using both busses give some advantage? No, in fact, I had not noticed that there are also some pure PCI backplanes, so that should be better for you. > > I still think you will be better off making a CPU board to plug into a > > socket 370 or socket A. That gives you a lot of very low cost options > > and is still supported widely. It will be a lot less work making a > > board with fewer chips too. > > Could you explain your reasoning here? It seems that integrating into a > socket like those above would be more difficult than simply using PCI. I > browsed the site you linked to and it seems that the only standard > socket that they offer (without doing custom work) is Socket 7. What > would the board gain by plugging into a CPU socket as opposed to PCI? > Are the components which are integrated into a motherboard (eg: Socket > 7) well documented to the point where I could interface with them from > an FPGA plugged directly into the CPU Socket? If so, then it might be > more cost effective to manufacture a board which included just an FPGA > and a package conversion to a popular socket format. However, I don't > see any such products avaliable for purchase (meaning that it would have > to be custom fabricated). It seems to me that FPGAs on PCI cards > (complete with things such as memories and programming interfaces) are > quite avaliable and can be had at a lower cost. The other thing is that > it is much easier to find products for PCI than it is for Socket 7. > Although Socket 7 has lasted for quite some while I doubt that it will > be around as long as PCI. This would mean a new board when Socket 7 > becomes hard to find (as it already is in the PC world). First, you need to do more than just look at web pages. ISI is a company that you need to talk with to get info on just what they do and don't have. They have a full line of PGA adapters. It is unlikely that they can't fit another socket. If you plug into the CPU socket, you don't need to build any of the other stuff at all. I am sure you can get adequate info on socket 7. Intel had to document it for the chip makers. This would be part of the chip spec. If not Intel, then AMD likely has a spec. They made parts for it too, didn't they? Why do you need a socket that will be long lived? Changing your FPGA design for a different socket should be no big deal if you need to do that in a couple of years. Are you going to mass produce this thing? I have not seen any PCI cards with FPGAs setup to be bus masters, but if they are there that would be fine. Keep in mind that it will need memory on the card since PCI transfers are much slower than SDRAM or DDR. The other difference is that a PC motherboard will have all the IO features you need built in. It is not easy to find interfaces for keyboards, etc on PCI cards. But I guess you can add anything you want via USB. I have not spent much time thinking about this. I just know that a mother board gives you everything a high speed CPU needs (including low voltage power in large doses). A PCI card will have to do a lot of work to replace that. I may have said this once before, or maybe I said it to John, but you should do your design work before you even both to consider how or what hardware to put it in. You likely have months of work ahead of you designing the HDL. Finding hardware should be the easy part. Heck, if push comes to shove, you can use one of my boards if you will be happy with an XC3S400. It will have SDRAM and SBSRAM, (you can ignore the DSP chip) but only a PC104 interface, no PCI... at least not this version. Good Luck. :) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 67618
UCF is used with the command NGDBuild, XCF is used with XST. I managed to do some projects without using any XCF constraints, so I guess XCF is not compulsory... Kelvin Sudhir Singh <Sudhir.Singh@email.com> wrote in message news:e3db8a89.0403151715.4960252b@posting.google.com... > Hello, > Would anyone be able to provide me with some info on which constraints > file format to use for Xilinx designs - UCF or XCF? Do I need to use > both or just one will do for a design? > > Thanks > Sudhir SinghArticle: 67619
> No, in fact, I had not noticed that there are also some pure PCI > backplanes, so that should be better for you. What's a "pure" PCI backplane? Where do the clocks come from and/or who does the bus arbitration? Got a sample URL? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 67620
Is there anything to do ??? you could try re-dreaming up a different algorithm... or use the RAM better... Can you fit a bigger device on the same footprint.? Can you get a piggy back board built to tide you over to the next PCB release... P.S. its important to check your resources before designing something... or you'll design a PC with 640 k of RAM and expect it to run windows Simon "roland voraberger" <madcap@sbox.tugraz.at> wrote in message news:c348n4$23a9qs$1@ID-209114.news.uni-berlin.de... > hello! > > iīve got big problems with RAM in a ACEX 1k design. i canīt get a fit > because i use too much (16/ 12) EABīs but in total number of bits iīm > far beyond the maximum number of the bits available. > what can i do (software is max+plus II 10.1) > > thanks in advance, roland > >Article: 67621
The "trigger" in chipsope pro refers to external trigger(manually applied to board) or is an internal trigger(generated by the software)? Whichever is true, what are the steps to see the waveforms on the waveform window in chipscope. When I set the trigger condition, the software starts "uploading data" from fpga but doesnot collect any samples and it keeps on showing"upload data" message and my fpga gets heated up.I have been going nuts on this, somebody please help.Article: 67622
process(clk,iReset)
begin
if(iReset='1') then
ResetSR="00";
elsif(clk'event and clk = '1') then
ResetSR(0) <= '1';
ResetSR(1) <= ResetSR(0);
end if;
end process;
RESET <= ResetSR(1);
simplesm : process(clk,RESET)
begin
if(Reset = '1') then -- NOTE, this is not iReset
state <= S001;
elsif(clk'event and clk='1') then
case state is =>
when S001 =>
state <= S010;
when S010 =>
state <= S100;
when S100 =>
state <= S001;
end case
end if
end process simplesm;
Ray Andraka <ray@andraka.com> wrote in message news:<404DEFB5.6806938E@andraka.com>...
> The GSR net is asynchronous. No matter how slow your clock is, unless you synchronize the reset to the
> clock OUTSIDE OF THE FPGA, you can't guarantee all flip-flops in the design will see the release of
> reset on the same clock edge. This is because without syncronization to the clock, there is no
> guarantee the release of reset won't happen close enough to a clock edge to make some flip-flops see it
> before the clock edge, and others after the clock edge. You can't synchronize it inside the FPGA
> because GSR affects all the flip-flops. A side issue is the fact that the GSR net is very slow compared
> to the speed the rest of the FPGA logic can operate at.
>
> William Wallace wrote:
>
> > Jeff Cunningham <jcc@sover.net> wrote in message news:<m8I2c.274$_43.199987@newshog.newsread.com>...
> > > William Wallace wrote:
> > > > THE IMPORTANCE OF PROVIDING A RESET THAT LEAVES THE RESET
> > > > SYNCHRONOUSLY EVEN IF IT DRIVES THE ASYNCHRONOUS RESET...
> > >
> > > You cannot rely on async reset at startup for initializing one hot state
> > > machines and the like...
> >
> > Please explain why. Meanwhile, releasing the asynchronous reset
> > synchronously, and ensuring that the reset path delay and setup is
> > less than a clock period, would work.
> >
> > Please re-read my original post, and tell me exactly where I am wrong.
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930 Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
> "They that give up essential liberty to obtain a little
> temporary safety deserve neither liberty nor safety."
> -Benjamin Franklin, 1759
Article: 67623have added the ILA and the ICON core to my design... but when i run the analyser it simply hang and says "waiting to be uploaded". Is this the problem with the setting of the triggers. do i need to give the chip (FPGA kit) any external input.... how does it take these triggers....Article: 67624
"It is the control logic, and only control logic that will take off running that matters." I agree that matters. E.g., a state machine that has some INIT states before it transitions to an IDLE state. State Machines that are waiting for some external input to change may be less prone to problems. rickman <spamgoeshere4@yahoo.com> wrote in message news:<404D54D8.7AC8882E@yahoo.com>... > William Wallace wrote: > > > > rickman <spamgoeshere4@yahoo.com> wrote in message > > > > > ...The async global reset is not designed to be fast. So > > > you have to make sure that your design will work if the FFs come out of > > > reset on different clock cycles. > > > > That is what I was getting at with the static timing analysis checking > > the reset line to ensure that all flip flops with an asynchronous > > reset (driven from the output of a FF) see the same first clock. If > > the static timing analysis tools can do that, you don't need to waste > > combinatorial real-estate on synchronous resets. > > The analysis tool can't make the GSR network faster than it is. It is > not designed to be fast, it is designed to minmize its use of resources > (area). I don't have a number for the speed of the path, but even when > FPGA logic topped out at 50 MHz, we were warned not to rely on the GSR > net to release all the FFs on the same clock cycle. > > Normally you don't need to worry with the reset release on most of your > logic. Things like data path registers don't care about the reset. It > is the control logic, and only control logic that will take off running > that matters. In most of my designs, the control logic waits for some > input signal anyway. I don't build too many FSMs that start off by > counting. The ones that do can be set to go through a set of gray codes > initially so that they are reset release insensitive. > > If you can get the reset to release the entire design in the same clock > cycle, then you are ok. But you can't use one of the standard clocked > FFs to do that. It will have to be an external FF that controls the > timing of the release. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX
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