Forums

looking for dev kit for ProAsic3

Started by alb October 28, 2014
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