looking for dev kit for ProAsic3

[alb]

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?

 

[Rob Doyle]

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.

 

[alb]

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

 

[rickman]

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

 

[alb]

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

 

[HT-Lab]

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

 

[rickman]

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

 

[rickman]

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