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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 28125

Article: 28125
Subject: Re: Question about Xilinx pins at high-frequency
From: David Hawke <dhawke@xilinx.com>
Date: Thu, 21 Dec 2000 21:55:25 +0000
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------F59E606C382D8359F21F5837
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Andy Peters wrote:

> David Hawke wrote:
> >
> > "Pascal C." wrote:
> >
> > > A few things:
> > >
> > > 1.  for case 1, we did create a 32-bit registered OE and did PAR with the "-pr b" switch.  What tools do you use David? Personnally, I am using Foundation 3.2i.5 (note: I installed SP6 yesterday and MAP crashed pathethically even when started by the GUI!) with FPGA Express 3.4.3.  Is it possible that FPGA Express made it impossible for the PAR to recognize the OEs and place them properly (I did prevent it from merging the logic)?
> > >
> >
> > I forgot to mention, the other reason that it may not do this, is if you have the logic sense the wrong way round in the code....(therefore requiring a LUT before the Tri) - Can't remember if it is active high or low to HighZ...Think it is high!
>
> David,
>
> According to the Virtex 23 May 2000 datasheet, "The output buffer and
> all of the IOB control signals have independent polarity controls." In
> fact, a quick peek via FPGA editor shows a four-input mux for the
> tristate enable.  This means that you should be able to write the output
> enable as either active high or active low, and the synthesis tool
> should do the right thing.

I stand corrected. I was just being lazy! It is probably down to the synthesis tool and its ability to target the architecture. I have had no problems with Leonardo on this...

Merry Xmas,

Dave

>
>
> > Best thing to do it check the schematic viewer in Synopsys and checking whether there is a LUT in the way....If there is correct the code, and this should work...
>
> Ah, there's the rub.  At least for FPGA Express v3.4 and the XC4KXLA
> family, there's a bug: FPGA Express doesn't know about the
> polarity-select mux, and if you write your output enable code active
> high, an inverter in a CLB is put before the IOB's output enable
> control.
>
> -- a
> ----------------------------
> Andy Peters
> Sr. Electrical Engineer
> National Optical Astronomy Observatory
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters (at) n o a o [dot] e d u
>
> "It is better to be silent and thought a fool,
>  than to send an e-mail to the entire company
>  and remove all doubt."

--------------F59E606C382D8359F21F5837
Content-Type: text/x-vcard; charset=us-ascii;
 name="dhawke.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Hawke
Content-Disposition: attachment;
 filename="dhawke.vcf"

begin:vcard 
n:Hawke;David Hawke
tel;cell:(+44) 778 875 5002
tel;work:(+44) 870 7350 517
x-mozilla-html:TRUE
org:<br><img src="http://www.xilinx.com/images/smvirtex.gif" alt="Xilinx">
version:2.1
email;internet:dhawke@xilinx.com
title:XILINX   Field Applications Engineer
adr;quoted-printable:;;Xilinx Northern Europe=0D=0ABenchmark House;203 Brooklands road;Weybridge;;
x-mozilla-cpt:;2672
fn:David Hawke
end:vcard

--------------F59E606C382D8359F21F5837--


Article: 28126
Subject: Re: really fast counter in SpartanXL?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 22 Dec 2000 11:22:14 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Hal Murray wrote:
> 
<snip>
> Come to think of it:
> Why limit yourself to just two edegs? You can create a bunch of increasingly
> longer clock delays with perhaps 100 ps granularity, and use all of them.

 Certainly easy to implement in a FPGA, but has some things to watch in
the
details.
 A number of cells would be chained, so as to ensure the delay was
always > 1 CLK
period, and a (frequent) calibrate phase would be needed, as this delay
line will
be Vcc and Temp dependant.
 The MSB info is captured by a GATE / Enable process, whilst the LSB
(Delay line fraction)
would have to be register captured, from the delay line.
 This could cause some interesting/nasty hand-over aperture problems, as
ideally the
capture paths should have the same timing models.

 As in reciprocal counters, you need to do this twice, to find the clock
fraction
overlap on both leading and trailing PULSE edges.

 If the PULSE width is long, and precision is important, it could pay to
do a 
clock/Delay calibrate on both edges, so you store 4 numbers for the
fractional
calc : LeadDelay, Lead100%, TrailDelay, Trail100%

 Any ideas on the ultimate resolution you could achieve ?

-jg

Article: 28127
Subject: "lo profile" PLCC sockets
From: htytus@shell1.iglou.com (Hul Tytus)
Date: 21 Dec 2000 18:47:00 -0500
Links: << >>  << T >>  << A >>
comp.arch.fpga
"lo profile" PLCC sockets

Anyone know of a "lo profile" 44 pin PLCC thru-hole socket. A .250 in. 
(6.3mm) height rather than the typical .320 in. (8.1mm) is needed. The 
board on this application fits nearly flush against a panel and .320 
inches is too high.

Hul			htytus@iglou.com

Article: 28128
Subject: Re: 3V -> 5V clock signal level conversion
From: Robert <romapa@earthlink.net>
Date: Fri, 22 Dec 2000 01:35:16 GMT
Links: << >>  << T >>  << A >>


Nial Stewart wrote:

> Ray Andraka wrote:
> >
> > WOrks as long as 1) you can tolerate the ringing that inevitably occurs when the
> > driver shuts off,
>
> Ray,
>
> I clearly saw this effect on a 'scope when experimenting with
> different configurations for driving the op. As you might expect
> it gets worse as the DRIVE attribute is increased.
>
> It's actually very hard to properly terminate the track whilst
> pulling the line high as hard as possible.
>
> Nial.

When the buffer turns off, you are inducing a negative current step of -I traveling
down the line. Here I is the current still being delivered by the buffer at the
instant of turn-off. The net result is a voltage of magnitude -I*Zo superimposed upon
the line voltage already established and traveling to the destination. This tells you
that until I has decayed to negligible levels, you have accomplished nothing. The
timing will be a function of your termination RC time constant and the travel time
down the line.

The simplest fix here would be to use one or two diodes, or even a zener, to lower the
Vcc of the receiver Schmitt trigger so that the worst case Vin,h threshold can be met
by the Xilinx Voh output level.  This will certainly be the case at Vcc=3.0V so you
have lots of room to work with. You terminate the line in a series RC in shunt with
the line with R=Z0 and C=Trise/(2.2*R) where Trise is the fastest expected rise time
from the Xilinx under this loading. This will yield a reasonable value  of C that
produces negligible reflection. Having done this, you can use the Schmitt to directly
drive any TTL compatible load under light loading. It pulls right up to its rails at
100uA. The outputs are not 5V tolerant but there should be no problem with driving an
ACT/HCT type of CMOS input with a leakage pulldown of  33K ohm (100uA limit).

In summary then, use the NC7SZ14 single Schmitt trigger from the UHS (CMOS) line
running off 3.0V, for a maximum Vin,h threshold of 2.2V, to receive the clock  line.
This can drive the NC7ST04 (TTL Input and input leakage ~0.1uA) single inverter
running off 5V. Use precautionary resistive pulldown at output of Schmitt not to
exceed 100uA at Voh=3V.


Article: 28129
Subject: Synplicity and multiple input IOB flops...how to specify which one goes in the IOB?
From: "Austin Franklin" <austin@darkroo98m.com>
Date: 22 Dec 2000 03:58:43 GMT
Links: << >>  << T >>  << A >>
I have an input that has two flops for destinations.  I want one of them to
be in the IOB, and the other flop to use a CLB flop, and the tools do
that....but it's the wrong one that ends up in the IOB.

I have an <all> syn_useioff in the .sdc file, and I also use the map option
-pr b...that's how the FFs get in the IOBs in the first place...and I've
tried both specifying that specific register as syn_useioff in the .sdc
file, as well as the <all>, and I've tried giving the Verilog the /*
synthesis syn_useioff = 1 */ on that particular reg statement....nothing
has worked yet.

When I use look at the technology mapping from Synplicity, it doesn't show
what flops are IOB flops...when I bring up the .ncd file (pre PAR) in
Floorplanner...the FF for one of the two destination registers is already
in the IOB...but it's the wrong one...

So, how do I tell Synplicity (preferably) specifically which flop I want in
the IOB?


Article: 28130
Subject: PIN NOT FOUND
From: "Qian Zhang" <qianz@cae.wisc.edu>
Date: Thu, 21 Dec 2000 23:19:29 -0600
Links: << >>  << T >>  << A >>
Hi There I tried to synthesize my VHDL file, I used Xilinx Foundation li.3 I
have got *.enf, *.alr file I just tried to read schematic from those files
but it failed the error is C4061.G not found, Why have I had such error?
Thank you very much




Article: 28131
Subject: Implementation Fatal Error
From: "Qian Zhang" <qianz@cae.wisc.edu>
Date: Thu, 21 Dec 2000 23:19:55 -0600
Links: << >>  << T >>  << A >>
Hi

When I tried to implement my VHDL file by Xilinx Foundation li.3 THe report
says

Reading NGO file "F:/xilinx/projects/pwma/xproj/ver1/pwma.ngo" ...
FATAL_ERROR:Utilities:UtilPtrfilimp.c:140:1.5 - Pointer b29980 already
registered. Process will terminate. To resolve this error, please consult
the Answers Database and other online resources at http://support.xilinx.com

Can anyone give me any suggestion on it? Thanks a lot!

Qian







Article: 28132
Subject: Re: Synplicity and multiple input IOB flops...how to specify which one
From: Phil Hays <spampostmaster@sprynet.com>
Date: Thu, 21 Dec 2000 22:26:03 -0800
Links: << >>  << T >>  << A >>
Austin Franklin wrote:

> So, how do I tell Synplicity (preferably) specifically which flop I want in
> the IOB?

Put an area constraint (or a fixed constraint) on the other FF, the one that you
don't want in the IOB.  


-- 
Phil Hays

Article: 28133
Subject: Re: testbench generation tool
From: murray@pa.dec.com (Hal Murray)
Date: 22 Dec 2000 08:21:19 GMT
Links: << >>  << T >>  << A >>

>  I'm sorry for issuing a kind of advertisement to this groupe, but let us
> intruduce our new product.

Why are you apologizing for an announcement that was appropriate
to this group?

I like things like that.  I won't like them if there are 999 similar
tools but we aren't at that stage yet.

Note that it was a reasonable announcement, not a pile of marketing
crap.

If you have to apologize in advance, maybe you shouldn't post it.

[Spam is one of my hot buttons these days.  I just got hit by
another headhunter.]

-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 28134
Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ?
From: murray@pa.dec.com (Hal Murray)
Date: 22 Dec 2000 08:34:14 GMT
Links: << >>  << T >>  << A >>

> I just had a look at the online docs, and it's pretty much all covered
> in the first few pages of:
> 
> Synthesis and Simulation Design Guide
>  Chapter 4: Designing FPGAs with HDL
>   Using Dedicated Global Set/Reset Resource

Thanks.  Interesting that it doesn't say anything like that
in the data sheet.

-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 28135
Subject: Re: XC18V02 programming with xsvf file
From: Etienne Racine <etienne@cae.ca>
Date: Fri, 22 Dec 2000 08:08:46 -0500
Links: << >>  << T >>  << A >>
Bonjour Alex,

alexboyer@my-deja.com wrote:

> I used the algorithm in the xapp058 from Xilinx to load a serial
> eeprom XC18V02 with a xsvf file and it is not working.

Where did you take the original SVF (not the compressed XSVF) file? If it
was produced by a relatively recent version of JTAGprogrammer, the SVF
should be OK. If you don't have the latest one, the WebPack version can be
downloaded from the Xilinx website.

You just need to compress the SVF into XSVF (source code is given in
XAPP058) and execute it at a proper speed. Where (on what SVF line) and
what is the error?

In some cases, people do not take into account the TCK frequency they use.
In the SVF file, there are some "RUNTEST nnn TCK" statements; when the nnn
value is low, it can be assumed they mean *real* idle cycles spent in RTI.
However, there's also a convention that each cycle is a microsecond (1MHz
TCK), thus if you see a large value (such as RUNTEST 100000 TCK), this
means to spend 100ms idle in RTI.

So, if you use a different TCK frequency, you may actually spend less/more
time idling than what is required, and thus proper behavior of the device
cannot be garanteed. For example, I believe an XC18V512 needs about 100ms
(from the SVF file) to complete a "erase" operation. Using a higher TCK
freq means the device will not be given enough time to erase, so that might
explain why errors are produced.

Étienne.


Article: 28136
Subject: driving color VGA from FPGA ??
From: sja@world.std.com (Stuart J Adams)
Date: Fri, 22 Dec 2000 13:58:34 GMT
Links: << >>  << T >>  << A >>
 Anyone know of a nice solution for
 driving a color VGA display with a
 FPGA based video controller ??

 We want to add VGA output to a product
 and we happend to have lots of space
 left in an FPGA on the board. 

 The digital logic is not a problem,
 the issue is finding a suitable low-cost 
 RAMDAC. Since RAMDACs are no longer used in the
 mainstream PC industry many are on EOL
 status and are more expensive than a
 standalone VGA controller chip.

-- Stuart

Article: 28137
Subject: Re: driving color VGA from FPGA ??
From: acher@in.tum.de (Georg Acher)
Date: 22 Dec 2000 14:20:03 GMT
Links: << >>  << T >>  << A >>
In article <G5z2tM.BKt@world.std.com>,
 sja@world.std.com (Stuart J Adams) writes:
|>  Anyone know of a nice solution for
|>  driving a color VGA display with a
|>  FPGA based video controller ??
|> 
|>  We want to add VGA output to a product
|>  and we happend to have lots of space
|>  left in an FPGA on the board. 
|> 
|>  The digital logic is not a problem,
|>  the issue is finding a suitable low-cost 
|>  RAMDAC. Since RAMDACs are no longer used in the
|>  mainstream PC industry many are on EOL
|>  status and are more expensive than a
|>  standalone VGA controller chip.

If you are not planning to add a true colour display, you can use simple R/2R
networks as DACs (maybe restricted to 4 or 6 bit resolution). If you have 
plenty of gates left, the RAM should also pose no problem inside the FPGA ;-)

-- 
         Georg Acher, acher@in.tum.de         
         http://www.in.tum.de/~acher/
          "Oh no, not again !" The bowl of petunias          

Article: 28138
Subject: Re: driving color VGA from FPGA ??
From: Dave Vanden Bout <devb@xess.com>
Date: Fri, 22 Dec 2000 09:29:02 -0500
Links: << >>  << T >>  << A >>


Stuart J Adams wrote:

>  Anyone know of a nice solution for
>  driving a color VGA display with a
>  FPGA based video controller ??
>
>  We want to add VGA output to a product
>  and we happend to have lots of space
>  left in an FPGA on the board.

We have a simple circuit that drives a VGA display from an FPGA.  The
documentation on the circuit is at http://www.xess.com/appnotes/vga.pdf,
and the design files are at http://www.xess.com/projects/vga.zip.


--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||



Article: 28139
Subject: Re: Question about Xilinx pins at high-frequency
From: sulimma@my-deja.com
Date: Fri, 22 Dec 2000 18:12:31 GMT
Links: << >>  << T >>  << A >>
In article <ee6f135.10@WebX.sUN8CHnE>,
  "Pascal C." <> wrote:
> The pins on which I am trying to reduce the drive are LVTTL.  I've
> constrained them to a Clock to out of 6 ns, to allow some setup time
> (the clock is 131M, so clock period is about 7.8ns).  Under 12 mA, it
> tells me it can't possibly meet a clock to out of 6 ns.  And fails.

Your load is 30pF less than the standard load, this gives you the
following adjustments relativ to 12mA, 35pF:
(Table 15 of the Databook)
fast:
12mA => -30x0.44        = -1.32 ns
8mA  => -30x0.079 + 1   = -1.37 ns
6mA  => -30x0.13  + 3.1 = -0.8  ns
4mA  => -30x0.2   + 5.3 = -0.7  ns
2mA  => -30x0.41  +13.1 = +0.8  ns

This means, 8mA is actually faster than 12mA in your case.
You can not use 2mA drivers, and all the other variants differ by only
500ps.
If you relax your timing constraints by 700ps you can use any driver
you want (except 2mA). If you relax by 1.3ns you can use 8mA drivers
and still meet your setup time.
CU,
	Kolja


Sent via Deja.com
http://www.deja.com/

Article: 28140
Subject: Re: Synplicity and multiple input IOB flops...how to specify which one
From: Frederic RIVOALLON <frederic@xilinx.com>
Date: Fri, 22 Dec 2000 11:17:54 -0800
Links: << >>  << T >>  << A >>

Austin,

  You could use the xc_props attribute from Synplify to tag the flops with the
appropriate Xilinx attribute IOB = (TRUE|FALSE).
  The following example should do what you are asking for (note that I  had to
use the syn_preserve attribute so that all the flops don't get merged):

module flop_crtl (clk, src, dest1, dest2);
   input clk;
   input src;
   output dest1;
   output [7:0] dest2;

   reg dest1         /* synthesis syn_preserve = 1
        xc_props = "IOB=TRUE" */;
   reg [7:0] dest2   /* synthesis syn_preserve = 1
        xc_props = "IOB=FALSE" */;

   always @(posedge clk)
     dest1 <= src ;

   always @(posedge clk)
     dest2 <= {8{src}} ;

endmodule // flop_crtl

Frédéric


Austin Franklin wrote:

> I have an input that has two flops for destinations.  I want one of them to
> be in the IOB, and the other flop to use a CLB flop, and the tools do
> that....but it's the wrong one that ends up in the IOB.
>
> I have an <all> syn_useioff in the .sdc file, and I also use the map option
> -pr b...that's how the FFs get in the IOBs in the first place...and I've
> tried both specifying that specific register as syn_useioff in the .sdc
> file, as well as the <all>, and I've tried giving the Verilog the /*
> synthesis syn_useioff = 1 */ on that particular reg statement....nothing
> has worked yet.
>
> When I use look at the technology mapping from Synplicity, it doesn't show
> what flops are IOB flops...when I bring up the .ncd file (pre PAR) in
> Floorplanner...the FF for one of the two destination registers is already
> in the IOB...but it's the wrong one...
>
> So, how do I tell Synplicity (preferably) specifically which flop I want in
> the IOB?


Article: 28141
Subject: Re: really fast counter in SpartanXL?
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 22 Dec 2000 20:37:23 +0100
Links: << >>  << T >>  << A >>
Jim Granville <jim.granville@designtools.co.nz> writes:

> Peter Alfke wrote:
> > 
> > Hal Murray wrote:
> > 
> <snip>
> > Come to think of it:
> > Why limit yourself to just two edegs? You can create a bunch of increasingly
> > longer clock delays with perhaps 100 ps granularity, and use all of them.
> 
>  Certainly easy to implement in a FPGA, but has some things to watch in
> the
> details.
>  A number of cells would be chained, so as to ensure the delay was
> always > 1 CLK
> period, and a (frequent) calibrate phase would be needed, as this delay
> line will
> be Vcc and Temp dependant.

About calibration. Couldn't you design a self calibratingsystem? I'm
not sure what you are after here, so my mind might wander aimlessly.

Having a chain with 100 ps granularity and making it so long that the
fastest die under the fastest condition can't fill it in one CLK
period.  Then just keep track on how many delay elements get filled in
one CLK period.

Say that you have 1 ns granularity. There's a 10 to 1 diff
fastest/slowest, then you need 100 delay steps for fastest (and 10 for
slowest). If you inject a signal, you can then measure with an clock
how many delay elements were filled. Say you get 53. When you do the measurement of the fraction of signal, you get 32. Divide, and you have your fraction.

Or maybe I didn't understand the question?

Homann, not speaking for my employer or Xilinx.
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 28142
Subject: Re: Virtex and metastability
From: bob elkind <eteam@aracnet.com>
Date: Fri, 22 Dec 2000 11:48:36 -0800
Links: << >>  << T >>  << A >>
Can't let this one nit pass without comment...

The fact that the input buffer has lots of gain *is* important.

The fact that the input buffer has hysteresis (little or lots)
is *completely inconsequential* in the context of discussing
metastability.  Don't think for a second that hysteresis provides
any relief from determining your design's susceptibility to
metastable "events".

-- Bob Elkind, eteam@aracnet.com

Peter Alfke wrote:

> 
> Jonas Thor wrote:
> 
> 
>> Why is the "standard" estimation of MTBF a function of only td, f1 and
>> f2? (td = acceptable extra delay, f1 = clock and f2 = data frequency).
>> The rise time of the clocks and data signals must matter... or? At
>> least for external interfaces.
>> 
>> 
> 
> 
> I don't think so.
> 1. There is sufficient gain in the input buffer and even some hysteresis to
> make any input rise time look fast once it reaches the internal flip-flop.
> 
> 2. What matters is how often the master latch is caught in the process of
> changing and being "in the middle", exactly at the moment when the clock pulse
> stops it from being transparent. Then the issue is, how long it takes to fall
> to one side. The input rise time should be irrelevant. IMHO
> 
> Peter Alfke


Article: 28143
Subject: Re: driving color VGA from FPGA ??
From: Arrigo Benedetti <arrigo@vision.caltech.edu>
Date: 22 Dec 2000 12:37:04 -0800
Links: << >>  << T >>  << A >>
IBM used to make some nice RAMDACs. I just checked out
www.chips.ibm.com and it seems that they are not making them anymore.
Another vendor is Analog Devices.

Good luck,

-Arrigo

Article: 28144
Subject: Re: Virtex and metastability
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sat, 23 Dec 2000 10:01:07 +1300
Links: << >>  << T >>  << A >>
bob elkind wrote:
> 
> Can't let this one nit pass without comment...
> 
> The fact that the input buffer has lots of gain *is* important.
> 
> The fact that the input buffer has hysteresis (little or lots)
> is *completely inconsequential* in the context of discussing
> metastability.  Don't think for a second that hysteresis provides
> any relief from determining your design's susceptibility to
> metastable "events".
> Peter Alfke wrote:
> > I don't think so.
> > 1. There is sufficient gain in the input buffer and even some hysteresis to
> > make any input rise time look fast once it reaches the internal flip-flop.

 Hysteresis cannot eliminate metastability, but it can avoid it
worsening
with slow clock edges - ie it makes the test bench values more
portable, and avoids transistion oscillations, which can throw the whole
data sheet out the window.

 - jg

Article: 28145
Subject: Re: Virtex and metastability
From: Ron Cline <Ron.Cline@xilinx.com>
Date: Fri, 22 Dec 2000 14:08:45 -0700
Links: << >>  << T >>  << A >>
In the interest of POE (Peace On Earth, for those who never saw Doctor
Strangelove) ... everybody's right.  Actual implementations of
hysteresis consequentially increases input gain because of the positive
feedback...  (The noise immunity also certainly helps the measurement.)

- RLC

Article: 28146
Subject: Re: Synplicity and multiple input IOB flops...how to specify which one goes in the IOB?
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 22 Dec 2000 22:11:26 +0100
Links: << >>  << T >>  << A >>
"Austin Franklin" <austin@darkroo98m.com> writes:

> I have an input that has two flops for destinations.  I want one of them to
> be in the IOB, and the other flop to use a CLB flop, and the tools do
> that....but it's the wrong one that ends up in the IOB.

* Watch out for setup and hold timing.
* You could use UCF to specify IOB TRUE, and turn it off in Synplify.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 28147
Subject: Question about programming xcv100
From: longwayhome@my-deja.com
Date: Sat, 23 Dec 2000 00:48:21 GMT
Links: << >>  << T >>  << A >>
Hi
I bought an xsv100 board from Xess, which has a Xilinx xcv100 chip on
it. With the board came a utility which can send compiled bitstreams to
the chip. I'd like to manually generate the bitstreams though, rather
than compile them from a vhdl spec though, as my intention is to
program it using evolutionary algorithms and I think this would be
easier and faster than actually generating vhdl and compiling that then
sending that to the chip.

Does anyone know where I can find a spec which would show exactly how
the bitstreams are interpreted by xcv100 ? I've already had an
unsuccessfull look at the Xilinx site (but i've had problems finding
what i want there before...)

I'm a complete beginner at this, all advice greatfully accepted.

Thanks

David


Sent via Deja.com
http://www.deja.com/

Article: 28148
Subject: Re: "lo profile" PLCC sockets
From: nishioka@my-deja.com
Date: Sat, 23 Dec 2000 01:50:26 GMT
Links: << >>  << T >>  << A >>
In article <3a429674$1_3@news.iglou.com>,
  htytus@shell1.iglou.com (Hul Tytus) wrote:
> comp.arch.fpga
> "lo profile" PLCC sockets
>
> Anyone know of a "lo profile" 44 pin PLCC thru-hole socket. A .250 in.
> (6.3mm) height rather than the typical .320 in. (8.1mm) is needed. The
> board on this application fits nearly flush against a panel and .320
> inches is too high.
>
> Hul			htytus@iglou.com

I have never seen such a socket.

Does it have to be a socket?

Or can you use a PLCC to PGA adapter from Aries
Electronics.  http://www.arieselec.com/
They have an adapter that is .082 high, so with a .180 high PLCC, the
total would be .262 inches.

Alan Nishioka
alann@accom.com


Sent via Deja.com
http://www.deja.com/

Article: 28149
Subject: VGA compatible design for a Xilinx FPGA needed.
From: "Dan" <daniel.deconinck@sympatico.ca>
Date: Sat, 23 Dec 2000 04:12:01 GMT
Links: << >>  << T >>  << A >>
Hello,

The previous post wants to drive a VGA monitor.(Just generate HS=30KHZ and
VS=60 etc..)  This is not related to making a VGA compatible graphics board.
This requires cloning the BASIC/STANDARD/DEFAULT VGA registers so any WinTel
or DOS motherboard will boot and use it successfully.

I need to use a Xilinx FPGA to make a VGA compatible graphics card.

If not available then how much work is this ?


Sincerely
Daniel DeConinck
High Res Technologies, Inc.







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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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