Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 139250

Article: 139250
Subject: Flow Control
From: Essy <ehsan.hosseini@gmail.com>
Date: Tue, 24 Mar 2009 04:33:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

In my design I have a number of blocks (five) which should be cascaded
together. The first block is the data source which can be continuos or
paused whenever required. Each block receives a packet of data and
after processing passes it to the next block. Since the packet sizes
at each stage are different, the whole design cannot work in a
continuos manner (the transfer of packets at different stages requires
different number of clocks).

The very simple solution would be to receive a packet from the source
and wait until the last stage finishes the process. Obviously, this
reduces the overall throughput significantly. I'm sure that this
problem has been addressed by others ages ago (probably those working
in the network field), but I wanted to see what the FPGA guys do in
this case (or maybe I'm a little lazy to look for it ;)

Article: 139251
Subject: flash controller
From: superwolfish <superwolfish@gmail.com>
Date: Tue, 24 Mar 2009 04:35:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi everybody,

i need some Mbits of flash storage, and i need them to be controlled
from a fpga.
I'm using Xilinx tools. Is the memory controller MIG from "IP Core
generator" suitable to control NOR FLASH memory?
I only see the options DDR ans DDR2 when configuring MIG.

I'm not using microblaze nor picoblaze. And i need to read and to
write the flash at very different times, that is, not simultaneously.


Thanks in advance,
Joe.


Article: 139252
Subject: Re: Silicon Blue last datesheet correct URL
From: rickman <gnuarm@gmail.com>
Date: Tue, 24 Mar 2009 07:03:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 6:20=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
> > None of this relates to the issue of the I/O voltages. =A0There are 5
> > volt functioning transistors on the die and it is pretty clear that
> > the I/O driver circuits are designed by SiBlue. =A0So far I don't see
> > any of the discussion about oxide thickness to be relevant.
>
> Oxide thickness is the most important factor in
> determining the transistor voltage. =A0That said, we really
> don't know anything about the design of the transistors,
> so, yes, there isn't much reason to discuss it.
>
> -- glen

Isn't the data sheet an indicator???

Rick

Article: 139253
Subject: chipscope pro 9.2i can't triger immediately !
From: "guards" <guards@126.com>
Date: Tue, 24 Mar 2009 09:11:02 -0500
Links: << >>  << T >>  << A >>
Hello friends , I need your help !
I am using chipscope pro 9.2i ,and it can't triger now !
It can't triger immediately 
the state shows "Waiting for triger ,Sample buffer has zero samples(0%)"
I'm sure the sample clock is right ,the evidence is that when I push
reset
on my board ,it shows
"Waiting for triger ,Sample buffer has zero samples(0%),slow or stop
clock"
I think there may be a problem in the implement design ,but I don't know
what it  exactly is.
Did anyone have a similar problem?




Article: 139254
Subject: Can the complex DSP archetecture based on FPGA+DSP be replaced by FPGA
From: "zhj1985" <zhanghaojun1985@hotmail.com>
Date: Tue, 24 Mar 2009 09:11:12 -0500
Links: << >>  << T >>  << A >>
Generally, the most popular DSP archetecture which focused on complex
digital signal processing is based on DSP +FPGA. FPGA is often used as a
coprocessor for a DSP because those PowerPC 440 cores aren't as fast as DSP
and those algorithms which are developed by C language can be developped
more easily than those developed by Verilog or VHDL language.

However, as the time goes, FPGA has developped fast in recent years. I
want to ask that whether those complex digital system which was based on
DPS+FPGA can be replaced by FPGA now. And if it is, then how can I do that?
I know Xilinx has developed those software such as system generator, but I
don't know whether it can work out. Does anybody know where I can get more
information about those things(By the way, I use Xilinx products)? Thanks. 




Article: 139255
Subject: Re: FPGAs in automotive apps (was Re: Silicon Blue last datesheet
From: rickman <gnuarm@gmail.com>
Date: Tue, 24 Mar 2009 07:15:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 5:02=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> rickman <gnu...@gmail.com> writes:
> > That makes some sense I suppose. =A0But the automotive market is not
> > one of the places I would expect to see many FPGAs. =A0Even if they
> > are low power, why does an auto maker need the flexibility of
> > reconfiguration? =A0Their volumes are high enough that they can spin
> > low cost ASICs at large feature sizes which keeps the NRE down
> > compared to FPGAs.
>
> You might be surprised :) (sorry if this is a bit blatant, but it's on
> topic...http://www.conekt.net/fpgas-for-ldw.html)
>
> And being able to reconfigure is not a bad thing - we also use a lot
> of flash micros, rather than ROMming everything.

Yup, it makes sense when the cost of reconfigurability is just the
cost of the memory.  But does it make sense when reconfigurability
makes the logic cost 10 times as much?

I looked at your web page and I expect this is a prototype, no?  Do
you plan to go into production with a $10+ FPGA when you could use a
$2 ASIC?  But then again, a "Lane Departure Warning System" wouldn't
really be installed in many autos would it?  At least, not until the
cost comes down by using ASICs instead of FPGAs...

Am I wrong about this?


> > Autos are using a lot of DSP and higher end embedded processors.
> > Otherwise, I don't see autos pushing semi technology. =A0Yeah, chips
> > will be made to fit all those sockets, but the use of technology is
> > mainly to cut the cost to the bone and FPGAs will never fit that
> > socket.
>
> You can get an awful lot of FPGA for the price of a DSP these days.
> And if you've been thinking highly parallel all the way through
> development, you can do a lot more with them (IMHO :)

Yes, but what can you do in an FPGA that you can't do in an ASIC, even
just a gate array, that wouldn't be much cheaper in high quantities?
Sure, the costs of FPGAs have come down over the years and there are
clearly some reasons to use FPGA, even in some high volume products.
But I don't see any of those reasons applying to auto usage other than
perhaps "special" features that you only see in Cadillacs and high end
Mercedes.

I'm happy to be corrected.  I just don't see where autos are an
application where FPGAs will have much of a market for the foreseeable
future.  What feature of FPGAs make them a primary solution for a high
volume automotive product?

Rick

Article: 139256
Subject: Re: Flow Control
From: Muzaffer Kal <kal@dspia.com>
Date: Tue, 24 Mar 2009 08:04:31 -0700
Links: << >>  << T >>  << A >>
On Tue, 24 Mar 2009 04:33:49 -0700 (PDT), Essy
<ehsan.hosseini@gmail.com> wrote:

>Hi,
>
>In my design I have a number of blocks (five) which should be cascaded
>together. The first block is the data source which can be continuos or
>paused whenever required. Each block receives a packet of data and
>after processing passes it to the next block. Since the packet sizes
>at each stage are different, the whole design cannot work in a
>continuos manner (the transfer of packets at different stages requires
>different number of clocks).
>
>The very simple solution would be to receive a packet from the source
>and wait until the last stage finishes the process. Obviously, this
>reduces the overall throughput significantly. I'm sure that this
>problem has been addressed by others ages ago (probably those working
>in the network field), but I wanted to see what the FPGA guys do in
>this case (or maybe I'm a little lazy to look for it ;)

The simplest way to start would be to add flow control to each block
so that each block can be paused at the output whenever required. This
at least gives you a pipeline of 4 packets. 
If you want/need higher performance (and if you put a little thought
into the design of inter-block flow control ahead of time) you can go
into each block and increase the granularity of flow control at the
input and data availability at the output to get a more smoothly
flowing data stream to increase throughput and reduces latency.

Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

Article: 139257
Subject: Re: flash controller
From: gabor <gabor@alacron.com>
Date: Tue, 24 Mar 2009 08:40:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 7:35=A0am, superwolfish <superwolf...@gmail.com> wrote:
> Hi everybody,
>
> i need some Mbits of flash storage, and i need them to be controlled
> from a fpga.
> I'm using Xilinx tools. Is the memory controller MIG from "IP Core
> generator" suitable to control NOR FLASH memory?
> I only see the options DDR ans DDR2 when configuring MIG.
>
> I'm not using microblaze nor picoblaze. And i need to read and to
> write the flash at very different times, that is, not simultaneously.
>
> Thanks in advance,
> Joe.

MIG is not made for NOR flash (or any flash memory).  NOR
flash is very simple to use.  Take a look at the datasheet
for the part you're planning to use.  Its interface is
probably easier to grasp than the user interface side of MIG.

Regards,
Gabor

Article: 139258
Subject: Re: Silicon Blue last datesheet correct URL
From: rickman <gnuarm@gmail.com>
Date: Tue, 24 Mar 2009 09:02:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 23, 12:13=A0pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> 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 us=
e
> > 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, includin=
g
> > 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

I would like to see how you routed this part.  Can you share the
artwork, or at least the portion around the BGA?

Rick

Article: 139259
Subject: Re: Can the complex DSP archetecture based on FPGA+DSP be replaced by
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Tue, 24 Mar 2009 09:27:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 24 mar, 10:11, "zhj1985" <zhanghaojun1...@hotmail.com> wrote:
> Generally, the most popular DSP archetecture which focused on complex
> digital signal processing is based on DSP +FPGA. FPGA is often used as a
> coprocessor for a DSP because those PowerPC 440 cores aren't as fast as DSP
> and those algorithms which are developed by C language can be developped
> more easily than those developed by Verilog or VHDL language.
>
> However, as the time goes, FPGA has developped fast in recent years. I
> want to ask that whether those complex digital system which was based on
> DPS+FPGA can be replaced by FPGA now. And if it is, then how can I do that?
> I know Xilinx has developed those software such as system generator, but I
> don't know whether it can work out. Does anybody know where I can get more
> information about those things(By the way, I use Xilinx products)? Thanks.

Sure they can, it depends on your application. There are no easy
answers, though. System Generator is a good tool, it's incomplete for
signal processing development imo. Synplify DSP or Accel DSP are
better tools (more expensive though).

If your processing requirements can be met with a DSP or even a
general purpose processor, I recommend you use one. If you need more
power, then yes an FPGA might be better.

Article: 139260
Subject: Re: Silicon Blue Warm-Boot not working properly
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 24 Mar 2009 09:32:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 22, 2:13=A0am, Prevailing over Technology <steve.kn...@prevailing-
technology.com> wrote:
> On Mar 20, 3:23=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
>
> > Hi
>
> > I know this is too much to hope solution, but maybe..
>
> > the winter 2008 SBT tools seem to generate a multi boot header for
> > cold boot only (works ok)
>
> > trying warm-boot with the same multiboot applet doesnt seem to work
> > however :(
>
> > any help?
> > (yes i have submitted help request to SBT)
>
> > Antti
>
> Hi Antti,
>
> Make sure that you have at least iCEcube 2008.12.sp1, which is
> available for download from the SiliconBlue web site.http://www.siliconbl=
uetech.com/iCECube_development_software.aspx
>
> For WarmBoot to work, you also need to instantiate the SB_WARBOOT
> primitive and connect up the select lines (pointing to one of four
> configuration images stored in SPI FlashPROM) and the active-High BOOT
> signal that trigger reconfiguration. =A0The BOOT signal needs to be High
> for 200 ns or more to be recognized.
>
> =A0 =A0 SB_WARMBOOT SB_WARMBOOT_inst (
> =A0 =A0 =A0 =A0 .S1(<select1>),
> =A0 =A0 =A0 =A0 .S0(<select2>),
> =A0 =A0 =A0 =A0 .BOOT(<activeHiTrigger>)
> =A0 =A0 );
>
> When you generate the configuration image, you then need to load the
> WarmBoot bitstreams for each of the four select values (S[1:0]).
>
> I haven't tried this in hardware myself. =A0I did make it work with an
> earlier version of iCEcube by handcrafting a bitstream.
>
> -- Steve Knapp
> =A0 =A0Prevailing Technology, Inc.
> =A0 =A0www.prevailing-technology.com

I am now trying with 12.SP1 and equally without luck :(

coldboot works so the images in the flash must be correct - right?
and the tools do not produce different boot applet for warmboot, so i
am using the same flash image, is that ok?

but as soon as i set BOOT active to the warmboot primitive, it does
force reconfiguration, but the done need
asserts after that, ever..

i tried to patch the hex file myself too, but so far no luck

from your comments it was not so sure, did you actually got it to work
with real hardware? (with older tools)?

i am testing on very early iceMAN65 rev B serial number "5"

i can test on other newer silicon too but i think the warmboot does
work on early ES samples too?

Antti



















Article: 139261
Subject: Re: Silicon Blue last datesheet correct URL
From: Prevailing over Technology <steve.knapp@prevailing-technology.com>
Date: Tue, 24 Mar 2009 09:36:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 23, 9: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? =A0

[snip]

I've talked to them about that also.  All I can say at this point is
watch this space.  I think they plan on some sort of 3.3V support in I/
O Bank 3.

[snip]

> 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 'L04 and 'L08 are _almost_ pin compatible in the 196-pin package.
There is a table on page 62 in the data sheet that shows the
differences.  The real differences are if you use differential I/O and
if you use the Global Buffer INput (GBIN) pins in banks 2 and 3.  If
you use single-ended I/O and direct clock inputs in those banks, then
both devices are pin compatible in the 196-pin package.

> 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?

There are some examples layouts from the iCEman65 development board.
The board uses the 284-ball chip-scale BGA package (CB284) which is a
superset of the 132-ball package (CB132).  The inner balls are
identical.

A PDF version of the layout appears in the user guide beginning on
page 44.
http://www.siliconbluetech.com/media/iCEmanBoardUserGuide.pdf

The Gerber files are available as well.  Note that the link on their
website apparently points to an old version (Should be Rev. D).
http://www.siliconbluetech.com/media/iCEman65GerbersRevB.zip

-- Steven K. Knapp
   Prevailing Technology, Inc.
   www.prevailing-technology.com

Article: 139262
Subject: Re: chipscope pro 9.2i can't triger immediately !
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Tue, 24 Mar 2009 09:36:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 24 mar, 10:11, "guards" <gua...@126.com> wrote:
> Hello friends , I need your help !
> I am using chipscope pro 9.2i ,and it can't triger now !
> It can't triger immediately
> the state shows "Waiting for triger ,Sample buffer has zero samples(0%)"
> I'm sure the sample clock is right ,the evidence is that when I push
> reset
> on my board ,it shows
> "Waiting for triger ,Sample buffer has zero samples(0%),slow or stop
> clock"
> I think there may be a problem in the implement design ,but I don't know
> what it =A0exactly is.
> Did anyone have a similar problem?

Are you sure that you have a valid clock connected? If the "clock"
connected to the chipscope core is not a real clock, then you won't be
able to trigger it manually.Try using another clock.

If it doesn't work, in Xilinx click on clean implementation data and
start another chipscope file, sometimes there are some ".ngc" problems
that can't really be solved unless you start a new synthesis/
implementation process.

Article: 139263
Subject: Re: Silicon Blue last datesheet correct URL
From: Prevailing over Technology <steve.knapp@prevailing-technology.com>
Date: Tue, 24 Mar 2009 09:42:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
[snip]

> 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 ? :)

Actually, it is a little more flexible than that.  If you are
downloading to the part or configure from SPI PROM, just conect the
VPP_2V5 pin to some voltage between 1.3V and 3.45V to trip the power-
on reset (POR) circuit.

If you want to configure from the Nonvolatile Configuration Memory
(NVCM), then VPP_2V5 needs to be between 2.3 and 3.45V.

If you want to program the NVCM, then VPP_2V5 must be between 2.3 and
3.0V.

-- Steven K. Knapp
   Prevailing Technology, Inc.
   www.prevailing-technology.com

Article: 139264
Subject: Re: Silicon Blue last datesheet correct URL
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 24 Mar 2009 09:49:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 6:36=A0pm, Prevailing over Technology <steve.kn...@prevailing-
technology.com> wrote:
> On Mar 23, 9: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? =A0
>
> [snip]
>
> I've talked to them about that also. =A0All I can say at this point is
> watch this space. =A0I think they plan on some sort of 3.3V support in I/
> O Bank 3.
>
> [snip]
>
> > 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 'L04 and 'L08 are _almost_ pin compatible in the 196-pin package.
> There is a table on page 62 in the data sheet that shows the
> differences. =A0The real differences are if you use differential I/O and
> if you use the Global Buffer INput (GBIN) pins in banks 2 and 3. =A0If
> you use single-ended I/O and direct clock inputs in those banks, then
> both devices are pin compatible in the 196-pin package.
>
> > 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?
>
> There are some examples layouts from the iCEman65 development board.
> The board uses the 284-ball chip-scale BGA package (CB284) which is a
> superset of the 132-ball package (CB132). =A0The inner balls are
> identical.
>
> A PDF version of the layout appears in the user guide beginning on
> page 44.http://www.siliconbluetech.com/media/iCEmanBoardUserGuide.pdf
>
> The Gerber files are available as well. =A0Note that the link on their
> website apparently points to an old version (Should be Rev. D).http://www=
.siliconbluetech.com/media/iCEman65GerbersRevB.zip
>
> -- Steven K. Knapp
> =A0 =A0Prevailing Technology, Inc.
> =A0 =A0www.prevailing-technology.com

Steven,

iceMAN65 is multilayer PCB, Rick asked how i made it on 2 layers :)

well i have to say that the SB easyBGA is not that easy, mostly
because of the inner vcc/gnd pads, so most of the inner free space
is wasted to route out vccint and vccio
also some other pins are rather hard to route on 2 layers

so bga 0.5 with 3 outer rows only could actually be easier
as the easyBGA as it leaves large space in the middle

Antti

Article: 139265
Subject: Re: Looking for a low-cost development kit
From: "Johnson L" <gpsabove@yahoo.com>
Date: Tue, 24 Mar 2009 11:12:38 -0600
Links: << >>  << T >>  << A >>
I found the PIC microcontroller, and it includes free IDE. From the link 
below, it seems the costs are minimum. Any objection or suggestion?

http://www.sparkfun.com/tutorial/ARM/ARM_Cross_Development_with_Eclipse.pdf


"Johnson L" <gpsabove@yahoo.com> wrote in message 
news:FPExl.73664$FI5.25671@newsfe07.iad...
> For my hobby work, I am looking for a low-cost development kit to
> develope a simple embedded system. This system will measure the 
> temperature
> and heart beat rate, compare them with a predefined table which implements
> some health-care knowledge, then provide some useful information. This
> development kit should be low-cost, support C programming, debugging, 
> better
> with JTAG or other on-site debugging. It should support at least one type 
> of
> popular microprocessors, or a mainstream FPGA,
> and easy to use. Could anybody recommend me some? Thank you in advance.
>
> Johnson
>
> 



Article: 139266
Subject: Re: Xilinx XAPP052 LFSR and its understanding
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 24 Mar 2009 18:15:35 GMT
Links: << >>  << T >>  << A >>
Weng Tianxiang <wtxwtx@gmail.com> wrote:

>
>The reason I want to exclude the dead-lock situation is that in my
>project, I use the random number generator to generate random number
>to detect design errors. If there is an error, my design will detect

What kind of tests are you doing? A random generator isn't the
solution to generate all possible inputs. You might be better off
determining the worse conditions and test those. When I design load
tests I use semi random (predictable) patterns so a test can be
repeated accurately to check if a bug really has been fixed.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 139267
Subject: Re: Xilinx XAPP052 LFSR and its understanding
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Tue, 24 Mar 2009 12:35:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 11:15=A0am, n...@puntnl.niks (Nico Coesel) wrote:
> Weng Tianxiang <wtx...@gmail.com> wrote:
>
> >The reason I want to exclude the dead-lock situation is that in my
> >project, I use the random number generator to generate random number
> >to detect design errors. If there is an error, my design will detect
>
> What kind of tests are you doing? A random generator isn't the
> solution to generate all possible inputs. You might be better off
> determining the worse conditions and test those. When I design load
> tests I use semi random (predictable) patterns so a test can be
> repeated accurately to check if a bug really has been fixed.
>
> --
> Failure does not prove something is impossible, failure simply
> indicates you are not using the right tools...
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"If it doesn't fit, use a bigg=
er hammer!"
> --------------------------------------------------------------

Hi Nico,
Your judgement is right.

Expecially an ordinal random number generator doesn't always generate
what the data pattern it needs to detect errors, or at least in an
efficient way.

But in my case, I would like to use more than 1 random number
generator to generate data pattern to detect design errors.

Weng

Article: 139268
Subject: Xilinx ISE 10.1 Error reporting
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Tue, 24 Mar 2009 13:03:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Xilinx,
Here is the error reporting with its code and compilation result with
ISE 10.1 and service pack 3.
The code is specially simplified to highlight the VHDL compiler error
characteristics.
There are global data array definitions.
when one of many data in the global data array is accessed in one
logic level, all other non-accessed data in the global data array
cannot be accessed and declared a data access error.
I list only one error case when one of many data in the global data
array is accessed at one level.
Another similar error case is when one of many data in the global data
array is accessed at two different levels in a module, the same
compilation error occurs again.

Error reason: Each of many data in a global data array must have its
independent own data source ID and a global data array cannot share
only one data source ID to determine whether the access violation
occurs or not.

LIBRARY ieee;
USE ieee.std_logic_1164.all;
use ieee.numeric_std.all;

Package XILINX_ERROR_REPORT is
 constant TOP           : integer := 1;
 constant BOTTOM	: integer := 0;
 signal Error              : unsigned(TOP downto BOTTOM);
end package;

-------------------------------------------------------------------------------

LIBRARY ieee;
USE ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.XILINX_ERROR_REPORT.all;

entity Xilinx_Error is
 generic(X : integer := 1);
  port(
   CLK : in std_logic;
   SINI : in std_logic;

   Error_I	: in std_logic;
   Error_O	: out std_logic
  );
end Xilinx_Error;

architecture A of Xilinx_Error is
begin
 Error_O <= Error(X);

 A1 : process(CLK)
 begin
  if CLK'event and CLK = '1' then
   if SINI = '1' then
    Error(X) <= '0';
   else
    if Error_I = '1' then
     Error(X) <= '1';
    else
     Error(X) <= '0';
    end if;
   end if;
  end if;
 end process;
end A;

-------------------------------------------------------------------------------

LIBRARY ieee;
USE ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.XILINX_ERROR_REPORT.all;

entity Xilinx_Error_Detect is
 generic(X : integer := 1);
  port(
   CLK : in std_logic;
   SINI : in std_logic;
   Error_I	: in std_logic_vector(TOP downto BOTTOM);
   Error_O	: out std_logic_vector(TOP downto BOTTOM)
  );
end Xilinx_Error_Detect;

architecture A of Xilinx_Error_Detect is
 component Xilinx_Error is
  generic(X : integer := 1);
   port(
    CLK : in std_logic;
    SINI : in std_logic;
    Error_I	: in std_logic;
    Error_O	: out std_logic
   );
 end component;

begin
 Generate_A : for J in BOTTOM to TOP generate
  Xilinx_Error_A : Xilinx_Error
   generic map(X => J)
   port map (
    CLK	=> CLK,
    SINI	=> SINI,
    Error_I	=> Error_I(J),
    Error_O	=> Error_O(J)
   );
 end generate;
end A;

-------------------------------------------------------------------------------
=========================================================================
*                          HDL
Compilation                              *
=========================================================================
Compiling vhdl file "C:/Xilinx-Error-Report/Xilinx_Error_Report.vhd"
in Library work.
Package <xilinx_error_report> compiled.
Entity <xilinx_error> compiled.
Entity <xilinx_error> (Architecture <a>) compiled.
Entity <xilinx_error_detect> compiled.
Entity <Xilinx_Error_Detect> (Architecture <A>) compiled.

=========================================================================
*                     Design Hierarchy
Analysis                         *
=========================================================================
Analyzing hierarchy for entity <Xilinx_Error_Detect> in library <work>
(architecture <A>) with generics.
	X = 1

Analyzing hierarchy for entity <Xilinx_Error> in library <work>
(architecture <a>) with generics.
	X = 0

Analyzing hierarchy for entity <Xilinx_Error> in library <work>
(architecture <a>) with generics.
	X = 1


=========================================================================
*                            HDL
Analysis                               *
=========================================================================
Analyzing generic Entity <Xilinx_Error_Detect> in library <work>
(Architecture <A>).
	X = 1
Entity <Xilinx_Error_Detect> analyzed. Unit <Xilinx_Error_Detect>
generated.

Analyzing generic Entity <Xilinx_Error.1> in library <work>
(Architecture <a>).
	X = 0
Entity <Xilinx_Error.1> analyzed. Unit <Xilinx_Error.1> generated.

Analyzing generic Entity <Xilinx_Error.2> in library <work>
(Architecture <a>).
	X = 1
ERROR:Xst:2548 - "C:/Xilinx-Error-Report/Xilinx_Error_Report.vhd" line
36:
Signal 'Error' defined in a package is already used in entity
<Xilinx_Error.1>.
-->

Total memory usage is 129212 kilobytes

Number of errors   :    1 (   0 filtered)
Number of warnings :    1 (   0 filtered)
Number of infos    :    0 (   0 filtered)


Process "Synthesis" failed

In the above example, Error(1 downto 0) is declared in package
XILINX_ERROR_REPORT, and its components are used in different modules:
Error(0) is used in module Xilinx_Error.1 and Error(1) is used in
module Xilinx_Error.2, but the compiler fails to correctly register
the domain for each of Error(1 downto 0) and declares a error that is
not an error.


Article: 139269
Subject: Re: FPGAs in automotive apps (was Re: Silicon Blue last datesheet
From: -jg <Jim.Granville@gmail.com>
Date: Tue, 24 Mar 2009 13:44:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 2:15=A0am, rickman <gnu...@gmail.com> wrote:
> I'm happy to be corrected. =A0I just don't see where autos are an
> application where FPGAs will have much of a market for the foreseeable
> future. =A0What feature of FPGAs make them a primary solution for a high
> volume automotive product?

 Whilst you are strictly correct about high volume costings, remember
all new product ideas need to be developed first
(and a market established), and those volumes and timelines are
not your mainstream  "high volume automotive product"

 Indeed, given the present downturn, finding ANY " high
volume automotive product" might be a challenge!  ;)

 - but that's always FPGAs problem, and one reason the business
as a whole, has low growth : The high-volume designs move to ASICs,
so FPGAs chase the pioneer (and low-med volume) sockets...

-jg

Article: 139270
Subject: Re: FPGAs in automotive apps (was Re: Silicon Blue last datesheet ?correct URL)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 24 Mar 2009 20:50:28 +0000 (UTC)
Links: << >>  << T >>  << A >>
-jg <Jim.Granville@gmail.com> wrote:
 
> - but that's always FPGAs problem, and one reason the business
> as a whole, has low growth : The high-volume designs move to ASICs,
> so FPGAs chase the pioneer (and low-med volume) sockets...

And as mask costs (and other NRE) increase, the crossover
point moves up.  Also, as low end FPGAs get cheaper.

There is an article that says that low end Spartan's,
I believe S3E, were supposed to be in the $2 range.

-- glen

Article: 139271
Subject: Re: Antti Processor
From: -jg <Jim.Granville@gmail.com>
Date: Tue, 24 Mar 2009 13:56:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 8:30=A0pm, Antti <Antti.Luk...@googlemail.com> wrote:
> it is being developed :)
> well it is actually NPU version 2
> (where NPU stands for my node processor unit - a not finished design
> concept)
>
> some features
> * optimized for streaming media, that is clocked data streams (serial
> flash, SD card, etc..)
> * PC is optional
> * Stack is optional
> * minimum number of registers: 0
> * minimum size of internal RAM: 0
> * no reset pin needed (input stream can force reset)
> * operand widths: 1 to unlimited
> * address space: unlimited
> * minimal configuration : 0 LUT/0 FF (1 Block ROM + IOB F/F's)
>
> there are some compromises of course, say 32 bit ALU operation
> would take 40 clock cycles for the operation itself + some more
> clocks to select the operands and operation type. shorter operation
> will be less clock cycles, but still rather slow in terms of clock
> cycles
> otoh as the serialized nature allows operation at higher fabric speeds
> then the overall performance could be rather good.
> Quad SPI memories can stream data at 320MBit/s, in modern
> FPGA NPU2 could easily run at 320mhz, what would give some
>
> >5 MIPS for 32 bit operations what is not that bad at all
>
> the Processor is currently designed using EXCEL
>
> main problem would be the tool support, as the assembler/compiler
> would  need to be generated based on the processor description, there is =
no
> fixed  instruction set at all, and pretty much all features of the proces=
sor
> are  configurable, also variables and constant can be of different widths=
,
> so the  compiler should know how wide variables to use, not only 8/16/32 =
but
> they  can really be any size with single bit granularity

interesting - Sounds like a nice blank canvas :)

Does it have skip opcodes ?

A register frame pointer, for when registers are in BRAM ?

The ability to run a 'dual-core' by time-slot allocating multiple
register/flag sets ?
(probably dictates a second SO8 memory?)

-jg

Article: 139272
Subject: Re: Flow Control
From: Mike Treseler <mtreseler@gmail.com>
Date: Tue, 24 Mar 2009 14:08:35 -0700
Links: << >>  << T >>  << A >>
Essy wrote:

> The very simple solution would be to receive a packet from the source
> and wait until the last stage finishes the process. Obviously, this
> reduces the overall throughput significantly. I'm sure that this
> problem has been addressed by others ages ago (probably those working
> in the network field)

Yes. Have a look at the octet and packet level handshake examples here:
http://www.ipmplsforum.org/ftp/pub/approved-specs/af-phy-0017.000.pdf

    -- Mike Treseler

Article: 139273
Subject: Which ISE Webpack version for S3A..?
From: Mike Harrison <mike@whitewing.co.uk>
Date: Tue, 24 Mar 2009 23:46:55 +0000
Links: << >>  << T >>  << A >>
I'm about to start a project on an Spartan3A (200) in VHDL - having seen a few comments here about
ISE problems I was wondering if I'd be best using the Webpack v 9.2 that came with the devboard or
downloading the latest 10.1 ?
Is there anything in V10 that would be worth the doubtless colossal download ? 
Or anything sufficiently broken in either version to be a big deal?


Article: 139274
Subject: Re: Looking for a low-cost development kit
From: mng <michael.jh.ng@gmail.com>
Date: Tue, 24 Mar 2009 21:19:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 12:12=A0pm, "Johnson L" <gpsab...@yahoo.com> wrote:
> I found the PIC microcontroller, and it includes free IDE. From the link
> below, it seems the costs are minimum. Any objection or suggestion?
>
> http://www.sparkfun.com/tutorial/ARM/ARM_Cross_Development_with_Eclip...
>
> "Johnson L" <gpsab...@yahoo.com> wrote in message
>
> news:FPExl.73664$FI5.25671@newsfe07.iad...
>
> > For my hobby work, I am looking for a low-cost development kit to
> > develope a simple embedded system. This system will measure the
> > temperature
> > and heart beat rate, compare them with a predefined table which impleme=
nts
> > some health-care knowledge, then provide some useful information. This
> > development kit should be low-cost, support C programming, debugging,
> > better
> > with JTAG or other on-site debugging. It should support at least one ty=
pe
> > of
> > popular microprocessors, or a mainstream FPGA,
> > and easy to use. Could anybody recommend me some? Thank you in advance.
>
> > Johnson

Yeah, if you go with a PIC-based dev kit, Microchip provides MPLAB and
a limited C compiler for free.

You may want to consider the Arduino, which has gotten to be pretty
popular in the hobbyist community. There's a lot of examples and
resources on the web. The software toolchain is all free.

http://www.arduino.cc/

As for DSP, here's a free book.

http://www.dspguide.com/

Good luck,
Mike



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search