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 65350

Article: 65350
Subject: Re: Spirit on Mars
From: jmoore@xilinx.com (Jason)
Date: 25 Jan 2004 20:51:10 -0800
Links: << >>  << T >>  << A >>
"Pablo Bleyer" <pbleyerN@SPAMembedded.cl> wrote in message news:<4010abf0$1_1@nova.entelchile.net>...
> "Austin Lesea" <austin@xilinx.com> escribió en el mensaje
> news:bup6dl$8dl2@cliff.xsj.xilinx.com...
> > The reason for the failure of other parts could be that they are NOT
> > FPGAs.  FPGAs are manufactured in huge volumes, and are all tested in
> > the qualification for latch up under irradiation.  Many SRAM,s and other
> > products do not have the volume to afford such testing, and in fact
> > recent shrinks of common parts are known to latch up with a single
> > event, and destroy themselves.
> 
>  Interesting. Under what conditions and what kind of tests are Xilinx
> rad-hard FPGAs tested for irradiation? Datasheets usually have too condensed
> information about rad parameters...
> 
>  Regards.

Pablo - they undergo the standard tests....TID per spec 1019.5, SEL
and SEU (Heavy Ion and Proton - Static and Dynamic).  All of the
specifications (from krads to Cross Sections to energies, etc) are
listed in the datasheet.  For more detailed info test results are
published via the Xilinx Single Event Effects Consoritum, which
includes major Aerospace companies, at the typical industry
conferences - NSREC, RADECS and MAPLD mainly.

Thanks
Jason 
Xilinx Mil/Aero Group

Article: 65351
Subject: Re: VHDL newbie
From: Jim Lewis <Jim@SynthWorks.com>
Date: Sun, 25 Jan 2004 21:18:46 -0800
Links: << >>  << T >>  << A >>

Use package numeric_std from IEEE and the type unsigned.

library ieee ;
use ieee.numeric_std.all ;

. . .

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

Currently there is no package that directly supports
the type std_ulogic_vector.   There is a package that
supports std_logic_vector (called std_logic_unsigned).
Some like it, some don't.  The argument is that whenever
possible, use the type unsigned as it contains
documentation in the type.  My thought is that for
somethings (such as testbenches) it is unpractical to not
use std_logic_unsigned (at least until we have something
better from IEEE).

The use of std_logic_unsigned is clear as long as you
never use the package std_logic_signed.

Regards,
Jim
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Trent R. wrote:
> 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
> 


Article: 65352
Subject: How to do with guard bits practically?
From: freelait2000@yahoo.com (Jeff)
Date: 25 Jan 2004 22:15:44 -0800
Links: << >>  << T >>  << A >>
Hi,
Last time I have posted a question about guard bit in CORDIC
algorithm. I have got some good answers from this goupe. When I
programe in C to do a simulation, I still don't understand how I do
with the guard bits.
From one of the papers talking about implementation of CORDIC, it says
the input is 12 bits, internal data paths are 16 plus extra 6 guard
bits. At the input stage adds 6 all-zero guard bit extension. At the
output stage it erases guard bits. And, it also divides two inputs
number by 2 at first to prevent overflow. The internal data are
represented as signed numbers. My question is:

1. What are the differences between the internal 22 (16+6) bits
calculation and 16 bits data plus 6 guard bits extension? Especially I
want to get an example to make this question clear.
2. If the 6 extra guard bits are MSB, to erase them will not destroy
data? There are 9 stages of CORDIC cells in my application. In my
simulation programe I find the high bit in the last stage is at bit 5
(in the guard bits range when I simply use 22 internal bits with there
are 6 bits leave off at the first input data stage).
3. Which book talks about the guard bit? Could you recommend me some?



Thanks in advance.

Article: 65353
Subject: TBUF-PAR-Warning in detail
From: t.bartzick@gmx.net (Thomas Bartzick)
Date: 25 Jan 2004 23:32:05 -0800
Links: << >>  << T >>  << A >>
Hello,

these below are my warning and error-messages:
**********************************************

---<snip!>

WARNING:Place:119 - Unable to find location.  TBUF component I41_1 not placed.
   TBUF "I41_1".
ERROR:Place:120 - There were not enough sites to place all selected components
Phase 6.9 (Checksum:39386fa) REAL time: 30 secs 

Total REAL time to Placer completion: 30 secs 
Total CPU time to Placer completion: 29 secs 

---<snap!>

Best regards,
Thomas.

Article: 65354
(removed)


Article: 65355
Subject: Re: How to do with guard bits practically?
From: freelait2000@yahoo.com (Jeff)
Date: 26 Jan 2004 04:20:44 -0800
Links: << >>  << T >>  << A >>
Sorry for some inaccury description. Following is the corrections.


a. "At every input stage adds 6 all-zero guard bit extension first,
then at its
output it erases all the guard bits."

b. "There are 6 stages of CORDIC cells cascaded in my application."

As my understanding of CORDIC, its vector/rotation is from the MSB.
So, there is no overflow like multiply. I just need consider the
CORDIC rotation gain(1.647)? In this considering, besides the input
data divide 2, why it needs extra 6 guard bits?

BTW, in the reply to my last post, What Ray said about MAC is right. I
found my previous understanding was wrong. In that paper,
multiply-accumulate or divide-accumulate are not performed directly.


Any suggestion is highly appreciated.

Article: 65356
Subject: Re: Tristate buffer
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Mon, 26 Jan 2004 12:22:17 +0000 (UTC)
Links: << >>  << T >>  << A >>
Tullio Grassi <tgrassi@cut_here.mail.cern.ch> wrote:
: Hi,

:  just to simplify the previous reccomandations, I suggest you
: instantiate the primitive IOBUF at the xilinx pins.

Instantiate Entities are normally manufacturer dependant. Normal verilog
code has better chances to be manufacturer indpendant.

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

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

Article: 65357
(removed)


Article: 65358
Subject: Re: Cascading of many stages of DCM...
From: "Nial Stewart" <nial@nialstewartdevelopments.co.uk>
Date: Mon, 26 Jan 2004 13:14:32 -0000
Links: << >>  << T >>  << A >>

"Kelvin @ SG" <kelvin8157@hotmail.com> wrote in message
news:bv1hed$8kd$1@mawar.singnet.com.sg...
> Yeah, yours is the better approach...However I am converting an ASIC
design
> into FPGA...
> there are a few megabytes of source codes...sigh...that is the problem...

If you are familiar with any of the scripting languages you
should be able to write something which looks for the
lower clocks, changes them to the 36Mhz clock and inserts
a pair of lines with the relevant clock enable.

It might be a good idea to get it to display what
it's done and get you to confirm it, or add comments
above every changed line with an easily found search
string so you can quickly check what it's done.

Give it a _thorough_ visial inspection and make sure
it's _well_ simulated to check you haven't messed up.

Nial

------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
Cyclone based 'Easy PCI' proto board
www.nialstewartdevelopments.co.uk



Article: 65359
(removed)


Article: 65360
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: usenet_10@stanka-web.de (Thomas Stanka)
Date: 26 Jan 2004 05:38:05 -0800
Links: << >>  << T >>  << A >>
Hi,

Austin Lesea <austin@xilinx.com> wrote:
> radioactive after spending so much time in the beam.  Oh, and none of 
> them ever suffer any damage -- they power on and meet all specs after 
> hundred and hundreds of rads.

What about 100 krad? I'm just curios. In our company we have problems
to use devices without qualification for at least 30krad.

> > Analysis
> 
> This is a standard procedure, and we are the ONLY company that actually 
> KNOWS how our parts are affected by cosmic neutron showers, alpha 
> particles, etc in REAL applications from sea level to 60,000 feet (I 
> can't talk about the programs we have for mil/aerospace until you sign 
> an NDA).

This seems a bit too overconfident.
Actually I didn't know your effort, but I know the effort Actel is
doing for its devices. And they prove very sufficient analyses beside
the analyses spacecompanies are doing with Actel Fpgas for themself.
 
> Competitors
> 
> Other companies out there are in a state of "blissful ignorance" and 
> when (not if) they start to have customers complain of failures, they 
> will be saying, "gee, we don't see anything (because we can't), must be 
> something you are doing."  Why can't they see anything when a customer 
> complains?

I'm shure you wouldn't tell names, but did you _ever_ tried the
hotline of another fpga vendor? Tell us a bit about your experience.
I'm very satisfied the way Actel is reacting on complaints. 



bye Thomas

Article: 65361
(removed)


Article: 65362
Subject: Re: How to do with guard bits practically?
From: Ray Andraka <ray@andraka.com>
Date: Mon, 26 Jan 2004 11:03:50 -0500
Links: << >>  << T >>  << A >>
It sounds like they are calling the added LSBs guard bits.  CORDIC has a
gain of 1.647.  Assuming the input is left justified, it needs to be right
shifted (divided by 2) to accommodate the gain.  I am sure what they are
calling guard bits are extra bits tacked onto the LSBs to absorb the
rounding errors that happen inside the CORDIC as a consequence of the
right shifts (I am also accustomed to 'guard bits' referring to extra sign
bits, not added LSBs).

SO what they are doing is adding extra LSBs to absorb the
truncation/rounding errors that inevitably happen because of the right
shifted cross terms in the CORDIC algorithm, however for 6 iterations, 6
guard bits is excessive.  If you look at the maximum error introduced, it
is +/-0.5 at each iteration if the iteration sum/difference is rounded.
Summing that up over the iterations you get a bounded error that is
related to log2(iterations).  This can be dealt with by carrying enough
extra precision through the computation to permit you to truncate off the
error at the output.

Jeff wrote:

> Sorry for some inaccury description. Following is the corrections.
>
> a. "At every input stage adds 6 all-zero guard bit extension first,
> then at its
> output it erases all the guard bits."
>
> b. "There are 6 stages of CORDIC cells cascaded in my application."
>
> As my understanding of CORDIC, its vector/rotation is from the MSB.
> So, there is no overflow like multiply. I just need consider the
> CORDIC rotation gain(1.647)? In this considering, besides the input
> data divide 2, why it needs extra 6 guard bits?
>
> BTW, in the reply to my last post, What Ray said about MAC is right. I
> found my previous understanding was wrong. In that paper,
> multiply-accumulate or divide-accumulate are not performed directly.
>
> Any suggestion is highly appreciated.

--
--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: 65363
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 26 Jan 2004 08:35:37 -0800
Links: << >>  << T >>  << A >>
Jim,

See below,

Austin


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

Yes.

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

If BRAM or LUTRAM is storing constants, then you may include it in the 
readback verify.

> 
> -jg
> 


Article: 65364
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 26 Jan 2004 08:45:00 -0800
Links: << >>  << T >>  << A >>
Thomas,

You need to contact one of our FAEs!

See below,

Austin

Thomas Stanka wrote:

> Hi,
> 
> Austin Lesea <austin@xilinx.com> wrote:
> 
>>radioactive after spending so much time in the beam.  Oh, and none of 
>>them ever suffer any damage -- they power on and meet all specs after 
>>hundred and hundreds of rads.
> 
> 
> What about 100 krad? I'm just curios. In our company we have problems
> to use devices without qualification for at least 30krad.

Better than 100Krad.  Ask for the FAE for radiation test results.

> 
> 
>>>Analysis
>>
>>This is a standard procedure, and we are the ONLY company that actually 
>>KNOWS how our parts are affected by cosmic neutron showers, alpha 
>>particles, etc in REAL applications from sea level to 60,000 feet (I 
>>can't talk about the programs we have for mil/aerospace until you sign 
>>an NDA).
> 
> 
> This seems a bit too overconfident.
> Actually I didn't know your effort, but I know the effort Actel is
> doing for its devices. And they prove very sufficient analyses beside
> the analyses spacecompanies are doing with Actel Fpgas for themself.

No, it is not.  Some competitors are spreading information that is 
patently false, and misleading (there, I said it).  They compare us with 
commercial SRAM, which is false and misleading, as we are not commercial 
SRAM, have nothing to do with commercial SRAM, and do not use commercial 
SRAM technology or cells.  We use our own design cmos configuration 
latches, which are shown to be 20X to 100X more robust for the same 
technology.  As for their own tests, they only talk about their fuses, 
and not their logic, or flip flops.  How fair is that?  With a part that 
is one tenth the size of ours.  Tens times smaller, is also ten times 
fewer upsets.

How to lie with numbers.

>  
> 
>>Competitors
>>
>>Other companies out there are in a state of "blissful ignorance" and 
>>when (not if) they start to have customers complain of failures, they 
>>will be saying, "gee, we don't see anything (because we can't), must be 
>>something you are doing."  Why can't they see anything when a customer 
>>complains?
> 
> 
> I'm shure you wouldn't tell names, but did you _ever_ tried the
> hotline of another fpga vendor? Tell us a bit about your experience.
> I'm very satisfied the way Actel is reacting on complaints. 
> 

OK, let us try it:  Competitors?  What is your cross section for logic? 
  Cross section for flip flops?  Cross section for config bits, RAM?  Go 
ahead, let us all know your data.  Ours is very simple, you can not 
upset our logic or flip flops as they are so heavily loaded.  And the 
rest of our data is in the power point MAPLD presentation that RK has so 
kindly provided the link to.



Article: 65365
Subject: Re: Tristate buffer
From: Bassman59a@yahoo.com (Andy Peters)
Date: 26 Jan 2004 11:12:47 -0800
Links: << >>  << T >>  << A >>
Tullio Grassi <tgrassi@cut_here.mail.cern.ch> wrote in message news:<Pine.LNX.4.44.0401260218490.15967-100000@lxplus090.cern.ch>...
> Hi,
> 
>  just to simplify the previous reccomandations, I suggest you
> instantiate the primitive IOBUF at the xilinx pins.

1) The original poster wanted to use internal tristates.

2) All of the current synthesis tools infer the right sort of buffers,
so there's no need to hand-instantiate them.

--a

Article: 65366
Subject: Re: Problem with TBUF-Placing
From: bret.wade@xilinx.com (Bret Wade)
Date: 26 Jan 2004 11:15:14 -0800
Links: << >>  << T >>  << A >>
t.bartzick@gmx.net (Thomas Bartzick) wrote in message news:<cdd36e13.0401251931.2f3cb1c7@posting.google.com>...
> Hello everybody!
> 
> I have a problem with placing my tbuf-elements.
> Modules using bus operations are coupled to top-level switching them
> to a bidirectional bus. See, like this:
> 
> ---<snip!>
> 
> entity my_struct is port (
>    ...
>    BD : inout std_logic_vector(15 downto 0);
>    ...);
> end my_struct;
> 
> architecture Behavioral of my_struct is
> ...
> signal de, di : std_logic_vector(15 downto 0);
> ...
> begin
> ...
> my_external_connector : process (de, BD, ext_read)
> begin
>    if (ext_read = '1') then
>       BD <= de;
>       de <= "ZZZ...Z";
>    else
>       BD <= "ZZZ...Z";
>       de <= BD;
>    end if;
> end process;
> ...
> mod_databus_write_sync : SYNC_2xFF port map (
>    I => de,
>    O => di);
> ...
> my_module : SOME_MODULE port map (
>    DIN => di,
>    DOUT => internal_output,
>    CS => ...,
>    ...);
> 
> my_toplevel_bus_read_process: process (internal_output,
> read_condition)
> begin
>    if (read_condition = '1') then
>       de <= internal_output;
>    else
>       de <= "ZZZ...Z";
>    end if;
> end process;
> 
> end Behavioral;
> 
> ---<snap!>
> Additional Note:
> ****************
> There are about 3 upto 5 internal modules which make use of this
> structure.
> So we get a maximum of 5x16 = 80 tristate buffer lines, probably some
> more.
> ****************
> 
> Synthezising, Translation and Mapping is always fine, but since the
> implementation process comes to PAR, the placer stops after a couple
> of warnings and at least one error like this:
> 
> ---<snip!>
> 
> ... WARNING! Unable to place TBUF of module <#1>!
> ...
> ... WARNING! Unable to place TBUF of module <#n>!
> ...
> ... ERROR! Placing was not complete!
> ...
> 
> ---<snap!>
> 
> I have read on XILINX support pages, that this problem can be worked
> around by using AREA_GROUP constraints. If I have understood this in
> the right way, the constraints will show the placer how I would like
> to layout the tristate buffers. But all I can choose in ISE for
> SPARTANII are Row and Column-statements, for which I have no idea how
> to use them in a proper way.
> 
> I am using XILINX Webpack ISE 6.1 with a SPARTANII (-5) architecture.
> Help or at least some hints would be very appreciated!
> 
> Bye,
> Thomas.


Hello Thomas,

When considering TBUF placement issues, it's necessary to understand
the placement limitations of the TBUF sets as a whole. How large a set
can the device handle? How many total sets of a particular size can it
handle? These are limitations that come into play long before the
total number of TBUF sites available becomes a factor.

Spartan-II devices can not handle multi-row TBUF placement within a
set (Virtex-II can) so the largest possible TBUF set is equal to the
number of columns in the device. The TBUF long lines can be segmented
in groups of four TBUFs, so the number of sites consumed by each set
should be rounded up to a factor of four, then the total number of
possible sets calculated. For example, if the set size is greater than
half the number of TBUFs on a long line, then the number of possible
sets is equal to two times the number of rows (two TBUFs per CLB),
even though TBUF site utilization may only be slightly greater than
50%.

If you're unsure of the size of your TBUF sets and the number of sets,
see the following Answer record for a perl script that can be used to
count them:
http://support.xilinx.com/techdocs/2872.htm

Regarding constraining TBUF placement, it's often enough to LOC a
single TBUF from each set to a site on a particular longline. The rest
of the TBUFs in the set are then implicitly LOC'd to the same long
line.

One possibility is to allow Map to transform some of the TBUFs to
slice logic by using the -tx switch.

Regards,
Bret

Article: 65367
Subject: CFP: Evolvable Hardware 2004
From: eh-2004@ehw.jpl.nasa.gov (EH-2004)
Date: 26 Jan 2004 11:17:03 -0800
Links: << >>  << T >>  << A >>
Dear Colleague,

Please find below information on the Poster Sessions
(Regular and Group) of the 2004 NASA/DoD Conference
on Evolvable Hardware. Please visit the Conference
web-site at:

http://ehw.jpl.nasa.gov/events/nasaeh04

for more information about EH-2004.

With best regards

Ricardo S. Zebulum
David Gwaltney
Gregory Hornby
Didier Keumeulen
Jason Lohn
Adrian Stoica

-------------------------------------------------

SUBMISSION OF  SHORT PAPERS (REGULAR POSTERS)

Prospective authors (who did not submit an abstract in
the full-paper deadline) are invited to submit the
electronic version of their short  paper (ie PS, PDF,
MSWord) by email to eh-2004@cism.jpl.nasa.gov . The
paper is limited to 4 pages and should be submitted in
single-spaced, 10 point type on a 8.5" X 11" or
equivalent paper with 1" margins on all sides. Each
submission should contain the following items:
(1) title of paper, (2) author name(s), (3) first
author physical address, (4) first author e-mail
address, (5) first author phone number, (6) a maximum
200 words abstract (7) the text of the paper, and (8)
references.
Short-papers should be submitted by January, 31st.
Accepted short papers will be published in the
conference proceedings and presented as  REGULAR
POSTERS.

SUBMISSION OF  GROUP POSTERS

In addition to the oral and regular poster
presentations, the 2004 NASA/DoD Conference on
Evolvable Hardware will also include a Group Poster
session, similarly to the one of the previous years.
Each research group is invited to prepare a poster
describing the research performed by their group.

If you are interested, please  e-mail  to
eh-2004@cism.jpl.nasa.gov
a one-page abstract describing your group poster by
March, 5th, 2004,
so that your group poster can be referenced in the
Conference Proceedings.

The abstract submission should contain the following
items:
(1) title of poster,
(2) Researchers' name(s),
(3) Research  Group web address,
(4) Research  Group physical address,
(5) a maximum 200 words describing poster contents

Article: 65368
Subject: isp Cable for Lattice CPLD
From: "Mario Ivancic" <mario.i@teol.net>
Date: Mon, 26 Jan 2004 20:43:27 +0100
Links: << >>  << T >>  << A >>
Hi!
I would like to build isp cable for lattice CPLD (ispLSI 1016), but I
don't know how.
Can you help me?

Best Regards,
                        Mario



Article: 65369
Subject: Re: How to do with guard bits practically?
From: freelait2000@yahoo.com (Jeff)
Date: 26 Jan 2004 12:12:45 -0800
Links: << >>  << T >>  << A >>
Thanks, Ray.
Your reply is always right and accurate. I owe you a lot!
Sorry again for my incomplete description. There are 22 iterations in
our CORDIC cells. So, the 6 LSB guard bits are reasonable.


Have a good day!

Article: 65370
Subject: Re: changing values in a fifo
From: pklacka@trexenterprises.com (Patrick Klacka)
Date: 26 Jan 2004 12:16:54 -0800
Links: << >>  << T >>  << A >>
jim granville <no.spam@designtools.co.nz> wrote...

>   We need some more info on peak/average Read and Change stream rates, 
> and likely 'change depth'.

data is 8 bits, fifo is 512 entries, reading from the fifo happens
once every 10 clock cycles, a change happens approx. every 10th time,
and the average change depth is 2.

>   You can either change on read, and iterate until the change stack
> stops changes, which will be HW frugal, but will have a finite settling 
> time. ( similar to a linked-list in SW )

Yes, this is what I am currently doing. For situations where change
depth is 2 or less, this works fine. For change depths of 3 or more, I
have to buffer the incoming data.

>   Or, you can change all in-situ, but that is also likely to have a 
> finite settling time, as the delta-list will have to arrive 
> sequentially, but maybe at a much lower average rate.
>   This will read faster, but consume much more HW.
> So it's like any parallel/serial trade off: HW vs bandwidth.

I'm hoping for some clever solution that uses this method -
unfortunately the best I could come up with involved too much hardware
- leaving no room for anything else. If there was a way to implement
this smarter, I'm interested!
 
>   If the change-list stream rate is slow, you could do a combination of 
> table correct {fast, but one-deep), and interleaved scan change,
> (slower, but will recurse).
>   Thus the FIFO becomes a bit like video memory, where one task 
> scans/changes and the other reads.
>   It would need "pause" ability, for when/if too many changes arrive
> for the change paths to settle.

I've considered this approach, and if you can figure out a way to make
it work, that would be great. The problem I had was that many values
could change to the same value, eliminating the possibility of using
another linked-list (reverse direction from the initial solution) to
iterate through the changes in the lookup-table.

Article: 65371
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: Ray Andraka <ray@andraka.com>
Date: Mon, 26 Jan 2004 16:15:01 -0500
Links: << >>  << T >>  << A >>
Austin,

Are you sure this is true for BRAM?  As I understood it, the readback logic for
the BRAM in virtex is shared with part of the operational logic and you will
corrupt a user read if readback is performed on a BRAM while a user read is also
happening, ie, you need to either shut down the clock or have the user circuit
ignore read data.  I'm hoping this was not conveyed to me properly, but my
source was rather emphatic (source was involved with the radiation testing at
LANL).

Austin Lesea wrote:

>
> >
> > If that BRAM was storing constants/lookup info (read only), then
> > I can see a need to verify the table is actually still correct ?
>
> If BRAM or LUTRAM is storing constants, then you may include it in the
> readback verify.
>
> >
> > -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: 65372
Subject: Re: Tristate buffer
From: Ray Andraka <ray@andraka.com>
Date: Mon, 26 Jan 2004 16:19:41 -0500
Links: << >>  << T >>  << A >>
The tools are horrible at placing the internal tristates.  Putting LOCs on them within the code is one *very* good reason to
instantiate them.

Andy Peters wrote:

> Tullio Grassi <tgrassi@cut_here.mail.cern.ch> wrote in message news:<Pine.LNX.4.44.0401260218490.15967-100000@lxplus090.cern.ch>...
> > Hi,
> >
> >  just to simplify the previous reccomandations, I suggest you
> > instantiate the primitive IOBUF at the xilinx pins.
>
> 1) The original poster wanted to use internal tristates.
>
> 2) All of the current synthesis tools infer the right sort of buffers,
> so there's no need to hand-instantiate them.
>
> --a

--
--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: 65373
Subject: Re: How to do with guard bits practically?
From: Ray Andraka <ray@andraka.com>
Date: Mon, 26 Jan 2004 16:21:08 -0500
Links: << >>  << T >>  << A >>
Where should I send the invoice?  ;-)

Glad to have been able to help.

Jeff wrote:

> Thanks, Ray.
> Your reply is always right and accurate. I owe you a lot!
> Sorry again for my incomplete description. There are 22 iterations in
> our CORDIC cells. So, the 6 LSB guard bits are reasonable.
>
> Have a good day!

--
--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: 65374
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 26 Jan 2004 14:08:52 -0800
Links: << >>  << T >>  << A >>
Ray,

As we all know, I am certainly not perfect, so I could be wrong here.  I 
am checking.  I was pretty confident that changing the address while 
trying to read hte LUTs affected the contents as they have to share 
circuitry, but the BRAM is a two port plus the config access, or really 
a three port memory as the addressing of the config is independent.

I will post as soon as I know for sure....

Austin

Ray Andraka wrote:

> Austin,
> 
> Are you sure this is true for BRAM?  As I understood it, the readback logic for
> the BRAM in virtex is shared with part of the operational logic and you will
> corrupt a user read if readback is performed on a BRAM while a user read is also
> happening, ie, you need to either shut down the clock or have the user circuit
> ignore read data.  I'm hoping this was not conveyed to me properly, but my
> source was rather emphatic (source was involved with the radiation testing at
> LANL).
> 
> Austin Lesea wrote:
> 
> 
>>>If that BRAM was storing constants/lookup info (read only), then
>>>I can see a need to verify the table is actually still correct ?
>>
>>If BRAM or LUTRAM is storing constants, then you may include it in the
>>readback verify.
>>
>>
>>>-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
> 
> 




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