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.
Re: Spirit on Mars
Started by ●January 22, 2004
Reply by ●January 26, 20042004-01-26
Reply by ●January 26, 20042004-01-26
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
Reply by ●January 26, 20042004-01-26
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 > >
Reply by ●January 26, 20042004-01-26
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
Reply by ●January 26, 20042004-01-26
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 > >
Reply by ●January 26, 20042004-01-26
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
Reply by ●January 27, 20042004-01-27
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
Reply by ●January 27, 20042004-01-27
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 > >
Reply by ●January 27, 20042004-01-27
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 >> >> >
Reply by ●January 27, 20042004-01-27
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.
