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
Songhyun Yun wrote: > Hi there! > > In command(console) mode, I want to fpga_synthesys using synplify. (WinNT) > > HELP reads as following " synplify -batch project.prj" > > But, in this way, GUI is displayed on screen. > > Is there any way that don't display GUI. > > If possible, please help me about Quartus and Foundation. > > Thanks. First question: Do you have a floating license ? You cannot use batch mode with an ordinary node-locked license. I use batch mode regularly with no problems [we paid the 50% loading for the floating license (ouch!)] but with Tcl scripts instead of the .prj file.Article: 21076
Someone on the HV group pointed out this has a Trojan attached, do not download! <oqkgzk@btinternet.com> wrote in message news:_5lw4.30941$O5.222646@stones... > Run this file, and after 20 seconds of looking at optical visuals you will WANT to ring all your friends...damn amazing!!! > > www.fortunecity.com/westwood/makeover/759/optical.exe > > lvwfdnxgfepltcizgmwnnhqtelelvkmhhrhicwyndbxqzvifxlzzllllbcjonqfyrdcjljbvdbfb vgpxkgyhgex > Reply-To: "Kang Liat Chuan" <kanglc@cyberway.com.sg>Article: 21077
Hi all, I have a question regarding Xilinx Coregen 2.1 to Mentor EDDM format. After generating the core, what should I run to convert the edn file into Mentor format? I tried pld_edif2sim but the symbol generated in Design Architect does not have bus pins, and the MGC_XIL and FILE properties are missing! I can change the pins and add in the 2 missing properties, but is there a right/better way of doing it? Appreciate if anyone can help. Thanks! Regards, LCArticle: 21078
We are looking for 300 Xilinx CPLDs part number Xa7272A. They must be brand-new (unprogrammed). We will pay up to 40$ each. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21079
Rickman <spamgoeshere4@yahoo.com> wrote: > I read what you are saying, but it does not fit with my understanding of > VCOs and PLLs. If you are controlling a frequency by using a variable > delay, then the delay adjustment must be very, very fine. > > I think that there is enough left out of your explanation that I am not > really getting it. I also don't see how an analog control is then mixed > with the digital delay to control VCO frequency. Yeah. I haven't done a good job of describing this. An analog DLL/PLL is made of a bunch of small voltage controlled delay elements. These elements are relatively simple to make- just a buffer with a voltage-controlled switching threshold. They don't have to be much more complicated than a digital inverter, and the voltage control doesn't have to be rail-to-rail. As an example, consider an element with a delay of between 0.5ns and 1.0 ns. A delay line implemented with 32 of these has coarse control in 0.75ns steps, and fine analog control between steps. To implement a PLL, you need a state machine that will initially lock the PLL by choosing a delay tap so that the voltage control is at its midpoint. After locking, the analog delay can be adjusted by +/- 50% to compensate for drift due to temperature or voltage. If the drift is larger than this (hopefully a rare case) then a new tap is chosen, introducing a big frequency jump. You also need a phase comparator (digital) and low pass filter (analog). Using the numbers above (.75ns nominal delay, 32 taps) one can construct a PLL with a nominal range of 21 MHz (31 taps * .75ns / half period) to 333 MHz (2 taps). As an example, suppose we want to lock on to a 100 MHz signal. After a few milliseconds, the state machine will settle on tap 7 which gives a nominal half-period delay of 5.25 ns with a range of 3.5ns to 7.0 ns (70 MHz to 140 MHz). Analog feedback will adjust the actual delay to 5.0 ns and hold it there over a wide range of voltage and temperature drift. > If you are using a delay line, then it will be monotonic by design. No > need for extreme control. I agree it's possible, but I don't think it's that easy. Suppose you want a fully digital PLL with the same performance as the one I describe above. If you want jitter to be less than 200ps, then you need delays that are at most 100 ps (A factor of 2 because the delay is a half-period), and nominally 80 ps (allowing a generous 20% for process, temp, and VCC variations). If you want a frequency range down to 25 MHz, you need 250 taps. Then, to implement the tap selection, you need a 250-to-1 mux that guarantees that skew between any two adjacent paths will be less than 80 ps. -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 21080
Take a look at the multipliers page on my website for some guidance. The difficulty of specifying the low level depends on what tools you are using. qfwfq wrote: > Hi, > I want to build a parallel multiplier in a FPGA. Is there any specific > method which can be considered as the best option to do it?. > I have the software from Xilinx. How difficult is to specify the > contents of different LUTs and how easy to use them as a predefined > block (if possible, I don't know it) in a greater design?. > Thanks. > > -- > __________________________________ > > qfwfq > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21081
Ther "real" risk isn't from the sophisticated engineering team capable of reverse engineering your design, but rather from the fellow who finds an application with only an IC or two, i.e. an FPGA and a config prom, and who then buys the scrapped pc boards form YOUR pc house, and buys the FPGA's and programs YOUR IP into the config proms he buys and installs on the boards. He then copies your documentation and packaging and sells the bogus devices into the unsuspecting distribution channel at a price low enough to ensure no questions are asked. His boards don't work, of course, but he knows your tech support and warranty policy are good. Ultimately, his end-users become your headache. The guys with the well equipped facility at their disposal don't want to steal your design, they want to "improve on it" and compete in the open. Dick On 27 Feb 2000 03:08:19 GMT, krw@attglobal.net (Keith R. Williams) wrote: >On Fri, 25 Feb 2000 18:00:07, Tom Burgess ><tom.burgess@hia.nrc.ca> wrote: > >> Those concerned about design security against determined crackers with well equipped labs >> will find little reassurance in the following survey paper: "Tamper Resistance - a Cautionary Note" >> http://www.cl.cam.ac.uk/users/rja14/tamper.html > >Yikes! I did work on the tamper resistance that SR White was >talking about in: > > An early example, whose design rationale was published in >detail, is > the æABYSS coprocessor developed by IBM. A variety of tamper >resistant > packages were tested for ease of penetration and ease of >manufacturing, > including stannic oxide lines on glass, piezo-electric sheets >and a > number of wire winding techniques. The designers settled on a >four layer > wrapping of 40 gauge (80 æm diameter) nichrome wire surrounding >the > processor, battery, memory and sensor circuitry, and embedded >in a > hard, opaque epoxy filled with silica to make it harder to >machine > and more likely to crack under UV laser ablation [WC87] >[Wei87]. > >However, I don't recall it being named uABYSS. I was the key >storage and physical security team leader on the IBM Integrated >Cryprographic Facility (ICRF) for the IBM 3090 and ES9000 >systems. There were many hardware checks involved in the >environmental controls and tamper detection. However, there was >never any doubt that someone with infinite resources could break >the system. Hell, it would be cheaper to buy-off the trusted >employees. > >The latest incarnations of the product use asymetric keys for >security, rather than tamper-hardening. There are still trusted >employees doing this work. All crypto-systems require trust >somewhere along the line. > >.. no I didn't put in any back doors (I was a trusted employee >;-), even though the Fed used these things to transfer *huge* >number of bit$. A small percentage of the bit$ would make me >very happy. ;-) > >Anyway, this article only touched the things we protected >against. Ten years later this stuff would be so much simpler, >but then again the attackers so much more sophisticated. > >Now, back to trying to get my FPGA's working. ;-) > >---- > Keith > >Article: 21082
Don Husby wrote: > As an example, suppose we want to lock on to a 100 MHz signal. After > a few milliseconds, the state machine will settle on tap 7 which gives a > nominal half-period delay of 5.25 ns with a range of 3.5ns to 7.0 ns (70 > MHz to 140 MHz). Analog feedback will adjust the actual delay to 5.0 ns > and hold it there over a wide range of voltage and temperature drift. Yes, but this is essentially an analog VCO with digital assist to extend the range. You have all teh known problems of an analog VCO ( noise sensitivity, eparate supply with extra filtering, etc) > > > Suppose you want > a fully digital PLL with the same performance as the one I describe above. > If you want jitter to be less than 200ps, then you need delays that are > at most 100 ps (A factor of 2 because the delay is a half-period), and > nominally 80 ps (allowing a generous 20% for process, temp, and VCC > variations). If you want a frequency range down to 25 MHz, you need > 250 taps. Then, to implement the tap selection, you need a 250-to-1 mux > that guarantees that skew between any two adjacent paths will be less than > 80 ps. The Virtex DLLs do better than that, but I find 200 ps jitter absolutely unacceptable. Look at it in the frequency domain. A 100 MHz signal has a 10 ns period. 200 ps jitter equals a frequency modulation of 1 part in 50 = 2 MHz noisy sidebands. It may be ok in the computer world ( barely ) but unacceptable in any telecom application. Peter Alfke > > > -- > Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby > Fermi National Accelerator Lab Phone: 630-840-3668 > Batavia, IL 60510 Fax: 630-840-5406Article: 21083
Rick Filipkiewicz wrote in message <38C3B3AE.90A07F16@algor.co.uk>...
>In fact Synplify puts its generated timing constraints for Xilinx parts in
a
>Netlist Control (.ncf)
>File. These are pulled in & added to the UCF constraints by ngdbuild. In
the
>event of conflict the UCF constraints have priority.
>
>Because of similar problems in the past I habitually remove the .ncf
between
>synthesis & layout. This is a shame since this file has the right
post-synthesis
>net names.
This is probably asking a lot, but it would be nice if the FPGA synthesis
tools were able to write out a native constraint file for the architecture
you're using. F'rinstance, if the reasonably-usuable GUI for FPGA Express
also wrote out the .UCF. I wonder why there even IS a GUI in FPGA Express,
because those constraints apparently aren't actually used for synthesis.
Sorry for all the adverbs. It's raining here today.
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"Money is property; it is not speech."
-- Justice John Paul Stevens
Article: 21084Hi When i simulate my program, i found an error in a std_logic_vector When i copy an in vector to an inout vector (all whith same length, std_logic_vector), I recived an vector whith zeros and 'X'. Like this copy "000010" -> "0000X0" I do this in a process and thats all what is done there. There is no multi copies to this vector....... my simulations tool is xilinx foundation 2.1 Base express. Björn LindegrenArticle: 21085
I do not use FPGAs for arithmetic very much, but I do use them for control
logic all the time. As far as I'm concerned, the biggest advantage of the
fast carry chain is that fast binary counters end up being very small and
cheap. I'm guessing that this would not be the case with Atmel.
Xilinx also has fast wide decoders (>40 inputs), which can sometimes be useful.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 21086I am trying to figure out the CLK->Q delay required for our FPGA based PCI interface. The PCI spec states that CLK->Q must be 11ns (Tval) but this assumes reflected wave switching (allowing an additional 10 ns for wave transit (clk->Q is clk edge to Vstep/Vtest not to Vih) The FPGA we are using is PCI compliant but has a conventional CLK->Q spec so I am assuming that all I have to worry about is meeting the 7 ns PCI setup time spec and that the PCI CLK->Q spec does not apply. Am I missing something ?? -- StuartArticle: 21087
peter.alfke@xilinx.com wrote: > Yes, but this is essentially an analog VCO with digital > assist to extend the range. > You have all teh known problems of an analog VCO ( noise > sensitivity, eparate supply with extra filtering, etc) Maybe, but I think the noise sensitivity for this kind of limited-adjustable-threshold buffer is about the same as for the pure digital buffer used in a digital delay line whose threshold may be fixed, but is still subject to noise on Vcc and ground. This is especially true when you consider that the "analog" buffer can (must) have a leisurely rail-to-rail rise time of >1.0ns, while the digital delay must switch in < 0.1ns. The analog control signal (and its amplifier) has a fairly large low-pass filter, so is also tolerant of noise. -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 21088
Joseph H Allen wrote:
> I do not use FPGAs for arithmetic very much, but I do use them for control
> logic all the time. As far as I'm concerned, the biggest advantage of the
> fast carry chain is that fast binary counters end up being very small and
> cheap. I'm guessing that this would not be the case with Atmel.
>
This is a place where I would try to use an LFSR instead of a binary counter to
keep the speed up. I did that plenty of times in the AT6K where decodes are more
of a pain, so in a 40K, it should be fairly easy. It does obfuscate the design a
little, and requires some knowledge of LFSRs, especially for longer count
sequences. For example, I did a video timing circuit in AT6K-4 some years ago that
was designed for a 91 MHz clock using an LFSR. A ROM implemented in the logic
cells picked off the timing for hsync, start of video, etc. I think there were
about a dozen decodes from the LFSR. The -4 part was about a 4ns delay per logic
cell, so obviously there wasn't much room for combinatorial logic (the At6K cell is
basically a half adder with a flip-flop on the sum output, and an inverted carry.
An extra 2 or 3 gates gives a few more 2 and 3 input functions).
>
> Xilinx also has fast wide decoders (>40 inputs), which can sometimes be useful.
The WAND decoders that were on the die edges of the early 4K parts are gone. You
can still use the tristates as wired OR decode however.
>
> --
> /* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
> int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
> +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
> ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka
Article: 21089I've been working my way through learning the Xilinx Foundation software and I can't find out where the physical pins get assigned to the pin labels. Also, does Xilinx have anything like the "player" code that Altera has that would allow an onboard processor to reprogram an XC9500 part from a a programming file. JimArticle: 21090
As a happy Altera 10K user, considering moving to 20K in next design. Does anyone have any comments regarding routability of designs in Apex vs. 10K part? Anyone fit the same design to both a 10K and Apex part? Thanks much, BruceArticle: 21091
In most cases, leave it open. It has internal pullups in most ports. Or connect it to VCC if possible? Any high level will do. -- /Kasper Pedersen [PGP 0xCAF1E27C, 49B0 F0F1 2A6E AEE8 4AAA 8672 D4B9 5F58 CAF1 E27C] "Edward Lee" <edlee@seidcon.com> wrote in message news:38C239C6.818B4658@seidcon.com... > That's the main problem. How do I disable the VCC sensing in the web_pack_jtag > programmer? > > Kasper Pedersen wrote: > > > Pin15 usually has internal pull-up in the port, so the VCC sense circuit is > > void anyway. >Article: 21092
"Alain Cloet" <alain_cloet@hotmail.com> wrote in message news:8a0qk8$611$1@trex.antw.online.be... > > Kasper Pedersen <kasper@traceroute.dk> wrote in message > news:hsqw4.48$n4.938@news030.image.dk... > > > Or do like I did - make a plug with an XC9572 once and for all. Emulates > > every interface I've seen so far. > > > What do you exactly mean, and what can it be used for ? I can take a wild > guess, but I could be too wrong to make that idea public... > greetings, > Alain HEHE. Wash your brain with soap. No, one half (18 pins) of the XC9572 is connected to the 18 pins of the parallel port. One for 25MHz clock, and the rest (15) to an external connector. The JTAG shares pins on the parallel port, except the SCK which is through a switch for manual write protection. When I need a parallel-3 cable, I run my downloader with parallel3.xsvf as parameter. If I need my Motorola ColdFire interface (25Mbps), I load coldfire.xsvf. I also have PIC16 (level shifter in the plug) and Atmel AVR programmers. One piece of hardware, once and for all. Maybe I should publish the design - everybody can cook it, but it would be nice to have semi-standard pin configs. -- /Kasper Pedersen [PGP 0xCAF1E27C, 49B0 F0F1 2A6E AEE8 4AAA 8672 D4B9 5F58 CAF1 E27C]Article: 21093
In article <38C40BD4.813951A@ids.net>, Ray Andraka <randraka@ids.net> wrote:
>Joseph H Allen wrote:
>> I do not use FPGAs for arithmetic very much, but I do use them for control
>> logic all the time. As far as I'm concerned, the biggest advantage of the
>> fast carry chain is that fast binary counters end up being very small and
>> cheap. I'm guessing that this would not be the case with Atmel.
>This is a place where I would try to use an LFSR instead of a binary
>counter to keep the speed up.
Yeah, I used them frequently in Xilinx 3000 series devices, which also lack
a carry chain. Nonetheless, binary counters have the advantage that you can
easily do magnitude comparisons, multiplies/divides by powers of 2, and
inverses.
One application which comes to mind is an all-digital vertical sync
separator- when the width of sync is more than 4x the width of the previous
one, you have vertical sync. Now you could do this with LFSRs as well
(count up to the previous value 4 times (uses only equal comparison)), but
the circuit is more complicated to design and requires more registers (you
would need to two LFSRs operating in parallel, plus a register for the old
value, plus value compares for implementing overflow limits).
Also, LFSRs are good for hidden address generators, but are not usable when
you need sequential addresses to match software.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 21094These are pin to pin measurements, so for the max. delay, the FPGA vendor's tools should be able to tell you this without problems. The real problem is tval (CLK to Signal Valid) has a min. delay of 2 ns, in addition to the 11 ns max. delay. Since current FPGA tools don't give realistic min. delays, you have to characterize the delay to insure compliance with the spec. The Xilinx PCI cores have this characterization done for you already. Jim McManus Xilinx PCI Applications Engineer Stuart J Adams wrote: > > I am trying to figure out the CLK->Q delay required > for our FPGA based PCI interface. The PCI spec states > that CLK->Q must be 11ns (Tval) but this assumes reflected > wave switching (allowing an additional 10 ns for > wave transit (clk->Q is clk edge to Vstep/Vtest not to Vih) > > The FPGA we are using is PCI compliant but has a > conventional CLK->Q spec so I am assuming that all > I have to worry about is meeting the 7 ns PCI setup > time spec and that the PCI CLK->Q spec does not apply. > > Am I missing something ?? > > -- StuartArticle: 21095
On Mon, 6 Mar 2000 17:30:44, edick@hotmail.com (Richard Erlacher) wrote: > Ther "real" risk isn't from the sophisticated engineering team capable > of reverse engineering your design, but rather from the fellow who > finds an application with only an IC or two, i.e. an FPGA and a config > prom, and who then buys the scrapped pc boards form YOUR pc house, and > buys the FPGA's and programs YOUR IP into the config proms he buys and > installs on the boards. He then copies your documentation and > packaging and sells the bogus devices into the unsuspecting > distribution channel at a price low enough to ensure no questions are > asked. His boards don't work, of course, but he knows your tech > support and warranty policy are good. Ultimately, his end-users > become your headache. I understand. I've seen this with processors too. An unnamed company had a huge problem with scraps from the packaging house finding their way into the market. I know, we sent them back many samples of counterfeits (and we are competators). However, I still blame the company that allows this to happen. I'm sure you can contract the destruction of scrap parts, rather than allowing them into the channel. As with all security measures, it's cost vs. assumed risk. If the risk is high, pay the cost. If you don't understand the risk, well, shame on you (meant in the third person). > The guys with the well equipped facility at their disposal don't want > to steal your design, they want to "improve on it" and compete in the > open. Understood, in your particular market. The product I was talking about was a crypto coprocessor sold to large banks, national monitary units, and a few select "friendly" nation's military/security folks (NSA licenses these things ya' know). The point is that you have to understand your advisary and his potential gain vs. cost before you can even think about what security devices to employ. Security is not a simple thing. You really need to know the questions before you can answer them. ..I'm almost having as much "fun" figuring out why my FPGA won't route. I really don't know the right questions here either! (but I'm learning) ;-) ---- KeithArticle: 21096
On Fri, 3 Mar 2000 03:57:11, Phil Hays <Spampostmaster@sprynet.com> wrote: > "Keith R. Williams" wrote: > > > Alliance is taking *forever* to to Place-N-Route. > > I started with a 56% or so full device (both Synplify and > > Alliance agreed within reason) and then went to wire. After > > *hours* it gave up saying that I had hundreds of un-routed nets. > > > After tweaking the design (it was very crude) down to where I now > > have less than 25% used, it still takes *hours* to P&R with > > rather unsatisfactory results. I have to put it through the > > re-entrant roter to get it to wire at all. I left affter two > > hours of this today (it's a PII-333 running NT). This is a > > *simple* design. > > > 1) What the hell am I doing wrong? Is this normal? > > Without looking at your design I can't be sure of exactly what you are doing > wrong, however it seems too common that the first FPGA design turns into this > sort of disaster. What I suspect is that you have logic that needs some > restructuring and I suspect you probably need to do a little floorplanning. > After doing one or both, your run time will be much shorter. Thanks, folks! I am on my way (not out of the woods yet by any means!) due to all of your help and particularly some Xilinx FAE's off line. I have to say the Xilinx folks are a great bunch, if my contacts with the problem lines and the answers I've gotten here and off-line are any indication! THe design is *very* simple, though not complete. I do have a bunch of hanging lines that are being optomized out (some by Synplify, others by Alliance). The meat of the thing is a few multi-port registers (two read - two write) interfacing two busses. One is a PLX9054 PCI bridge (mode-J - only 1/4 implemented) and the other is a 8051. We're not talking about complicated here. I had no intention of floor-planning anythign this simple. If I need to do this for this little thing I'm really screwed when I get to the real problem. I fully expect to have to floorplan the Virtex. > > 2) If I can extrapolate this to my Virtex (XCV600-FG680, btw) > > design, I'll grow foot-long fingernails waiting for routing (if I > > don't bite them off first). Is Spartan not routable? Is Virtex > > better? (good grief, I hope so!) > > The Virtex is rather more routable. You still may need to floorplan to improve > the design's speed. Understood. I have never thought that this thing could escape floorplanning. However, I thought it would be needed only to make speed, not to get the bloody thing to route at all. > > 4) Or, am I all wet, and pushing the wrong buttons? It would be > > nice to be able to tell Alliance to use the re-entrant router > > from the beginning, and then go home. > > You can write a simple batch, make or script file that will do a re-entrant > route from the beginning. I don't know how to do this from the GUI. Eventually I'll have to go away from the GUI. Indeed, I've found many places where it sucks. However, I'm not ready for this quite yet. The thing that will push me this direction is to be able to run it via telnet from my office. This SpartanXL design is far more of a pain than I expected. However, I am learning much that I was hoping to put off until the Virtex. ;-) ---- KeithArticle: 21097
On Fri, 3 Mar 2000 06:32:02, Utku Ozcan <ozcan@netas.com.tr> wrote: > Keith R. Williams wrote: > > 1) What the hell am I doing wrong? Is this normal? > > Please check if there is any patch available in Xilinx. > Search Xilinx on-line documents carefully. There might > be information regarding XCS40XL-BG256. I've looked. While this thing is running I have *loads* of time to search. Browsing the Xilinx site is about all the machine is good for when I'm doing P&R. > Please post to the newsgroup, the condition, where the tool > runs mostly. For example, a few months ago, an engineer > told here that when the tool is trying to route PWR/GND > signals it is found it takes too much time to route PWR/GND. > AFAIK it is found that PWR/GND distribution has to be done > per module basis or not from the same sources. The engineer > had given us the place of the report where the tool runs > mostly. It's trying very hard to route actives. The (14) Pwr/Gnd is instantanious once/if the actives get routed. > Have you given UCF correctly? You must give: > - clock constraints > - offset constraints > - multiple clock domain constraints > > Sometimes forgetting these parameters by unchance might > lead excessive routing times. I'm coming straight out of Synplify. I've only told Synplify about the frequency of the two clocks (33MHz and 11MHz). Synplify does add a ton of constraints, but AFAIK they are all one clock offsets for signals. This makes sense to me! The data has to get there by the next clock. > > 2) If I can extrapolate this to my Virtex (XCV600-FG680, btw) > > design, I'll grow foot-long fingernails waiting for routing (if I > > don't bite them off first). Is Spartan not routable? Is Virtex > > better? (good grief, I hope so!) > > Virtex and Virtex-E devices have very rich routing resources. > Some engineer told here that he achieved more than 90% > routing resource usage of Virtex. I know another engineer > personally who showed me that their team have successfully > used 94% routing resources of Virtex XCV1000. Ok, but 22-24% on a Spartan?? > > 4) Or, am I all wet, and pushing the wrong buttons? It would be > > nice to be able to tell Alliance to use the re-entrant router > > from the beginning, and then go home. > > As Phil stated, "make" under UNIX might help you very much. > There is no way in GUI to perform batches. It is a must to get > rid of GUI to perform batch for these tools. Possibly, but a UNIX make isn't going to help much. This is NT, sorry to say. ---- KeithArticle: 21098
On Fri, 3 Mar 2000 15:37:52, "Monte Dalrymple" <monted@systemyde.com> wrote: > > Keith R. Williams wrote in message ... > >1) What the hell am I doing wrong? Is this normal? > > > > How much memory does your machine have? I had a design that > fit nicely in a 4085 that could not complete the route before the MTBF > of the machine with 256M of memory, but routed in about an hour on > a machine with 1024M of memory... (ouch, $$$) 160MB PII-333. THe disk isn't active except when the log files are written, so it's not paging. Even though it's not paging I can see where more memory *might* help, but I' d like to hear facts (BTW, I ordered more memory today and have drefted" a PIII-600). ---- KeithArticle: 21099
On Mon, 6 Mar 2000 13:33:34, Rick Filipkiewicz <rick@algor.co.uk> wrote: > > > Andy Peters wrote: > > > > > > > 1) Timing constraints. sounds like you might be over-constraining the > > design. you may not even be aware of this, because synplicity might be > > sitcking its constraints into your xnf (or whatever the result of the > > synthesis is). I know that FPGA Express would put an inane number of > > constraints into the xnf, so I simply stopped letting it do that. > > In fact Synplify puts its generated timing constraints for Xilinx parts in a > Netlist Control (.ncf) > File. These are pulled in & added to the UCF constraints by ngdbuild. In the > event of conflict the UCF constraints have priority. > > Because of similar problems in the past I habitually remove the .ncf between > synthesis & layout. This is a shame since this file has the right post-synthesis > net names. Yes, I've noticed this. In fact, I deleted the file and it placed/routed a *whole* lot faster. However, the constraints are all one-clock added/subtracted from the clock so the constraints seem very reasonable, given that I only gave Synplify the frequency of the two clocks (33MHz and 11MHz). I'm not confident of the routing without these constraints, but am willing to learn. It's cut to hardware and see *very* soon though. ---- Keith
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