Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

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

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





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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