ProAsic3 (PA3)

Hi,

Just wondering if anyone has used, or tried to use
this device yet. I have a design I did for the ProAsic+
that I converted to use the PA3 as a test.  Went fairly well. Only
real issue I had was that when I set the option for Designer or move
flip flops to the IO cells, it did not implement them correctly.
Specifically the async resets where the wrong sense. Since The device I
am targeting is not in production yet so I can only simulate the back
annotated
design. This is where I discovered the problem so I do not know if the
problem
is with the simulation model or with designer.

I had a couple of problems with the Plus and notice some changes to the PA3
data sheet; primarily concerned with the JTAG TRST pin. Under the pin
description
section, They "recommend" the following:

"TRST Boundary Scan Reset Pin

The TRST pin functions as an active low input to
asynchronously initialize (or reset) the boundary scan
circuitry. There is an internal weak pull-up resistor on the
TRST pin. In the operating mode, a 100 ? external pulldown
resistor should be placed between TRST and GND
to ensure that the chip does not switch into a different
mode."

I had a power-up problem on some of  the Plus device and found out
that if I ground the TRST pin , the device would start working. I
report this to Actel and had them evaluate the parts that exhibited the
problem.
There recommendation: "ground the TRST pin". Sounds to me like there is a
problem with the TAP port on both the Plus and PA3 devices and the
100 ? resistor is the "patch" to fix it. I am curious if anyone else has had
problems with the TRST pin.

The other problem I have had is a high programming failure rate
while using the FlashPro programmer, mostly exit 11 errors.
Actel was not able to helps us solve this problem. We did
not press them on this since eventually we would be getting the
devices programmed by our supplier and it would become
a non-issue after that.  The curious thing is that if a device successfully
programmed the first time, it would more then likely always program
successfully. I have reprogram a single device 50 to 60 times
with no problem. I suspect a marginal problem with the device itself or
a problem with the programming algorithm and not with my programming
fixture.

It bothers me that Actel will not admit problems with their devices. Xilinx
has no problem with admitting problems with devices and then publishing
a work around to the problem until a permanent fix to the silicon is
implemented.
Why is Actel reluctant to do this. Maybe this problem with the TRST was
already
know to them, and if they had published an errata on this then maybe I would
not have
spent over a week debugging this problem.

Why do I use Actel if I am unhappy with there devices? the truth is it is
the only
reprogrammable FPGA that fit the application.

Would like to hear about any experiences that other people have had with the
Actel
Flash parts.

Thanks
Dave Colson

This week the Actel FAEs came in to tell us about a problem with the
pro-ASIC plus chip. It seems the flash retention rate is much lower
than expected when using designer prior to 6.1 due to a load balancing
issue across transistors. Unfortunately, they don't have a write-up of
this problem on their website yet.

Dave Colson wrote:
> Hi,
> 
> Just wondering if anyone has used, or tried to use
> this device yet. I have a design I did for the ProAsic+
> that I converted to use the PA3 as a test.  Went fairly well. Only
> real issue I had was that when I set the option for Designer or move
> flip flops to the IO cells, it did not implement them correctly.
> Specifically the async resets where the wrong sense. Since The device I
> am targeting is not in production yet so I can only simulate the back
> annotated
> design. This is where I discovered the problem so I do not know if the
> problem
> is with the simulation model or with designer.
> 
> I had a couple of problems with the Plus and notice some changes to the PA3
> data sheet; primarily concerned with the JTAG TRST pin. Under the pin
> description
> section, They "recommend" the following:
> 
> "TRST Boundary Scan Reset Pin
> 
> The TRST pin functions as an active low input to
> asynchronously initialize (or reset) the boundary scan
> circuitry. There is an internal weak pull-up resistor on the
> TRST pin. In the operating mode, a 100 ? external pulldown
> resistor should be placed between TRST and GND
> to ensure that the chip does not switch into a different
> mode."
> 
> I had a power-up problem on some of  the Plus device and found out
> that if I ground the TRST pin , the device would start working. I
> report this to Actel and had them evaluate the parts that exhibited the
> problem.
> There recommendation: "ground the TRST pin". Sounds to me like there is a
> problem with the TAP port on both the Plus and PA3 devices and the
> 100 ? resistor is the "patch" to fix it. I am curious if anyone else has had
> problems with the TRST pin.
> 
> The other problem I have had is a high programming failure rate
> while using the FlashPro programmer, mostly exit 11 errors.
> Actel was not able to helps us solve this problem. We did
> not press them on this since eventually we would be getting the
> devices programmed by our supplier and it would become
> a non-issue after that.  The curious thing is that if a device successfully
> programmed the first time, it would more then likely always program
> successfully. I have reprogram a single device 50 to 60 times
> with no problem. I suspect a marginal problem with the device itself or
> a problem with the programming algorithm and not with my programming
> fixture.
> 
> It bothers me that Actel will not admit problems with their devices. Xilinx
> has no problem with admitting problems with devices and then publishing
> a work around to the problem until a permanent fix to the silicon is
> implemented.
> Why is Actel reluctant to do this. Maybe this problem with the TRST was
> already
> know to them, and if they had published an errata on this then maybe I would
> not have
> spent over a week debugging this problem.
> 
> Why do I use Actel if I am unhappy with there devices? the truth is it is
> the only
> reprogrammable FPGA that fit the application.
> 
> Would like to hear about any experiences that other people have had with the
> Actel
> Flash parts.

I am meeting with a sales rep and FAE on these products tomorrow, opps, 
today.  My main concern is that they are not slated to be out until Q4 
although I was told possibly Q3 (meaning end of Sept).  I also want to 
hear some real pricing instead of the "as low as xxx in quantity".

I was told that the larger parts would be out first.  So if you want a 
$1.50 part you will need to wait until '06, I expect.

The data sheet talks about being 5 volt tolerant, but they aren't.  They 
just do the same game of using resistors like the Virtex, etc. parts.

I don't see the pulldown on the TRST as being much of a bug myself.  My 
experience has been that every part handles the JTAG signals in 
different, often incompatible ways.  But if you use the spec'd pull ups 
or downs and use their cable the JTAG should work just like TI DSPs and 
Xilinx FPGAs.

I'll let you know what I find out from the FAE.

"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag
news:Wrqdneo8FpgSkpbfRVn-jw@adelphia.com...
> Dave Colson wrote:
> > Hi,
> >

> > Would like to hear about any experiences that other people have had with
the
> > Actel
> > Flash parts.
>
> I am meeting with a sales rep and FAE on these products tomorrow, opps,
> today.  My main concern is that they are not slated to be out until Q4
> although I was told possibly Q3 (meaning end of Sept).  I also want to
> hear some real pricing instead of the "as low as xxx in quantity".
>
> I was told that the larger parts would be out first.  So if you want a
> $1.50 part you will need to wait until '06, I expect.
>
> The data sheet talks about being 5 volt tolerant, but they aren't.  They
> just do the same game of using resistors like the Virtex, etc. parts.
>
> I don't see the pulldown on the TRST as being much of a bug myself.  My
> experience has been that every part handles the JTAG signals in
> different, often incompatible ways.  But if you use the spec'd pull ups
> or downs and use their cable the JTAG should work just like TI DSPs and
> Xilinx FPGAs.
>
> I'll let you know what I find out from the FAE.

Please do so!

The first part out is 600E that was known already at Electronica 2004 (that
is nov 2004)
hm are you saying no parts will be available til Q4 ? that would be pitty!

Most vendors dont admit silicon bugs! You need to prove their silicon is
faulty
then in some case with long delay they might agree yes there is a problem.

Antti

Hi,

"Dave Colson" <dscolson@rcn.com> wrote:
> It bothers me that Actel will not admit problems with their devices. Xilinx
> has no problem with admitting problems with devices and then publishing
> a work around to the problem until a permanent fix to the silicon is
> implemented.

I'm not sure, but I think, the fact that Actel has mostly highpriced
devices means that the applications were the fpgas are used, are also
high valued.
This means that systematically failure tend to be more expensive for
Actel.
 
> Would like to hear about any experiences that other people have had with the
> Actel
> Flash parts.

I use some for prototyping and I am very satisfied with. The only wish
I had are 5V IO Buffer. Unfortunately there seems to be no
reprogrammable device with 5V IO and sufficient cells on market to do
prototyping for Asics with 5V IO.

bye Thomas

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:Wrqdneo8FpgSkpbfRVn-jw@adelphia.com...
> Dave Colson wrote:
> > Hi,
> >
> > Just wondering if anyone has used, or tried to use
> > this device yet. I have a design I did for the ProAsic+
> > that I converted to use the PA3 as a test.  Went fairly well. Only
> > real issue I had was that when I set the option for Designer or move
> > flip flops to the IO cells, it did not implement them correctly.
> > Specifically the async resets where the wrong sense. Since The device I
> > am targeting is not in production yet so I can only simulate the back
> > annotated
> > design. This is where I discovered the problem so I do not know if the
> > problem
> > is with the simulation model or with designer.
> >
> > I had a couple of problems with the Plus and notice some changes to the
PA3
> > data sheet; primarily concerned with the JTAG TRST pin. Under the pin
> > description
> > section, They "recommend" the following:
> >
> > "TRST Boundary Scan Reset Pin
> >
> > The TRST pin functions as an active low input to
> > asynchronously initialize (or reset) the boundary scan
> > circuitry. There is an internal weak pull-up resistor on the
> > TRST pin. In the operating mode, a 100 ? external pulldown
> > resistor should be placed between TRST and GND
> > to ensure that the chip does not switch into a different
> > mode."
> >
> > I had a power-up problem on some of  the Plus device and found out
> > that if I ground the TRST pin , the device would start working. I
> > report this to Actel and had them evaluate the parts that exhibited the
> > problem.
> > There recommendation: "ground the TRST pin". Sounds to me like there is
a
> > problem with the TAP port on both the Plus and PA3 devices and the
> > 100 ? resistor is the "patch" to fix it. I am curious if anyone else has
had
> > problems with the TRST pin.
> >
> > The other problem I have had is a high programming failure rate
> > while using the FlashPro programmer, mostly exit 11 errors.
> > Actel was not able to helps us solve this problem. We did
> > not press them on this since eventually we would be getting the
> > devices programmed by our supplier and it would become
> > a non-issue after that.  The curious thing is that if a device
successfully
> > programmed the first time, it would more then likely always program
> > successfully. I have reprogram a single device 50 to 60 times
> > with no problem. I suspect a marginal problem with the device itself or
> > a problem with the programming algorithm and not with my programming
> > fixture.
> >
> > It bothers me that Actel will not admit problems with their devices.
Xilinx
> > has no problem with admitting problems with devices and then publishing
> > a work around to the problem until a permanent fix to the silicon is
> > implemented.
> > Why is Actel reluctant to do this. Maybe this problem with the TRST was
> > already
> > know to them, and if they had published an errata on this then maybe I
would
> > not have
> > spent over a week debugging this problem.
> >
> > Why do I use Actel if I am unhappy with there devices? the truth is it
is
> > the only
> > reprogrammable FPGA that fit the application.
> >
> > Would like to hear about any experiences that other people have had with
the
> > Actel
> > Flash parts.
>
> I am meeting with a sales rep and FAE on these products tomorrow, opps,
> today.  My main concern is that they are not slated to be out until Q4
> although I was told possibly Q3 (meaning end of Sept).  I also want to
> hear some real pricing instead of the "as low as xxx in quantity".
>
> I was told that the larger parts would be out first.  So if you want a
> $1.50 part you will need to wait until '06, I expect.
>
> The data sheet talks about being 5 volt tolerant, but they aren't.  They
> just do the same game of using resistors like the Virtex, etc. parts.
>
> I don't see the pulldown on the TRST as being much of a bug myself.  My
> experience has been that every part handles the JTAG signals in
> different, often incompatible ways.  But if you use the spec'd pull ups
> or downs and use their cable the JTAG should work just like TI DSPs and
> Xilinx FPGAs.
>
> I'll let you know what I find out from the FAE.


I seem to remember that the JTAG spec requires(recommends) that TRST is
optional.
That is it is not require to perform any of the JTAG operations, including
powering up.
As far as a bug. We had 2 unexplained catastrophic field failures (parts
actually were fried)
of the Plus device before I was able to figure out the problem in the lab.

Some of the parts that fail to power up correct started to go into thermally
run away.
Eventually they would overhead and destroy themselves. It is one think if it
powers up
brain dead but another when it destroy itself and half of the other
components on the board.

My main issue is the fact that they do not notify customer of problems with
the device. I always
felt like I was the only one having problems with the device, but I am not
so sure now.

Dave Colson wrote:
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:Wrqdneo8FpgSkpbfRVn-jw@adelphia.com...
> 
>>Dave Colson wrote:
>>
>>>Hi,
>>>
>>>Just wondering if anyone has used, or tried to use
>>>this device yet. I have a design I did for the ProAsic+
>>>that I converted to use the PA3 as a test.  Went fairly well. Only
>>>real issue I had was that when I set the option for Designer or move
>>>flip flops to the IO cells, it did not implement them correctly.
>>>Specifically the async resets where the wrong sense. Since The device I
>>>am targeting is not in production yet so I can only simulate the back
>>>annotated
>>>design. This is where I discovered the problem so I do not know if the
>>>problem
>>>is with the simulation model or with designer.
>>>
>>>I had a couple of problems with the Plus and notice some changes to the
> 
> PA3
> 
>>>data sheet; primarily concerned with the JTAG TRST pin. Under the pin
>>>description
>>>section, They "recommend" the following:
>>>
>>>"TRST Boundary Scan Reset Pin
>>>
>>>The TRST pin functions as an active low input to
>>>asynchronously initialize (or reset) the boundary scan
>>>circuitry. There is an internal weak pull-up resistor on the
>>>TRST pin. In the operating mode, a 100 ? external pulldown
>>>resistor should be placed between TRST and GND
>>>to ensure that the chip does not switch into a different
>>>mode."
>>>
>>>I had a power-up problem on some of  the Plus device and found out
>>>that if I ground the TRST pin , the device would start working. I
>>>report this to Actel and had them evaluate the parts that exhibited the
>>>problem.
>>>There recommendation: "ground the TRST pin". Sounds to me like there is
> 
> a
> 
>>>problem with the TAP port on both the Plus and PA3 devices and the
>>>100 ? resistor is the "patch" to fix it. I am curious if anyone else has
> 
> had
> 
>>>problems with the TRST pin.
>>>
>>>The other problem I have had is a high programming failure rate
>>>while using the FlashPro programmer, mostly exit 11 errors.
>>>Actel was not able to helps us solve this problem. We did
>>>not press them on this since eventually we would be getting the
>>>devices programmed by our supplier and it would become
>>>a non-issue after that.  The curious thing is that if a device
> 
> successfully
> 
>>>programmed the first time, it would more then likely always program
>>>successfully. I have reprogram a single device 50 to 60 times
>>>with no problem. I suspect a marginal problem with the device itself or
>>>a problem with the programming algorithm and not with my programming
>>>fixture.
>>>
>>>It bothers me that Actel will not admit problems with their devices.
> 
> Xilinx
> 
>>>has no problem with admitting problems with devices and then publishing
>>>a work around to the problem until a permanent fix to the silicon is
>>>implemented.
>>>Why is Actel reluctant to do this. Maybe this problem with the TRST was
>>>already
>>>know to them, and if they had published an errata on this then maybe I
> 
> would
> 
>>>not have
>>>spent over a week debugging this problem.
>>>
>>>Why do I use Actel if I am unhappy with there devices? the truth is it
> 
> is
> 
>>>the only
>>>reprogrammable FPGA that fit the application.
>>>
>>>Would like to hear about any experiences that other people have had with
> 
> the
> 
>>>Actel
>>>Flash parts.
>>
>>I am meeting with a sales rep and FAE on these products tomorrow, opps,
>>today.  My main concern is that they are not slated to be out until Q4
>>although I was told possibly Q3 (meaning end of Sept).  I also want to
>>hear some real pricing instead of the "as low as xxx in quantity".
>>
>>I was told that the larger parts would be out first.  So if you want a
>>$1.50 part you will need to wait until '06, I expect.
>>
>>The data sheet talks about being 5 volt tolerant, but they aren't.  They
>>just do the same game of using resistors like the Virtex, etc. parts.
>>
>>I don't see the pulldown on the TRST as being much of a bug myself.  My
>>experience has been that every part handles the JTAG signals in
>>different, often incompatible ways.  But if you use the spec'd pull ups
>>or downs and use their cable the JTAG should work just like TI DSPs and
>>Xilinx FPGAs.
>>
>>I'll let you know what I find out from the FAE.
> 
> 
> 
> I seem to remember that the JTAG spec requires(recommends) that TRST is
> optional.
> That is it is not require to perform any of the JTAG operations, including
> powering up.

I don't believe that is correct.  The TRST pin is optional, but it does 
not have to allow the part to work if not driven to the correct state, 
as in the JTAG cable can ignore it.


> As far as a bug. We had 2 unexplained catastrophic field failures (parts
> actually were fried)
> of the Plus device before I was able to figure out the problem in the lab.
> 
> Some of the parts that fail to power up correct started to go into thermally
> run away.
> Eventually they would overhead and destroy themselves. It is one think if it
> powers up
> brain dead but another when it destroy itself and half of the other
> components on the board.

I have not looked at the programming process, but isn't there a signal 
to indicate a programming failure?  The SRAM based parts have that.


> My main issue is the fact that they do not notify customer of problems with
> the device. I always
> felt like I was the only one having problems with the device, but I am not
> so sure now.

rickman wrote:
> Dave Colson wrote:
> 
>> Hi,
>>
>> Just wondering if anyone has used, or tried to use
>> this device yet. I have a design I did for the ProAsic+
>> that I converted to use the PA3 as a test.  Went fairly well. Only
>> real issue I had was that when I set the option for Designer or move
>> flip flops to the IO cells, it did not implement them correctly.
>> Specifically the async resets where the wrong sense. Since The device I
>> am targeting is not in production yet so I can only simulate the back
>> annotated
>> design. This is where I discovered the problem so I do not know if the
>> problem
>> is with the simulation model or with designer.
>>
>> I had a couple of problems with the Plus and notice some changes to 
>> the PA3
>> data sheet; primarily concerned with the JTAG TRST pin. Under the pin
>> description
>> section, They "recommend" the following:
>>
>> "TRST Boundary Scan Reset Pin
>>
>> The TRST pin functions as an active low input to
>> asynchronously initialize (or reset) the boundary scan
>> circuitry. There is an internal weak pull-up resistor on the
>> TRST pin. In the operating mode, a 100 ? external pulldown
>> resistor should be placed between TRST and GND
>> to ensure that the chip does not switch into a different
>> mode."
>>
>> I had a power-up problem on some of  the Plus device and found out
>> that if I ground the TRST pin , the device would start working. I
>> report this to Actel and had them evaluate the parts that exhibited the
>> problem.
>> There recommendation: "ground the TRST pin". Sounds to me like there is a
>> problem with the TAP port on both the Plus and PA3 devices and the
>> 100 ? resistor is the "patch" to fix it. I am curious if anyone else 
>> has had
>> problems with the TRST pin.
>>
>> The other problem I have had is a high programming failure rate
>> while using the FlashPro programmer, mostly exit 11 errors.
>> Actel was not able to helps us solve this problem. We did
>> not press them on this since eventually we would be getting the
>> devices programmed by our supplier and it would become
>> a non-issue after that.  The curious thing is that if a device 
>> successfully
>> programmed the first time, it would more then likely always program
>> successfully. I have reprogram a single device 50 to 60 times
>> with no problem. I suspect a marginal problem with the device itself or
>> a problem with the programming algorithm and not with my programming
>> fixture.
>>
>> It bothers me that Actel will not admit problems with their devices. 
>> Xilinx
>> has no problem with admitting problems with devices and then publishing
>> a work around to the problem until a permanent fix to the silicon is
>> implemented.
>> Why is Actel reluctant to do this. Maybe this problem with the TRST was
>> already
>> know to them, and if they had published an errata on this then maybe I 
>> would
>> not have
>> spent over a week debugging this problem.
>>
>> Why do I use Actel if I am unhappy with there devices? the truth is it is
>> the only
>> reprogrammable FPGA that fit the application.
>>
>> Would like to hear about any experiences that other people have had 
>> with the
>> Actel
>> Flash parts.
> 
> 
> I am meeting with a sales rep and FAE on these products tomorrow, opps, 
> today.  My main concern is that they are not slated to be out until Q4 
> although I was told possibly Q3 (meaning end of Sept).  I also want to 
> hear some real pricing instead of the "as low as xxx in quantity".
> 
> I was told that the larger parts would be out first.  So if you want a 
> $1.50 part you will need to wait until '06, I expect.
> 
> The data sheet talks about being 5 volt tolerant, but they aren't.  They 
> just do the same game of using resistors like the Virtex, etc. parts.
> 
> I don't see the pulldown on the TRST as being much of a bug myself.  My 
> experience has been that every part handles the JTAG signals in 
> different, often incompatible ways.  But if you use the spec'd pull ups 
> or downs and use their cable the JTAG should work just like TI DSPs and 
> Xilinx FPGAs.
> 
> I'll let you know what I find out from the FAE.


Here is what I found.  The 600 is the first part out of the chute.  It 
will sample by April, as in *we* can get samples then.  We never got to 
a production date because the part does not fit my socket.  The lack of 
5 volt tolerance and the schedule keeps it off my board.  I also did not 
really get much on pricing.

A thing that I found very surprising, I was told it is not really field 
programmable, as in by a MCU.  It has to be programmed by cable because 
you have to supply +16 and -13.5 volts (or similar).  So if the chip can 
take these voltages, why can't it handle 5 volts on the IOs??? 
Obviously they are switching high voltages without problems.

"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag
news:CbmdnZjg1d9gppHfRVn-qg@adelphia.com...
> rickman wrote:
> > Dave Colson wrote:

> >
> > I'll let you know what I find out from the FAE.
>
>
> Here is what I found.  The 600 is the first part out of the chute.  It
> will sample by April, as in *we* can get samples then.  We never got to
> a production date because the part does not fit my socket.  The lack of
> 5 volt tolerance and the schedule keeps it off my board.  I also did not
> really get much on pricing.

are you sure its 600 not 600E ?
600E is supported by free tools, 600 not :)

the samples did exist in october 2004! just not for regular mortals :(

> A thing that I found very surprising, I was told it is not really field
> programmable, as in by a MCU.  It has to be programmed by cable because
> you have to supply +16 and -13.5 volts (or similar).  So if the chip can
> take these voltages, why can't it handle 5 volts on the IOs???
> Obviously they are switching high voltages without problems.

NO NO!
the +16.5 -11.5 are for ProAsic+ not for PA3 !
PA3 works down to 1.5 single supply and needs 3.3 for programming

Antti

See comments below.

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:AOKdneYeb9dcpJHfRVn-hA@adelphia.com...
> Dave Colson wrote:
> > "rickman" <spamgoeshere4@yahoo.com> wrote in message
> > news:Wrqdneo8FpgSkpbfRVn-jw@adelphia.com...
> >
> >>Dave Colson wrote:
> >>
> >>>Hi,
> >>>
> >>>Just wondering if anyone has used, or tried to use
> >>>this device yet. I have a design I did for the ProAsic+
> >>>that I converted to use the PA3 as a test.  Went fairly well. Only
> >>>real issue I had was that when I set the option for Designer or move
> >>>flip flops to the IO cells, it did not implement them correctly.
> >>>Specifically the async resets where the wrong sense. Since The device I
> >>>am targeting is not in production yet so I can only simulate the back
> >>>annotated
> >>>design. This is where I discovered the problem so I do not know if the
> >>>problem
> >>>is with the simulation model or with designer.
> >>>
> >>>I had a couple of problems with the Plus and notice some changes to the
> >
> > PA3
> >
> >>>data sheet; primarily concerned with the JTAG TRST pin. Under the pin
> >>>description
> >>>section, They "recommend" the following:
> >>>
> >>>"TRST Boundary Scan Reset Pin
> >>>
> >>>The TRST pin functions as an active low input to
> >>>asynchronously initialize (or reset) the boundary scan
> >>>circuitry. There is an internal weak pull-up resistor on the
> >>>TRST pin. In the operating mode, a 100 ? external pulldown
> >>>resistor should be placed between TRST and GND
> >>>to ensure that the chip does not switch into a different
> >>>mode."
> >>>
> >>>I had a power-up problem on some of  the Plus device and found out
> >>>that if I ground the TRST pin , the device would start working. I
> >>>report this to Actel and had them evaluate the parts that exhibited the
> >>>problem.
> >>>There recommendation: "ground the TRST pin". Sounds to me like there is
> >
> > a
> >
> >>>problem with the TAP port on both the Plus and PA3 devices and the
> >>>100 ? resistor is the "patch" to fix it. I am curious if anyone else
has
> >
> > had
> >
> >>>problems with the TRST pin.
> >>>
> >>>The other problem I have had is a high programming failure rate
> >>>while using the FlashPro programmer, mostly exit 11 errors.
> >>>Actel was not able to helps us solve this problem. We did
> >>>not press them on this since eventually we would be getting the
> >>>devices programmed by our supplier and it would become
> >>>a non-issue after that.  The curious thing is that if a device
> >
> > successfully
> >
> >>>programmed the first time, it would more then likely always program
> >>>successfully. I have reprogram a single device 50 to 60 times
> >>>with no problem. I suspect a marginal problem with the device itself or
> >>>a problem with the programming algorithm and not with my programming
> >>>fixture.
> >>>
> >>>It bothers me that Actel will not admit problems with their devices.
> >
> > Xilinx
> >
> >>>has no problem with admitting problems with devices and then publishing
> >>>a work around to the problem until a permanent fix to the silicon is
> >>>implemented.
> >>>Why is Actel reluctant to do this. Maybe this problem with the TRST was
> >>>already
> >>>know to them, and if they had published an errata on this then maybe I
> >
> > would
> >
> >>>not have
> >>>spent over a week debugging this problem.
> >>>
> >>>Why do I use Actel if I am unhappy with there devices? the truth is it
> >
> > is
> >
> >>>the only
> >>>reprogrammable FPGA that fit the application.
> >>>
> >>>Would like to hear about any experiences that other people have had
with
> >
> > the
> >
> >>>Actel
> >>>Flash parts.
> >>
> >>I am meeting with a sales rep and FAE on these products tomorrow, opps,
> >>today.  My main concern is that they are not slated to be out until Q4
> >>although I was told possibly Q3 (meaning end of Sept).  I also want to
> >>hear some real pricing instead of the "as low as xxx in quantity".
> >>
> >>I was told that the larger parts would be out first.  So if you want a
> >>$1.50 part you will need to wait until '06, I expect.
> >>
> >>The data sheet talks about being 5 volt tolerant, but they aren't.  They
> >>just do the same game of using resistors like the Virtex, etc. parts.
> >>
> >>I don't see the pulldown on the TRST as being much of a bug myself.  My
> >>experience has been that every part handles the JTAG signals in
> >>different, often incompatible ways.  But if you use the spec'd pull ups
> >>or downs and use their cable the JTAG should work just like TI DSPs and
> >>Xilinx FPGAs.
> >>
> >>I'll let you know what I find out from the FAE.
> >
> >
> >
> > I seem to remember that the JTAG spec requires(recommends) that TRST is
> > optional.
> > That is it is not require to perform any of the JTAG operations,
including
> > powering up.
>
> I don't believe that is correct.  The TRST pin is optional, but it does
> not have to allow the part to work if not driven to the correct state,
> as in the JTAG cable can ignore it.


To be more precise, the default state of the pin (left unconnected) will
allow the JTAG to work properly. That is you do not have connect anything to
the pin
in order for the JTAG to work. It is in the spec.


>
>
> > As far as a bug. We had 2 unexplained catastrophic field failures (parts
> > actually were fried)
> > of the Plus device before I was able to figure out the problem in the
lab.
> >
> > Some of the parts that fail to power up correct started to go into
thermally
> > run away.
> > Eventually they would overhead and destroy themselves. It is one think
if it
> > powers up
> > brain dead but another when it destroy itself and half of the other
> > components on the board.
>
> I have not looked at the programming process, but isn't there a signal
> to indicate a programming failure?  The SRAM based parts have that.


ProAsic parts are Flash parts you only program them once, they are
non-volatile,
there is no "programming" on power up like the Xilinx or Altera. The device
is ready
to go immediately on power up.

Maybe I did not explain this well, The issue is that on power up the JTAG
circuits
powered up in a undetermined state which cause the boundry scan circuit to
do bad
things to the IOs. Causing the device to not work because it had no control
over the IOs. I believe what happen on some of the parts was that the
boundry scan
cause contention inside the device which cause the thermal run away.


>
>
> > My main issue is the fact that they do not notify customer of problems
with
> > the device. I always
> > felt like I was the only one having problems with the device, but I am
not
> > so sure now.
>