what are your current SoC design for ?

I don't need your IP secrecies...

This is for my students : what, in your current design, requires using
a fpga + softcore, in place of a COTS micro controler ?
less IC -> lower footprint, lower power cons., parallelism,...

thanks,
raph

rponsard@gmail.com wrote:
> I don't need your IP secrecies...
>
> This is for my students : what, in your current design, requires using
> a fpga + softcore, in place of a COTS micro controler ?
> less IC -> lower footprint, lower power cons., parallelism,...

The first two.

Cheers,
Jon

can you describe a little more your app...

On Dec 13, 1:03 pm, "Jon Beniston" <j...@beniston.com> wrote:
> rpons...@gmail.com wrote:
> > I don't need your IP secrecies...
>
> > This is for my students : what, in your current design, requires using
> > a fpga + softcore, in place of a COTS micro controler ?
> > less IC -> lower footprint, lower power cons., parallelism,...The first two.
> 
> Cheers,
> Jon

rponsard@gmail.com schrieb:
> I don't need your IP secrecies...
> 
> This is for my students : what, in your current design, requires using
> a fpga + softcore, in place of a COTS micro controler ?
> less IC -> lower footprint, lower power cons., parallelism,...

I/O Bandwidth.

Kolja Sulimma

<rponsard@gmail.com> ha scritto nel messaggio 
news:1166010235.979393.32660@16g2000cwy.googlegroups.com...
>I don't need your IP secrecies...
>
> This is for my students : what, in your current design, requires using
> a fpga + softcore, in place of a COTS micro controler ?
> less IC -> lower footprint, lower power cons., parallelism,...
>
> thanks,
> raph
>

Chip customization VS asic project.

Marco 

rponsard@gmail.com wrote:
> I don't need your IP secrecies...
> 
> This is for my students : what, in your current design, requires using
> a fpga + softcore, in place of a COTS micro controler ?
> less IC -> lower footprint, lower power cons., parallelism,...

There are two levels of softCPU apps :
a) The tiny ones, where the code fits inside the FPGA, in BRAM.
b) The larger ones, that need external code memory.

For a) the SoftCPU comes almost for free, and can be used to
handle less time-critical tasks, and give a degree of
programmability to all the other FPGA coded peripherals.
Or they may be DSP(s), doing focused tasks.

Unless you need ADCs / DACs, or similar peripherals, these
do meet the lower footprint consideration.

For b) once you have to add Code memory, you've lost the 'single chip', 
and the interface between the memory/fpga is poor for RFI & pin count.

  Now it's becomes less clear-cut on which is better, and
the choice swings somewhat, as each alternative goes thru
generation cycles, or as code size changes.
  If your code CAN fit into an external 32 bit uC, and meet
speed targets, the tight local bus Code-CPU, gives the uC
quite an edge.
  Better 32 bit uC now have DMA SSC channels, so FPGA
interfaces can have low pin counts, and they have quite
impressive FLASH resource, so the SoftCPU can struggle
against this growing option.
Leading example: Atmels upcomming AT91SAM9XE512 Flash uC.

  Once your app gets so large (MBytes), that is has outgrown uC Flash,
and it needs SDRAM to run, then it swings more balanced.
SDRAM uC are appearing, but not widely yet (example: AT91SAM9263),
and both choices have PCB traces to SDRAM, so there less of a clear edge.

Also, show your students this:
http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=HAHXOJ0RM2UHYQSNDLSCKHA?articleID=196603670

Details are presently sketchy, but a large dual port memory that was not 
niche-priced, would be interesting indeed to FPGA + SoftCPU + uC trade offs.

-jg

Jim Granville wrote:
> rponsard@gmail.com wrote:
> > I don't need your IP secrecies...
> >
> > This is for my students : what, in your current design, requires using
> > a fpga + softcore, in place of a COTS micro controler ?
> > less IC -> lower footprint, lower power cons., parallelism,...
>
> There are two levels of softCPU apps :
> a) The tiny ones, where the code fits inside the FPGA, in BRAM.
> b) The larger ones, that need external code memory.
>
> For a) the SoftCPU comes almost for free, and can be used to
> handle less time-critical tasks, and give a degree of
> programmability to all the other FPGA coded peripherals.
> Or they may be DSP(s), doing focused tasks.
>
> Unless you need ADCs / DACs, or similar peripherals, these
> do meet the lower footprint consideration.
>
> For b) once you have to add Code memory, you've lost the 'single chip',
> and the interface between the memory/fpga is poor for RFI & pin count.
>
>   Now it's becomes less clear-cut on which is better, and
> the choice swings somewhat, as each alternative goes thru
> generation cycles, or as code size changes.
>   If your code CAN fit into an external 32 bit uC, and meet
> speed targets, the tight local bus Code-CPU, gives the uC
> quite an edge.
>   Better 32 bit uC now have DMA SSC channels, so FPGA
> interfaces can have low pin counts, and they have quite
> impressive FLASH resource, so the SoftCPU can struggle
> against this growing option.
> Leading example: Atmels upcomming AT91SAM9XE512 Flash uC.
>
>   Once your app gets so large (MBytes), that is has outgrown uC Flash,
> and it needs SDRAM to run, then it swings more balanced.
> SDRAM uC are appearing, but not widely yet (example: AT91SAM9263),
> and both choices have PCB traces to SDRAM, so there less of a clear edge.
>
> Also, show your students this:
> http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=HAHXOJ0RM2UHYQSNDLSCKHA?articleID=196603670
>
> Details are presently sketchy, but a large dual port memory that was not
> niche-priced, would be interesting indeed to FPGA + SoftCPU + uC trade offs.
>
> -jg

Aye, if you require external memory, you do no longer have a single
chip solution. However, note that the Spartan 3e can boot from a NOR
Flash memory. You can configure from one end of the device, and store
your application in the other. I'm not sure if the Virtex 5's support
this feature or not, but it is quite handy on the spartan 3e sample
pack board.

radarman schrieb:

> Jim Granville wrote:
> > rponsard@gmail.com wrote:
> > > I don't need your IP secrecies...
> > >
> > > This is for my students : what, in your current design, requires using
> > > a fpga + softcore, in place of a COTS micro controler ?
> > > less IC -> lower footprint, lower power cons., parallelism,...
> >
> > There are two levels of softCPU apps :
> > a) The tiny ones, where the code fits inside the FPGA, in BRAM.
> > b) The larger ones, that need external code memory.
> >
> > For a) the SoftCPU comes almost for free, and can be used to
> > handle less time-critical tasks, and give a degree of
> > programmability to all the other FPGA coded peripherals.
> > Or they may be DSP(s), doing focused tasks.
> >
> > Unless you need ADCs / DACs, or similar peripherals, these
> > do meet the lower footprint consideration.
> >
> > For b) once you have to add Code memory, you've lost the 'single chip',
> > and the interface between the memory/fpga is poor for RFI & pin count.
> >
> >   Now it's becomes less clear-cut on which is better, and
> > the choice swings somewhat, as each alternative goes thru
> > generation cycles, or as code size changes.
> >   If your code CAN fit into an external 32 bit uC, and meet
> > speed targets, the tight local bus Code-CPU, gives the uC
> > quite an edge.
> >   Better 32 bit uC now have DMA SSC channels, so FPGA
> > interfaces can have low pin counts, and they have quite
> > impressive FLASH resource, so the SoftCPU can struggle
> > against this growing option.
> > Leading example: Atmels upcomming AT91SAM9XE512 Flash uC.
> >
> >   Once your app gets so large (MBytes), that is has outgrown uC Flash,
> > and it needs SDRAM to run, then it swings more balanced.
> > SDRAM uC are appearing, but not widely yet (example: AT91SAM9263),
> > and both choices have PCB traces to SDRAM, so there less of a clear edge.
> >
> > Also, show your students this:
> > http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=HAHXOJ0RM2UHYQSNDLSCKHA?articleID=196603670
> >
> > Details are presently sketchy, but a large dual port memory that was not
> > niche-priced, would be interesting indeed to FPGA + SoftCPU + uC trade offs.
> >
> > -jg
>
> Aye, if you require external memory, you do no longer have a single
> chip solution. However, note that the Spartan 3e can boot from a NOR
> Flash memory. You can configure from one end of the device, and store
> your application in the other. I'm not sure if the Virtex 5's support
> this feature or not, but it is quite handy on the spartan 3e sample
> pack board.

xilinx config evolution

s3e - NOR config, multi-boot, 2 bit files, can init reconfig from
opposite direction
v5 NOR config, can select new boot address
s3a NOR config, can select new boot address, can change reboot mode, eg
start from SPI loc 0, then reboot to some location from NOR flash, then
reboot again from different address in SPI, etc.

v5,s3a also have watchdog timers

Antti

rponsard@gmail.com wrote:
> I don't need your IP secrecies...
> 
> This is for my students : what, in your current design, requires using
> a fpga + softcore, in place of a COTS micro controler ?
> less IC -> lower footprint, lower power cons., parallelism,...
> 
> thanks,
> raph
> 

Fewer ICs? Yes - why have a $3 I2C PROM and a $5 microcontroller with 
the extra manufacturability programming bother when they can be emulated 
using a spare BRAM or two and 200 slices in a $40 FPGA that's already 
there for high-bandwidth signal processing?

Lower power? Yes - sort of: more in the form of not needing an extra 
power regulator, clock source and other such items for the external 
microcontroller

Parallelism? No - a soft core sounds like a pretty lousy choice for pure 
software parallelism... you might need to fill an XC5V330LX with 
microblazes to match modern CPUs. High-performance algorithms in FPGAs 
are much better served with pipelined parallelized logic implementations.

Other reasons?
- Cost: if the microcontroller core fits, it is practically free
- Cost: an integrated microcontroler does not need IOs to interface with 
internal logic
- Simplicity: an integrated microcontroller is easier to interface (no 
need to manage tristate IOs)
- Simplicity: an integrated microcontroller can be customized
- Simplicity: auxiliary microcontroller functions can be implemented in 
logic
- Flexibility: all of the above
- Flexibility: No compromising with multi-function pins
- Performance, bandwidth, latency, etc.
- If I had time, I could probably list over 100 reasons

I have often been very frustrated with multi-function pins on 
off-the-shelf chips where two features I want often end up being 
mutually exclusive on most reasonably sized devices. With soft cores, 
nobody ever has to face this irritating limitation of hard-wired logic.

As a PhD student researching soft cores, I'd love to hear a little more
of the 100-long list of advantages.  Also if you have any insight into
"typical uses" of a soft core that would also be very insightful.

Thanks.


On Dec 17 2006, 11:46 pm, "Daniel S."
<digitalmastrmind_no_s...@hotmail.com> wrote:
> rpons...@gmail.com wrote:
> > I don't need your IP secrecies...
>
> > This is for my students : what, in your current design, requires using
> > a fpga + softcore, in place of a COTS micro controler ?
> > less IC -> lower footprint, lower power cons., parallelism,...
>
> > thanks,
> > raphFewer ICs? Yes - why have a $3 I2C PROM and a $5 microcontroller with
> the extra manufacturability programming bother when they can be emulated
> using a spare BRAM or two and 200 slices in a $40 FPGA that's already
> there for high-bandwidth signal processing?
>
> Lower power? Yes - sort of: more in the form of not needing an extra
> power regulator, clock source and other such items for the external
> microcontroller
>
> Parallelism? No - a soft core sounds like a pretty lousy choice for pure
> software parallelism... you might need to fill an XC5V330LX with
> microblazes to match modern CPUs. High-performance algorithms in FPGAs
> are much better served with pipelined parallelized logic implementations.
>
> Other reasons?
> - Cost: if the microcontroller core fits, it is practically free
> - Cost: an integrated microcontroler does not need IOs to interface with
> internal logic
> - Simplicity: an integrated microcontroller is easier to interface (no
> need to manage tristate IOs)
> - Simplicity: an integrated microcontroller can be customized
> - Simplicity: auxiliary microcontroller functions can be implemented in
> logic
> - Flexibility: all of the above
> - Flexibility: No compromising with multi-function pins
> - Performance, bandwidth, latency, etc.
> - If I had time, I could probably list over 100 reasons
>
> I have often been very frustrated with multi-function pins on
> off-the-shelf chips where two features I want often end up being
> mutually exclusive on most reasonably sized devices. With soft cores,
> nobody ever has to face this irritating limitation of hard-wired logic.