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 15200

Article: 15200
Subject: Re: Spartan, delaying a clock.
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 12 Mar 1999 11:39:14 -0800
Links: << >>  << T >>  << A >>
fpgar@my-dejanews.com wrote:

> Hi.
>
>  I need to introduce a 40-50 ns delay in the line clock of
> the fpga (the clock
> will be in the 5-8MHz range). how can i do it??
>
>  I thought in feeding back the clock in a new pin and
> delaying with a cap,
> but, i suppose this delay can be do with internal logic
> also.

Using internal logic or routing delays will give you
wide-ranging errors, perhaps 3-to-1, due to temperature
effects ( 0.25% per degree C ), voltage effects ( 10 to 15%
over the Vcc range ), and processing differences, (up to
50%).
Here is my suggestion:
The cleanest would be to take the opposite clock edge.
That's something you have external control over.
The alternative is an external RC. I suggest 330 Ohm in
series and 150 pF to ground. That swamps out the drive
impedance and the input capacitance.

Peter Alfke, Xilinx Applications

Article: 15201
Subject: Re: Spartan, delaying a clock.
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 12 Mar 1999 11:57:21 -0800
Links: << >>  << T >>  << A >>
fpgar@my-dejanews.com wrote:

> Hi.
>
>  I need to introduce a 40-50 ns delay in the line clock of
> the fpga (the clock
> will be in the 5-8MHz range). how can i do it??
>
>  I thought in feeding back the clock in a new pin and
> delaying with a cap,
> but, i suppose this delay can be do with internal logic
> also.
>  

Having endorsed the external low-pass RC filter as a delay
element, my bad conscience causes me to post this warning:
It introduces a slow-risetime clock, which can lead to
double-triggering if there is ground-bounce or other noise
in the system ( and where is this not!) So be very careful
how you use this clock. You could also increase the
hysteresis (Schmitt trigger action) on the delayed clock
input, but that costs you an additional output.
I much prefer the opposite-clock-edge approach.

Peter Alfke, Xilinx

Article: 15202
Subject: Re: Infidels Invited, Heathens Highly Welcome !
From: "Luis de Funes" <fuzzy8888@hotmail.com>
Date: Fri, 12 Mar 1999 22:23:11 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.

------=_NextPart_000_001B_01BE6CD6.EA043CE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Peter,
thank you for the message.
But it is a too late for the italian people :-(
Ciao

Luigi


------=_NextPart_000_001B_01BE6CD6.EA043CE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Dear Peter,<BR>thank =
you for the=20
message.<BR>But it is a too late for the italian people =
:-(</FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
size=3D2>Ciao</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Luigi</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
    <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_001B_01BE6CD6.EA043CE0--

Article: 15203
Subject: Re: Spartan, delaying a clock.
From: fpgar@my-dejanews.com
Date: Fri, 12 Mar 1999 22:25:17 GMT
Links: << >>  << T >>  << A >>
Thanks Peter

The specific problem is:

I need a write enable signal for a 100 ns RAM.
The clock of the system is 5-8 MHz, and i need write once per cycle.

If i use the opposite clock-edge i must change the RAM to 60ns access time.
This memory is controlled something like that

Wenable
 --+      +--+
           
   +------+  +---.....
->  <100n  <-

CLK
 --+    +----+
           
   +----+    +----.....



With a 8 Mhz clock i thougth generating it as Wenable = /CLOCK*Clockdelayed
so i assure the minimun access time.

Also I can delay the clock with external digital logic to avoid the slow rise
time, but i was looking for the easy and cheapest solution.

Thanks for your help

drp@lettera.net


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 15204
Subject: Re: Virtex LUT equation syntax in Xilinx EPIC 1.5?
From: Stephen Swearingen <sasweari@orbitworld.net>
Date: Fri, 12 Mar 1999 16:38:11 -0600
Links: << >>  << T >>  << A >>
This is what I've used

*   AND
+   OR
@   XOR
~   NOT/INVERT

hope this helps,
Stephen Swearingen
ICS Triplex


Alex Rast wrote:

> I am creating a low-level FPGA design using Xilinx EPIC. Great program, but
> nowhere can I find any documentation on the syntax for the LUT equations.
> Essentially, if you highlight a logic slice in a CLB, pick editblock, pick a
> LUT (by clicking on the check box market "LUT" on the logic element), then
> click attr (for attibutes), you get a dialog box with "LUT Equations". Great,
> that's just what I need, but a few syntax guesses all errored out. I called
> Xilinx tech support - they said they would find out (didn't know immediately
> over the phone) - and I have not heard back from them since. No phone, no
> voice mail, no e-mail. I also called up one of our local distribution reps -
> he again said he would try to find me the right person, but when I called him
> today, he hemmed and hawed, said he was having difficulty tracking down
> someone who could help, said he would try looking through old manuals, faxed
> me a sheet, and it did not help. So I'm still stopped. So, very simply put,
>
> What is the correct syntax for entering LUT equations for Virtex parts in the
> dialog box for that purpose in Xilinx EPIC 1.5?
>
> Any help would be MUCH appreciated.
>
> TIA,
>
> Alex Rast
> arast@inficom.com

Article: 15205
Subject: Re: Spartan, delaying a clock.
From: "Ken Coffman" <kcoffman@intermec.com>
Date: Fri, 12 Mar 1999 16:14:35 -0800
Links: << >>  << T >>  << A >>
What I suggest is a FPGA pin drives an AC (or anything reasonably fast as
long as it has a CMOS threshold) gate, which drives an RC network (say 100pF
and 560 ohm) which drives another AC gate, and drives back into the FPGA.
Play with the R to get the right delay (probably something smaller than 560
will be needed, but it depends on the sum of the delay through the FPGA
driver, the Tpd of the gates, and the delay through the input buffer).
I don't recommend using internal delays.
Your mileage may vary...
fpgar@my-dejanews.com wrote in message <7cbkvc$nvd$1@nnrp1.dejanews.com>...
>Hi.
>
> I need to introduce a 40-50 ns delay in the line clock of the fpga (the
clock
>will be in the 5-8MHz range). how can i do it??
>
> I thought in feeding back the clock in a new pin and delaying with a cap,
>but, i suppose this delay can be do with internal logic also.
>
>Thanks.
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


Article: 15206
Subject: Power Estimiation
From: Richard Guerin <guerin2@home.com>
Date: Sat, 13 Mar 1999 02:04:16 GMT
Links: << >>  << T >>  << A >>
Can anyone suggest a good post-route power estimation method/tool for
FPGA's ? (realize that this is highly dependent on frequency and
probability of switching events .... Pav=CL*VDD^2*f)
Article: 15207
Subject: Re: Power Estimiation
From: carlhermann.schlehaus@t-online.de (Carlhermann Schlehaus)
Date: Sat, 13 Mar 1999 04:47:10 +0100
Links: << >>  << T >>  << A >>
Hi,

ALTERA offers in their data book and as an application note (*.pdf) a
calculation sheet for power estimation.

Ciao, CS
Richard Guerin <guerin2@home.com> schrieb in Nachricht
36E9C804.13E88966@home.com...///
>Can anyone suggest a good post-route power estimation method/tool for
>FPGA's ? (realize that this is highly dependent on frequency and
>probability of switching events .... Pav=CL*VDD^2*f)


Article: 15208
Subject: Re: Actel FPGA
From: nospam_ees1ht@ee.surrey.ac.uk (Hans)
Date: 13 Mar 1999 10:02:07 GMT
Links: << >>  << T >>  << A >>

In my opinion Actel FPGA's are great if only they would increase the number of 
clock lines (announced for the SX64) family and would make a low pin-count 
small package version of the SX family (e.g. SOIC). Their free development 
tools are easy to use and the Actmap synthesiser produces in most cases much 
better result than the $$ tools. As far as I know (correct me if I am wrong) 
there is no low cost programmer available. We are currently in the final stages 
of implementing a high speed  EDAC controller in a SX16.

Hans.
 
In article <7c6od4$ebu$1@nnrp1.dejanews.com>, ggli@dictaphone.com says...
>
>I'm looking at using some Actel FPGA's . . . you know the anti-fuse variety. 
>It seems the ..SX16 family is quick and definitely inexpensive on a gate per
>gate basis vs. other vendors.  My question is, has anybody used these yet,
>and what general pros and cons do you see.  I'd still consider using an SRAM
>based part from say Altera (FLEX10K series) if needed.  Are there any
>penalties (besides OTP) that this architecture has?
>
>Any help would be great
>
>gene
>ggli@dictaphone.com
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Article: 15209
Subject: Re: Actel FPGA
From: nateg@pobox.com (Nate Goldshlag)
Date: Sat, 13 Mar 1999 10:02:16 -0500
Links: << >>  << T >>  << A >>
In article <7c6od4$ebu$1@nnrp1.dejanews.com>, ggli@dictaphone.com wrote:

> I'm looking at using some Actel FPGA's . . . you know the anti-fuse variety. 
> It seems the ..SX16 family is quick and definitely inexpensive on a gate per
> gate basis vs. other vendors.  My question is, has anybody used these yet,
> and what general pros and cons do you see.  I'd still consider using an SRAM
> based part from say Altera (FLEX10K series) if needed.  Are there any
> penalties (besides OTP) that this architecture has?
> 
> Any help would be great
> 
> gene
> ggli@dictaphone.com
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

We have just completed two Actel SX16 designs.  These parts are **very**
fast, although the design tools are not quite there yet.  Timing driven
place and route does not work yet.  We had problems routing both designs
to a chosen pinout.  R398 just failed completely.  We had to get an alpha
version of R199 to get the parts to route, and even then they are on the
verge of not routing.

Performance, though, is excellent.  One design runs at 90 MHz and the
other at 83 MHz worst case.  Clock pin to output is around 5 ns.

I submitted the design to an Altera FAE to put into a FLEX 10KA part and
the best he was able to do on the 90 MHz design was 68 MHz.

Nate

----------------------------------------------------
Nate Goldshlag      nateg@pobox.com
Arlington, MA       http://www.pobox.com/~nateg
Article: 15210
Subject: Re: Power Estimiation
From: "Matthew Morris" <mattm@no_spam.uswest.net>
Date: Sat, 13 Mar 1999 10:31:50 -0700
Links: << >>  << T >>  << A >>
In addition to the databook/app note they have a Excel spreadsheet which
implements the stuff in the app note..

Matthew

Carlhermann Schlehaus wrote in message <7cctda$qn5$1@news08.btx.dtag.de>...
>Hi,
>
>ALTERA offers in their data book and as an application note (*.pdf) a
>calculation sheet for power estimation.
>
>Ciao, CS
>Richard Guerin <guerin2@home.com> schrieb in Nachricht
>36E9C804.13E88966@home.com...///
>>Can anyone suggest a good post-route power estimation method/tool for
>>FPGA's ? (realize that this is highly dependent on frequency and
>>probability of switching events .... Pav=CL*VDD^2*f)
>
>


Article: 15211
Subject: Re: Infidels Invited, Heathens Highly Welcome !
From: msimon@tefbbs.com (M.Simon)
Date: Sat, 13 Mar 1999 17:55:09 GMT
Links: << >>  << T >>  << A >>

Could you post the seminar on the net for those of us who can't
include the seminar in our schedules?


Simon - http://www.tefbbs.com/spacetime/index.html
Article: 15212
Subject: Re: Actel FPGA
From: rk <stellare@erols.com.NOSPAM>
Date: Sun, 14 Mar 1999 07:45:35 -0500
Links: << >>  << T >>  << A >>
Nate Goldshlag wrote:

> In article <7c6od4$ebu$1@nnrp1.dejanews.com>, ggli@dictaphone.com wrote:
>
> > I'm looking at using some Actel FPGA's . . . you know the anti-fuse variety.
> > It seems the ..SX16 family is quick and definitely inexpensive on a gate per
> > gate basis vs. other vendors.  My question is, has anybody used these yet,
> > and what general pros and cons do you see.  I'd still consider using an SRAM
> > based part from say Altera (FLEX10K series) if needed.  Are there any
> > penalties (besides OTP) that this architecture has?
> >
> > Any help would be great
> >
> > gene
> > ggli@dictaphone.com
> >
> > -----------== Posted via Deja News, The Discussion Network ==----------
> > http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
>
> We have just completed two Actel SX16 designs.  These parts are **very**
> fast, although the design tools are not quite there yet.  Timing driven
> place and route does not work yet.  We had problems routing both designs
> to a chosen pinout.  R398 just failed completely.  We had to get an alpha
> version of R199 to get the parts to route, and even then they are on the
> verge of not routing.
>
> Performance, though, is excellent.  One design runs at 90 MHz and the
> other at 83 MHz worst case.  Clock pin to output is around 5 ns.
>
> I submitted the design to an Altera FAE to put into a FLEX 10KA part and
> the best he was able to do on the 90 MHz design was 68 MHz.
>
> Nate

hi,

i would suggest "unfixing" all of the i/o pins and then trying r3-1998 again, and
see how it does.  also, for comparison, you might want to try p&r the design in an
a1280a and an a14100a to see how the routability compares between the new device
and the older families, after removing the fixed i/o properties.  generally, my
designs and the designs i have seen others do haven't had routing problems -
except when the pins were fixed in advanced without consideration for the logic on
the chip.  also, in general, with a good i/o placement, a relatively high
percentage of internal logic modifications had no effect on routability.

rk


Article: 15213
Subject: Re: Actel FPGA
From: Richard Guerin <guerin2@home.com>
Date: Sun, 14 Mar 1999 17:07:20 GMT
Links: << >>  << T >>  << A >>
At my company, Actel anti-fused products are the preferred programmable
device, especially for the saftey-critical flight control applications
that we design (many of these designs simply can't tolerate the latency
associated with device configuration nor can they tolerate the small
probability of an anomalous event during during configuration ... such
as in the rare event of an in-flight system reset). 

In terms of performance and reliability (across Military temp ranges),
we've had pretty good experience with Actel (plastic) devices ...(
albiet I haven't worked with the SX16 family yet).  With their
fine-grained anti-fused based architecture, Actel devices (in my
opinion) represent some of the most ASIC-like FPGA's available today
(hope I don't piss off any QuickLogic people).

As far as tools go.... Actel is offering a free development suite (for a
limited time) that includes, VeriBest, Synplify-Lite, and Designer-Lite
R3-1998 (See: http://www.acteldesktop.com/). These tools are pretty
decent ....definitely get the job done for most applications (though
you'll have to pry my Model Tech & Exemplar dongles from my dead hand)

One nice feature, that the Actel devices offer, is the action probe
capability (See: http://www.actel.com/html/_____silicon_explorer.html). 
The ability to monitor internal signals (real time) during system debug
has proven invaluable and has saved numerous hours of debug time.

Hope that helps ....Good luck in your new design :-)

ggli@dictaphone.com wrote:
> 
> I'm looking at using some Actel FPGA's . . . you know the anti-fuse variety.
> It seems the ..SX16 family is quick and definitely inexpensive on a gate per
> gate basis vs. other vendors.  My question is, has anybody used these yet,
> and what general pros and cons do you see.  I'd still consider using an SRAM
> based part from say Altera (FLEX10K series) if needed.  Are there any
> penalties (besides OTP) that this architecture has?
> 
> Any help would be great
> 
> gene
> ggli@dictaphone.com
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
Article: 15214
Subject: FYI: XC4013EPQ240C and XCS30PQ240C bit stream identical....
From: "Austin Franklin" <austin@dark9room.com>
Date: 14 Mar 1999 19:22:14 GMT
Links: << >>  << T >>  << A >>
Hi,

We have a product that has been using an XC4013EPQ240C.  I built a new
board and populated it with an XCS30PQ240C, with NO changes to the bit
stream at all...and...it just worked.  I did two cuts on the PCB to isolate
pins 58 and 62.  That's it!  Big cost savings ;-)

Austin Franklin
austin@darkroom.com

Article: 15215
Subject: SDF
From: VAX
Date: 15 Mar 1999 05:21:43 GMT
Links: << >>  << T >>  << A >>
Hi, 

   I simulate a design by Vsystem4.4j, the result is correct with no SDF.
But when I apply SDF file to my design, each Components has a ERROR,

vsim -sdftyp d:\time_sim.sdf, then I select design Unit in Menu.
...

#ERROR: d:\time_sim.sdf(97):The design does not have an instance named'/c55'.

...

But I can find all the Components in both time_sim.sdf and time_sim.vhd.
I use Foundation Express v1.5.

   can anyone help me?


Tom

Article: 15216
Subject: Want to learn about FPGA.
From: (NO-SPAM)md7114@mclink.it (damiano)
Date: 15 Mar 1999 07:49:02 GMT
Links: << >>  << T >>  << A >>
Hi all,

I just ended my studies to become an electronic engineer and I'd like 
to start a few projects.
This is intended for learning purposes.
I heard that FPGA can be managed with a PC and a few hunred dollars, 
is it true?
What can I do using FPGA at the moment?


Damiano Rullo
Trezzano S/N
Milan, Italy
http://members.it.tripod.de/Damianoux/index.html
mailto: dmn@cheerful.com
mailto: damiano@mclink.it

Article: 15217
Subject: Re: SDF
From: Le mer Michel <michel.lemer@ago.fr>
Date: Mon, 15 Mar 1999 10:46:02 +0100
Links: << >>  << T >>  << A >>
VAX wrote:

> Hi,
>
>    I simulate a design by Vsystem4.4j, the result is correct with no SDF.
> But when I apply SDF file to my design, each Components has a ERROR,
>
> vsim -sdftyp d:\time_sim.sdf, then I select design Unit in Menu.
> ...
>
> #ERROR: d:\time_sim.sdf(97):The design does not have an instance named'/c55'.
>
> ...
>
> But I can find all the Components in both time_sim.sdf and time_sim.vhd.
> I use Foundation Express v1.5.
>
>    can anyone help me?
>
> Tom

I did it like that :
vsim testop -sdfmax I1=/home/../time_sim.sdf

(time_sim.sdf applied to the module I1 of the top level testop,
I1 is the vhdl file produced by Foundation, other modules are stimuli).

Good luck.

Michel Le Mer
Gerpi sa (Xilinx Xpert)
3, rue du Bosphore
Alma city
35000 Rennes
France
(02 99 51 17 18)
http://www.xilinx.com/company/consultants/partdatabase/europedatabase/gerpi.htm


Article: 15218
Subject: Clock multiplier
From: Sven Svensson <sveng@ce.chalmers.se>
Date: Mon, 15 Mar 1999 10:59:08 +0100
Links: << >>  << T >>  << A >>
Does anyone have a suggestion on how to make a clock multiplier
according to specs below:

Fin: 10 Hz - 2000 Hz
Fout: Fin*100

I would like to use a FPGA but other ideas are also appreciated.


Sven

Article: 15219
Subject: APS, Xilinx FPGA Boards Now Available Direct In Europe
From: info <info@euro-eda.com>
Date: Mon, 15 Mar 1999 10:10:54 +0000
Links: << >>  << T >>  << A >>
Xilinx FPGA development boards by Associated Professional Systems Inc.
(APS) are now available direct in Europe from EuroEDA Limited.

Full details from http://www.euro-eda.com or email info@euro-eda.com.
Article: 15220
Subject: Possible problem with die shrink of xc4010
From: wgilles@my-dejanews.com
Date: Mon, 15 Mar 1999 13:18:34 GMT
Links: << >>  << T >>  << A >>
we are experiencing a problem with xilinx XC4010E FPGAs. So far the problem
manifests itself as a stuck pin (Pin 126 of PQ208 package) to VCC. Two
XC4010E fpgas with different date codes (FPGA #1 = PQ208CKM9809 A105288A 4I,
FPGA #2 = PQ208CKJ9701 A105288A 4I) are programmed with the same image file.
FPGA #2 works properly but FPGA #1 with 9809 Date code has the stuck pin
problem. In the current design, Pin 126 is used as an external RAM data pin
which constantly being used.

Per our xilinx rep, FPGA #2 has a smaller die than #1.	Presently, we are not
sure whether if it is a timing problem with we are having with the latest
die. Since the fpga design was farmed out to an outside firm and they are
currently unavailable to aid us, we can't take a look at the timing
simulation to see whether we are border line or not, or, bring out test pins
to monitor the logics that affect pin 126.

Has anyone out there experienced or heard of similar problems? If yes, how did
you overcome it? And if no, can you offer any advise?

Thanks,

gilles

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 15221
Subject: Re: Possible problem with die shrink of xc4010
From: Achim Gratz <gratz@ite.inf.tu-dresden.de>
Date: 15 Mar 1999 17:19:38 +0100
Links: << >>  << T >>  << A >>
wgilles@my-dejanews.com writes:

> Per our xilinx rep, FPGA #2 has a smaller die than #1.	Presently, we are not
> sure whether if it is a timing problem with we are having with the latest
> die. Since the fpga design was farmed out to an outside firm and they are
> currently unavailable to aid us, we can't take a look at the timing
> simulation to see whether we are border line or not, or, bring out test pins
> to monitor the logics that affect pin 126.

If it's purely a timing problem, then variations in chip temperature
and power supply voltage should demonstrate the problem on FPGA#2 as
well and make it go away on FPGA#1.  Get out that cold spray and the
hair dryer.  If it is indeed a timing problem, I'd suggest taking the
designer to task over it.


Achim Gratz.

--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW:    http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gratz@ite.inf.tu-dresden.de
Phone:  +49 351 463 - 8325
Article: 15222
Subject: Re: Possible problem with die shrink of xc4010
From: Tom Kean <tom@algotronix.com>
Date: Mon, 15 Mar 1999 16:58:00 +0000
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------05DA82C062B78C1D8A05BFA3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A couple of comments:
1. If you have only seen the 'stuck at' problem on one FPGA then you should
consider
that it might be a bad chip rather than there being a systematic problem with all
shrunk
FPGA's.  Maybe that pin got zapped by static or the bond wire fell off or there is
a bad
solder joint on the board or ......
2. Second most likely problem is a timing problem in the design.  Heating it up or
cooling
it down *may* cause the other FPGA to have problems if the design is poor.  But it
is not
guaranteed to:  heating up or cooling down should make all timing paths delays
scale
by the same amount (e.g. 10% faster) with a shrink some paths might get 10% faster
and
others 20% faster.

Tom.


wgilles@my-dejanews.com wrote:

> we are experiencing a problem with xilinx XC4010E FPGAs. So far the problem
> manifests itself as a stuck pin (Pin 126 of PQ208 package) to VCC. Two
> XC4010E fpgas with different date codes (FPGA #1 = PQ208CKM9809 A105288A 4I,
> FPGA #2 = PQ208CKJ9701 A105288A 4I) are programmed with the same image file.
> FPGA #2 works properly but FPGA #1 with 9809 Date code has the stuck pin
> problem. In the current design, Pin 126 is used as an external RAM data pin
> which constantly being used.
>
> Per our xilinx rep, FPGA #2 has a smaller die than #1.  Presently, we are not
> sure whether if it is a timing problem with we are having with the latest
> die. Since the fpga design was farmed out to an outside firm and they are
> currently unavailable to aid us, we can't take a look at the timing
> simulation to see whether we are border line or not, or, bring out test pins
> to monitor the logics that affect pin 126.
>
> Has anyone out there experienced or heard of similar problems? If yes, how did
> you overcome it? And if no, can you offer any advise?
>
> Thanks,
>
> gilles
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

--------------05DA82C062B78C1D8A05BFA3
Content-Type: text/x-vcard; charset=us-ascii;
 name="tom.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Tom Kean
Content-Disposition: attachment;
 filename="tom.vcf"

begin:vcard 
n:Kean;Tom
tel;fax:UK +44 131 556 9247
tel;work:UK +44 131 556 9242
x-mozilla-html:TRUE
org:Algotronix Ltd.
adr:;;P.O. Box 23116;Edinburgh;;EH8 8YB;Scotland
version:2.1
email;internet:tom@algotronix.com
title:Director
note:Web Site: www.algotronix.com
x-mozilla-cpt:;4768
fn:Tom Kean
end:vcard

--------------05DA82C062B78C1D8A05BFA3--

Article: 15223
Subject: multiport register file--Altera Flex10k20 ?
From: <mathai@ecf.toronto.edu>
Date: Mon, 15 Mar 1999 17:44:46 GMT
Links: << >>  << T >>  << A >>
Hi, I'm designing a small RISC on a Flex10k20 and have run into a problem
implementing my register file.


The register file I want is 16 regs deep, each with width 16 bits.  I need
five data out (read) ports (two to the alu, three so I can do branch
condition detection and program counter loads on a branch), and one data
in (write) port. I tried to implement this as 16 registers with the output
ports as five huge 16:1 16 bit muxes. On compilation and fitting, I found
that this was must too large for the Flex10k20.

My question ... is there a more efficient way to implement this kind of
functionality?

Thanks for your advice,
Nebu

Article: 15224
Subject: Seeking for data in an FPGA RAM
From: Eduardo Augusto Bezerra <E.A.Bezerra@sussex.ac.uk>
Date: Mon, 15 Mar 1999 17:49:19 +0000
Links: << >>  << T >>  << A >>

Hello

In the example below I have used only 'if' and 'case' statements to
write/read the RAM memory. I would like to know if it is possible
to use 'for' statements in this synthesizable code. For example,
when FLAG_POWERUP = '0' I want to find out if DATA_IN is located
in the memory. Is it possible to sweep the memory using a 'for' loop?

Thanks

Eduardo.

P.S. This code is working without any problem in an XC4010XL
(XS40 - XESS board).


library IEEE;
   use IEEE.std_logic_1164.all;
   use IEEE.std_logic_unsigned.all;

entity RDWR_RAM256x8 is

  port ( -- CLK_IN        : in  std_logic;                     -- Global
clock
         RESET_NEG_IN  : in  std_logic;                     -- Global
reset (P0, parallel port)
         DATA_IN       : in  std_logic_vector(3 downto 0);  -- parallel
port (P5..P2)
         DATA_OUT      : out std_logic_vector(6 downto 0)   -- 7-seg
display
       );

end RDWR_RAM256x8;

architecture RDWR_RAM256x8_BEH of RDWR_RAM256x8 is

   component RAM256x8
      port ( 
             a       : in  std_logic_vector(7 downto 0);    -- RAM
address (WE = 1, write; CE=1, read)
             d       : in  std_logic_vector(7 downto 0);    -- Data
input (WE = 1, C = 1)
             we      : in  std_logic;                       -- '1' ==
write to the memory
             c       : in  std_logic;                       -- Clock
             ce      : in  std_logic;                       -- '1' ==
read memory
             q       : out std_logic_vector(7 downto 0)     -- Data
output (CE = 1, C = 1)
            );
   end component;

   component HEX2LED
      port (
             CLK_IN   : in  std_logic;
             DATA_IN  : in  std_logic_vector (7 downto 0);
             DATA_OUT : out std_logic_vector (6 downto 0)
            );
   end component;
   
   component OSC4
      port (
            F8M : out std_logic;
            F15 : out std_logic
           );
   end component;

   component BUFG
      port (
            I : in  std_logic;
            O : out std_logic
	   );
   end component;


   -- declarations for RAM256x8
   signal ADDR_RAM256x8    : std_logic_vector(7 downto 0);
   signal DATAIN_RAM256x8  : std_logic_vector(7 downto 0);
   signal WR_RAM256x8      : std_logic;
   signal CLK_RAM256x8     : std_logic;
   signal CE_RAM256x8      : std_logic;
   signal DATAOUT_RAM256x8 : std_logic_vector(7 downto 0);

   -- declarations for HEX2LED
   signal CLK_HEX2LED     : std_logic;
   signal DATAIN_HEX2LED  : std_logic_vector(7 downto 0);
   signal DATAOUT_HEX2LED : std_logic_vector(6 downto 0);
   
   -- declarations for OSC4
   signal CLK8M, CLK15Hz  : std_logic;
   
   -- declarations for BUFG
   signal OSCOUT, CLK_IN  : std_logic;
   
   signal FLAG_POWERUP,
          NOT_FOUND       : std_logic;
   signal OLD_DATA        : std_logic_vector(3 downto 0);
          
   type STATES_TYP is (SX_C, S1_C, S2_C, S3_C, S4_C, S5_C, S6_C, S7_C);
   signal NEXT_STATE      : STATES_TYP;

begin

   --
   -- instantiate the components
   --
   RAM256x8_1 : RAM256x8 port map (
                                  a  => ADDR_RAM256x8,
                                  d  => DATAIN_RAM256x8,
                                  we => WR_RAM256x8,
                                  c  => CLK_RAM256x8,
                                  ce => CE_RAM256x8,
                                  q  => DATAOUT_RAM256x8
                                 );

   HEX2LED_1 : HEX2LED port map (
                                  CLK_IN   => CLK_HEX2LED,
                                  DATA_IN  => DATAIN_HEX2LED,
                                  DATA_OUT => DATAOUT_HEX2LED
                                );
                                

   OSCILLATOR: OSC4 port map    (
                                  F8M      => CLK8M,
                                  F15      => CLK15Hz
                                );

   CLOCKBUF:BUFG port map       (
                                 I         => OSCOUT,
                                 O         => CLK_IN
                                );

   OSCOUT         <= CLK15Hz;
                                
   CLK_RAM256x8   <= CLK_IN;
   CLK_HEX2LED    <= CLK_IN;

   DATAIN_HEX2LED <= "11111111" when NOT_FOUND = '1' else
                     DATAOUT_RAM256x8;

   DATA_OUT       <= DATAOUT_HEX2LED;

   RDWR_RAM256x8_PRO: process (CLK_IN, RESET_NEG_IN )
   begin

      if RESET_NEG_IN = '0' then

         NOT_FOUND          <= '1';
         ADDR_RAM256x8      <= (others => '0');
         DATAIN_RAM256x8    <= (others => '0');
         WR_RAM256x8        <= '1';             -- Write memory on power
up
         CE_RAM256x8        <= '0';             -- Don't read memory
         FLAG_POWERUP       <= '1';

      elsif CLK_IN'event and CLK_IN = '1' then

        
-----------------------------------------------------------------------------
         -- Initialize on Powerup
        
-----------------------------------------------------------------------------
         if FLAG_POWERUP = '1' then

            if WR_RAM256x8 = '0' then
               --
               -- Fill SRAM with RAMPS
               --
               if ADDR_RAM256x8 = 255 then                 -- last
address == 255
                  DATAIN_RAM256x8 <= ADDR_RAM256x8(7 downto 1) & "0";
                  NEXT_STATE      <= S1_C;
                  FLAG_POWERUP    <= '0';
               else                                      -- fill
memories
                  DATAIN_RAM256x8 <= ADDR_RAM256x8(7 downto 1) & "0";
                  FLAG_POWERUP    <= '1';                 -- keep
filling RAM;
               end if;
               WR_RAM256x8         <= '1';                 -- Next
clock, write
            else
               DATAIN_RAM256x8    <= (others => '0');
               FLAG_POWERUP       <= '1';                 -- keep
filling RAM;
               ADDR_RAM256x8      <= ADDR_RAM256x8 + 1;
               WR_RAM256x8        <= '0';                 -- Next clock,
don't write
            end if;

         else

            FLAG_POWERUP   <= '0';
            CE_RAM256x8    <= '1';
            WR_RAM256x8    <= '0';                 -- Next clock, don't
write
            
           case NEXT_STATE is

               -- SX_C is used for simulation purposes only. No hardware
is generated to represent
               -- this initialization state. It is used to detect
resetting problems.
               when SX_C =>
                  NEXT_STATE    <= SX_C;

               when S1_C =>
                  NOT_FOUND     <= '1';
                  OLD_DATA      <= DATA_IN;
                  ADDR_RAM256x8 <= (others => '0');
                  NEXT_STATE    <= S2_C;
            
               when S2_C =>

                  if ADDR_RAM256x8 = 255 then
                     NOT_FOUND  <= '1';
                     NEXT_STATE <= S3_C;
                  else
                     if DATAOUT_RAM256x8 = ("0000" & OLD_DATA) then
                        NOT_FOUND     <= '0';
                        NEXT_STATE    <= S3_C;
                     else
                        NOT_FOUND     <= '1';
                        ADDR_RAM256x8 <= ADDR_RAM256x8 + 1;
                        NEXT_STATE    <= S2_C;
                     end if;
                  end if;
                  
               when S3_C =>

                  if DATA_IN = OLD_DATA then
                     NEXT_STATE <= S3_C;
                  else
                     NEXT_STATE <= S1_C;
                  end if;

               when others =>

                  NEXT_STATE <= S4_C;

            end case;
                              
         end if;

      end if;

   end process RDWR_RAM256x8_PRO;

end RDWR_RAM256x8_BEH;


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