1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr 2017

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

Custom Search

# Messages from 21075

Article: 21075
Subject: Re: To use synplify in command mode
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 06 Mar 2000 13:48:45 +0000
Links: << >>  << T >>  << A >>


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.
>
>
> Thanks.

First question: Do you have a floating license ? You cannot use batch mode with

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
Subject: Re: An optical allusion that will astound you, works on all spec pc's:) 9523
From: "Mark W." <marknews@ramseyelectronics.com>
Date: Mon, 6 Mar 2000 08:57:41 -0500
Links: << >>  << T >>  << A >>
Someone on the HV group pointed out this has a Trojan attached, do not

<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 Subject: From Xilinx Coregen 2.1 to Mentor EDDM From: "Kang Liat Chuan" <kanglc@cyberway.com.sg> Date: Mon, 6 Mar 2000 22:12:07 +0800 Links: << >> << T >> << A >> 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, LC  Article: 21078 Subject: 300 Xilinx Xa7272a wanted, we'll pay up to 45$ each
From: alexlamba@my-deja.com
Date: Mon, 06 Mar 2000 14:37:47 GMT
Links: << >>  << T >>  << A >>
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 Subject: Re: New name: DLLs, PLLs and videotape... From: husby@fnal.gov (Don Husby) Date: Mon, 06 Mar 2000 15:06:45 GMT Links: << >> << T >> << A >> 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-5406  Article: 21080 Subject: Re: about multipliers From: Ray Andraka <randraka@ids.net> Date: Mon, 06 Mar 2000 15:27:07 GMT Links: << >> << T >> << A >> 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/~randraka  Article: 21081 Subject: Re: Design security From: edick@hotmail.com (Richard Erlacher) Date: Mon, 06 Mar 2000 17:30:44 GMT Links: << >> << T >> << A >> 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 Subject: Re: New name: DLLs, PLLs and videotape... From: Peter Alfke <peter@xilinx.com> Date: Mon, 06 Mar 2000 09:32:43 -0800 Links: << >> << T >> << A >>  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-5406  Article: 21083 Subject: Re: SpartanXL route and place From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> Date: Mon, 6 Mar 2000 10:49:32 -0700 Links: << >> << T >> << A >> 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: 21084 Subject: Problem with vector copy From: "Björn Lindegren" <bjorn.lindegren@home.se> Date: Mon, 6 Mar 2000 18:53:49 +0100 Links: << >> << T >> << A >> Hi 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 Lindegren  Article: 21085 Subject: Re: Comment on Atmel AT40K ? From: jhallen@world.std.com (Joseph H Allen) Date: Mon, 6 Mar 2000 18:16:22 GMT Links: << >> << T >> << A >> 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: 21086 Subject: PCI reflected wave switching spec ??? From: sja@world.std.com (Stuart J Adams) Date: Mon, 6 Mar 2000 18:19:48 GMT Links: << >> << T >> << A >> 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 ?? -- Stuart  Article: 21087 Subject: Re: New name: DLLs, PLLs and videotape... From: husby@fnal.gov (Don Husby) Date: Mon, 06 Mar 2000 18:52:07 GMT Links: << >> << T >> << A >> 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-5406  Article: 21088 Subject: Re: Comment on Atmel AT40K ? From: Ray Andraka <randraka@ids.net> Date: Mon, 06 Mar 2000 19:49:45 GMT Links: << >> << T >> << A >>  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: 21089 Subject: Stupid Foundation question From: Jim Stewart <jstewart@jkmicro.com> Date: Mon, 06 Mar 2000 11:58:50 -0800 Links: << >> << T >> << A >> I'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. Jim  Article: 21090 Subject: Apex vs. 10K From: pirger@astrosun.tn.cornell.edu Date: Mon, 06 Mar 2000 16:00:17 -0500 Links: << >> << T >> << A >> 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, Bruce  Article: 21091 Subject: Re: JTAG Programmer & Windows 2000 From: "Kasper Pedersen" <kasper@traceroute.dk> Date: Mon, 6 Mar 2000 22:05:57 +0100 Links: << >> << T >> << A >> 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 Subject: Re: JTAG Programmer & Windows 2000 From: "Kasper Pedersen" <kasper@traceroute.dk> Date: Mon, 6 Mar 2000 22:22:00 +0100 Links: << >> << T >> << A >> "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
Subject: Re: Comment on Atmel AT40K ?
From: jhallen@world.std.com (Joseph H Allen)
Date: Mon, 6 Mar 2000 21:26:33 GMT
Links: << >>  << T >>  << A >>
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: 21094
Subject: Re: PCI reflected wave switching spec ???
From: Jim McManus <jim.mcmanus@xilinx.com>
Date: Mon, 06 Mar 2000 14:04:50 -0800
Links: << >>  << T >>  << A >>
These 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

Jim McManus
Xilinx PCI Applications Engineer

>
> 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 ??
>
> -- Stuart

Article: 21095
Subject: Re: Design security
From: krw@attglobal.net (Keith R. Williams)
Date: 7 Mar 2000 00:49:21 GMT
Links: << >>  << T >>  << A >>
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
> 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

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) ;-)

----
Keith


Article: 21096
Subject: Re: SpartanXL route and place
From: krw@attglobal.net (Keith R. Williams)
Date: 7 Mar 2000 01:02:54 GMT
Links: << >>  << T >>  << A >>
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.  ;-)

----
Keith

Article: 21097
Subject: Re: SpartanXL route and place
From: krw@attglobal.net (Keith R. Williams)
Date: 7 Mar 2000 01:10:39 GMT
Links: << >>  << T >>  << A >>
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

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.

----
Keith

Article: 21098
Subject: Re: SpartanXL route and place
From: krw@attglobal.net (Keith R. Williams)
Date: 7 Mar 2000 01:14:07 GMT
Links: << >>  << T >>  << A >>
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).

----
Keith


Article: 21099
Subject: Re: SpartanXL route and place
From: krw@attglobal.net (Keith R. Williams)
Date: 7 Mar 2000 01:31:57 GMT
Links: << >>  << T >>  << A >>
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