looking for dev kit for ProAsic3

Hi everyone,

I'm looking for a dev kit for a ProAsic3 A3PE3000 (microsemi) with some 
minimum amount of functional blocks around (volatile/non-volatile 
memory, few peripherals like UART, USB, SPI ...).

So far I've found this interesting piece
http://www.skylabs.si/DevBoard_PicoSky_a3pe3000.aspx

but something simpler can work as well.

The main reason is to use it as a testbed for our own processor core (an 
mblite with an extra fpu) so to have some rapid prototyping platform.

Any pointer?

Thanks,

Al

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On 10/28/2014 12:44 AM, alb wrote:
> Hi everyone,
>
> I'm looking for a dev kit for a ProAsic3 A3PE3000 (microsemi) with some
> minimum amount of functional blocks around (volatile/non-volatile
> memory, few peripherals like UART, USB, SPI ...).
>
> So far I've found this interesting piece
> http://www.skylabs.si/DevBoard_PicoSky_a3pe3000.aspx
>
> but something simpler can work as well.
>
> The main reason is to use it as a testbed for our own processor core (an
> mblite with an extra fpu) so to have some rapid prototyping platform.
>
> Any pointer?
>
> Thanks,
>
> Al
>

Why not an Igloo2?  I've pretty much dropped the ProAsic 3 from new designs.

Rob.

Hi Rob,
Rob Doyle <radioengr@gmail.com> wrote:
>> I'm looking for a dev kit for a ProAsic3 A3PE3000 (microsemi) with some
>> minimum amount of functional blocks around (volatile/non-volatile
>> memory, few peripherals like UART, USB, SPI ...).
[]
> Why not an Igloo2?  I've pretty much dropped the ProAsic 3 from new designs.

The Igloo2 is a very interesting device and I've used it in the past. 
Unfortunately the need for the ProAsic is strictly related to the market 
we are in: space.

There few options available when you talk about FPGA for space 
applications, essentially the RTAX family (antifuse) and the ProAsic3 
(flash based), with the latter only used in one yet to be launched 
mission (INSIGHT, Mars).

Xilinx has done efforts in this direction but I believe that Microsemi, 
former Actel, is still leading this market and will do so for a while.

So why not Igloo2? Because ESA is very picky in choosing FPGAs and 
Igloo2 is not in their target 
(http://www.google.com/url?sa=t&rct=j&q=igloo2%20space%20applications&source=web&cd=7&ved=0CEcQFjAG&url=https%3A%2F%2Famstel.estec.esa.int%2Ftecedm%2Fwebsite%2Fconferences%2Fsefuw%2Fd2_p1_ESA_Microsemi_RT_FPGA.pdf&ei=GAtQVOOuFcv7ygPhqYA4&usg=AFQjCNEaSGQdBridl53K1wtjUjvJiZ9OpA&bvm=bv.78597519,d.bGQ).

Al

On 10/28/2014 5:43 PM, alb wrote:
> Hi Rob,
> Rob Doyle <radioengr@gmail.com> wrote:
>>> I'm looking for a dev kit for a ProAsic3 A3PE3000 (microsemi) with some
>>> minimum amount of functional blocks around (volatile/non-volatile
>>> memory, few peripherals like UART, USB, SPI ...).
> []
>> Why not an Igloo2?  I've pretty much dropped the ProAsic 3 from new designs.
>
> The Igloo2 is a very interesting device and I've used it in the past.
> Unfortunately the need for the ProAsic is strictly related to the market
> we are in: space.
>
> There few options available when you talk about FPGA for space
> applications, essentially the RTAX family (antifuse) and the ProAsic3
> (flash based), with the latter only used in one yet to be launched
> mission (INSIGHT, Mars).
>
> Xilinx has done efforts in this direction but I believe that Microsemi,
> former Actel, is still leading this market and will do so for a while.
>
> So why not Igloo2? Because ESA is very picky in choosing FPGAs and
> Igloo2 is not in their target
> (http://www.google.com/url?sa=t&rct=j&q=igloo2%20space%20applications&source=web&cd=7&ved=0CEcQFjAG&url=https%3A%2F%2Famstel.estec.esa.int%2Ftecedm%2Fwebsite%2Fconferences%2Fsefuw%2Fd2_p1_ESA_Microsemi_RT_FPGA.pdf&ei=GAtQVOOuFcv7ygPhqYA4&usg=AFQjCNEaSGQdBridl53K1wtjUjvJiZ9OpA&bvm=bv.78597519,d.bGQ).

I was supposed to work with Rich Katz at NASA once to do some testing on 
Xilinx parts for radiation susceptibility.  He tends to drag his feet 
then needs it all at once and I got busy on my end.  So it moved on 
without me.  You might try contacting him to see what they ended up 
doing with the parts.  I think the philosophy was to run the part for a 
while, then reconfigure it in case it had taken any soft errors.  I 
didn't really get how that would help, but I guess they had ways of 
using an FPGA like that.

-- 

Rick

Hi Rick,

rickman <gnuarm@gmail.com> wrote:
[]
> I was supposed to work with Rich Katz at NASA once to do some testing on 
> Xilinx parts for radiation susceptibility.  He tends to drag his feet 
> then needs it all at once and I got busy on my end.  So it moved on 
> without me.  You might try contacting him to see what they ended up 
> doing with the parts.  

There's a lot of documentation on klabs.org but it starts to be a little 
out dated. I'd love to work with them but our business is not interested 
in FPGA testing, with rather use the ones which have been already tested 
;-)

> I think the philosophy was to run the part for a 
> while, then reconfigure it in case it had taken any soft errors.  I 
> didn't really get how that would help, but I guess they had ways of 
> using an FPGA like that.

Xilinx has always thrived to provide a way to perform partial 
reconfiguration, so with the appropriate control logic you could sense 
where the problem is and reprogram it.

The 'Curiosity' mission hosted Xilinx parts (Rad Tolerant) but 
reprogrammability is needed to correct faults in the configuration 
registers.

Currently, at least in Europe, the trend seems to push towards flash 
based products which provide higher tolerance to radiation and 
reprogrammability.

The great benefit of reprogrammability may be its biggest weakness as 
well, though. While the possibility to reprogram the target even in 
later stages of the project (if not after the launch!) may have two 
important consequences:

1. not enough verification/validation (since there's always a chance to 
'fix it later')

2. features creeping

Current FPGA plans, as mandated by ESA, are well aware of this risk and 
boards continue to be very strict during reviews. Yet everybody is aware 
that if a bug *can* be fixed later *won't* be fixed now :-)

Al

On 30/10/2014 00:09, rickman wrote:
> On 10/28/2014 5:43 PM, alb wrote:
..
>>
>> So why not Igloo2? Because ESA is very picky in choosing FPGAs and
>> Igloo2 is not in their target
>> (http://www.google.com/url?sa=t&rct=j&q=igloo2%20space%20applications&source=web&cd=7&ved=0CEcQFjAG&url=https%3A%2F%2Famstel.estec.esa.int%2Ftecedm%2Fwebsite%2Fconferences%2Fsefuw%2Fd2_p1_ESA_Microsemi_RT_FPGA.pdf&ei=GAtQVOOuFcv7ygPhqYA4&usg=AFQjCNEaSGQdBridl53K1wtjUjvJiZ9OpA&bvm=bv.78597519,d.bGQ).
>>
>
> I was supposed to work with Rich Katz at NASA once to do some testing on
> Xilinx parts for radiation susceptibility.

Xilinx has done quite some extensive radiation testing already many 
years ago (Qpro series) and they are fully qualified to be used in space 
(like the Mars Rover!)

> He tends to drag his feet

That's because he is the number 1 FPGA/Space guy in the world and tends 
to multi-task between many projects. I thought I knew a bit about FPGA's 
in space until I met him....

I would definitely contact him as he is great guy and will help you even 
when he is overloaded with other projects.

Regards,
Hans
www.ht-lab.com


> then needs it all at once and I got busy on my end.  So it moved on
> without me.  You might try contacting him to see what they ended up
> doing with the parts.  I think the philosophy was to run the part for a
> while, then reconfigure it in case it had taken any soft errors.  I
> didn't really get how that would help, but I guess they had ways of
> using an FPGA like that

On 10/30/2014 4:08 AM, alb wrote:
> Hi Rick,
>
> rickman <gnuarm@gmail.com> wrote:
> []
>> I was supposed to work with Rich Katz at NASA once to do some testing on
>> Xilinx parts for radiation susceptibility.  He tends to drag his feet
>> then needs it all at once and I got busy on my end.  So it moved on
>> without me.  You might try contacting him to see what they ended up
>> doing with the parts.
>
> There's a lot of documentation on klabs.org but it starts to be a little
> out dated. I'd love to work with them but our business is not interested
> in FPGA testing, with rather use the ones which have been already tested
> ;-)

That's why I said to get in touch with Rich Katz.  He will have some 
info on what is what in that department.


>> I think the philosophy was to run the part for a
>> while, then reconfigure it in case it had taken any soft errors.  I
>> didn't really get how that would help, but I guess they had ways of
>> using an FPGA like that.
>
> Xilinx has always thrived to provide a way to perform partial
> reconfiguration, so with the appropriate control logic you could sense
> where the problem is and reprogram it.

This was not partial configuration.  I can't say I really got the 
concept.  I mean what is happening while the device is being configured? 
  Who is running the store?


> The 'Curiosity' mission hosted Xilinx parts (Rad Tolerant) but
> reprogrammability is needed to correct faults in the configuration
> registers.
>
> Currently, at least in Europe, the trend seems to push towards flash
> based products which provide higher tolerance to radiation and
> reprogrammability.
>
> The great benefit of reprogrammability may be its biggest weakness as
> well, though. While the possibility to reprogram the target even in
> later stages of the project (if not after the launch!) may have two
> important consequences:
>
> 1. not enough verification/validation (since there's always a chance to
> 'fix it later')

Red herring.  That is an issue of your design process, not the 
technology used.


> 2. features creeping
>
> Current FPGA plans, as mandated by ESA, are well aware of this risk and
> boards continue to be very strict during reviews. Yet everybody is aware
> that if a bug *can* be fixed later *won't* be fixed now :-)

Bug fix is not feature creep.  But the point is valid.  Again it is an 
issue of the design process really.  No changes unless they can be 
adequately verified.

-- 

Rick

On 10/30/2014 4:27 AM, HT-Lab wrote:
> On 30/10/2014 00:09, rickman wrote:
>> On 10/28/2014 5:43 PM, alb wrote:
> ..
>>>
>>> So why not Igloo2? Because ESA is very picky in choosing FPGAs and
>>> Igloo2 is not in their target
>>> (http://www.google.com/url?sa=t&rct=j&q=igloo2%20space%20applications&source=web&cd=7&ved=0CEcQFjAG&url=https%3A%2F%2Famstel.estec.esa.int%2Ftecedm%2Fwebsite%2Fconferences%2Fsefuw%2Fd2_p1_ESA_Microsemi_RT_FPGA.pdf&ei=GAtQVOOuFcv7ygPhqYA4&usg=AFQjCNEaSGQdBridl53K1wtjUjvJiZ9OpA&bvm=bv.78597519,d.bGQ).
>>>
>>>
>>
>> I was supposed to work with Rich Katz at NASA once to do some testing on
>> Xilinx parts for radiation susceptibility.
>
> Xilinx has done quite some extensive radiation testing already many
> years ago (Qpro series) and they are fully qualified to be used in space
> (like the Mars Rover!)
>
>> He tends to drag his feet
>
> That's because he is the number 1 FPGA/Space guy in the world and tends
> to multi-task between many projects. I thought I knew a bit about FPGA's
> in space until I met him....
>
> I would definitely contact him as he is great guy and will help you even
> when he is overloaded with other projects.

I will second that.  I was scrambling for work back then and couldn't 
accommodate his schedule.  Now things are more relaxed for me and I 
would work with him any day.  He is a great guy.

-- 

Rick