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 65300

Article: 65300
Subject: Re: is this a good idea
From: Ray Andraka <ray@andraka.com>
Date: Fri, 23 Jan 2004 17:32:04 -0500
Links: << >>  << T >>  << A >>
The global reset nets in FPGAs are generally too slow to use in systems that are using the clock rate
capability of the FPGA.  In those cases, you need to assume the reset is asynchronous to your clock
anyway because the propagation time on the net can exceed the clock cycle making its release
indeterminate relative to the clock, and possibly on different clock cycles in different places on the
design.  All that really needs to be reset is critical circuits on the FPGA.   For the most part, this
means you just need something to force any feedback loops to a known state so that after some known
number of cycles with reset asserted, you know the state of all the registers in the design without
having to do an explicit reset on more than a small portion of the design.  FPGAs do come out of
configuration in a known state, however you should hold the reset on critical items like state machines
for a clock or two to make sure everything starts cleanly.  Sometimes, even that is unnecessary other
than for simulation purposes if you have a state machine with no illegal states, for example a counter
that only needs to produce an output at some interval for which you do not care about the phasing.

Assaf Sarfati wrote:

> paulw@mmail.ath.cx (Paul) wrote in message news:<3ba4d769.0401040319.40ffdbcd@posting.google.com>...
> > Hi
> >
> > I know that the "reg"'s are all zeroes when powered on (on Xilinx
> > FPGAs). Is this a good idea (assumption) to work on? Can I assume the
> > same for ASIC development? that is I don't have to change my codes
> > later on?
> >
> > Thanks.
>
> This is a very bad idea. Bad/no design for exiting reset state will
> cause your ASIC/FPGA to be unreliable - sometimes it will start
> working, sometimes not.
>
> In addition, most simulators HATE it - they will start with everything
> in "unknown" state. Reset-recovery problems are very hard to simulate
> (same category as meta-stability problems - not really deterministic),
> so that the design appears to be OK in simulation.
>
> Best practice:
> * EVERY flip-flop should be explicitly reset (including FFs in I/O
> pads).
>
> * Resets are global nets, treated exactly like clocks. Most FPGAs
> allow using dedicated clock nets for reset - recommended.
>
> * Each clock-domain should have its own reset. The trailing edge of
> the reset signal should be synchronous to the clock and shouldn't
> violate reset-recovery timing for any FF. (use a synchronizer for
> reset - the probability of two FFs stuck in meta-stable state is much
> lower than one or two of a set including tens of thousands FFs in the
> clock-domain).
>
> * Just to make your design clear, use the same signal-name everywhere
> for every reset net (also good practice for clock nets).

--
--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: 65301
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: jim granville <no.spam@designtools.co.nz>
Date: Sat, 24 Jan 2004 12:37:34 +1300
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Pablo,
> 
> Thanks for the opportunity to let us brag a bit:
<snip interesting info>
> Xilinx Advanced Technology
> 
> Our advanced readback and internal access configuration port allows us 
> to actually check all memory cell states to see if anything anywhere has 
> flipped.  We can then locate the exact cell that flipped (ie LUT, BRAM, 
> config latch, etc. and from than know what the susceptibility of each 
> one really is).  We can identify if that bit is used in the customer's 
> design, and what it does.  Because we have had to do this for the 
> military/aerospace community for years, we are able to do this for 
> everyone else who may suspect that they have soft errors.

How much of this is non-invasive - ie can be done with the device
operating, and how much needs it to be halted/paused ?

-jg


Article: 65302
Subject: Re: Xilinx LVDS_25_DT termination issues????
From: johnp3+nospam@probo.com (John Providenza)
Date: 23 Jan 2004 16:18:33 -0800
Links: << >>  << T >>  << A >>
Austin -

Thanks for the feedback.  I REALLY appreciate the feedback
from you and Peter in this newsgroup.

My local FAE is nervous about using the internal DT terminating
resistors at 800 MHz input (400MHz DDR).  He says he's seen
external resistors work fine at this speed, so why tempt fate?

Have you had good performance with the DT style termination at
these speeds?  I'd sure like to get rid of the stubs at these
frequencies!

Thanks!

John P

Austin Lesea <austin@xilinx.com> wrote in message news:<bupm6q$8dh2@cliff.xsj.xilinx.com>...
> John,
> 
> This is a true differential termination (a resistor) that is switched in 
> between + and - inputs.
> 
> No 'issues'.
> 
> Enjoy,
> 
> Austin
> 
> John Providenza wrote:
> > I'm doing a high speed design with 800 MHz LVDS data input into
> > a Virtex2-Pro V2P7 part.  I've looked at the new 'DT' input
> > termination mode for the LVDS standard and looked at the
> > Xilinx Answer Record 17244 for further info.
> > 
> > It sounds like this mode may not have the issues that DCI had.
> > 
> > Does anyone know of any issues with using this input termination
> > mode?
> > 
> > Thanks!
> > 
> > John Providenza

Article: 65303
Subject: Re: Programming and debugging the Altera Cyclone family
From: sraza@altera.com (Sabrina)
Date: 23 Jan 2004 16:31:22 -0800
Links: << >>  << T >>  << A >>
"Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in message news:<4002b0a7$0$227$fa0fcedb@lovejoy.zen.co.uk>...
> Ben Popoola <b.popoola@ntlworld.com> wrote in message
> news:qmkMb.4126$OA3.1018845@newsfep2-win.server.ntli.net...
> 
> > I think that you can also program the EPCS1 via the Cyclone chip itself
> > but I do not know how off head.
> >
> > This might work:
> >
> > (1) Configure the FPGA through the JTAG port.
> > (2) If you have an I/O connection between your logic in the Cyclone and
> > a PC, download your configuration bitstream into the EPCS1 via your
> > logic in the Cyclone.
> > (3) Turn the power off then on. The Cyclone should boot from the EPCS1.
> 
> 
> I don't think it's as easy as this.
> 
> There's an IP block AMSI which a NIOS processor can use to
> acesss/reconfigure an AS device, but this can't easily be
> accessed without the NIOS.
> 
> Details of how it's driven aren't published so it's probably
> not impossible to use, but not easy.
> 
> This seems a daft move by Altera as easy access to the AS
> device allowing in system up-dates would be a good marketing
> point.
> 
> 
Altera has example designs demonstrating EPCS configuration using Nios
in a Cyclone device. These designs come with the Nios Development Kit
and include the software drivers.
Mr. Stewart - I will contact you directly to provide those example
files via email or ftp.

Sabrina Raza
sraza@altera.com

Article: 65304
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 23 Jan 2004 16:34:20 -0800
Links: << >>  << T >>  << A >>
Jim,

It is true in the past that readback while operating caused some issues 
(pre-Virtex).  And even today, LUTRAM is disturbed by readback if it is 
being used at the same time (address is changing).

With Virtex II, II Pro, Spartan 3 we can readback all memory excepting 
LUTRAM/SRL16 while it is operating and not disturb the static values, 
nor disturb the customer design.  In the next generation we have also 
fixed that, and allow for readback while LUTRAM/SRL16 are operating.

Now, of course, using readback on LUTRAM/SRL16 and BRAM doesn't help 
you, as you do not know what it is supposed to be (as it just might be 
changing).

But you can readback the rest of the config memory.  That covers 90% of 
the static cells (excluding BRAM which has a parity bit that can be used 
to see when the BRAM has been upset).  BRAM is also more than 8 times 
less likely to be upset than a static config latch (from actual data in 
Rosetta).

In fact, you can in your design check that all static config bits are 
unchanged by simply reading all of them back and comparing a checksum 
with one calculated when first powered on.

Or, you can imagine making an error check AND correcting "crawler" that 
goes around and fixes any soft errors that might have occurred before 
they affect the customer design.....

Spirit and Opportunity use an even simpler method, which is they 
continually re-program all static memory cells (skipping LUTRAM/SRL16, 
BRAM if necessary) while operating.  Of course they also used full 
triple modular redundancy with voting, too.  That level of reliability 
is only required for applications where it can absolutely NOT ever fail!

If you can integrate these self-test and monitoring features with the 
rest of the system, you can even check BRAM and LUTRAM by stopping the 
processing at strategic moments.

Austin

jim granville wrote:
> Austin Lesea wrote:
> 
>> Pablo,
>>
>> Thanks for the opportunity to let us brag a bit:
> 
> <snip interesting info>
> 
>> Xilinx Advanced Technology
>>
>> Our advanced readback and internal access configuration port allows us 
>> to actually check all memory cell states to see if anything anywhere 
>> has flipped.  We can then locate the exact cell that flipped (ie LUT, 
>> BRAM, config latch, etc. and from than know what the susceptibility of 
>> each one really is).  We can identify if that bit is used in the 
>> customer's design, and what it does.  Because we have had to do this 
>> for the military/aerospace community for years, we are able to do this 
>> for everyone else who may suspect that they have soft errors.
> 
> 
> How much of this is non-invasive - ie can be done with the device
> operating, and how much needs it to be halted/paused ?
> 
> -jg
> 


Article: 65305
Subject: Re: Xilinx LVDS_25_DT termination issues????
From: Ray Andraka <ray@andraka.com>
Date: Fri, 23 Jan 2004 19:40:20 -0500
Links: << >>  << T >>  << A >>
We looked at the DCI for an SDRAM interface.  The DCI slowed down the pins too much to be useful
in that application.   At 400MHz, I suspect you will find the same thing.

John Providenza wrote:

> Austin -
>
> Thanks for the feedback.  I REALLY appreciate the feedback
> from you and Peter in this newsgroup.
>
> My local FAE is nervous about using the internal DT terminating
> resistors at 800 MHz input (400MHz DDR).  He says he's seen
> external resistors work fine at this speed, so why tempt fate?
>
> Have you had good performance with the DT style termination at
> these speeds?  I'd sure like to get rid of the stubs at these
> frequencies!
>
> Thanks!
>
> John P
>
> Austin Lesea ?austin@xilinx.com? wrote in message news:?bupm6q$8dh2@cliff.xsj.xilinx.com?...
> ? John,
> ?
> ? This is a true differential termination (a resistor) that is switched in
> ? between + and - inputs.
> ?
> ? No 'issues'.
> ?
> ? Enjoy,
> ?
> ? Austin
> ?
> ? John Providenza wrote:
> ? ? I'm doing a high speed design with 800 MHz LVDS data input into
> ? ? a Virtex2-Pro V2P7 part.  I've looked at the new 'DT' input
> ? ? termination mode for the LVDS standard and looked at the
> ? ? Xilinx Answer Record 17244 for further info.
> ? ?
> ? ? It sounds like this mode may not have the issues that DCI had.
> ? ?
> ? ? Does anyone know of any issues with using this input termination
> ? ? mode?
> ? ?
> ? ? Thanks!
> ? ?
> ? ? John Providenza

--
--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: 65306
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 23 Jan 2004 19:44:41 -0500
Links: << >>  << T >>  << A >>
For the configuration bits, most of it can be read while the device is being
clocked.  The exception is the block ram contents, and in Virtex, columns
containing SRL16's or CLB RAM.  Not sure if they fixed the problem reading
back the SRL16/CLB Ram columns in VirtexII.  The discovery was close to
virtexII tape-out IIRC.

jim granville wrote:

> Austin Lesea wrote:
> ? Pablo,
> ?
> ? Thanks for the opportunity to let us brag a bit:
> ?snip interesting info?
> ? Xilinx Advanced Technology
> ?
> ? Our advanced readback and internal access configuration port allows us
> ? to actually check all memory cell states to see if anything anywhere has
> ? flipped.  We can then locate the exact cell that flipped (ie LUT, BRAM,
> ? config latch, etc. and from than know what the susceptibility of each
> ? one really is).  We can identify if that bit is used in the customer's
> ? design, and what it does.  Because we have had to do this for the
> ? military/aerospace community for years, we are able to do this for
> ? everyone else who may suspect that they have soft errors.
>
> How much of this is non-invasive - ie can be done with the device
> operating, and how much needs it to be halted/paused ?
>
> -jg

--
--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: 65307
Subject: Xilinx Map & Par time spent
From: "Brannon King" <bking@starbridgesystems.com>
Date: 23 Jan 2004 19:55:53 EST
Links: << >>  << T >>  << A >>
So here's the scenario:

Virtex 2 6000 1152  board (dual Xeon 2.6 Win2k w/ 4GB RAM)
Slice usage: 95%
IOB,BRAM usage: 50%
ISE 6.1 Mapper with -timing, -pr b, -k 8, -ol med as the only params: 39 hr
until the mapper was done, then 1 hr in Par -ub -ol med
All eight timing constraints were met.

ISE 5.2 with the same parameters: 1 hr in Mapper and 17 hr in Par
All eight timing constraints were met.

So the 6.1 tools take twice as long to meet the same timing constraints. I
recognize that on average the 6.1 tools have much better timing because of
the timing in the mapper, and it's impressive that they ran for 40 hours
without crashing, but is it worth the time cost? We've made great strides in
Map/Par time, but 39 hours for one (non-reentrant) file on a fast machine?
Is that average? In that the timing constraints aren't overly rigorous, what
can I do to speed up the Map/Par time? How come no one has written these
tools to run in the Xilinx hardware? Or with some kind of accelerator board?
Thanks for your time.



Article: 65308
Subject: Re: Quartus doesn't work with Pentium Hypertheading!
From: "Paul Leventis \(at home\)" <paul.leventis@utoronto.ca>
Date: Sat, 24 Jan 2004 01:20:59 GMT
Links: << >>  << T >>  << A >>
> Does a way exist for resolving this? I have tried to disable from the PC
> BIOS, the Hypertheading, also this doesn't resolve the problem .


The hyper-threading "problem" is a red herring -- once you disable
hyper-threading in the BIOS, your machine will not use any hyper-threading
functionality and is in effect just a normal P4 processor.  There must be
some other problem with your compile -- see Subroto's post.

Regards,

Paul Leventis
Altera Corp.



Article: 65309
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 23 Jan 2004 18:10:39 -0800
Links: << >>  << T >>  << A >>
Let me answer this in more general terms:
Anything that is stable can be reliably included in the readback, i.e.
configuration bits, LUTs, flip-flops that happen not to change., etc.

For stuff that toggles, it is even conceptually difficult to envision
what to do, and how to interpret the result.Especially with multiple
clock domains.
So, even if we do a prefect job in designing the part, the user would
still be faced with a complex job to specify the capture moment, and
then to interpret the result.

But the simple answer is:
 you can read all static data, without interfering with the operation of
the FPGA...
Peter Alfke
========================
Austin Lesea wrote:
> 
> Jim,
> 
> It is true in the past that readback while operating caused some issues
> (pre-Virtex).  And even today, LUTRAM is disturbed by readback if it is
> being used at the same time (address is changing).
> 
> With Virtex II, II Pro, Spartan 3 we can readback all memory excepting
> LUTRAM/SRL16 while it is operating and not disturb the static values,
> nor disturb the customer design.  In the next generation we have also
> fixed that, and allow for readback while LUTRAM/SRL16 are operating.
> 
> Now, of course, using readback on LUTRAM/SRL16 and BRAM doesn't help
> you, as you do not know what it is supposed to be (as it just might be
> changing).
> 
> But you can readback the rest of the config memory.  That covers 90% of
> the static cells (excluding BRAM which has a parity bit that can be used
> to see when the BRAM has been upset).  BRAM is also more than 8 times
> less likely to be upset than a static config latch (from actual data in
> Rosetta).
> 
> In fact, you can in your design check that all static config bits are
> unchanged by simply reading all of them back and comparing a checksum
> with one calculated when first powered on.
> 
> Or, you can imagine making an error check AND correcting "crawler" that
> goes around and fixes any soft errors that might have occurred before
> they affect the customer design.....
> 
> Spirit and Opportunity use an even simpler method, which is they
> continually re-program all static memory cells (skipping LUTRAM/SRL16,
> BRAM if necessary) while operating.  Of course they also used full
> triple modular redundancy with voting, too.  That level of reliability
> is only required for applications where it can absolutely NOT ever fail!
> 
> If you can integrate these self-test and monitoring features with the
> rest of the system, you can even check BRAM and LUTRAM by stopping the
> processing at strategic moments.
> 
> Austin
> 
> jim granville wrote:
> > Austin Lesea wrote:
> >
> >> Pablo,
> >>
> >> Thanks for the opportunity to let us brag a bit:
> >
> > <snip interesting info>
> >
> >> Xilinx Advanced Technology
> >>
> >> Our advanced readback and internal access configuration port allows us
> >> to actually check all memory cell states to see if anything anywhere
> >> has flipped.  We can then locate the exact cell that flipped (ie LUT,
> >> BRAM, config latch, etc. and from than know what the susceptibility of
> >> each one really is).  We can identify if that bit is used in the
> >> customer's design, and what it does.  Because we have had to do this
> >> for the military/aerospace community for years, we are able to do this
> >> for everyone else who may suspect that they have soft errors.
> >
> >
> > How much of this is non-invasive - ie can be done with the device
> > operating, and how much needs it to be halted/paused ?
> >
> > -jg
> >

Article: 65310
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 23 Jan 2004 23:52:51 -0500
Links: << >>  << T >>  << A >>
Peter,

My understanding is that there is a readback bug for SRL16/CLBRAM
that causes corruption of the user circuit if the column is read while
those elements are being clocked in Virtex, VirtexE, and possibly
VirtexII.  As I recall, it was found right about the time VirtexII was
going into tape-out, and it didn't sound like it would be fixed for
VirtexII.  We had to avoid readback during operation of columns
with SRL16s in it on one of my customer's projects that was destined
for space.  The work-around included clustering the SRL16s to specific
columns and using a different approach to discover configuration faults
in those columns.  My paper "A Low Complexity Method for Detecting
Configuration Upset in SRAM Based FPGAs" goes into a little bit more
detail (the paper is available on my website for download at no charge)
as to the problem and the technique I used to be able to still use the
SRL16's without compromising upset detection.  As I recall, there was
also an issue reading BRAM columns while they were being clocked
because the readback circuits shared some of the user circuit in Virtex.
IIRC, that one was corrected in VirtexII.

The caveat to your statement is then, configuration bits can be read back
while the circuit is operating except for SRL16's CLB_RAM and in
virtex, block RAM as reading columns with those elements while they are
being clocked can corrupt the state of the user circuit.


Peter Alfke wrote:

> Let me answer this in more general terms:
> Anything that is stable can be reliably included in the readback, i.e.
> configuration bits, LUTs, flip-flops that happen not to change., etc.
>
> For stuff that toggles, it is even conceptually difficult to envision
> what to do, and how to interpret the result.Especially with multiple
> clock domains.
> So, even if we do a prefect job in designing the part, the user would
> still be faced with a complex job to specify the capture moment, and
> then to interpret the result.
>
> But the simple answer is:
>  you can read all static data, without interfering with the operation of
> the FPGA...
> Peter Alfke
> ========================
> Austin Lesea wrote:
> >
> > Jim,
> >
> > It is true in the past that readback while operating caused some issues
> > (pre-Virtex).  And even today, LUTRAM is disturbed by readback if it is
> > being used at the same time (address is changing).
> >
> > With Virtex II, II Pro, Spartan 3 we can readback all memory excepting
> > LUTRAM/SRL16 while it is operating and not disturb the static values,
> > nor disturb the customer design.  In the next generation we have also
> > fixed that, and allow for readback while LUTRAM/SRL16 are operating.
> >
> > Now, of course, using readback on LUTRAM/SRL16 and BRAM doesn't help
> > you, as you do not know what it is supposed to be (as it just might be
> > changing).
> >
> > But you can readback the rest of the config memory.  That covers 90% of
> > the static cells (excluding BRAM which has a parity bit that can be used
> > to see when the BRAM has been upset).  BRAM is also more than 8 times
> > less likely to be upset than a static config latch (from actual data in
> > Rosetta).
> >
> > In fact, you can in your design check that all static config bits are
> > unchanged by simply reading all of them back and comparing a checksum
> > with one calculated when first powered on.
> >
> > Or, you can imagine making an error check AND correcting "crawler" that
> > goes around and fixes any soft errors that might have occurred before
> > they affect the customer design.....
> >
> > Spirit and Opportunity use an even simpler method, which is they
> > continually re-program all static memory cells (skipping LUTRAM/SRL16,
> > BRAM if necessary) while operating.  Of course they also used full
> > triple modular redundancy with voting, too.  That level of reliability
> > is only required for applications where it can absolutely NOT ever fail!
> >
> > If you can integrate these self-test and monitoring features with the
> > rest of the system, you can even check BRAM and LUTRAM by stopping the
> > processing at strategic moments.
> >
> > Austin
> >
> > jim granville wrote:
> > > Austin Lesea wrote:
> > >
> > >> Pablo,
> > >>
> > >> Thanks for the opportunity to let us brag a bit:
> > >
> > > <snip interesting info>
> > >
> > >> Xilinx Advanced Technology
> > >>
> > >> Our advanced readback and internal access configuration port allows us
> > >> to actually check all memory cell states to see if anything anywhere
> > >> has flipped.  We can then locate the exact cell that flipped (ie LUT,
> > >> BRAM, config latch, etc. and from than know what the susceptibility of
> > >> each one really is).  We can identify if that bit is used in the
> > >> customer's design, and what it does.  Because we have had to do this
> > >> for the military/aerospace community for years, we are able to do this
> > >> for everyone else who may suspect that they have soft errors.
> > >
> > >
> > > How much of this is non-invasive - ie can be done with the device
> > > operating, and how much needs it to be halted/paused ?
> > >
> > > -jg
> > >

--
--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: 65311
Subject: Re: WTD: info on AMD palce22v10
From: Ralph Malph <noone@yahoo.com>
Date: Sat, 24 Jan 2004 00:32:33 -0500
Links: << >>  << T >>  << A >>
Raivo Nael wrote:
> 
> As much as i know ATT never made their own software for Xilinx
> compatible chips. Why? Do they considered it too costly or got only
> rights to deal with silicon, not the soft?
> 
> It seems to me that in this case software problems were reasons why
> ATT droped this product line. As soon as Xilinx ceased to support 3000
> series, ATT chips also became useless.
> 
> Interesting to know what happened first: ATT deciding that 3000 is too
> oldfashioned to make profit of it or Xilinx droping non-A series
> support and so making ATT chips useless?

I don't think Xilinx "dropped" the XC3000 family, they still sell them
today, AFAIK.  They don't provide design software unless you really need
it.  I believe someone posted here recently that they needed this
software and they got help to reach the right person at Xilinx for
this.  

But you may be partly right about them dropping support for the 3000 to
cut ATT out of *new* Xilinx business.  But then with *every* new
generation, all the FPGA companies want you to design in the latest
parts rather than the old ones.  They know the competition also has new
parts and the old ones won't get design wins... mostly.  

In one case, Altera has a part that is still fully supported for new
designs and has full 5 volt tolerance without having high startup
current issues.  I don't think Xilinx has any current parts like that. 
So I guess an old part could get a design win over even the latest parts
since they no longer have 5 volt tolerance (they almost don't have 3
volt tolerance).

Article: 65312
Subject: Re: xilinx 70% tracking rule
From: Ralph Malph <noone@yahoo.com>
Date: Sat, 24 Jan 2004 00:40:49 -0500
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> 
> > Ralph Malph wrote:
> 
> >>logic cell count.  The last time I checked, counting involved actually
> >>counting things.  Xilinx seems to think that counting logic cells
> >>involves counting and then multiplying by 1.125.
> 
> Why would an engineer be concerned
> about such estimates when he can run a
> synthesis on his design and
> get the *exact utilization* ?
> 
>          -- Mike Treseler

Because some engineers have to consider costs and need to know how large
a part is before it is designed into a board.  Not all FPGAs are used
like ASICs.  Often they are used like FPGAs where designs are added to
the board well after it is in the field.  So the only analysis that can
be done at the time of part selection is paper design based on the
*published* information.  If no one ever needed the info in the data
sheets, why would they publish them?

Article: 65313
Subject: Re: RocketIO evaluation
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 24 Jan 2004 06:51:57 -0000
Links: << >>  << T >>  << A >>
>sorry...i mean i use the rocket IO as receiver only

If you are going to receive something, something else has to
transmit it.  The simplest transmitter you are going to find
is probably on the board you already have.

You may have to build a loop-back connector.

Anyway, I suggest looking for a self-test setup rather than just
something to test the receiver.

-- 
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: 65314
Subject: Re: Altera Active Serial
From: Ben Popoola <b.popoola@ntlworld.com>
Date: Sat, 24 Jan 2004 07:03:06 +0000
Links: << >>  << T >>  << A >>
Khim Bittle wrote:
> hi folks ... when using the Cyclones with the EPCS4 flash
> configuration chip and active serial mode ... I'd like to use the
> extra memory space to store a memory image ... so all I need to do is
> read or write it in a big block .. so yes i have done this with Nios
> but this is too much overhead in a small cyclone device simply to copy
> an image from the flash to an external ram  .. anyone know how to read
> the flash without using nios ?  kb
> 
> 
Hi Khim,
	As I understand things, the Altera flash memory devices are based upon 
standard serial flash devices  (ST microelectronics ?). Hence you would 
program these devices as you would any normal serial memory device. You 
only have yo be careful that you do not overwrite your configuration data.

	The Altera Cyclone data sheets have the relevant information you are 
looking, including the memory maps of the configuration and user spaces.

Ben


Article: 65315
Subject: Re: Random data generator...
From: news@sulimma.de (Kolja Sulimma)
Date: 24 Jan 2004 02:01:35 -0800
Links: << >>  << T >>  << A >>
Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<c57110htvcsi0vlcjcc13cjdsde1rpfage@4ax.com>...
> On Thu, 22 Jan 2004 10:19:12 -0800, Peter Alfke <peter@xilinx.com>
> wrote:
> 
> >David Nyberg wrote:
> >> 
> >> Anybody ever come accross a way to design and build a random high speed
> >> data pattern generator?  It just dawned on me that I'm going to need a
> >> way to test the MUX design I posted to 300MB/s!

> These LFSRs have been designed for testing *serial* data links.
> Experience gained when I was at Agilent indicated that they don't have
> enough transitions to properly stress wide parallel interfaces.
> 
> A combination of LFSR and an alternating all ones / all zeros pattern
> seemed ok.
Lot's of simultaneous transisitions are good for testing against
timing problems due to ground bounce, cross talk and the like.
Another problem you should be aware of, is that for some circuits a
random pattern with 50% propability for one and zero on each bit might
not be a good test. A PCI core with 16 active bits in it's address
decoder for example will only be selected once out of 64k cycles.

But one' can very easily produce random bit's of different
propabilities:
Just make the shift register longer and AND or OR together multiple
shift register bits to produce a single output bit.
AND3 for example gives you a 12.5% prob. for 1.

Kolja Sulimma

Article: 65316
Subject: UCF constraints for DCM outputs?
From: "Kelvin @ SG" <kelvin8157@hotmail.com>
Date: Sat, 24 Jan 2004 18:55:53 +0800
Links: << >>  << T >>  << A >>
Hi, all:

I am using a DCM to multiply my clock by 2.5...In the UCF file, do I define
a Period constraint for
the 2.5X clock or the original input clock?

Thanks for your comments.

Best Regards,
Kelvin



Article: 65317
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: jim granville <no.spam@designtools.co.nz>
Date: Sun, 25 Jan 2004 00:48:59 +1300
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> Peter,
> 
> My understanding is that there is a readback bug for SRL16/CLBRAM
> that causes corruption of the user circuit if the column is read while
> those elements are being clocked in Virtex, VirtexE, and possibly
> VirtexII.  As I recall, it was found right about the time VirtexII was
> going into tape-out, and it didn't sound like it would be fixed for
> VirtexII.  We had to avoid readback during operation of columns
> with SRL16s in it on one of my customer's projects that was destined
> for space.  The work-around included clustering the SRL16s to specific
> columns and using a different approach to discover configuration faults
> in those columns.  My paper "A Low Complexity Method for Detecting
> Configuration Upset in SRAM Based FPGAs" goes into a little bit more
> detail (the paper is available on my website for download at no charge)
> as to the problem and the technique I used to be able to still use the
> SRL16's without compromising upset detection.  As I recall, there was
> also an issue reading BRAM columns while they were being clocked
> because the readback circuits shared some of the user circuit in Virtex.
> IIRC, that one was corrected in VirtexII.
> 
> The caveat to your statement is then, configuration bits can be read back
> while the circuit is operating except for SRL16's CLB_RAM and in
> virtex, block RAM as reading columns with those elements while they are
> being clocked can corrupt the state of the user circuit.

Sounds like that one, if true, needs a fix....
( and an alert -> someone might think they are increasing reliability
by reading back all nodes, and ignoring the 'might change' ones  ) -

>>Austin Lesea wrote:
>>
>>>Jim,
>>>
<snip>
 >>>With Virtex II, II Pro, Spartan 3 we can readback all memory excepting
 >>>LUTRAM/SRL16 while it is operating and not disturb the static values,
 >>>nor disturb the customer design.  In the next generation we have also
 >>>fixed that, and allow for readback while LUTRAM/SRL16 are operating.

  So this fixed, 'next generation' is not Spartan 3, but whatever is 
comming after that ?

>>>Now, of course, using readback on LUTRAM/SRL16 and BRAM doesn't help
>>>you, as you do not know what it is supposed to be (as it just might be
>>>changing).

If that BRAM was storing constants/lookup info (read only), then
I can see a need to verify the table is actually still correct ?

-jg



Article: 65318
Subject: How come NGDBuild derive a clk_36m_tmp/4 clock?
From: "Kelvin @ SG" <kelvin8157@hotmail.com>
Date: Sat, 24 Jan 2004 21:57:25 +0800
Links: << >>  << T >>  << A >>
I am using this DCM module, It is supposed to generate a 36MHz clock,
however NGDBuild gave me this message...How do I explain this strange
behavior?

Best Regards,
Kelvin


INFO:XdmHelpers:851 - TNM "clock", used in period specification "TS_clock",
was
   traced into DCM instance "DCM0". The following new TNM groups and period
   specifications were generated at the DCM output(s):
   CLKFX: TS_clk_36m_tmp_0=PERIOD clk_36m_tmp_0 TS_clock/4.000000 HIGH
50.000000%


IBUFG CLOCK_IN ( .I(clk_40m), .O(clock)  );
DCM DCM0 ( .CLKFB(clock_out), .CLKIN(clock),
   .DSSEN(low),  .PSCLK(low), .PSEN(low),  .PSINCDEC(low),   .RST(low),
   .CLK0(),  .CLK90(),  .CLK180(),  .CLK270(),    .CLK2X(clk0),
.CLK2X180(),
   .CLKDV(), .CLKFX(clk_36m_tmp),  .CLKFX180(), .LOCKED(dcm0_locked),
.PSDONE(),  .STATUS()  );
BUFG CLK_BUF0( .I(clk0),    .O(clock_out)  );
//synthesis translate_off
defparam DCM0.DLL_FREQUENCY_MODE = "LOW";
defparam DCM0.DUTY_CYCLE_CORRECTION = "TRUE";
defparam DCM0.STARTUP_WAIT = "TRUE";
defparam DCM0.DFS_FREQUENCY_MODE = "LOW";
defparam DCM0.CLKFX_DIVIDE = 10;
defparam DCM0.CLKFX_MULTIPLY = 9;
defparam DCM0.CLK_FEEDBACK = "2X";
defparam DCM0.CLKOUT_PHASE_SHIFT = "FIXED";
defparam DCM0.PHASE_SHIFT = 0;
//synthesis translate_on




Article: 65319
Subject: Re: is this a good idea
From: news@sulimma.de (Kolja Sulimma)
Date: 24 Jan 2004 06:14:12 -0800
Links: << >>  << T >>  << A >>
"Jerry" <nospam@nowhere.com> wrote in message news:<vvhf7ii29ntnbf@corp.supernews.com>...
> "Paul" <paulw@mmail.ath.cx> wrote in message

> Watch your simulator. It should have unknown in registers that were not
> initialized.

No, at least for VHDL it should not.
For STD_LOGIC types it should have "uninitialized"=U if no initial
value was given. This is different from "unknown"=X.
As all xilinx flip-flops have an initial value, the VHDL code should
explicitly initialize the registers to '0'. (Or '1', if you use a
register with preset or initialize it to 1 in the UCF file)

For an asic design the registers should be initialized explicitly to
'X'.

That way your simulation should match the behavour of the FPGA/ASIC.

BTW:
As a CAD developer I do not really understand, why I have to set the
power up value in the UCF file when the VHDL line

signal register : std_logic := '1';

tells the synthesis tool all that it needs to know.

Kolja Sulimma

Article: 65320
Subject: xilinx EDK and Webpack 6.x
From: "cwoodring" <cwoodring@cox.net>
Date: Sat, 24 Jan 2004 09:21:32 -0500
Links: << >>  << T >>  << A >>
To all,
    Does anyone know if you can use the EDK with Webpack. I currently have
6.1 release of the ISE environment at work but use the WebPack SW at home
for testing things out.  I'd like to evaluate the EDK at home but I
installed the 6.x version of it and the 6.1 version of Webpack but I get an
error when I start up the EDK XPS about a missing dll and then the GUI will
allow me to go all the way through a tutorial I downloaded setting up a
Microblaze Processor on a Mimic protocard but at the last step the XPS dies
and locks up??

    I initially installed a trial version of the EDK Version 3.1 that I had
on CD and then upgraded from the Website to 6.1. There was some weirdness
doing that but I don't recall details.  The trial version had a trial
version of 5.1 or so of the ISE included but I want to run the latest and
greatest stuff.

  Thanks,

CTW



Article: 65321
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: rk <stellare@NOSPAMPLEASE.erols.com>
Date: 24 Jan 2004 14:23:42 GMT
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

                           [ snip ]

> We are presenting papers at conferences (MAPLD 2003, for example) 
> detailing our results for .5u, .35u, .22u. .18u, .15u, .13u and 90 
> nanometer.  If interested, email me directly, and I will send you the 
> MAPLD ppt presentation.

Here's the presentation, on-line (no paper available that I know of):

   "NSEU Sensitivity of SRAM-based FPGAs"
   Joe Fabula, Austin Lesea, Carl Carmichael, and Saar Drimer
   Xilinx Corp.

   http://klabs.org/richcontent/MAPLDCon03/presentations/c/c5_fabula_s.ppt

-- 
rk, Just an OldEngineer
"For a successful technology, reality must take precedence over public 
relations, for nature cannot be fooled."
-- R. Feynman, Appendix F.

Article: 65322
Subject: Power Cosumption of a Memory Unit
From: nagaraj_c_s@yahoo.com (Nagaraj)
Date: 24 Jan 2004 06:35:59 -0800
Links: << >>  << T >>  << A >>
Hello all,
   I have a basic question. 

1.   How do you find out power consumption (dynamic) of a memory unit?
 Specifically, if I have a DPRAM (one port Write only @ X MHz, other
Read only @ Y MHz), of depth D and width W, what is the power
consumption equation?

   Now one additional question. 

2.  Does the power consumption depend on memory organization? (Rows
and columns can be organized as ... (D/2)x2W, DxW, 2Dx(W/2), ...).

   My input data width is always W and output data width is also W. In
this case if the memory organization is other than DxW, extra
circuitry is required for converting W bits to memory width at the
input and memory width to W bits conversion at the output. Also,
memory write and read frequencies have to be appropriately scaled
according to memory organization. So for answering the second
question, you have to consider "equivalent systems" and compare apples
with apples.

   I do not know whether the problem I have is trivial. In that case
can somebody give me a good reference book where I can get information
about these?

Thanx in advance,
Nagaraj C S

Article: 65323
Subject: Re: UCF constraints for DCM outputs?
From: "Robert Sefton" <rsefton@abc.net>
Date: Sat, 24 Jan 2004 07:05:47 -0800
Links: << >>  << T >>  << A >>
> I am using a DCM to multiply my clock by 2.5...In the UCF file, do I
define
> a Period constraint for
> the 2.5X clock or the original input clock?
>

Kelvin -

You specify the input clock period in the DCM attributes. You can/should
also specify the output clock period in a timespec to constrain your
logic. Like this:

# for the DCM
INST "dcm_inst" CLKIN_PERIOD=25;

# for your logic
NET "clk_out" TNM_NET = "clk_out";
TIMESPEC "TS_CLKOUT" = PERIOD "clk_out" 10 ns HIGH 50 %;

Robert



Article: 65324
Subject: VHDL newbie
From: "Trent R." <rnenna@gmx.de>
Date: Sat, 24 Jan 2004 18:16:21 +0100
Links: << >>  << T >>  << A >>
Hello,

I started now with VHDL....so maybe itīs a stupid Question....
but is there an easy way to increment a bitvector?
For example something like this:

	SIGNAL nano_bin : std_ulogic_vector(31 downto 0);
	IF....THEN
		nano_bin <= nano_bin +1 ;
	END IF;

THX Trent




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