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
Allan, We were having a little trouble with our server's posting ability so it might not be your fault. The sad part is I have written several responses to people over the past few months but no one could see them unless you look at our server (it showed up on our server but not the outside world so I thought they were getting out). I think all is fixed now and if you are reading this, then hopefully the problem is corrected and should not cause confusion going forward. Sorry about that. BTW, that attribute is in the 6.1i Constraints Guide on page 333 but looks like you might have found it now. -- Brian Allan Herriman wrote: > On Thu, 04 Mar 2004 21:31:18 +1100, Allan Herriman > <allan.herriman.hates.spam@ctam.com.au.invalid> wrote: > > >>On Tue, 02 Mar 2004 05:08:06 +1100, Allan Herriman >><allan.herriman.hates.spam@ctam.com.au.invalid> wrote: >> >>[snip] >> >>I didn't see Brian's post on my server, but google found it. >> >>// synthesis attribute equivalent_register_removal of c is "no" >>// synthesis attribute equivalent_register_removal of d is "no" >> >> >>Silly me. I was looking for constraints in the constraints guide, and >>this one isn't listed there. > > > Hang on, it *is* there. I don't understand how I missed it. > > Oh well. > > Allan.Article: 67051
William Wallace wrote: > TRST is often used. Could you explain this a bit more detailled? TRST is an optional JTAG signal and in JTAG applications you can easily get the same effect using the other signals. Or am I mistaken? Janos Ero CERN Div. EPArticle: 67052
Hello all I guess I had better stop saying that I'm new to this FPGA stuff as I've being saying that for two years now. Anyway Im certainly a novice who is improving with time and the gratefully accepted input of this newsgroups members. At this stage I am reasonably happy with my design in Verilog targeting a xilinx xcs05xl. However, I find that there is one latch that I dont want to reset when I am reseting everything else in the FPGA. This is because it holds configuration information for the FPGA and the external circuitry. If I dont set this latch to zero when my global clear line is low I get about 55 warnings at my synthesis step. I get: DPM : Warning NET ACB/ACB_NOT_TRIGGER_FOUND does not set/reset /Int_read_trigger_address/Q_reg (FPGA -GSRMAP-13) about 55 times. Im not sure how the nets mentioned above relate to the latch that is not being cleared. What is the effect of my action. Are there lots of FFs not being reset by my global clear signal? How do I get rid of all these warnings? Can I decide not to clear one latch and get all others to clear without all the warnings? Thanks in advance. Denis ___________________ http://www.CentronSolutions.com From concept to productionArticle: 67053
erojr wrote: > > William Wallace wrote: > > TRST is often used. > > Could you explain this a bit more detailled? > > TRST is an optional JTAG signal and in JTAG applications you can easily > get the same effect using the other signals. Or am I mistaken? TRST puts the state machine in a defined state. Most devices also reset the state machine on power up. In addition, if you hold the TMS line high and clock TCK it will return the state machine to the starting state after 5 clock cycles, IIRC. Of course, depending on the implementation, the mechanism that operates the state machine can get fouled up by power glitches or other anomalies. Then the machine may get into a state that operating the TCK line may not control the state. Then you will need a power on or a TRST type reset. I don't know that this is common, but in theory it is possible. -- 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: 67054
On 04 Mar 2004 00:30:13 +0100, Petter Gustad wrote: >> The hyperthreaded Xeons run as two processors, so a quad Xeon board >> appears to a HT-aware OS as an 8-CPU system. > >Then you would call a system with single P4 with HyperThreading a dual >processor system as well then? This would be a little "unfair" when >comparing to a full dual-core CPU like the rumored UltraSparc-IV. Windows XP sees my dual-Xeon workstation as a quad CPU machine, so it can schedule four separate simultaneous threads. If it's behaving as a quad-processor, then I'm not sure what else I should call it. >> Why pay for all the extra high-end hardware in a top-end server if you >> don't need it? When I was last looking at building systems like this, > >My point was that you usually get lots of extra high-end hardware when >you buy large SMP systems, especially when you need to go beyond >4-way. Also, it's usually cheaper to get 4x4GB RAM rather than 16GB >RAM for a single MB (unless you have a large enough number of DIMM >slots). I agree, it's difficult to buy a ready-made high-end system that doesn't have redundant PSUs, hot-swap RAID etc. This is why I haven't bought off the shelf for over 5 years now, but buy the components I actually want and assemble it myself. >> about 18 months or so ago, a quad-Xeon mobo from Supermicro was >> <$2000, and the processors were around $450 apiece. > >This is pretty good, I was not aware of the low cost of the Supermicro >MB. You would end up at close to $4000, e.g. in the same ballpark as >buying 4 P4 systems. So if the application was performing better on >the SMP than on the to the cluster I would definitely go with the SMP. Bare high-end mobos are cheaper than most people think. At the time, I paid around $850 for a Supermicro P4DC6+ dual Xeon board, but I haven't looked at current prices. There is a hike when you want more than two physical processors, though - presumably due to low demand and less competition. The P4 Xeons are hugely cheaper than the PIII versions for some reason. If you're an AMD fan, then Tyan make nice multi-CPU boards at sensible prices. -- MaxArticle: 67055
See also: http://www.xilinx.com/products/virtex2pro/v2p-pkgs.htm (for the V2Pro only) Marc Baker <marc.baker@xilinx.com> wrote in message news:<4044DBC2.D7A5AFA1@xilinx.com>... > There are various graphical tools to see the association of CLBs to IOBs, such > as PACE, Floorplanner, and FPGA Editor. A straight ASCII file can be generated > by running partgen - for example, "partgen -v 3s200ft256" which creates a > 3s200ft256.pkg file. > > Chris Cheung wrote: > > > Hi, > > > > Just a stupid question: > > > > I need to implement something in high speed so I have to use RLOC_ORIGIN > > statement as some experts suggested. > > However, I couldn't find any information regarding to the "which CLB > > (x?y?) associate with which output pin". > > Does anyone know which Xilinx document to look at for the "addresses" > > and phyiscal location of CLBs for certain FPGA? ( I am doing design with > > Spartan 3 and Virtex 2 pro). > > > > Thanks > > > > ChrisArticle: 67056
Denis Gleeson wrote: > > Hello all > > I guess I had better stop saying that I'm new to this FPGA stuff > as I've being saying that for two years now. Anyway Im certainly a > novice > who is improving with time and the gratefully accepted input of > this newsgroups members. > > At this stage I am reasonably happy with my design in Verilog > targeting > a xilinx xcs05xl. > > However, I find that there is one latch that I dont want to reset when > I am reseting everything else in the FPGA. This is because it holds > configuration > information for the FPGA and the external circuitry. If I dont set > this latch > to zero when my global clear line is low I get about 55 warnings at my > synthesis step. > > I get: > DPM : Warning NET ACB/ACB_NOT_TRIGGER_FOUND does not set/reset > /Int_read_trigger_address/Q_reg (FPGA -GSRMAP-13) > > about 55 times. > > Im not sure how the nets mentioned above relate to the latch that is > not being cleared. > > What is the effect of my action. Are there lots of FFs not being reset > by my global clear signal? > How do I get rid of all these warnings? > Can I decide not to clear one latch and get all others to clear > without all the warnings? I could be wrong, so maybe I should let the Xilinx people reply. But I am pretty sure that in the Xilinx parts, *all* CLB FFs are either set or reset by the async GRS. This is a hardware feature and does not depend on how you specify the async reset in your code. The code can only control whether it is set vs. reset. (I don't remember if the IOB FFs are cleared or have a controlled async set/reset). The GRS always controls the starting state of the CLB FFs on configuration, but you don't have to use the GRS signal when you reset your design otherwise. In that case you can use your own input to globally reset your design and have that signal go to the FFs of your choice. In either case, you need to be aware of the problems created anytime you use a global reset. The delays are typically pretty long and it is hard to assure that your reset trailing edge meets the setup and hold times on all the FFs. When it does not, it can create problems with FFs coming out of reset on different clock cycles and even FFs suffering from metastability problems, although I expect that would be exceedingly rare. Typically an async reset needs to be combined with a mechanism to hold various parts of your design in reset until every FF has been released. -- 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: 67057
On 2 Mar 2004 14:47:55 -0800, Ted Lechman wrote: >I've discovered incompatability between the ModelSim dongle and >certain notebook computer's printer ports Unfortunately, parallel and serial port dongles aren't really compatible with *anything*. They inevitably work by stealing power from the interface they're plugged into, and it's a matter of pure chance whether that will work at all, since the PC isn't obliged to provide power in this way. Not surprisingly, laptops are frequently problematic in this respect. I would have thought a competent company should be able to supply a USB dongle, which may legally negotiate to draw up to 500mA from the port. Alternatively, you might try wiring in an external PSU of some sort to supply the dongle? Ugly, but it might get you going. Personally, I avoid dongles like the plague they are, but I realise there isn't always a credible alternative. -- MaxArticle: 67058
rickman <spamgoeshere4@yahoo.com> wrote in message news:<4046C6F1.6CEF9658@yahoo.com>... > However, I must say I still have not figured out how to connect the FPGA > to a CPU data bus without a CPLD in between. Why? What's the issue here? JakeArticle: 67059
hi all,
i am getting this error while synthesizing on XILINX4.1e.
the individual units are synthesizing.
FATAL_ERROR:HDLParsers:vhptype.c:270:$Id: vhptype.c,v 1.1 2001/03/22
18:59:29 kingsley Exp $:200 - INTERNAL ERROR... while parsing
G:/ACSUNIT/totalunit.vhd line 337. Contact your hot line. Process will
terminate. To resolve this error, please consult the Answers Database
and other online resources at http://support.xilinx.com
EXEWRAP detected a return code of '1' from program
'F:/Xilinx/bin/nt/xst.exe'
Done: failed with exit code: 0001.
thank u all.
Article: 67060On Fri, 5 Mar 2004 00:29:01 +1300, Bevan Weiss wrote: >I'm trying to find some information on how the mersenne twister pseudo >random number generator would be implemented in hardware. So far the only >descriptions I can find for the algorithm relate to 32bit (or more) software >operations. Why do you particularly want to use a Mersenne Twister? It's fast, and it has a long period, but other RNGs might be more suitable for your application. MT is patented, as well, though it's currently freely licensed for commercial use. I wouldn't want to try to convert it to use less than 32-bit operations though, since you're inevitably going to lose a great deal of the performance that presumably caused you to choose it in the first place. What would be the period of a 16-bit implementation, for instance? >If anyone has any information on how I might go about such an implementation >or any links on where I might be able to get more information on how to >perform such an implementation it would be greatly appreciated. Here's the MT inventor's home page, if it helps: http://www.math.keio.ac.jp/~matumoto/emt.html -- MaxArticle: 67061
Jake Janovetz wrote: > > rickman <spamgoeshere4@yahoo.com> wrote in message news:<4046C6F1.6CEF9658@yahoo.com>... > > However, I must say I still have not figured out how to connect the FPGA > > to a CPU data bus without a CPLD in between. > > Why? What's the issue here? I want to find a way to connect this programming interface directly to the CPU as if it were a peripheral device. So far I have not figured out a way to do that. Most CPUs provide a WR- signal that changes *within* the CS- being active. So that would trigger an abort if connected directly. Further, there is no signal equivalent to the CCLK coming from an MCU. I also don't understand what Chen meant by having to clock out the "status words" with CCLK. I have been reading XAPP176 which applies to Spartan II since I don't see a similar document on the Spartan 3. I don't see where reading "status words" is discussed. I also don't see this in the Spartan 3 data sheet But I can say I have finally figured out the documentation on the bit stream format. Maybe it is just me, but I find the Xilinx documentation on configuration is very cryptic. I had to read and reread that section over a dozen times to finally understand all the difficult parts. I also want to have my FPGA design be able to use this same interface, but not give up partial reconfiguration. At this point I am pretty sure the only way to map my FPGA design to the CPU bus and still retain the ability for partial reconfiguration is to have *two* separate interfaces on the FPGA. So I will have to have two sets of data bus pins and two sets of WR-, CS-, etc on the FPGA. -- 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: 67062
Austin, Thanks, that's a decent and concise treatment of jitter. Not particularly easy to do. Quick question that perhaps you (or anyone who's had experience w/ the RocketIO receivers) could answer... Is the Peak-Peak Jitter tolerance spec'd in the rocketIO user's guide (.65 UI) spec'd in the 14-sigma fashion described in the xapp462 or is some measurement interval (such as loop lock time) assumed? As it's given in the RocketIO User's guide, there's no BER, no sigma factor, and no specific measurement interval. Table 3-3, p.103 of the guide only says "peak-to-peak" Any help/ experience would be greatly appreciated Thanks, --Josh Model MIT Lincoln Laboratory "Austin Lesea" <austin@xilinx.com> wrote in message news:c27kfg$e211@cliff.xsj.xilinx.com... > http://www.xilinx.com/products/virtex/techtopic/vtt013.pdf > > Is a side by side bench test of the DLL vs the PLL in a "real" situation > where IOs and logic are switching, not just a quiet side by side > back-off of a do-nothing design. > > As frequencies increase, delays decrease, jitter fast becomes the number > one problem in a design. > > Realizing this, we have many tools, design notes, suggestions, and > techniques to minimize jitter, and maximize performance. > > Also, > > http://www.xilinx.com/bvdocs/appnotes/xapp462.pdf > > is an excellent newly written description of the DCM (includes DLL) for > Spartan 3 which also makes for good reading. > > Austin > > Michael Chan wrote: > > Just wondering if anyone can point me to some articals or papers that analyse > > the characteristics of xilinx DLLs vs altera PLLs. > > > > Thanks. > > > >Article: 67063
Josh, The p-p jitter for the V2P Rocekt IO is specified by using the 14 sigma case of broadband (DC to daylight, no filters) RMS jitter as measured by the Agilent DCA. This method defines the "eye" as that which has 1E-12 BER or less extrapolated from the 14 sigma points (no actual BER measurements are done with this method). As most folks know, if you filter out the low frequency phase noise (which is tracked out by the receiver) then the RMS jitter is even less. Hence the claim that we are error free when used correctly is valid (as the 1E-12 contour was grossly pessimistic). Austin Josh Model wrote: > Austin, > > Thanks, that's a decent and concise treatment of jitter. Not particularly > easy to do. > > Quick question that perhaps you (or anyone who's had experience w/ the > RocketIO receivers) could answer... > > Is the Peak-Peak Jitter tolerance spec'd in the rocketIO user's guide (.65 > UI) spec'd in the 14-sigma fashion described in the xapp462 or is some > measurement interval (such as loop lock time) assumed? > > As it's given in the RocketIO User's guide, there's no BER, no sigma factor, > and no specific measurement interval. Table 3-3, p.103 of the guide only > says "peak-to-peak" > > Any help/ experience would be greatly appreciated > > Thanks, > --Josh Model > MIT Lincoln Laboratory > > > > > > "Austin Lesea" <austin@xilinx.com> wrote in message > news:c27kfg$e211@cliff.xsj.xilinx.com... > >>http://www.xilinx.com/products/virtex/techtopic/vtt013.pdf >> >>Is a side by side bench test of the DLL vs the PLL in a "real" situation >>where IOs and logic are switching, not just a quiet side by side >>back-off of a do-nothing design. >> >>As frequencies increase, delays decrease, jitter fast becomes the number >>one problem in a design. >> >>Realizing this, we have many tools, design notes, suggestions, and >>techniques to minimize jitter, and maximize performance. >> >>Also, >> >>http://www.xilinx.com/bvdocs/appnotes/xapp462.pdf >> >>is an excellent newly written description of the DCM (includes DLL) for >>Spartan 3 which also makes for good reading. >> >>Austin >> >>Michael Chan wrote: >> >>>Just wondering if anyone can point me to some articals or papers that > > analyse > >>>the characteristics of xilinx DLLs vs altera PLLs. >>> >>>Thanks. >>> >>> > > >Article: 67064
Hi, There is a reference design called the "half bridge" which you might consider using. I believe, with all the bells and whistles enabled, it is best implemented for 66 MHz designs. However, if you are interested in just a very small part of the functionality, you can customize it (pare it down) and end up with something that runs faster. You can also craft something yourself; if you want to go down that road I invite you to contact me privately. Eric Matthias Müller wrote: > > Hello, > I want to perform a DMA via the Xilinx PCI-X core (64bit/133MHz) to the > system's DRAM. Therefore I want to act as a busmaster and transfer > 4K-byte blocks (maximum bytecount) in initiator-burst-transfers. The > problem is that the DMA can be aborted at any time, so I have to > calculate the appropriate new byte-address, request the bus again and so > on. This can be a rather complicated design, so my question is: is there > any way to simplify a DMA like descriped above or are there any > interface-modules for the Xilinx PCI-X core which work as DMA-controller > for the core. > Futhermore I'm looking for a simulation-model for the PCI-X-bus-side. > Thank you for help, > MatthiasArticle: 67065
rickman is right, GSR forces every flip-flop in the chip. Faced with the need to store some bits that must be unaffected, I have suggested using latches made up of feddback across one LUT, but nowadays the SRL16 would be better. You just shift in some data into the SRL16, and you can rest assured that it will remain undisturbed by GSR. Peter Alfke ========================= rickman wrote: > > > I could be wrong, so maybe I should let the Xilinx people reply. But I > am pretty sure that in the Xilinx parts, *all* CLB FFs are either set or > reset by the async GRS. This is a hardware feature and does not depend > on how you specify the async reset in your code. The code can only > control whether it is set vs. reset. (I don't remember if the IOB FFs > are cleared or have a controlled async set/reset).vArticle: 67066
On Paul Leventis' info that the VPR Benchmark (Part of SPEC) is an FPGA Place and Route program I went and looked at a few results at www.spec.org. The interface is hideous, but I managed to ferret out a few results: 2.0 GHz Opteron time 115, score 1215 2.0 GHz Athlon 64 time 127, score 1102 2.2 GHz Athon XP (32bit) time 182, score 768 3.2 GHz Xeon (1MB cache) time 129, score 1085 I started out looking for a 32bit Athlon vs. 64bit, but couldn't find any exact matches on a GHz vs. GHz, but the slower 64bit cpu's trounced the 32 bit XP's even given its faster clock. Interesting also that the super Xeon couldn't best the Opteron even with over a GHz clock advantage. So if VPR is any indication then a 64 bit AMD system looks very promising. KenArticle: 67067
Rick, Abort status words get clocked out after Abort. I've also sent you a seperate e-mail on this. Regards, Wei rickman wrote: > Jake Janovetz wrote: > >>rickman <spamgoeshere4@yahoo.com> wrote in message news:<4046C6F1.6CEF9658@yahoo.com>... >> >>>However, I must say I still have not figured out how to connect the FPGA >>>to a CPU data bus without a CPLD in between. >> >>Why? What's the issue here? > > > I want to find a way to connect this programming interface directly to > the CPU as if it were a peripheral device. So far I have not figured > out a way to do that. > > Most CPUs provide a WR- signal that changes *within* the CS- being > active. So that would trigger an abort if connected directly. Further, > there is no signal equivalent to the CCLK coming from an MCU. > > I also don't understand what Chen meant by having to clock out the > "status words" with CCLK. I have been reading XAPP176 which applies to > Spartan II since I don't see a similar document on the Spartan 3. I > don't see where reading "status words" is discussed. I also don't see > this in the Spartan 3 data sheet > > But I can say I have finally figured out the documentation on the bit > stream format. Maybe it is just me, but I find the Xilinx documentation > on configuration is very cryptic. I had to read and reread that section > over a dozen times to finally understand all the difficult parts. > > I also want to have my FPGA design be able to use this same interface, > but not give up partial reconfiguration. At this point I am pretty sure > the only way to map my FPGA design to the CPU bus and still retain the > ability for partial reconfiguration is to have *two* separate interfaces > on the FPGA. So I will have to have two sets of data bus pins and two > sets of WR-, CS-, etc on the FPGA. > >Article: 67068
Peter Alfke wrote: > > rickman is right, GSR forces every flip-flop in the chip. Faced with the > need to store some bits that must be unaffected, I have suggested using > latches made up of feddback across one LUT, but nowadays the SRL16 would > be better. You just shift in some data into the SRL16, and you can rest > assured that it will remain undisturbed by GSR. Although that begs the question of how is this latch set on the initial power up of the part? It will either power up randomly (differently) each time, or it will power up in a consistent state, but not defined. I guess whether this matters depends on how it is being used... -- 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: 67069
In article <40479FA2.88E36F15@yahoo.com>, rickman <spamgoeshere4@yahoo.com> wrote: >> rickman is right, GSR forces every flip-flop in the chip. Faced with the >> need to store some bits that must be unaffected, I have suggested using >> latches made up of feddback across one LUT, but nowadays the SRL16 would >> be better. You just shift in some data into the SRL16, and you can rest >> assured that it will remain undisturbed by GSR. > >Although that begs the question of how is this latch set on the initial >power up of the part? It will either power up randomly (differently) >each time, or it will power up in a consistent state, but not defined. >I guess whether this matters depends on how it is being used... Actually, isn't the case that SRL16/LutAsRam data starts up at a known, DEFINED state based on the initial configuration of the LUT itself? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 67070
Kenneth Land wrote: > > On Paul Leventis' info that the VPR Benchmark (Part of SPEC) is an FPGA > Place and Route program I went and looked at a few results at www.spec.org. > > The interface is hideous, but I managed to ferret out a few results: > > 2.0 GHz Opteron time 115, score 1215 > 2.0 GHz Athlon 64 time 127, score 1102 > 2.2 GHz Athon XP (32bit) time 182, score 768 > 3.2 GHz Xeon (1MB cache) time 129, score 1085 > > I started out looking for a 32bit Athlon vs. 64bit, but couldn't find any > exact matches on a GHz vs. GHz, but the slower 64bit cpu's trounced the 32 > bit XP's even given its faster clock. > > Interesting also that the super Xeon couldn't best the Opteron even with > over a GHz clock advantage. > So if VPR is any indication then a 64 bit AMD system looks very promising. Ok, so the AMD 64 bit machines seem to outrun their 32 bit machines and even outrun the fastest Intel 32 bit machines, but this is while running 32 bit programs. The same AMD 64 bit machines run slower when running the same program in 64 bit mode. Hmmm... I'm not sure what this means in terms of the future of AMD 64 bit processing. I guess place and route is not the only engineering application, so the level of adoption of the AMD 64 bit architecture depends on a lot of other apps as well. What I do know is that the Itanium has been a big flop. It will be interesting to see what Intel's new 64 bit (32 bit compatible) machine will be like. But I'm not sure I want a CPU that clocks at frequencies higher than my cordless phone uses ;) -- 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: 67071
Max <mtj2@btopenworld.com> writes: > Windows XP sees my dual-Xeon workstation as a quad CPU machine, so I hardly ever use Windows so I haven't had a chance to observe this. I don't have a HT system at hand now, but what does grep ^processor /proc/cpuinfo return on a Linux based HT system? > If you're an AMD fan, then Tyan make nice multi-CPU boards at > sensible prices. We have a small cluster of Quad Opterons at work. They give superb performance when I run Synopsys Design Compiler and similar tools. Unfortunately I can't run Quartus II (3.0) on these as I have mentioned earlier. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 67072
In article <4047A189.496AF35B@yahoo.com>, rickman <spamgoeshere4@yahoo.com> wrote: >> The interface is hideous, but I managed to ferret out a few results: >> >> 2.0 GHz Opteron time 115, score 1215 >> 2.0 GHz Athlon 64 time 127, score 1102 >> 2.2 GHz Athon XP (32bit) time 182, score 768 >> 3.2 GHz Xeon (1MB cache) time 129, score 1085 >> >> I started out looking for a 32bit Athlon vs. 64bit, but couldn't find any >> exact matches on a GHz vs. GHz, but the slower 64bit cpu's trounced the 32 >> bit XP's even given its faster clock. >> >> Interesting also that the super Xeon couldn't best the Opteron even with >> over a GHz clock advantage. >> So if VPR is any indication then a 64 bit AMD system looks very promising. > >Ok, so the AMD 64 bit machines seem to outrun their 32 bit machines and >even outrun the fastest Intel 32 bit machines, but this is while running >32 bit programs. The same AMD 64 bit machines run slower when running >the same program in 64 bit mode. >Hmmm... I'm not sure what this means in terms of the future of AMD 64 >bit processing. I guess place and route is not the only engineering >application, so the level of adoption of the AMD 64 bit architecture >depends on a lot of other apps as well. WILD A** guess says this probably comes down to the faster memory heirarchy in the AMD 64 bit processors. Since the Athlon 64 has the memory controller on the CPU, directly connecting to the DIMMs, memory latency is something like 15 processor cycles + DRAM access, which is amazingly low, saving 2 chip crossings and a boatload of chipset overhead. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 67073
SRL16 starts up out of configuration with known contents (all '0's is the
default, use the INIT attribute to set some other value). It is not altered at
all by GSR. Just be careful coming out of reset that you don't write into it
inadvertently.
"Nicholas C. Weaver" wrote:
> IActually, isn't the case that SRL16/LutAsRam data starts up at a
> known, DEFINED state based on the initial configuration of the LUT
> itself?
> --
> Nicholas C. Weaver nweaver@cs.berkeley.edu
--
--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: 67074Denis, There are a few solutions to this problem. First the SRL was mentioned but since you are targeting a Spartan-XL, you do not have an SRL but you do have LUT-RAM and it can serve this same purpose. You can use a RAM16X1S with all address lines tied to a known value (zeroes) and the write enable tied high. You would have more-or-less a FF not tied to global set/reset (GSR) at all. Another possibility to fix this problem is to use a regular FF and have the initial state specied to a one. It sounded like the problem was this the register going to zero and the default state can be made to a one if that solves the issue. In that case, and time GSR is used that register would be set to a one not a zero. Both of the above suggestions are assuming that you are using the STARTUP block to get access to the dedicated GSR net which will set or reset depending on the defined init state of the FF at configuration. If you have not instantiated a STARTUP block in your code, then you will be using local resets using standard routing and in that case anything that you do not connect to the reset will not be reset after power up. This will consume routing resources but the XCS05XL is a small device and as long as timing can be met, should be OK. The warning message below looks to be issued by the synthesis tool and I am not exactly sure why it is being issued. I think it is trying to warn you that you may have made a mistake in accidentally not connecting one register to the reset but it sounds like you want this done. My suggestion would be to do a timing simulation and see if it works as you want it to. If so, then that can be ignored. If it does not act properly, then you can figure out why and maybe that can address this warning as well. Hope this helps, -- Brian Denis Gleeson wrote: > Hello all > > I guess I had better stop saying that I'm new to this FPGA stuff > as I've being saying that for two years now. Anyway Im certainly a > novice > who is improving with time and the gratefully accepted input of > this newsgroups members. > > At this stage I am reasonably happy with my design in Verilog > targeting > a xilinx xcs05xl. > > However, I find that there is one latch that I dont want to reset when > I am reseting everything else in the FPGA. This is because it holds > configuration > information for the FPGA and the external circuitry. If I dont set > this latch > to zero when my global clear line is low I get about 55 warnings at my > synthesis step. > > I get: > DPM : Warning NET ACB/ACB_NOT_TRIGGER_FOUND does not set/reset > /Int_read_trigger_address/Q_reg (FPGA -GSRMAP-13) > > about 55 times. > > Im not sure how the nets mentioned above relate to the latch that is > not being cleared. > > > What is the effect of my action. Are there lots of FFs not being reset > by my global clear signal? > How do I get rid of all these warnings? > Can I decide not to clear one latch and get all others to clear > without all the warnings? > > > Thanks in advance. > > Denis > ___________________ > http://www.CentronSolutions.com > From concept to production
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