Spirit on Mars

[Austin Lesea]

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.

 

[Ray Andraka]

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

 

[Austin Lesea]

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

 

[Ray Andraka]

Thanks, I appreciate it. It would be helpful to have a comprehensive readback
appnote that detailed all of the gotchas, both the ones that are by design and the
'ah-shits'. I know we stumbled on one or two during some of the radiation testing
experiments. In any event, I haven't seen anything that documents it as a complete
package. Readback induced problems can be subtle, and I imagine could be a nightmare
to diagnose without the nice patterns we were testing with. It would be very
beneficial to have all the data available to anyone who is attempting it. I'm once
again running into a "if you show me the documentation, I'll believe you"' situations
once again.

Austin Lesea wrote:

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

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

 

[Austin Lesea]

Ray,

I was correct (still correct). Readback does not corrupt BRAM contents.
But the config logic does take over the control of BRAM, so the user
may not see what they expect while you are reading back (takes total
control of ports A and B).

I agree that readback has not been comprehensively described, and that
is something that we are working on, since reading back is now becoming
so useful and interesting.

Austin

Ray Andraka wrote:

Thanks, I appreciate it. It would be helpful to have a comprehensive readback
appnote that detailed all of the gotchas, both the ones that are by design and the
'ah-shits'. I know we stumbled on one or two during some of the radiation testing
experiments. In any event, I haven't seen anything that documents it as a complete
package. Readback induced problems can be subtle, and I imagine could be a nightmare
to diagnose without the nice patterns we were testing with. It would be very
beneficial to have all the data available to anyone who is attempting it. I'm once
again running into a "if you show me the documentation, I'll believe you"' situations
once again.

Austin Lesea wrote:


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




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

 

[Ray Andraka]

Austin,

I don't think I said it corrupted the contents. I thought I said it corrupted the user
read of the contents. The point is, you can't read the BRAM while the user circuit is
running without messing up the user function. You either need to stop the clock, or the
user circuit has to somehow know it can't expect good data from the BRAM and deal with it
accordingly. One work around would be to use ECC and spread the read word width over
multiple BRAMs situated in different columns. Again, the designer has to be aware that
this behavior happens during readback. I don't think this particular one was documented
when we were looking at it, even though it was apparently an intentional behavior.

In the case of CLBRAM or SRL16's, one must be even more careful, because there, a readback
at the wrong time can actually corrupt the contents rather than just the read value. I
believe that one is a problem if the user circuit is changing the lut content (eg clocking
with WE='1') while a readback of that cell is occuring. That one seemed like it was not an
intentional behavior, and I've yet to see it documented anywhere. I've had two customers
run into this one, fortunately with the second one as soon as they told me that they were
doing readback, I knew what the problem was.

Keep up the good work. BTW, what is the latest on availability dates for the QPRO version
(space qual'd) virtexII? I've got a project right now where a V2 would save a bunch of
headache, but it has to be real relatively soon in order to make the launch schedule. I
can use which ever one comes out first. The design is currently slated for a pair of
V1000's, only because of the internal memory requirements. 75% of the logic in the V1000
prototype is SRL16's used as a delay buffer because we used up the BRAMs.


Austin Lesea wrote:

Ray,

I was correct (still correct). Readback does not corrupt BRAM contents.
But the config logic does take over the control of BRAM, so the user
may not see what they expect while you are reading back (takes total
control of ports A and B).

I agree that readback has not been comprehensively described, and that
is something that we are working on, since reading back is now becoming
so useful and interesting.

Austin

Ray Andraka wrote:
Thanks, I appreciate it. It would be helpful to have a comprehensive readback
appnote that detailed all of the gotchas, both the ones that are by design and the
'ah-shits'. I know we stumbled on one or two during some of the radiation testing
experiments. In any event, I haven't seen anything that documents it as a complete
package. Readback induced problems can be subtle, and I imagine could be a nightmare
to diagnose without the nice patterns we were testing with. It would be very
beneficial to have all the data available to anyone who is attempting it. I'm once
again running into a "if you show me the documentation, I'll believe you"' situations
once again.

Austin Lesea wrote:


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




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

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

 

[Jason]

Ray,
The devices will be release by the end of Q1 (the
2V1000/2V3000/2V6000) - the only gating item is the completion of the
package qual. Email me directly for more information...

Thanks
Jason Moore
Xilinx Mil/Aero Division

Ray Andraka <ray@andraka.com> wrote in message news:<4015C304.23292891@andraka.com>...

Austin,

I don't think I said it corrupted the contents. I thought I said it corrupted the user
read of the contents. The point is, you can't read the BRAM while the user circuit is
running without messing up the user function. You either need to stop the clock, or the
user circuit has to somehow know it can't expect good data from the BRAM and deal with it
accordingly. One work around would be to use ECC and spread the read word width over
multiple BRAMs situated in different columns. Again, the designer has to be aware that
this behavior happens during readback. I don't think this particular one was documented
when we were looking at it, even though it was apparently an intentional behavior.

In the case of CLBRAM or SRL16's, one must be even more careful, because there, a readback
at the wrong time can actually corrupt the contents rather than just the read value. I
believe that one is a problem if the user circuit is changing the lut content (eg clocking
with WE='1') while a readback of that cell is occuring. That one seemed like it was not an
intentional behavior, and I've yet to see it documented anywhere. I've had two customers
run into this one, fortunately with the second one as soon as they told me that they were
doing readback, I knew what the problem was.

Keep up the good work. BTW, what is the latest on availability dates for the QPRO version
(space qual'd) virtexII? I've got a project right now where a V2 would save a bunch of
headache, but it has to be real relatively soon in order to make the launch schedule. I
can use which ever one comes out first. The design is currently slated for a pair of
V1000's, only because of the internal memory requirements. 75% of the logic in the V1000
prototype is SRL16's used as a delay buffer because we used up the BRAMs.


Austin Lesea wrote:

Ray,

I was correct (still correct). Readback does not corrupt BRAM contents.
But the config logic does take over the control of BRAM, so the user
may not see what they expect while you are reading back (takes total
control of ports A and B).

I agree that readback has not been comprehensively described, and that
is something that we are working on, since reading back is now becoming
so useful and interesting.

Austin

Ray Andraka wrote:
Thanks, I appreciate it. It would be helpful to have a comprehensive readback
appnote that detailed all of the gotchas, both the ones that are by design and the
'ah-shits'. I know we stumbled on one or two during some of the radiation testing
experiments. In any event, I haven't seen anything that documents it as a complete
package. Readback induced problems can be subtle, and I imagine could be a nightmare
to diagnose without the nice patterns we were testing with. It would be very
beneficial to have all the data available to anyone who is attempting it. I'm once
again running into a "if you show me the documentation, I'll believe you"' situations
once again.

Austin Lesea wrote:


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




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



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

 

[Austin Lesea]

Ray,

Excellent summary of the operation. All perfectly correct.

V2P QPRO is still in progress, as we were "in the beam" at LANSCE just
last week. So far, so good.

Austin

Ray Andraka wrote:

Austin,

I don't think I said it corrupted the contents. I thought I said it corrupted the user
read of the contents. The point is, you can't read the BRAM while the user circuit is
running without messing up the user function. You either need to stop the clock, or the
user circuit has to somehow know it can't expect good data from the BRAM and deal with it
accordingly. One work around would be to use ECC and spread the read word width over
multiple BRAMs situated in different columns. Again, the designer has to be aware that
this behavior happens during readback. I don't think this particular one was documented
when we were looking at it, even though it was apparently an intentional behavior.

In the case of CLBRAM or SRL16's, one must be even more careful, because there, a readback
at the wrong time can actually corrupt the contents rather than just the read value. I
believe that one is a problem if the user circuit is changing the lut content (eg clocking
with WE='1') while a readback of that cell is occuring. That one seemed like it was not an
intentional behavior, and I've yet to see it documented anywhere. I've had two customers
run into this one, fortunately with the second one as soon as they told me that they were
doing readback, I knew what the problem was.

Keep up the good work. BTW, what is the latest on availability dates for the QPRO version
(space qual'd) virtexII? I've got a project right now where a V2 would save a bunch of
headache, but it has to be real relatively soon in order to make the launch schedule. I
can use which ever one comes out first. The design is currently slated for a pair of
V1000's, only because of the internal memory requirements. 75% of the logic in the V1000
prototype is SRL16's used as a delay buffer because we used up the BRAMs.


Austin Lesea wrote:


Ray,

I was correct (still correct). Readback does not corrupt BRAM contents.
But the config logic does take over the control of BRAM, so the user
may not see what they expect while you are reading back (takes total
control of ports A and B).

I agree that readback has not been comprehensively described, and that
is something that we are working on, since reading back is now becoming
so useful and interesting.

Austin

Ray Andraka wrote:

Thanks, I appreciate it. It would be helpful to have a comprehensive readback
appnote that detailed all of the gotchas, both the ones that are by design and the
'ah-shits'. I know we stumbled on one or two during some of the radiation testing
experiments. In any event, I haven't seen anything that documents it as a complete
package. Readback induced problems can be subtle, and I imagine could be a nightmare
to diagnose without the nice patterns we were testing with. It would be very
beneficial to have all the data available to anyone who is attempting it. I'm once
again running into a "if you show me the documentation, I'll believe you"' situations
once again.

Austin Lesea wrote:



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




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




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

 

[Jim Granville]

This was an interesting topic, so I've tagged it with a better title
than 'Spirit on Mars...' for later searchers
-jg

Austin Lesea wrote:

Ray,

Excellent summary of the operation. All perfectly correct.

V2P QPRO is still in progress, as we were "in the beam" at LANSCE just
last week. So far, so good.

Austin

Ray Andraka wrote:

Austin,

I don't think I said it corrupted the contents. I thought I said it
corrupted the user
read of the contents. The point is, you can't read the BRAM while the
user circuit is
running without messing up the user function. You either need to stop
the clock, or the
user circuit has to somehow know it can't expect good data from the
BRAM and deal with it
accordingly. One work around would be to use ECC and spread the read
word width over
multiple BRAMs situated in different columns. Again, the designer has
to be aware that
this behavior happens during readback. I don't think this particular
one was documented
when we were looking at it, even though it was apparently an
intentional behavior.

In the case of CLBRAM or SRL16's, one must be even more careful,
because there, a readback
at the wrong time can actually corrupt the contents rather than just
the read value. I
believe that one is a problem if the user circuit is changing the lut
content (eg clocking
with WE='1') while a readback of that cell is occuring. That one
seemed like it was not an
intentional behavior, and I've yet to see it documented anywhere.
I've had two customers
run into this one, fortunately with the second one as soon as they
told me that they were
doing readback, I knew what the problem was.

Keep up the good work. BTW, what is the latest on availability dates
for the QPRO version
(space qual'd) virtexII? I've got a project right now where a V2
would save a bunch of
headache, but it has to be real relatively soon in order to make the
launch schedule. I
can use which ever one comes out first. The design is currently
slated for a pair of
V1000's, only because of the internal memory requirements. 75% of the
logic in the V1000
prototype is SRL16's used as a delay buffer because we used up the BRAMs.


Austin Lesea wrote:


Ray,

I was correct (still correct). Readback does not corrupt BRAM contents.
But the config logic does take over the control of BRAM, so the user
may not see what they expect while you are reading back (takes total
control of ports A and B).

I agree that readback has not been comprehensively described, and that
is something that we are working on, since reading back is now becoming
so useful and interesting.

Austin

Ray Andraka wrote:

Thanks, I appreciate it. It would be helpful to have a
comprehensive readback
appnote that detailed all of the gotchas, both the ones that are by
design and the
'ah-shits'. I know we stumbled on one or two during some of the
radiation testing
experiments. In any event, I haven't seen anything that documents
it as a complete
package. Readback induced problems can be subtle, and I imagine
could be a nightmare
to diagnose without the nice patterns we were testing with. It
would be very
beneficial to have all the data available to anyone who is
attempting it. I'm once
again running into a "if you show me the documentation, I'll believe
you"' situations
once again.

Austin Lesea wrote:



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




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




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

 

[Ralph Malph]

Wow Austin, you really should cut down on the caffeine!!!



Austin Lesea wrote:

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.

 

[Austin Lesea]

Ralph,

Would you believe I drink decaf? Hard to imagine.

Austin



Ralph Malph wrote:

Wow Austin, you really should cut down on the caffeine!!!



Austin Lesea wrote:

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.

 

[Ralph Malph]

Yes it is hard to believe sometimes...


Austin Lesea wrote:

Ralph,

Would you believe I drink decaf? Hard to imagine.

Austin

Ralph Malph wrote:
Wow Austin, you really should cut down on the caffeine!!!



Austin Lesea wrote:

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.

 

[Uwe Bonnes]

Ralph Malph <noone@yahoo.com> wrote:
: Yes it is hard to believe sometimes...


Ralph,

is it really needed to full quote 90 lines of nearly unrelated text. This
only fills up the archives with redundancy and makes them hard to search.

<Posted, as no valid mailing address is given>

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

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