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 139225

Article: 139225
Subject: Re: Looking for a low-cost development kit
From: Chris Abele <ccabele@yahoo.com>
Date: Mon, 23 Mar 2009 22:30:09 -0400
Links: << >>  << T >>  << A >>
Johnson L wrote:
> 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
> 
> 

It's hard to get a functional FPGA development kit that's more 
affordable than Avnet's Spartan-3A Eval Kit. 
(http://tinyurl.com/blhcar) $50 gets you an XC3S400A-4FTG256C, two types 
of flash, a USB bridge, several type of I/O, and a Cypress PSoC.  Even 
better nothing else is required to program it (you don't need the $200 
Xilinx cable).

And for really cheap TI's eZ430 development kit is hard to beat - it's 
only $20. (http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html)
The MSP430 is a pretty low end processor, but the kick-start version of 
the IAR tools does allow you to develop in C and debug on the target.

There are lots of well done, not too expensive boards at Digilent 
(http://www.digilentinc.com), along with programming tools, various 
addons, and example code.  They have been good about answering my 
questions too.

(I have no commercial interest in any of these, they're just sources 
that I've found useful.)

Chris

Article: 139226
Subject: Re: Silicon Blue last datesheet correct URL
From: -jg <Jim.Granville@gmail.com>
Date: Mon, 23 Mar 2009 19:38:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 2:12=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> 2) the current numbers are reduces down, the smallest part at 32khz
> 8uA (was 25 i think)

 That  8uA is typical, but it is also OPERATING at 32KHz
 "VCC Power Consumption for Device Filled with 16-Bit Binary Counters"

The Static Standby power, is 3uA (so those 32Khz ctrs add 5uA)
Quite good numbers :)

-jg

Article: 139227
Subject: Re: Silicon Blue last datesheet correct URL
From: -jg <Jim.Granville@gmail.com>
Date: Mon, 23 Mar 2009 19:46:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 12:58=A0pm, rickman <gnu...@gmail.com> wrote:
> > The Bank3 does support MDDR, so that seems to be what chopped the 3.3V
>
> I did a search, but I didn't find many details on MDDR; or is it
> mDDR? =A0The supply voltage seems to be 1.8V and I believe it is
> differential. =A0Banks 0, 1 and 2 support 1.8V LVCMOS voltages. =A0I gues=
s
> I wonder why MDDR can't be supported with hardware that is 3.3V
> tolerant?

My guess would be that the MDDR IP they got from the foundry, did not
include 3V3 ?.
-jg


Article: 139228
Subject: Re: Silicon Blue last datesheet correct URL
From: -jg <Jim.Granville@gmail.com>
Date: Mon, 23 Mar 2009 19:51:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 1:12=A0pm, rickman <gnu...@gmail.com> wrote:
> > 5V is making something of a comeback, =A0more uC are now 5V too :)
>
> When you say "more", I never found many that dropped 5 volt tolerance,
> even the newer, low core voltage parts.

I am talking about 5V operation, and 5V CMOS drive, not merely 5V
tolerant.
It's an Important distinction, as you can properly drive a power fet,
and eliminate multiple rails (and read 5V Analog too...).

eg Newest Silabs Automotive  devices (F58x) are 5V operation, as are
newest
CoreRiver variants, and even NXP have 5V versions of their LPC coming
this year.

-jg

Article: 139229
Subject: Re: Silicon Blue last datesheet correct URL
From: rickman <gnuarm@gmail.com>
Date: Mon, 23 Mar 2009 20:04:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 23, 12:13 pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 23, 6:01 pm, 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.  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
>
> 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

To make sure I understand you, you are saying that you routed *part*
of the I/Os on the 132 pin BGA?  I guess if you don't route all of the
I/Os that helps with the routing.  I am concerned with the power pins
in the center.  How did you route G7, G8, H7 and H8?  These can be
routed through the pads next to them, but this makes for a higher
impedance ground path.  I guess this is not such an issue in a low
power device like this: no fast edges (I assume) causing ground bounce
and insignificant IR drops on the bond wires.  Otherwise, I don't a
way to route those four inner pads.

Still, if you do want to route all of the I/Os, the empty ball rings
don't appear to provide enough space for all of the pads on the two
adjacent populated rings to be broken out with out using very small
vias.

Rick

Article: 139230
Subject: cutting down opb_clk cycles while read-write BRAM-DDR in FPGA
From: chakra <narashimanc@gmail.com>
Date: Mon, 23 Mar 2009 20:05:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello all,

I am working on a project which involves a simple BRAM, OPB-PLB,
Microblaze/PPC, and opb_ddr_sdram controller. I am reading 1280 bytes
of data from bram (32 bits each read, thus a total of 320 reads) and
writing it to DDR sdram. i am using Xilinx standalone OS. i use the
command  XIo_in32(addr) to read from bram and use XIo_out32(addr,data)
to write to DDR sdram controller.

here is the c code i use to write to ddr.

for(p=0;p<320;p++) //number of reads from Bram = 320 (0:319)
{
 a = XIo_In32(bram_addr);
 XIo_Out32(ddr_addr+(p*4), a); //P*4 is to make sure we create room
for 32 bit data
}

I use chipscope pro to debug whats happenig inside.
stepa: It takes 3 opb clock cycles to read the value from bram
stepb: there is a 5 clock cycle delay (probably Processor is
calculating p*4),
stepc: it takes about 9 clock cycles to write to DDR sdram and
stepd: 7 clock cyles (no clue why it takes so long) to the next cycle
of read and  write.

question 1: is there a way to cutdown the clock cycles (delay clock
cycles b and d) (i  want to bring the total clock cycles for one
iteration down to about 15 or less)

question 2: is there a software way of reading from the bram and
writing to DDR sdram in burst mode (I know there is one in hardware
opb burst mode)

thanks,
with warm regards,
Chakra.

Article: 139231
Subject: Re: Silicon Blue last datesheet correct URL
From: rickman <gnuarm@gmail.com>
Date: Mon, 23 Mar 2009 20:27:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 23, 10:46=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
> On Mar 24, 12:58=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > > The Bank3 does support MDDR, so that seems to be what chopped the 3.3=
V
>
> > I did a search, but I didn't find many details on MDDR; or is it
> > mDDR? =A0The supply voltage seems to be 1.8V and I believe it is
> > differential. =A0Banks 0, 1 and 2 support 1.8V LVCMOS voltages. =A0I gu=
ess
> > I wonder why MDDR can't be supported with hardware that is 3.3V
> > tolerant?
>
> My guess would be that the MDDR IP they got from the foundry, did not
> include 3V3 ?.
> -jg

Do you really think they used someone else's IP for an FPGA?  How many
customers need I/Os that can support 9 different standards?  I would
think the the I/O configuration is one of the things that makes an
FPGA vendor.

Rick

Article: 139232
Subject: Re: Silicon Blue last datesheet correct URL
From: rickman <gnuarm@gmail.com>
Date: Mon, 23 Mar 2009 20:37:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 23, 10:51 pm, -jg <Jim.Granvi...@gmail.com> wrote:
> On Mar 24, 1:12 pm, rickman <gnu...@gmail.com> wrote:
>
> > > 5V is making something of a comeback,  more uC are now 5V too :)
>
> > When you say "more", I never found many that dropped 5 volt tolerance,
> > even the newer, low core voltage parts.
>
> I am talking about 5V operation, and 5V CMOS drive, not merely 5V
> tolerant.
> It's an Important distinction, as you can properly drive a power fet,
> and eliminate multiple rails (and read 5V Analog too...).
>
> eg Newest Silabs Automotive  devices (F58x) are 5V operation, as are
> newest
> CoreRiver variants, and even NXP have 5V versions of their LPC coming
> this year.

That makes some sense I suppose.  But the automotive market is not one
of the places I would expect to see many FPGAs.  Even if they are low
power, why does an auto maker need the flexibility of
reconfiguration?  Their volumes are high enough that they can spin low
cost ASICs at large feature sizes which keeps the NRE down compared to
FPGAs.

Autos are using a lot of DSP and higher end embedded processors.
Otherwise, I don't see autos pushing semi technology.  Yeah, 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.

Rick

Article: 139233
Subject: Re: Looking for a low-cost development kit
From: "Johnson L" <gpsabove@yahoo.com>
Date: Mon, 23 Mar 2009 22:10:20 -0600
Links: << >>  << T >>  << A >>

Well, both the price and the product sounds great! Thanks for sharing!
BTW, the software license expires every 6 months. Do you think they will 
charge me for renewing the license?

Johnson


"LittleAlex" <alex.louie@email.com> wrote in message 
news:c1ec1088-a658-46f5-b5b3-d66cb8fe327f@v23g2000pro.googlegroups.com...
>I just got an FPGA development kit from Lattice - 2200 CLB's, USB
> (FX2) Interface, a software starter kit, and an 8-bit embedded
> processor.
>
> $75 including tax & Shipping.
>
> Software license expires every 6 months; I'm guessing that they will
> renew it.  Software is reminiscent of Xilinx back in the ISE-4.2 days
> (clumsy, but functional).  The embedded processor (Mico8) looks -very-
> interesting: if I'm seeing things correctly, they chose 'wishbone' for
> their on-chip bus.
>
> AL
>
> On Mar 23, 3:14 pm, John Adair <g...@enterpoint.co.uk> wrote:
>> Johnson
>>
>> It's not quite true that there are not free tools for FPGAs. Both the
>> 2 biggest vendors Xilinx and Altera have free tools for building the
>> hardware side for the smaller end FPGAs themselves. Processor support
>> tools specifically Xilinx has 2 soft core processors that they support
>> - PicoBlaze and MicroBlaze. Altera have Nios. Picoblaze I believe a
>> third party has done a C compiler and the group probably has more
>> details that I do. MicroBlaze (EDK) and Nios toolsets are essentially
>> paid for tools although there are sometimes evaluation versions around
>> that are good for short term use.
>>
>> On I/O things like acceptable voltage levels e.g. 3.3V or 5V
>> signalling requirements are important. Many modern FPGAs cannot
>> tolerate 5V signalling levels directly without some protection, or
>> level shift, circuits. Particular protocols like I2C will need to be
>> driven and controlled by some logic function within the FPGA user
>> design. If you are using external modules for bluetooth etc. then
>> again you need to use whatever signalling levels and protocols are
>> required to transfer data and setup to the external modules.
>>
>> John Adair
>> Enterpoint Ltd.
>>
>> On 23 Mar, 21:36, "Johnson L" <gpsab...@yahoo.com> wrote:
>>
>> > "John Adair" <g...@enterpoint.co.uk> wrote in message
>>
>> >news:a38658ca-69a3-4af4-bfde-1c4abf7f7264@37g2000yqp.googlegroups.com...
>>
>> > > Johnson
>>
>> > > Can you elaborate on your I/O requirements as this may affect what is
>> > > best for your application.
>>
>> > > Most of the board vendors in the FPGA world like ourselves don't
>> > > supply boards as bundled software kits as such. The software aspect
>> > > tends to come from whichever processor core is being used. However
>> > > there are one or two Xilinx and Altera kits that include some sort of
>> > > tools version with the boards for MicroBlaze and Nios respectively 
>> > > but
>> > > they don't tend to be in hobby engineer price area.
>>
>> > > For the lowest cost you may have to think about seperate solution for
>> > > a microprocessor and board. There various microprocessor cores on
>> > > Opencores that are based on popular things like Z80 and so on and
>> > > there are lots of tools out there for that common processor. There
>> > > also things like 8086/8 cores available from third party vendors
>> > >http://www.ht-lab.com/hardware/drigmorn1/drigmorn1.htmlbutthese do
>> > > cost.
>>
>> > > John Adair
>> > > Enterpoint Ltd.
>>
>> > > On 23 Mar, 05:08, "Johnson L" <gpsab...@yahoo.com> wrote:
>> > >> 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
>>
>> > Thanks, John, your answer is very informative and helpful. However, as 
>> > a
>> > hobby engineer I don't know how to elaborate the I/O requirements. 
>> > Could you
>> > please give me a simple example?
>> > As for now, I would like the sensors being connected to the 
>> > microprocessor
>> > in a simple way, such as I2C or UART. I possibly also need a port for
>> > BLUETOOTH or ZIGBEE to send out the commands to a wireless peripheral.
>> > BTW, if I understand it correct, there is no free or low-cost 
>> > development
>> > kit for FPGA, right?
>> > Johnson- Hide quoted text -
>>
>> > - Show quoted text -
>



Article: 139234
Subject: Re: Looking for a low-cost development kit
From: "Johnson L" <gpsabove@yahoo.com>
Date: Mon, 23 Mar 2009 22:11:22 -0600
Links: << >>  << T >>  << A >>
I also want to know, is there any low-cost development kit for DSP as well? 
I
possibly need some filter function in the software as well so I am also
thinking about DSP. Anybody can help?

Thanks.

Johnson


"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: 139235
Subject: Re: Looking for a low-cost development kit
From: "Johnson L" <gpsabove@yahoo.com>
Date: Mon, 23 Mar 2009 22:21:04 -0600
Links: << >>  << T >>  << A >>


"Chris Abele" <ccabele@yahoo.com> wrote in message 
news:IfadnV9xaJ9I2FXUnZ2dnUVZ_oninZ2d@giganews.com...
> Johnson L wrote:
>> 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
>>
>>
>
> It's hard to get a functional FPGA development kit that's more affordable 
> than Avnet's Spartan-3A Eval Kit. (http://tinyurl.com/blhcar) $50 gets you 
> an XC3S400A-4FTG256C, two types of flash, a USB bridge, several type of 
> I/O, and a Cypress PSoC.  Even better nothing else is required to program 
> it (you don't need the $200 Xilinx cable).
>
> And for really cheap TI's eZ430 development kit is hard to beat - it's 
> only $20. (http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html)
> The MSP430 is a pretty low end processor, but the kick-start version of 
> the IAR tools does allow you to develop in C and debug on the target.
>
> There are lots of well done, not too expensive boards at Digilent 
> (http://www.digilentinc.com), along with programming tools, various 
> addons, and example code.  They have been good about answering my 
> questions too.
>
> (I have no commercial interest in any of these, they're just sources that 
> I've found useful.)
>
> Chris

Chris, thank you very much for sharing them! The kits look awesome!

BTW, for Avnet's Spartan-3A Eval Kit, nothing else is required to program 
it. However, I need to program it since I need to implement some generic 
functions written in C. So it isn't an option for me.

Johnson





Article: 139236
Subject: Re: ERROR:Pack:1564 on Virtex 4
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Tue, 24 Mar 2009 00:56:40 -0500
Links: << >>  << T >>  << A >>

>ERROR:Pack:1564 - The dual data rate register <signal name> failed to
>join the OLOGIC component as required.  The OLOGIC SR signal does not
>match the ILOGIC SR signal, or the ILOGIC SR signal is absent.

I assume that SR is the Set/Reset pin and that it's shared
by the input and output FFs.  Are you (re)setting one pair
of FFs and not the other?

I'd have to get out the data sheet and lookup the fine print
on the hardware and then look at the macros to see what
combinations make sense.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 139237
Subject: Using SelectIO LVDS to drive 40 inch backplane trace
From: Goli <togoli@gmail.com>
Date: Mon, 23 Mar 2009 23:16:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I am designing a system which needs multiple interfaces (about 16) to
backplane running at about ~700Mhz. These are going to be source
synchronous interfaces and clock will be available.  I did not wanted
to use the build in transceivers because the 20 transceiver devices
are very expensive. The logic and block Ram requirement of the design
is relatively small.

I was wondering if for Xilinx FPGA can I use the normal LVDS select IO
pins to drive the backplane. Will it work? Are there any design
consideration that I need to take to accomplish this. What is the
maximum trace that the select LVDS IO can drive.

Also wondering if there is any difference between Xilinx and Altera
LVDS, if either or one of them is suited for backplane applications.

Cheers.

--
Goli

Article: 139238
Subject: Re: Xilinx XAPP052 LFSR and its understanding
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Mon, 23 Mar 2009 23:24:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 23, 6:27=A0am, gabor <ga...@alacron.com> wrote:
> On Mar 23, 9:15=A0am, gabor <ga...@alacron.com> wrote:
>
>
>
>
>
> > On Mar 23, 5:19=A0am, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote:
>
> > > Hi Wang,
>
> > > I wouldn't dare (at my age) to get absorbed into that algebra of feed=
back
> > > shift pipes and polynomials. I believe there is plenty around(even wi=
ki got
> > > interesting stuff). I rather get things ready for me to use and let t=
he
> > > young research into the underlying mess.
>
> > > kadhiem
>
> > I was under the impression that all LFSR's used an even
> > number of terms. =A0The table of feedback terms in the appnote
> > is only one possible set of polynomials for maximal LFSR's of
> > each length, however these represent the ones with the least
> > number of terms for that length of LFSR. =A0At one time I had
> > written a C program to search for maximal LFSR feedback
> > terms. =A0Then I found the Xilinx appnote. =A0I think the main
> > requirement for a maximal LFSR is that the polynomial is
> > relatively prime with respect to 2^N - 1. =A0The number of
> > states for a given set of feedback terms does not depend
> > on use of XOR vs XNOR. =A0You can easily prove that these
> > two are equivalent by simply inverting the logic:
>
> > if Y =3D A XOR B
> > then not Y =3D not A XOR not B
>
> > Regards,
> > Gabor
>
> Oops, posted too fast. =A0I meant:
>
> if Y =3D A XOR B
> then not Y =3D not A XNOR not B- Hide quoted text -
>
> - Show quoted text -

Hi Gabor,
Good equation !

How dare you start writing a C program to search for LFSR feedback
terms!

It must be based on some mathematical theory.

I found a lot of books on Algebraic Coding from Amason, but I would
like someone to recommend one of those excellent books he read and
learned, and I would like to buy and read one as a hobby. Reading and
learning is funny than watching TV.

Weng

Article: 139239
Subject: Re: Silicon Blue last datesheet correct URL
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Tue, 24 Mar 2009 03:03:18 -0500
Links: << >>  << T >>  << A >>

>Do you really think they used someone else's IP for an FPGA?  How many
>customers need I/Os that can support 9 different standards?  I would
>think the the I/O configuration is one of the things that makes an
>FPGA vendor.

It wouldn't surpise me if they used vendor provided parts
for the final driving transistors and bonding pad area
and EMI on the input side.

The foundry probably doesn't want to do things like
develop a new oxide thickness.  It's probably simple
economics.   What's the NRE for a new oxide vs the
gain (better product) with more features vs risk
of the new stuff not working right.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 139240
Subject: Re: Xilinx XAPP052 LFSR and its understanding
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 24 Mar 2009 08:11:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
Weng Tianxiang <wtxwtx@gmail.com> wrote:
(big snip)
 
> How dare you start writing a C program to 
> search for LFSR feedback terms!
 
> It must be based on some mathematical theory.

Much theory research is done with programs.  My favorite
from some years ago was the proof of the four color theorem.
(Not that I understand the proof at all.)

The four color theorem is easy enough to explain to 
first graders, but the proof took many hours of computer
time, and is likely understood by very few.

-- glen

Article: 139241
Subject: Re: Silicon Blue last datesheet correct URL
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 24 Mar 2009 08:14:30 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
 
> It wouldn't surpise me if they used vendor provided parts
> for the final driving transistors and bonding pad area
> and EMI on the input side.
 
> The foundry probably doesn't want to do things like
> develop a new oxide thickness.  It's probably simple
> economics.   What's the NRE for a new oxide vs the
> gain (better product) with more features vs risk
> of the new stuff not working right.

Fewer different thicknesses would make fabrication easier.

For modern FPGAs you need at least two oxide
thicknesses, as the configuration storage needs are
very different from the logic needs.  Possibly
the configuration transistor oxide could also be
used for output drivers.  They probably won't tell
you, though.

-- glen 

Article: 139242
Subject: Re: Silicon Blue last datesheet correct URL
From: rickman <gnuarm@gmail.com>
Date: Tue, 24 Mar 2009 01:22:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 4:14=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Hal Murray <hal-use...@ip-64-139-1-69.sjc.megapath.net> wrote:
> > It wouldn't surpise me if they used vendor provided parts
> > for the final driving transistors and bonding pad area
> > and EMI on the input side.
> > The foundry probably doesn't want to do things like
> > develop a new oxide thickness. =A0It's probably simple
> > economics. =A0 What's the NRE for a new oxide vs the
> > gain (better product) with more features vs risk
> > of the new stuff not working right.
>
> Fewer different thicknesses would make fabrication easier.
>
> For modern FPGAs you need at least two oxide
> thicknesses, as the configuration storage needs are
> very different from the logic needs. =A0Possibly
> the configuration transistor oxide could also be
> used for output drivers. =A0They probably won't tell
> you, though.
>
> -- glen

None of this relates to the issue of the I/O voltages.  There are 5
volt functioning transistors on the die and it is pretty clear that
the I/O driver circuits are designed by SiBlue.  So far I don't see
any of the discussion about oxide thickness to be relevant.

Rick

Article: 139243
Subject: Antti Processor
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 24 Mar 2009 01:30:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 processor
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

Antti

Article: 139244
Subject: FPGAs in automotive apps (was Re: Silicon Blue last datesheet correct URL)
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Tue, 24 Mar 2009 09:02:37 +0000
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> writes:

> That makes some sense I suppose.  But the automotive market is not
> one of the places I would expect to see many FPGAs.  Even if they
> are low power, why does an auto maker need the flexibility of
> reconfiguration?  Their 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.

>
> Autos are using a lot of DSP and higher end embedded processors.
> Otherwise, I don't see autos pushing semi technology.  Yeah, 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 :)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 139245
Subject: Re: Xilinx XAPP052 LFSR and its understanding
From: Allan Herriman <allanherriman@hotmail.com>
Date: 24 Mar 2009 09:51:41 GMT
Links: << >>  << T >>  << A >>
On Mon, 23 Mar 2009 06:15:59 -0700, gabor wrote:

> On Mar 23, 5:19 am, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote:
>> Hi Wang,
>>
>> I wouldn't dare (at my age) to get absorbed into that algebra of
>> feedback shift pipes and polynomials. I believe there is plenty
>> around(even wiki got interesting stuff). I rather get things ready for
>> me to use and let the young research into the underlying mess.
>>
>> kadhiem
> 
> I was under the impression that all LFSR's used an even number of terms.

LFSRs with an odd number of feedback terms have a polynomial with (x+1) 
as a factor.  These are not primitive, not maximal length and not as 
interesting as the ones with an even number of feedback terms.  They're 
still LFSRs though.

Regards,
Allan

Article: 139246
Subject: Re: ERROR:Pack:1564 on Virtex 4
From: Bert <bert.pieters@gmail.com>
Date: Tue, 24 Mar 2009 03:05:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 6:56 am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >ERROR:Pack:1564 - The dual data rate register <signal name> failed to
> >join the OLOGIC component as required.  The OLOGIC SR signal does not
> >match the ILOGIC SR signal, or the ILOGIC SR signal is absent.
>
> I assume that SR is the Set/Reset pin and that it's shared
> by the input and output FFs.  Are you (re)setting one pair
> of FFs and not the other?
>
> I'd have to get out the data sheet and lookup the fine print
> on the hardware and then look at the macros to see what
> combinations make sense.
>
> --
> These are my opinions, not necessarily my employer's.  I hate spam.

I tried it and yes this fix it. I had 2 differents resets (one
synchronous to the ODDR clk, and one synchronous to the IDDR clock). I
set both on the same reset, and MAP succeeded.

Thanks a lot!

Article: 139247
Subject: Re: Silicon Blue last datesheet correct URL
From: -jg <Jim.Granville@gmail.com>
Date: Tue, 24 Mar 2009 03:19:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 3:27=A0pm, rickman <gnu...@gmail.com> wrote:
> On Mar 23, 10:46=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
>
> Do you really think they used someone else's IP for an FPGA? =A0How many
> customers need I/Os that can support 9 different standards? =A0I would
> think the the I/O configuration is one of the things that makes an
> FPGA vendor.

There are high costs to proving Pin Drivers, and if the foundry has a
KGIO
already, there is a strong temptation to use that on the first pass.

It certainly looks like the MDDA excluded 3.3 / 5V compliance.
Could be capacitance, perhaps someone at SlilconBlue will enlighten
us ?

-jg


Article: 139248
Subject: Re: Silicon Blue last datesheet correct URL
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 24 Mar 2009 10:20:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
 
> None of this relates to the issue of the I/O voltages.  There are 5
> volt functioning transistors on the die and it is pretty clear that
> the I/O driver circuits are designed by SiBlue.  So 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.  That said, we really 
don't know anything about the design of the transistors,
so, yes, there isn't much reason to discuss it.

-- glen

Article: 139249
Subject: Re: Using SelectIO LVDS to drive 40 inch backplane trace
From: Nathan Bialke <nathan@bialke.com>
Date: Tue, 24 Mar 2009 03:23:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello,

These questions are essentially impossible to answer. You need to
figure out what sort of backplane you're working on, what sort of
board will be driving the backplane, and what sort of board will be
receiving the LVDS signal. Next, target a particular family of FPGA
rather than "Xilinx FPGA". After that, spend some time with minimally
HyperLynx or preferably an electromagnetic field simulator to figure
out if this is possible or not. I think you will find that noone will
give you a definitive answer other than "if you don't do your
homework, this will not work."

Good luck,

Nathan

On Mar 24, 2:16=A0am, Goli <tog...@gmail.com> wrote:
> Hi,
>
> I am designing a system which needs multiple interfaces (about 16) to
> backplane running at about ~700Mhz. These are going to be source
> synchronous interfaces and clock will be available. =A0I did not wanted
> to use the build in transceivers because the 20 transceiver devices
> are very expensive. The logic and block Ram requirement of the design
> is relatively small.
>
> I was wondering if for Xilinx FPGA can I use the normal LVDS select IO
> pins to drive the backplane. Will it work? Are there any design
> consideration that I need to take to accomplish this. What is the
> maximum trace that the select LVDS IO can drive.
>
> Also wondering if there is any difference between Xilinx and Altera
> LVDS, if either or one of them is suited for backplane applications.
>
> Cheers.
>
> --
> Goli



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