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 50800

Article: 50800
Subject: Re: Async RAM on an FPGA board
From: prashantj@usa.net (Prashant)
Date: 19 Dec 2002 15:18:36 -0800
Links: << >>  << T >>  << A >>
"Jonathan Bromley" <jonathan@oxfordbromley.u-net.com> wrote in message news:<att08v$oam$1$830fa7b3@news.demon.co.uk>...
> > Thanks everyone for the suggestions. My FPGA runs @ 40MHz and the RAM
> > specs say its a 10ns RAM. I thought @ 40MHz the FPGA ran slow enough
> > for the RAM to be accessed comfortably. But I will take your
> > suggestion and give the RAM more time to fetch data.
> 
> WHOA THERE!  You didn't listen!
> 


Hi Jonathan,
I write data to the RAM through my PC's serial port to the FPGA and
then to the RAM. The data is written through the FPGA @ 40MHz, but its
only written once (one word) every 8.68us (1/115.2KHz). I checked my
code and the write enable signal stays enabled all the time (since I'm
only writing). The address also changes only @ the rate of 115.2 KHz
and many cycles after the data is written to the RAM. Also, if I read
back the external RAM data (one word every 8.68us)through the FPGA to
the PC, the data is found to be the same as what was written. Hence I
assume that the writing of the data was correct.

The problems start when I run a seperate piece of code on the FPGA
which requires to read 64 words of data from the RAM in 64 clock
cycles. Some of the values are captured incorrectly.

Hence, I assumed that it was the read cycles which were incorrectly
operating and so I wanted to slow down my read cycles.

Am I on the right track ?

I highly appreciate the timing diagrams you drew up there.

Thanks,
Prashant

Article: 50801
Subject: Re: Async RAM on an FPGA board
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 20 Dec 2002 12:33:52 +1300
Links: << >>  << T >>  << A >>
Prashant wrote:
> 
> "Jonathan Bromley" <jonathan@oxfordbromley.u-net.com> wrote in message news:<att08v$oam$1$830fa7b3@news.demon.co.uk>...
> > > Thanks everyone for the suggestions. My FPGA runs @ 40MHz and the RAM
> > > specs say its a 10ns RAM. I thought @ 40MHz the FPGA ran slow enough
> > > for the RAM to be accessed comfortably. But I will take your
> > > suggestion and give the RAM more time to fetch data.
> >
> > WHOA THERE!  You didn't listen!
> >
> 
> Hi Jonathan,
> I write data to the RAM through my PC's serial port to the FPGA and
> then to the RAM. The data is written through the FPGA @ 40MHz, but its
> only written once (one word) every 8.68us (1/115.2KHz). I checked my
> code and the write enable signal stays enabled all the time (since I'm
> only writing). 

?! - Do you mean this - the WRN should NOT be active on an address
change.
Normally, WRN is the 'most-narrow' pulse.


> The address also changes only @ the rate of 115.2 KHz
> and many cycles after the data is written to the RAM. Also, if I read
> back the external RAM data (one word every 8.68us)through the FPGA to
> the PC, the data is found to be the same as what was written. Hence I
> assume that the writing of the data was correct.

If you only read the last-written byte, you can get false-confidance :)
 
A better test is a pattern write, then read.
We use 255-(AdrU XOR AdrL) as a simple pattern, that rolls, and
avoids matching the address.

-jg

Article: 50802
Subject: Re: What voltage level is considered as "floating"?
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 19 Dec 2002 18:43:49 -0500
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
> 
> "John" <jjjkkl@hotmail.com> wrote in message
> news:4a50e479.0212181610.655dab95@posting.google.com...
> > I'm using a Xilinx Coolrunner CPLD (CMOS I/O's), with a VCC of 3.0 V.
> > In what range would the inputs be considered floating?
> 
> Any voltage, that when multiplied by zero has a product
> of zero is a possible voltage to a floating input.
> 
> Otherwise, if you explain what the real problem is, maybe we
> can find an answer.

Not sure what that means.  But I think he is saying that a floating
input is not defined by the voltage.  It is considered floating when
there is nothing driving it.  In that case, it can be at any voltage
which is the problem.  With CMOS devices, a floating input can be at a
voltage near the threshold which allows a large amount of current to
flow through the two transistors in the gate.  This can be enough to
cause damage in some cases.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 50803
Subject: Hi xilinx
From: Russell <rjshaw@iprimus.com.au>
Date: Fri, 20 Dec 2002 10:47:24 +1100
Links: << >>  << T >>  << A >>
I need a linux version of webpack with a gui
that works. If it wasn't for spartan-II devices
with distributed ram (SRL16) and some floorplanning
ability, i'd be using altera now.


Article: 50804
Subject: Re: What voltage level is considered as "floating"?
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 19 Dec 2002 16:33:31 -0800
Links: << >>  << T >>  << A >>


rickman wrote:

> With CMOS devices, a floating input can be at a
> voltage near the threshold which allows a large amount of current to
> flow through the two transistors in the gate.  This can be enough to
> cause damage in some cases.
>

No damage normally. Input buffers and internal circuits usually only draw a
few mA in this case. But the inputs can become noise amplfiers, beyond the
fact that they are driving unintentioned logic levels.

Leaving inputs floating was a sloppy habit in TTL, but is an invitation to
disaster in CMOS.
That's why Xilinx devices have optional internal pull-ups ( or -downs).

Peter Alfke


Article: 50805
Subject: Re: Hi xilinx
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 19 Dec 2002 16:39:34 -0800
Links: << >>  << T >>  << A >>
I'll forward this to our software tools management.
It is nice to hear that superior hardware feature still mean a little
something...

Peter Alfke
============================
Russell wrote:

> I need a linux version of webpack with a gui
> that works. If it wasn't for spartan-II devices
> with distributed ram (SRL16) and some floorplanning
> ability, i'd be using altera now.


Article: 50806
Subject: Problem of ISE 5.1i installation.
From: "Hua Ai" <hai@ualberta.ca>
Date: Fri, 20 Dec 2002 02:35:05 GMT
Links: << >>  << T >>  << A >>
I just installed an set of ISE 5.1i on a Win2K machine, but everytime when I
launch the project navigator, it complains "Unable to get a socket
connection (10107). Some processes in ISE may not work correctly". When I
test to create a testbench waveform, it reports "ProjNav couldn't find an
IPC port". Since my system administrator said this never happened before, I
would think it 's something wrong with this win2k machine which has disabled
IPC. But I really have no idea about this and I am not sure if my guess is
right. I would apprectiate very much if anyone could give me any
suggestions.

Hua



Article: 50807
Subject: Re: 16-bit LFSR
From: "Stan Lackey" <stanlackey@hotmail.com>
Date: Thu, 19 Dec 2002 22:55:47 -0500
Links: << >>  << T >>  << A >>
The 16-bit LFSR has taps at bits 15, 14, 12 and 3 (16, 15, 13 and 4 using
one-based numbering.)  There could be a shift register for the 9 bits 4 thru
12, and the rest in 7 flops.  The eqn for 17 bits is a little friendlier,
it has taps at 16 and 13, that would be 3 flops and 14 shift register
stages.  -Stan




Article: 50808
Subject: Re: Hi xilinx
From: Ray Andraka <ray@andraka.com>
Date: Fri, 20 Dec 2002 03:57:12 GMT
Links: << >>  << T >>  << A >>
Basically what I've been saying...the SRL16 is the biggest advantage the
virtex lines have over Altera's Stratix.  Don't let that capability fall
by the wayside just because your tier 1 customers are not using it.



Peter Alfke wrote:

> I'll forward this to our software tools management.
> It is nice to hear that superior hardware feature still mean a little
> something...
>
> Peter Alfke
> ============================
> Russell wrote:
>
> > I need a linux version of webpack with a gui
> > that works. If it wasn't for spartan-II devices
> > with distributed ram (SRL16) and some floorplanning
> > ability, i'd be using altera now.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 50809
Subject: Re: Multi cycle Paths..
From: "Stan Lackey" <stanlackey@hotmail.com>
Date: Thu, 19 Dec 2002 22:59:44 -0500
Links: << >>  << T >>  << A >>
Yes, I have found that it's much easier to create the RTL such that there
are no MCPs, than to deal with them.  Eliminates the possibility of human
error, too.

"Ray Andraka" <ray@andraka.com> wrote in message
news:3E02492F.DE1333F7@andraka.com...
> I have seen this.  I avoid multicycle constraints as much as possible
because it
> is too easy to inadvertantly relax a constraint  you didn't intend on
relaxing.
> It also keeps those who maintain the design honest.
>
> Austin Lesea wrote:
>
> > Ken,
> >
> > Just one comment on multi-cycle path contraints.  I have found that if
you
> > use them, you must use the "from" "through" and "to" form (all three) in
> > order not to confuse the tools (with no 'wild cards').  If you don't
specify
> > all three (and carefully), the constraints may actually be lessened,
instead
> > of tightened where intended.
> >
> > Is this your experience as well?
> >
> > Austin
> >
> > Ken McElvain wrote:
> >
> > > Muthu wrote:
> > >
> > > > Hi,
> > > >
> > > > I Have 2 Flip Flops (FF1 and FF2). The actual combination logic
delay
> > > > in between these FFs are 10ns. Say i have defined a path between FF1
> > > > and FF2 as a multicycle path in synplify_pro synthesis.
> > > >
> > > > Here is my questions regarding this?
> > > >
> > > > 1. Will the synplify_pro tool will put an additional FF between
these
> > > > FF1 and FF2? or it will simple assume that the dealy between these
> > > > Flip-Flops are 5ns.
> > >
> > > It will increase the available time for paths between FF1 and FF2
> > > according to the number of cycles you specify.
> > >
> > > >
> > > > 2. I know that, this multicycle path information will be passed to
the
> > > > Place and Route tool. what the place and route tool will do?
> > >
> > > The same thing.
> > >
> > > >
> > > > will it put some FFs in between ? or this is simply for timing
report
> > > > generation?
> > >
> > > No logic change is implied by a multi-cycle path specification.
> > >
> > > >
> > > > Thanks in advance
> > > >
> > > > Best regards,
> > > > Muthu
> > > >
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>



Article: 50810
Subject: stupid rookie timing question
From: agunos@cox.net (ed)
Date: 19 Dec 2002 21:07:38 -0800
Links: << >>  << T >>  << A >>
Hello All,

I am doing a desing that's supposed to run at a 100Mhz in a Virtex-II.
Is it good desing practice to run the synthesis and PAR tool with
higher frequency constraints (ie: 120Mhz)? Or can I assume that if the
PAR tool says a design
meets the 100Mhz constraints, the desing CAN and WILL run at a 100Mhz?

Thanks,
ed

Article: 50811
Subject: Re: stupid rookie timing question
From: "Kevin Neilson" <kevin_neilson@removethistextattbi.com>
Date: Fri, 20 Dec 2002 05:12:32 GMT
Links: << >>  << T >>  << A >>
You should constrain at 100MHz.  It will work.

"ed" <agunos@cox.net> wrote in message
news:c23bf65e.0212192107.4cdd8b67@posting.google.com...
> Hello All,
>
> I am doing a desing that's supposed to run at a 100Mhz in a Virtex-II.
> Is it good desing practice to run the synthesis and PAR tool with
> higher frequency constraints (ie: 120Mhz)? Or can I assume that if the
> PAR tool says a design
> meets the 100Mhz constraints, the desing CAN and WILL run at a 100Mhz?
>
> Thanks,
> ed



Article: 50812
Subject: Re: stupid rookie timing question
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Fri, 20 Dec 2002 05:42:57 GMT
Links: << >>  << T >>  << A >>
ed wrote:

> I am doing a desing that's supposed to run at a 100Mhz in a Virtex-II.
> Is it good desing practice to run the synthesis and PAR tool with
> higher frequency constraints (ie: 120Mhz)? Or can I assume that if the
> PAR tool says a design
> meets the 100Mhz constraints, the desing CAN and WILL run at a 100Mhz?

PAR needs to be run at the design frequency.  Don't forget to also
constrain your I/O timing with offset = in every input other than clock,
offset = out for every pin output, and both for every I/O.  See:

http://toolbox.xilinx.com/docsan/xilinx5/manuals.htm


Example that might go into your design.ucf:

# NET “pad_net_name” OFFSET = {IN|OUT} “offset_time” [units]
{BEFORE|AFTER} “clk_name” [TIMEGRP “group_name”]; 

NET "TXD" OFFSET = OUT 17 NS AFTER CLK;


After PAR claims that the design fits and meets all timing, running
static timing TRCE and looking at the unconstrained paths can be very
valuable.  If it needs a constraint, figure one out.  Look at any
constraint with "0 items analyzed" carefully to make sure it is checking
what you need it to.  This can happen with some automatically generated
constraints, so don't panic.  Example command:

TRCE -v 10 -u 100 designname


Synthesis tools, on the other hand, may need set to a frequency other
than the design frequency, especially when you get to doing designs that
push the limits of the parts and/or tools.  As a beginner, put this in
the back of your brain, and don't try to use it yet.  When (not if) you
get a situation where the synthesis tool is mucking with your design in
a bad way remember it.... And if you do this, don't forget to disable
the synthesis from sending the fake timing to PAR.


-- 
Phil Hays

Article: 50813
Subject: Re: Multi cycle Paths..
From: muthu_nano@yahoo.co.in (Muthu)
Date: 19 Dec 2002 21:49:26 -0800
Links: << >>  << T >>  << A >>
Hi,

If the multicycle path constrain is not iserting any FFs in the logic.
why should we use them? It is quite obivious that, we are telling the
synthesis and Place and route tools not to take the actual combination
delay between the FF1 and FF2.

What is the use of this? It doesn't make any sense????

correct if i am wrong.

Regards,
Muthu

Article: 50814
Subject: Re: Multi cycle Paths..
From: Muzaffer Kal <kal@dspia.com>
Date: Fri, 20 Dec 2002 07:32:23 GMT
Links: << >>  << T >>  << A >>
On 19 Dec 2002 21:49:26 -0800, muthu_nano@yahoo.co.in (Muthu) wrote:

>Hi,
>
>If the multicycle path constrain is not iserting any FFs in the logic.
>why should we use them? It is quite obivious that, we are telling the
>synthesis and Place and route tools not to take the actual combination
>delay between the FF1 and FF2.

Multi-cycle paths generate a relaxed constraint for the path in
question. If your clock period is 10ns and if you set a multi-cycle
path with a property of 2, then the logic between the two flops can
take 20ns WITHOUT inserting the pipeline flops. If you can really
guarantee and maintain MC constraints it can help save area and meet
timing but as there is no direct relationship between the RTL and the
property they can get out of sync, meaningless or worse plain wrong as
design changes.
MC paths usually become a maintenance problem. Avoid them if you can,
document really well if you can't.

Muzaffer Kal

http://www.dspia.com
ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations

Article: 50815
Subject: Re: Multi cycle Paths..
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 20 Dec 2002 07:48:37 -0000
Links: << >>  << T >>  << A >>
>MC paths usually become a maintenance problem. Avoid them if you can,
>document really well if you can't.

I assume the obvious case is a clock enable where you know some signal
is setup the cycle before it is needed.

How often do more complicated versions happen?

How would you document something like this?  Is there any
way to check it during simulations?  That is add some "code"
to the simulation so the tools will make sure some patch a
long time after the initial design doesn't break things.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 50816
Subject: Xilinx 1024 Pt FFT
From: "Sanjay Patil" <sanjay@cg-coreel.com>
Date: Fri, 20 Dec 2002 13:48:50 +0530
Links: << >>  << T >>  << A >>
Hi
Xilinx Free FFT core takes Imaginary input as zero.
If we need to use it for Real Time application, where Imaginary inputs will
be there, How to generate Imaginary Inputs for real time Data, which is just
a real Number.

Thanks in Advance
Sanjay




Article: 50817
Subject: Re: MPEG FPGA
From: lebrase@yahoo.fr (Erwan)
Date: 20 Dec 2002 00:51:10 -0800
Links: << >>  << T >>  << A >>
nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote in message news:<atnm26$15m2$1@agate.berkeley.edu>...

Thank you (and the others) for the answer(s). I have some more
question though.

> You would probably do better with FPGA only, or FPGA and uP (something
> more conventionally programmable), although it depends on the area and
> cost model.

What are the relations between cost model, area and the use of FPGA
only (or FPGA plus uP) ? Do you mean that FPGA solution imply some
more costs ? But actually what interest me is where it cost more and
why.

> >Is mixing C code (on DSP) and hardware optimized functions (on FPGA) a
> >good choice for speed ? (versus C only on DSP)
> 
> You might want to think of the split differently, as the communication
> costs between the two will be high.

What is actually wrong with high computational part moved into
functions and these functions moved to FPGA ? Is it the overhead of
the "call" a lot more slow between FPGA and DSP/uP than for classical
function call ? Which design minimizes this "communication cost" ?

Erwan

Article: 50818
Subject: Re: Hi xilinx
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Fri, 20 Dec 2002 08:51:25 +0000 (UTC)
Links: << >>  << T >>  << A >>
Russell <rjshaw@iprimus.com.au> wrote:
: I need a linux version of webpack with a gui
: that works. If it wasn't for spartan-II devices
: with distributed ram (SRL16) and some floorplanning
: ability, i'd be using altera now.

I installed a normal windows version of webpack/ise with a recent version of
wine on linux.  With some patches already included in newer version of wine,
webpack works quite well. No chance for running impact, and no interest from
xilinx to get help to get impact running however...

For webpack installation in wine, unzip the exe file in a directory. Read
the wine docs about Installshield 6 (in short builtin ole32/oleaut32/rpcrt4
and native std*.tlb). For running, native msvcrt helps in some
cases. Sometimes startup hangs, but restarting normally works then.

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 50819
Subject: Re: A/D converter in FPGA
From: bill.sloman@ieee.org (Bill Sloman)
Date: 20 Dec 2002 01:16:49 -0800
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3E024288.9A015A67@yahoo.com>...
> Lorenzo Lutti wrote:
> > 
> > "Allan Herriman" <allan_herriman.hates.spam@agilent.com> ha scritto nel
> > messaggio news:3e006906.33423169@netnews.agilent.com...
> > 
> > > These won't even come close to being able to convert 10
> > > bit values at
> > > 2.5MHz.
> > 
> > In the previous message I haven't noticed the 2.5 MHz thing; I agree
> > with you. Anyway, I think that the delta-sigma approach (even with an
> > external ADC) should be better in order to avoid the switching noise:
> > they are inherently better for this kind of problems.
> > 
> > Sadly, I'm not sure that you can find sigma-delta ADCs so fast. I have
> > seen some at 200-300 kSPS, not more.
> > 
> > The other user can try with a flash converter. It should be better than
> > a SAR (obviously is costs more).
> 
> Actually, I don't think a Flash converter of 10 bits at 5 MHz would cost
> any more than an SAR converter at the same speed.  I have looked at a
> few high res SARs below 1 MSPS and they get very pricey.  Perhaps a 12
> bit SAR converter would not be so expensive, but I have not seen them at
> 2.5 MSPS.  But then I haven't been looking.  I do know that this is the
> low end for 10 bit Flash converters and Flash converters have up to 14
> bits these days.  

A "real" 14-bit flash converter would have 16,384 comparators (with
maybe a couple more for over-range and under-range indication - I
never got interested enough to get on top of all the detail). The
"flash" converters that offered this sort of resolution used to be
dual flash devices,
- one 8-bit flash A/D converter feeding a 14-bit accurate 8-bit D/A
converter, and second 8-bit flash converter to digitise the difference
between the DAC output and the (sampled) signal. You had allow some
overlap between the stages for reasons that now escape me - I think
they tended to be self-calibrating with big tables of digital
corrections in fast RAM ....

Fairchild's SPT7937 12-bit 28 MSPS part rotates the signal around 18
parallel 13-bit SAR converters, which is to say it is more or less
conventional. The Analog Devices 14-bit 40MSPS AD6644 appears to be a
triple flash device, with three stages of sub-ranging, and their
14-bit 40/65 MSPS AD9244 appears to go to eight stages (but I've only
got a preliminary data sheet, though Analog Devices seems to be
claiming that it is in production).

------
Bill Sloman, Nijmegen

Article: 50820
Subject: Re: Single event Upset effect in One Time PROM used for configuration in Xilix FPGA
From: sthiruppathirajan@yahoo.com (sthiruppathirajan)
Date: 20 Dec 2002 01:23:54 -0800
Links: << >>  << T >>  << A >>
Thanx for the  reply.
Now Will I have to use triple mode redundancy for the latches inside
the FPGA?
How can I able to know about the number of latches configured for the
design?
Is there any VHDL code used to count the number of latches going to
configured for a design  so that TRM will be used ?Or can I have to
use triple mode redundancy for the FPGA i.e. three FPGAs for single
FPGA?
Tahnx in advance.
S.Thiruppathirajan.



Ray Andraka <ray@andraka.com> wrote in message news:<3DFF4392.C926D921@andraka.com>...
> There is no redundancy built into the PROM.  If you want it, you've got to add it
> yourself.  Rather than using serial proms in this situation, you might consider using a
> parallel PROM, storing ECC code with it and using a CPLD to do ECC on the memory reads as
> well as to take care of creating the configuration stream.  The CPLD design can be done
> with appropriate SEU mitigation (triple mode or other). You'll probably also want to do
> readback to confirm the configuration, as well as some form of configuration monitoring to
> make sure the configuration does not get upset after it has completed.  I presented a
> paper at MAPLD on detection of configuration upset this year.  The paper is not in its
> final form yet, or I would send it to you.  Basically, I was proposing some simple
> periodic test vector checks to confirm the FPGA still performed the programmed function.
> You can also put TMR inthe FPGA design to detect upsets in the configuration.
> 
> sthiruppathirajan wrote:
> 
> > Hai all,
> > I haven't got the answer for my question.
> > I hope u have'nt understood.
> > My quest is what is the remedy for SEU in One Time PROM configured
> > XILINX FPGA?
> > Can I use Triple Redundancy logic?{will this acceptable for only SRAM
> > configured FPGA?
> > I refered the xilinx website and there is no information about ,what
> > OTP is made of in Xilinx FPGA?Is it metal-metal antifuse or CMOS based
> > memories or floating gate technique?If it is metal-metal antifuse
> > means no problem at all in space!!
> >
> > Kindly reply my doubts
> > Thanx in advance.
> > Bye.
> > S.Thiruppathirajan
> >
> > Peter Alfke <peter@xilinx.com> wrote in message news:<3DFA73CE.2EC14CF8@xilinx.com>...
> > > Josh Model wrote:
> > >
> > > > http://www.xilinx.com/products/military/radhardv.htm
> > > >
> > > > This should get you started, especially the SEU paper. Xilinx's FPGA's have
> > > > their configuration stored in an external PROM, probably OTP.  To summarize,
> > > > suggested solutions involve Triple mode redundancy, and CRC checking the
> > > > bitstream using periodic repeated reconfiguration.
> > > >
> > > > One thing to watch out for, though, is current surges during
> > > > reconfiguration/power up.
> > >
> > > Just a slight correction:
> > > Yes, Xilinx FPGAs prior to Virtex-II have an Icc surge when first powering up.
> > > Virtex-II and later do NOT have that surge.
> > > More importantly:
> > > This surge does NEVER occur upon reconfiguration while Vcc is maintained, it
> > > only occurs when Vcc is (re)applied.
> > >
> > > Peter Alfke, XilinxApplications
> 
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
> 
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759

Article: 50821
Subject: Re: How to asynchronously reset a flip-flop?
From: "Alan Fitch" <alan.fitch@doulos.com>
Date: Fri, 20 Dec 2002 09:48:11 -0000
Links: << >>  << T >>  << A >>

"Jim Lewis" <jim@SynthWorks.com> wrote in message
news:3E01F363.2070701@SynthWorks.com...
> Christopher,
>     Of course the easy way to avoid the necessity to know
> the pins of a vendors gate library is to use one of the
> hardware description languages, such as VHDL.
>
> Below is an asynchronous reset coded in VHDL:
>
> AsyncRegProc : process(nReset, Clk)
> begin
>    if (nReset = '0') then
>      MyReg <= '0' ;
>    elsif rising_edge(Clk) then
>      MyReg <= '1' ;
>    end if ;
> end process ;
>
Jim,
    I guess you meant to put a data input in, e.g.

 AsyncRegProc : process(nReset, Clk)
 begin
    if (nReset = '0') then
      MyReg <= '0' ;
    elsif rising_edge(Clk) then
  --    MyReg <= '1' ;
      MyReg <= D;       -- input to flip-flop
    end if ;
 end process ;

regards

Alan

--
Alan Fitch
[HDL Consultant]

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project
Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire,
BH24 1AW, UK
Tel: +44 (0)1425 471223                          mail:
alan.fitch@doulos.com
Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.



Article: 50822
Subject: Re: 16-bit LFSR
From: "Alan Fitch" <alan.fitch@doulos.com>
Date: Fri, 20 Dec 2002 09:52:51 -0000
Links: << >>  << T >>  << A >>

<snip lots of good advice from Ray and Allan>
I think also there's a Xilinx app note XAPP052 about exactly this,

HTH (*)

regards

Alan

(*) Thought I'd put in another cryptic abbreviation after working
out what OP means at last - it means original poster
doesn't it? It's a new "meme", I've seen it in lots of messages
recently.

--
Alan Fitch
[HDL Consultant]

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project
Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire,
BH24 1AW, UK
Tel: +44 (0)1425 471223                          mail:
alan.fitch@doulos.com
Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 50823
Subject: Re: 16-bit LFSR
From: Jacky Renaux <renaux.jacky@wanadoo.fr>
Date: 20 Dec 2002 10:13:56 GMT
Links: << >>  << T >>  << A >>

Hi 

first: On XC4000 , you have to build up the address generator to drive the 
distributed ram addresses then 4 flips flops (2 CLBs) must be added 
second: 16 bits lsfr ( see xilinx app not xapp052.pdf) needs 4 taps , but 15 
bits or 17 requires only 2 
if you select 15 bits , then taps 15,14 are needed 
use a (16x1) and latch the output (bit 15) the ram output is the 14th 
by XORed to feedback the ram input you'll get a compact LSFR 
clb count : counter=2 , 16x1 ram=0.5, xor = 0.5 

17 bits is a bit more complex in term of size 
if you use a dual port ram you'll be able to tap 17 (ram+flip flop) and 14 
from the second port 
counters=2+ 2.5 , 16x1d=1,xor=0.5 

cheers
jacky 

-- 
Use our news server 'news.foorum.com' from anywhere.
More details at: http://nnrpinfo.go.foorum.com/

Article: 50824
Subject: Re: Async RAM on an FPGA board
From: "Jonathan Bromley" <jonathan@oxfordbromley.u-net.com>
Date: Fri, 20 Dec 2002 10:24:42 -0000
Links: << >>  << T >>  << A >>
"Prashant" <prashantj@usa.net> wrote

> I write data to the RAM through my PC's serial port to the FPGA and
> then to the RAM. The data is written through the FPGA @ 40MHz, but its
> only written once (one word) every 8.68us (1/115.2KHz). I checked my
> code and the write enable signal stays enabled all the time (since I'm
> only writing). The address also changes only @ the rate of 115.2 KHz
> and many cycles after the data is written to the RAM. Also, if I read
> back the external RAM data (one word every 8.68us)through the FPGA to
> the PC, the data is found to be the same as what was written. Hence I
> assume that the writing of the data was correct.

I agree with Jim Granville that it's a really bad idea to leave nWR
asserted continuously.  Are you pulsing nCS?  Usually, you expect
a SRAM to perform a write to its internal storage on the rising
edge of (nWR OR nCS).  If both are held asserted (low) then
it's not at all clear what will happen.  Possibly you get a
write taking effect when the address changes, but it's very
uncertain and very bad practice.

> The problems start when I run a seperate piece of code on the FPGA
> which requires to read 64 words of data from the RAM in 64 clock
> cycles. Some of the values are captured incorrectly.
> Hence, I assumed that it was the read cycles which were incorrectly
> operating and so I wanted to slow down my read cycles.

Let's assume for the moment that your writes really are correct,
and the reads are failing.

You need to think about the whole logic path from the FF that
registers your RAM address on one clock cycle, through any logic in
the FPGA, through the output pads, to the RAM, through the RAM's
access time, back into the FPGA through the input pads and finally
into a flipflop that captures the read data on the next clock edge:

LOGIC PATH:
===========
<----- FPGA address path ----->           <------ FPGA data path ------>
__________                                                     _________
FF inside |   ______    ______    ______    ______    _____   |FF inside|
FPGA,     |  |      |  | FPGA |  | SRAM |  | FPGA |  |     |  |    FPGA,|
storing  Q|--|logic?|--| OBUF |--|A    D|--| IBUF |--|logic|--|D      to|
address   |  |______|  |______|  |______|  |______|  |_____|  |  capture|
__________|                                                   | RAM data|
                                                              |_________|
TIMING:
=======
 FF prop.   + logic  +   OBUF   +  SRAM   + IBUF    + logic  + FF setup
  delay       delay      delay      tAA     delay     delay      time

All of this must fit into 25ns, of which the SRAM takes 10ns.  So you
have a 15ns budget which must be shared between the two completely
separate logic paths that I've labelled "FPGA address path" and "FPGA
data path".  So, the question is, how do you set up your constraints
(in the UCF file, or whatever)?  In practice the best way is probably
to guess as a first attempt - try allowing 9ns for the address path,
and 6ns for the data path.  Then you will get a timing report from the
place-and-route tools and there are 3 possible outcomes:

(1) both timing constraints were successfully met - you're done,
    the design will work OK
(2) BOTH constraints were violated - it looks like you have no
    chance of achieving single-cycle reads
(3) ONLY ONE constraint was violated - so you can now go back to the
    UCF file and change the way your 15ns constraint is shared
    between the two paths, and then try again.

Xilinx gurus will probably tell me how you can include an external
logic delay (like the SRAM) in a single, long path - but I don't
know the UCF syntax well enough to know how to do that, sorry.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                    mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.





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