>> > Do Atmel have any plans to do some point-mask solutions based on this ?
>>
>> The AT91CAP products was conceived as a way to cost effectively bring out
>> new
>> customized AT91 circuits. Now the focus has shifted slightly, but this is
>> still a possibility.
>>
>> The current focus is on winning all designs incorporating
>> a combination of an MCU and an FPGA.
>>
>> The dedicated interface between the parts allow the FPGA access to the
>> internal of the MCU (It can become an AHB master),
>> so it is decidedly superior to a solution putting the FPGA on the memory
>> bus.
>>
>> The idea is that if you win all those designs in general, you
>> also win all high volume designs in particular which can then
>> migrate to a mask version,losing the cost of the FPGA.
>>
>> The NRE to do this is less than 20% of the NRE of a standard cell ASIC
>> and the design will be much simpler, so it is expected that the volumes
>> mentioned above will really be the starting point.
>
> Can you make some guess on 100K prices and NRE for such, using
> QFN 32?
>


NRE's are in the range of $150k, but I doubt that they will fit into QFN32
due to the memory blocks.

You will be hard pressed to find *any* 32 bit in QFN-32,
but I guess they will come.

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

On Sep 12, 11:00 pm, "Ulf Samuelsson" <u...@a-t-m-e-l.com> wrote:
> "Jim Granville" <no.s...@designtools.maps.co.nz> skrev i meddelandetnews:46e878e5$1@clear.net.nz...
>
>
>
> > Ulf Samuelsson wrote:
>
> >> Actel told us yesterday that the ARM was not really suitable for
> >> inclusion in FPGA...
> >> Frequency limited to 29 MHz, and would hardly fit into their smallest
> >> FPGA
> >> wihtout peripherals.
>
> >> They believe more in their Cortex-M1, but personally I see few customers
> >> where 512 kB flash applications only need a few kB of SRAM.
> >> In practice you will need an external SRAM.
>
> > Of course, it is not so much an Engineering Solution, as a FPGA Sales
> > Solution - the drive is to sell more/bigger FPGAs, not to solve a pressing
> > design problem (in fact, you create a few : higher Power,
> > and much worse EMC, but the market-spin does no mention those! )
>
> > For apps where you CANNOT fit the code into a Microcontroller, the
> > playing field levels a little, but the speed comes in a distant
> > second to the 200MHz+ alternatives.
>
> > Of course, Microcontrollers keep getting bigger: 4MByte is one
> > data point.
>
> >> No way that is going to compete with a std ARM micro for price,
> >> performance and power.
> >> You will need that customization urge, to be interested.
>
> >> Any volume business can be handled by products like the AT91CAP stuff
> >> which will allow custom chips in realistic distribution volumes (15-25
> >> ku/year)
>
> > Do Atmel have any plans to do some point-mask solutions based on this ?
>
> The AT91CAP products was conceived as a way to cost effectively bring out
> new
> customized AT91 circuits. Now the focus has shifted slightly, but this is
> still a possibility.
>
> The current focus is on winning all designs incorporating
> a combination of an MCU and an FPGA.
>
> The dedicated interface between the parts allow the FPGA access to the
> internal of the MCU (It can become an AHB master),
> so it is decidedly superior to a solution putting the FPGA on the memory
> bus.
>
> The idea is that if you win all those designs in general, you
> also win all high volume designs in particular which can then
> migrate to a mask version,losing the cost of the FPGA.
>
> The NRE to do this is less than 20% of the NRE of a standard cell ASIC
> and the design will be much simpler, so it is expected that the volumes
> mentioned above will really be the starting point.

Can you make some guess on 100K prices and NRE for such, using
QFN 32?

>
> Then again, the price for the custom version is lower than the price for
> the version bonding out the dedicated FPGA interface (due to less pins),
> so Atmels revenue will be higher if they don't do the conversion :-)
>
> > -jg
>
> --
> Best Regards,
> Ulf Samuelsson
> This is intended to be my personal opinion which may,
> or may not be shared by my employer Atmel Nordic AB

"Jim Granville" <no.spam@designtools.maps.co.nz> skrev i meddelandet 
news:46e878e5$1@clear.net.nz...
> Ulf Samuelsson wrote:
>>
>> Actel told us yesterday that the ARM was not really suitable for 
>> inclusion in FPGA...
>> Frequency limited to 29 MHz, and would hardly fit into their smallest 
>> FPGA
>> wihtout peripherals.
>>
>> They believe more in their Cortex-M1, but personally I see few customers
>> where 512 kB flash applications only need a few kB of SRAM.
>> In practice you will need an external SRAM.
>
> Of course, it is not so much an Engineering Solution, as a FPGA Sales 
> Solution - the drive is to sell more/bigger FPGAs, not to solve a pressing 
> design problem (in fact, you create a few : higher Power,
> and much worse EMC, but the market-spin does no mention those! )
>
> For apps where you CANNOT fit the code into a Microcontroller, the
> playing field levels a little, but the speed comes in a distant
> second to the 200MHz+ alternatives.
>
> Of course, Microcontrollers keep getting bigger: 4MByte is one
> data point.
>
>>
>> No way that is going to compete with a std ARM micro for price, 
>> performance and power.
>> You will need that customization urge, to be interested.
>>
>> Any volume business can be handled by products like the AT91CAP stuff
>> which will allow custom chips in realistic distribution volumes (15-25 
>> ku/year)
>
> Do Atmel have any plans to do some point-mask solutions based on this ?
>

The AT91CAP products was conceived as a way to cost effectively bring out 
new
customized AT91 circuits. Now the focus has shifted slightly, but this is 
still a possibility.

The current focus is on winning all designs incorporating
a combination of an MCU and an FPGA.

The dedicated interface between the parts allow the FPGA access to the
internal of the MCU (It can become an AHB master),
so it is decidedly superior to a solution putting the FPGA on the memory 
bus.

The idea is that if you win all those designs in general, you
also win all high volume designs in particular which can then
migrate to a mask version,losing the cost of the FPGA.

The NRE to do this is less than 20% of the NRE of a standard cell ASIC
and the design will be much simpler, so it is expected that the volumes
mentioned above will really be the starting point.

Then again, the price for the custom version is lower than the price for
the version bonding out the dedicated FPGA interface (due to less pins),
so Atmels revenue will be higher if they don't do the conversion :-)




> -jg
>



-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

On Thu, 13 Sep 2007 00:00:35 +0200, "Ulf Samuelsson"
<ulf@a-t-m-e-l.com> wrote in comp.arch.embedded:

> "Jack Klein" <jackklein@spamcop.net> skrev i meddelandet 
> news:9iiee3lpe3la4ea8l5uac51tu0rbdts71o@4ax.com...
> > On Tue, 11 Sep 2007 21:06:02 -0000, ratemonotonic
> > <niladri1979@gmail.com> wrote in comp.arch.embedded:
> >
> >> Hi all,
> >>
> >> I have designed (on paper ) a radio system with the following
> >> components -
> >>
> >> 1) ATmega1280 - Responsible for talking to 3 uarts , the FPGA and
> >> Ethernet controller.
> >> 2) A Xilinx FPGA interfaced with the Atmega - responsible for digital
> >> modulation , demodulation of radio signals.
> >> It also interfaces with the Ethernet controller for high bit rate.
> >>
> >> the decision behind the ATmega was the low power requirements.
> >>
> >> Now I am having second thoughts about this design and am thinking of
> >> FPGA Devices with Soft / Hardcore and scrapping the ATmega. I have
> >> never used a FPGA with CPU core and am not aware of the pros and cons
> >> of it.
> >>
> >> I would be grateful if some experienced person could enlighten me
> >> about it.
> >>
> >> BR
> >> Rate
> >
> > linnix already pointed out the Actel FPGA with soft ARM cores.  I am
> > actually surprised that this has not come up on this group.
> >
> > Both Xilinx and Altera would love for you to use their soft cores,
> > Microblaze and Nios, respectively.  Because the soft core license only
> > allows you to use it on THEIR parts.  It's a form of lock-in.  If you
> > want to change to a competitor's parts, not only do you need new
> > development tools, but you have to change processor cores, too,
> > meaning extra firmware changes.
> >
> > ARM has announced soft core availability for appropriate parts from
> > Xilinx, Altera, and Actel.  Actel gives you the ARM IP license free to
> > use in their parts, because they are the little guy using every
> > advantage they can.
> >
> > Neither Xilinx or Altera even mentions the soft core ARM on their web
> > sites.  They don't promote it, or even tell you it exists.  Why?
> > Because if you use a soft core ARM instead of Microblaze or Nios, it
> > is that much easier and cheaper to move your design to another
> > manufacturer's parts.
> >
> > -- 
> 
> Actel told us yesterday that the ARM was not really suitable for inclusion 
> in FPGA...
> Frequency limited to 29 MHz, and would hardly fit into their smallest FPGA
> wihtout peripherals.
> 
> They believe more in their Cortex-M1, but personally I see few customers
> where 512 kB flash applications only need a few kB of SRAM.
> In practice you will need an external SRAM.
> 
> No way that is going to compete with a std ARM micro for price, performance 
> and power.
> You will need that customization urge, to be interested.
> 
> Any volume business can be handled by products like the AT91CAP stuff
> which will allow custom chips in realistic distribution volumes (15-25 
> ku/year)

Actually, I personally do not have much interest in using a soft core
CPU in an FPGA.  In fact, I don't have any interest at all.

It is a push from some (not all) of our EEs, who think the best way to
do anything and everything is to put everything in an FPGA.  The
biggest pusher is a Xilinx groupie, so of course everybody should do
things his way and use Microblaze.

Personally, I picked ARM as our next generation 32-bit architecture
some years ago, replacing 486.  We've been using Atmel's AT91RM9200
since just about when it first shipped.

But the "Forces of Evil"(tm) keep pushing for soft cores just because
it's "new" technology.

One of the reasons that I picked ARM was the wide range of parts from
a large number of vendors with all sorts of price/performance options,
and all sorts of on-chip peripherals.  And one development tool set
for all of them.

What I dislike most about soft cores from Altera and Xilinx is the
lock in.  You can use one of their soft cores only as long as you use
their FPGA parts.  If you switch from one to the other, you can't take
the soft core with you.  And you basically have only one gcc port and
a very limited selection of off-the-shelf OS/RTOS choices.

That is why, if I have to use a soft core in an FPGA, it would be nice
to have a standard soft core that you could use on any brand of FPGA,
and it would also be nice if there was a wide choice of development
tools and OS/RTOS options for the core.

Which means, if I get forced into using a soft core in an FPGA, having
an ARM soft core would seem to be the best of all possible choices.

But don't worry, Ulf, I am still resisting the "Forces of Evil"(tm)
with all my might, and our second product with a new board using
AT91RM9200 will be shipping by the end of the year.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

Ulf Samuelsson wrote:
> 
> Actel told us yesterday that the ARM was not really suitable for inclusion 
> in FPGA...
> Frequency limited to 29 MHz, and would hardly fit into their smallest FPGA
> wihtout peripherals.
> 
> They believe more in their Cortex-M1, but personally I see few customers
> where 512 kB flash applications only need a few kB of SRAM.
> In practice you will need an external SRAM.

Of course, it is not so much an Engineering Solution, as a FPGA Sales 
Solution - the drive is to sell more/bigger FPGAs, not to solve a 
pressing design problem (in fact, you create a few : higher Power,
and much worse EMC, but the market-spin does no mention those! )

For apps where you CANNOT fit the code into a Microcontroller, the
playing field levels a little, but the speed comes in a distant
second to the 200MHz+ alternatives.

Of course, Microcontrollers keep getting bigger: 4MByte is one
data point.

> 
> No way that is going to compete with a std ARM micro for price, performance 
> and power.
> You will need that customization urge, to be interested.
> 
> Any volume business can be handled by products like the AT91CAP stuff
> which will allow custom chips in realistic distribution volumes (15-25 
> ku/year)

Do Atmel have any plans to do some point-mask solutions based on this ?

-jg

"Jack Klein" <jackklein@spamcop.net> skrev i meddelandet 
news:9iiee3lpe3la4ea8l5uac51tu0rbdts71o@4ax.com...
> On Tue, 11 Sep 2007 21:06:02 -0000, ratemonotonic
> <niladri1979@gmail.com> wrote in comp.arch.embedded:
>
>> Hi all,
>>
>> I have designed (on paper ) a radio system with the following
>> components -
>>
>> 1) ATmega1280 - Responsible for talking to 3 uarts , the FPGA and
>> Ethernet controller.
>> 2) A Xilinx FPGA interfaced with the Atmega - responsible for digital
>> modulation , demodulation of radio signals.
>> It also interfaces with the Ethernet controller for high bit rate.
>>
>> the decision behind the ATmega was the low power requirements.
>>
>> Now I am having second thoughts about this design and am thinking of
>> FPGA Devices with Soft / Hardcore and scrapping the ATmega. I have
>> never used a FPGA with CPU core and am not aware of the pros and cons
>> of it.
>>
>> I would be grateful if some experienced person could enlighten me
>> about it.
>>
>> BR
>> Rate
>
> linnix already pointed out the Actel FPGA with soft ARM cores.  I am
> actually surprised that this has not come up on this group.
>
> Both Xilinx and Altera would love for you to use their soft cores,
> Microblaze and Nios, respectively.  Because the soft core license only
> allows you to use it on THEIR parts.  It's a form of lock-in.  If you
> want to change to a competitor's parts, not only do you need new
> development tools, but you have to change processor cores, too,
> meaning extra firmware changes.
>
> ARM has announced soft core availability for appropriate parts from
> Xilinx, Altera, and Actel.  Actel gives you the ARM IP license free to
> use in their parts, because they are the little guy using every
> advantage they can.
>
> Neither Xilinx or Altera even mentions the soft core ARM on their web
> sites.  They don't promote it, or even tell you it exists.  Why?
> Because if you use a soft core ARM instead of Microblaze or Nios, it
> is that much easier and cheaper to move your design to another
> manufacturer's parts.
>
> -- 

Actel told us yesterday that the ARM was not really suitable for inclusion 
in FPGA...
Frequency limited to 29 MHz, and would hardly fit into their smallest FPGA
wihtout peripherals.

They believe more in their Cortex-M1, but personally I see few customers
where 512 kB flash applications only need a few kB of SRAM.
In practice you will need an external SRAM.

No way that is going to compete with a std ARM micro for price, performance 
and power.
You will need that customization urge, to be interested.

Any volume business can be handled by products like the AT91CAP stuff
which will allow custom chips in realistic distribution volumes (15-25 
ku/year)

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

>>>Hi all,
>>>
>>>I have designed (on paper ) a radio system with the following
>>>components -
>>>
>>>1) ATmega1280 - Responsible for talking to 3 uarts , the FPGA and
>>>Ethernet controller.
>>>2) A Xilinx FPGA interfaced with the Atmega - responsible for digital
>>>modulation , demodulation of radio signals.
>>>It also interfaces with the Ethernet controller for high bit rate.
>>>
>>>the decision behind the ATmega was the low power requirements.
>>>
>>>Now I am having second thoughts about this design and am thinking of
>>>FPGA Devices with Soft / Hardcore and scrapping the ATmega. I have
>>>never used a FPGA with CPU core and am not aware of the pros and cons
>>>of it.
>>>
>>>I would be grateful if some experienced person could enlighten me
>>>about it.
>>>
>>>BR
>>>Rate
>>>
>>
>>
>> You would be better of with the AT32UC3A0128/256/512 AVR32
>> which is low power and has an integrated Ethernet MAC.
>> It also has a significant amount of SRAM on board.
>
> That makes more sense, than Atmega+Ethernet - unless chip-count
> and cost do not matter to you ?
>
> To decide between FPGA + uC, or FPGA+SoftCPU, you do the
> simple maths,
>
> The uC has peripherals - do you need ADC ?
> If yes, add that as external device to FPGA.
>
> The uC has peripherals - do you need UART ?
> If yes, add that Gate count to FPGA.
>
>
> The uC has FLASH included, and a means to PGM it
> Add a external FLASH device to your FPGA, or a SRAM,
> and a larger boot load device.
>
> You now have an external memory BUS, so might need
> more EMC mitigation/more layers. Allow for those costs.
>
> The uC has Brownout detect - do you need that ?
> If yes, add that as external device to FPGA.
>
> Add the SoftCPU gate count, and all the peripherals gate
> counts, and then compare the price delta of the
> two FPGAs indicated. Add the Config Device Delta,
> PCB area/layers, assembly costs, etc,
> and you have your comparisons.
>
> Normally, if you can find a std, volume production, uC
> that WILL do the job, it makes sense to use that. If you HAVE to have 
> external memory on the FPGA anyway, then it is a closer call.
>
> -jg
>


Another issue is Debugging.
Listened to an Actel presentation on Cortex-M1 in FPGA.
They can fit a Cortex into a $4 FPGA (large volume), but if you need 
debugging
then the core size increases so much that you need almost 2 x size,
so I guess the CPU core is about  $8 if you need debugging.




-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

On Sep 12, 1:49 am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> ratemonotonic wrote:
>
> > A really helpful suggestion. The only thing thats not clear to me is
> > the 'Config Device Delta' , do you mean the MCU used to boot the
> > bitstream to the FPGA?
>
> Sorry a bit brief : - with a typical SoftCPU setup, the config device
> ( usually a serial Flash device, as they are cheapest ) needs to be
> larger - to store the CPU itself, and also the code
> that is then loaded into RAM to run.

ProASIC3 is flash based, so you don't need to store the config bits.
However, you do need external program and working memories.  You can
also build a CF/SD boot loader directly from IP cores.

ratemonotonic wrote:

> 
> A really helpful suggestion. The only thing thats not clear to me is
> the 'Config Device Delta' , do you mean the MCU used to boot the
> bitstream to the FPGA?

Sorry a bit brief : - with a typical SoftCPU setup, the config device
( usually a serial Flash device, as they are cheapest ) needs to be 
larger - to store the CPU itself, and also the code
that is then loaded into RAM to run.

  So, the Config device needs to be larger by two factors, and that
will be another cost.
-jg

On 12 Sep, 04:40, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Ulf Samuelsson wrote:
> > "ratemonotonic" <niladri1...@gmail.com> skrev i meddelandet
> >news:1189544762.797677.265590@v23g2000prn.googlegroups.com...
>
> >>Hi all,
>
> >>I have designed (on paper ) a radio system with the following
> >>components -
>
> >>1) ATmega1280 - Responsible for talking to 3 uarts , the FPGA and
> >>Ethernet controller.
> >>2) A Xilinx FPGA interfaced with the Atmega - responsible for digital
> >>modulation , demodulation of radio signals.
> >>It also interfaces with the Ethernet controller for high bit rate.
>
> >>the decision behind the ATmega was the low power requirements.
>
> >>Now I am having second thoughts about this design and am thinking of
> >>FPGA Devices with Soft / Hardcore and scrapping the ATmega. I have
> >>never used a FPGA with CPU core and am not aware of the pros and cons
> >>of it.
>
> >>I would be grateful if some experienced person could enlighten me
> >>about it.
>
> >>BR
> >>Rate
>
> > You would be better of with the AT32UC3A0128/256/512 AVR32
> > which is low power and has an integrated Ethernet MAC.
> > It also has a significant amount of SRAM on board.
>
> That makes more sense, than Atmega+Ethernet - unless chip-count
> and cost do not matter to you ?
>
> To decide between FPGA + uC, or FPGA+SoftCPU, you do the
> simple maths,
>
> The uC has peripherals - do you need ADC ?
> If yes, add that as external device to FPGA.
>
> The uC has peripherals - do you need UART ?
> If yes, add that Gate count to FPGA.
>
> The uC has FLASH included, and a means to PGM it
> Add a external FLASH device to your FPGA, or a SRAM,
> and a larger boot load device.
>
> You now have an external memory BUS, so might need
> more EMC mitigation/more layers. Allow for those costs.
>
> The uC has Brownout detect - do you need that ?
> If yes, add that as external device to FPGA.
>
> Add the SoftCPU gate count, and all the peripherals gate
> counts, and then compare the price delta of the
> two FPGAs indicated. Add the Config Device Delta,
> PCB area/layers, assembly costs, etc,
> and you have your comparisons.
>
> Normally, if you can find a std, volume production, uC
> that WILL do the job, it makes sense to use that. If you HAVE to have
> external memory on the FPGA anyway, then it is a closer call.
>
> -jg- Hide quoted text -
>
> - Show quoted text -

Hi Jim ,

A really helpful suggestion. The only thing thats not clear to me is
the 'Config Device Delta' , do you mean the MCU used to boot the
bitstream to the FPGA?

BR
Rate