Silicon Blue last datesheet correct URL

Hi

the datasheet has been updated 18 march but the download link doesnt
work from SBT web,
correct URL is

http://www.siliconbluetech.com/media/iCE65Datasheet.pdf

Antti

Antti and others,

This may be covered by another thread, in which case I would
appreciate a link.

What are your thoughts on the Silicon Blue devices?  How is it to use
their tools?

Sephen

On Mar 23, 3:28=A0pm, Stephen Craven <stephen.cra...@gmail.com> wrote:
> Antti and others,
>
> This may be covered by another thread, in which case I would
> appreciate a link.
>
> What are your thoughts on the Silicon Blue devices? =A0How is it to use
> their tools?
>
> Sephen

OK, here it is

1) new project
2) add vhdl, verilog files
3) click constraints
4) select signals and IO locs from dropdown
5) close constraints window
6) click run flow
7) start SB backend tools
8) click programmer
9) click program

the tools are not as sophiscated as the bigones,
but they do generate bit files.. for me that all that matters.

there are some small news that are maybe not so known
1) all devices are now offered with nonvolatile storage (no more -V
parts)
2) the current numbers are reduces down, the smallest part at 32khz
8uA (was 25 i think)

sure as everything is pretty new still there are some problems, like
the hex files generated
use lower case ascii and Keil's hex2bin chokes on that :) so i had to
write another conversion
well actually i didnt, i added support for ascii-bin format to my
portable SPI flash programmer

http://www.microfpga.com/

i just got the LED blinking on the Silicon Blue stamp, not that it is
big achievement
but it is possible first public photo of an SB FPGA based product
ever :)

I am doing the factory boot image for the SB stamp, that should allow
user
configurations to be downloaded over UART/SPI or then loaded from SD
card

there is still some confusion with the warmboot what i hope to solve
soon
as well. besides the warmboot most other functions of the FPGA are
tested, that is block ram init, etc

Antti
PS I will write some more in March issue of the Brain...

I was reading the data sheet the other day and I noticed that these
parts have 5 volt compatible I/Os on three of the four banks.  I'm
pretty impressed with that... until I read that the fourth bank is not
even 3.3 volt tolerant!!!  What's up with that?  Can do 5 volts on
three banks and fourth can only do 2.5 just seems like a very strange
combination.  I can't for the life of me understand why or how this
was done.  Obviously there was some compelling reason to do this and I
can only speculate that it was because of the additional I/O types in
bank 3.  Still, taking away from the number of 3.3 volt I/Os is a
*very* poor marketing decision in my opinion.  Now I would have to use
a larger package to get the same number of *usable* I/O pins.

The other oddity I found was the lack of parity bits in the RAM
blocks.  There are a lot of designs that use the extra bits, including
mine, that won't fit on these parts at all.

One other thing I noticed, they seem to be changing the planned
packaging, which is not surprising I suppose.  In the package list,
they flag compatible pinouts using the same package.  But I don't see
the 04 and 08 as being compatible in the 196 pin package.  This
package was added since rev 1.1 of the data sheet, so it is surprising
to me that these would not be compatible.

The CS132 package looks pretty interesting.  The main reason that I
avoid BGAs is the PCB requirements to provide routing from the inner
pins.  This package looks like it might be routable without running
traces between the pads or even vias within the pads.  But the
innermost 16 pads seem to mess this up.  Anyone have a good routing
layout for this package?  What PCB design rules are required to use
this package?

Rick


On Mar 23, 10:12 am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 23, 3:28 pm, Stephen Craven <stephen.cra...@gmail.com> wrote:
>
> > Antti and others,
>
> > This may be covered by another thread, in which case I would
> > appreciate a link.
>
> > What are your thoughts on the Silicon Blue devices?  How is it to use
> > their tools?
>
> > Sephen
>
> OK, here it is
>
> 1) new project
> 2) add vhdl, verilog files
> 3) click constraints
> 4) select signals and IO locs from dropdown
> 5) close constraints window
> 6) click run flow
> 7) start SB backend tools
> 8) click programmer
> 9) click program
>
> the tools are not as sophiscated as the bigones,
> but they do generate bit files.. for me that all that matters.
>
> there are some small news that are maybe not so known
> 1) all devices are now offered with nonvolatile storage (no more -V
> parts)
> 2) the current numbers are reduces down, the smallest part at 32khz
> 8uA (was 25 i think)
>
> sure as everything is pretty new still there are some problems, like
> the hex files generated
> use lower case ascii and Keil's hex2bin chokes on that :) so i had to
> write another conversion
> well actually i didnt, i added support for ascii-bin format to my
> portable SPI flash programmer
>
> http://www.microfpga.com/
>
> i just got the LED blinking on the Silicon Blue stamp, not that it is
> big achievement
> but it is possible first public photo of an SB FPGA based product
> ever :)
>
> I am doing the factory boot image for the SB stamp, that should allow
> user
> configurations to be downloaded over UART/SPI or then loaded from SD
> card
>
> there is still some confusion with the warmboot what i hope to solve
> soon
> as well. besides the warmboot most other functions of the FPGA are
> tested, that is block ram init, etc
>
> Antti
> PS I will write some more in March issue of the Brain...

On Mar 22, 6:32=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi
>
> the datasheet has been updated 18 march but the download link doesnt
> work from SBT web,
> correct URL is
>
> http://www.siliconbluetech.com/media/iCE65Datasheet.pdf
>
> Antti

BTW, when I downloaded this file, I noticed that this is version 1.4.3
data March 9, while there is a 1.4.4 dated March 18.

Rick

On Mar 23, 6:01=A0pm, rickman <gnu...@gmail.com> wrote:
> I was reading the data sheet the other day and I noticed that these
> parts have 5 volt compatible I/Os on three of the four banks. =A0I'm
> pretty impressed with that... until I read that the fourth bank is not
> even 3.3 volt tolerant!!! =A0What's up with that? =A0Can do 5 volts on
> three banks and fourth can only do 2.5 just seems like a very strange
> combination. =A0I can't for the life of me understand why or how this
> was done. =A0Obviously there was some compelling reason to do this and I
> can only speculate that it was because of the additional I/O types in
> bank 3. =A0Still, taking away from the number of 3.3 volt I/Os is a
> *very* poor marketing decision in my opinion. =A0Now I would have to use
> a larger package to get the same number of *usable* I/O pins.
>
> The other oddity I found was the lack of parity bits in the RAM
> blocks. =A0There are a lot of designs that use the extra bits, including
> mine, that won't fit on these parts at all.
>
> One other thing I noticed, they seem to be changing the planned
> packaging, which is not surprising I suppose. =A0In the package list,
> they flag compatible pinouts using the same package. =A0But I don't see
> the 04 and 08 as being compatible in the 196 pin package. =A0This
> package was added since rev 1.1 of the data sheet, so it is surprising
> to me that these would not be compatible.
>
> The CS132 package looks pretty interesting. =A0The main reason that I
> avoid BGAs is the PCB requirements to provide routing from the inner
> pins. =A0This package looks like it might be routable without running
> traces between the pads or even vias within the pads. =A0But the
> innermost 16 pads seem to mess this up. =A0Anyone have a good routing
> layout for this package? =A0What PCB design rules are required to use
> this package?
>
> Rick

Hi

yes 5V tolerant !! yipiie jee, and bank-3 unusuable unless 2.5V supply
is available
its not only that it is not 3.3V tolerant, you need 2.5V if you want
to use this bank at all,
so in both my current design bank-3 is unused and VCCIO3 is open
i bet that bank 3 uses completly different IO cell, hence the voltage
requirements

http://www.microfpga.com/

both PCBs are 2 layer, no microvia, no trace between pads, no via in
pad,
no via between pads (but vias below the package where spacing areas
available)
smallest drilled hole 0.3mm

but the number of IOs routable on 2 layers is limited, for both those
FPGA's in 132 8x8 package the number of ios routable out in 2 layers
is something between 40 and 50

Antti

rickman <gnuarm@gmail.com> wrote:
> I was reading the data sheet the other day and I noticed that these
> parts have 5 volt compatible I/Os on three of the four banks.  I'm
> pretty impressed with that... until I read that the fourth bank is not
> even 3.3 volt tolerant!!!  What's up with that?  Can do 5 volts on
> three banks and fourth can only do 2.5 just seems like a very strange
> combination.  

I don't know about this one specifically, but there is
a well known tradeoff between voltage and speed.  It might
be that those are used when speed is important.

-- glen

On Mar 24, 4:01=A0am, rickman <gnu...@gmail.com> wrote:
> I was reading the data sheet the other day and I noticed that these
> parts have 5 volt compatible I/Os on three of the four banks. =A0I'm
> pretty impressed with that... until I read that the fourth bank is not
> even 3.3 volt tolerant!!! =A0What's up with that? =A0Can do 5 volts on
> three banks and fourth can only do 2.5 just seems like a very strange
> combination. =A0I can't for the life of me understand why or how this
> was done. =A0Obviously there was some compelling reason to do this and I
> can only speculate that it was because of the additional I/O types in
> bank 3. =A0Still, taking away from the number of 3.3 volt I/Os is a
> *very* poor marketing decision in my opinion. =A0Now I would have to use
> a larger package to get the same number of *usable* I/O pins.

The newest Xilinx parts drop 3.3V I believe ?
- but yes, on a small part that includes 5V, missing 3.3V on a bank,
looks more like a mistake, than a design-decision!.
5V IO is nice, especially on smaller parts.

5V is making something of a comeback,  more uC are now 5V too :)

Dropping 5V on small parts is never a good decision....

Power MOSFETS are lousy driven from 3.3V !

-jg



.

> yes 5V tolerant !! yipiie jee, and bank-3 unusuable unless 2.5V supply
> is available
> its not only that it is not 3.3V tolerant, you need 2.5V if you want
> to use this bank at all,
> so in both my current design bank-3 is unused and VCCIO3 is open
> i bet that bank 3 uses completly different IO cell, hence the voltage
> requirements

But isn't 2.5V always available ?
"VPP_2V5 must always be connected to a valid voltage."

I see it tolerates 2.3-3.0V, and B3 is 2.63V (abs Max 3.0) so perhaps
a new standard
of 2.65V could power the part ? :)

The Bank3 does support MDDR, so that seems to be what chopped the 3.3V


-jg

On Mar 24, 2:05=A0am, -jg <Jim.Granvi...@gmail.com> wrote:
> > yes 5V tolerant !! yipiie jee, and bank-3 unusuable unless 2.5V supply
> > is available
> > its not only that it is not 3.3V tolerant, you need 2.5V if you want
> > to use this bank at all,
> > so in both my current design bank-3 is unused and VCCIO3 is open
> > i bet that bank 3 uses completly different IO cell, hence the voltage
> > requirements
>
> But isn't 2.5V always available ?
> "VPP_2V5 must always be connected to a valid voltage."
>
> I see it tolerates 2.3-3.0V, and B3 is 2.63V (abs Max 3.0) so perhaps
> a new standard
> of 2.65V could power the part ? :)
>
> The Bank3 does support MDDR, so that seems to be what chopped the 3.3V
>
> -jg

Jim

VPP_2V5 tolerated 3.3V
so just happily connect 3.3V no need for 2.5 to be always present

Antti