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 48700

Article: 48700
Subject: Re: Decoupling BF957 Virtex II package
From: wangxy@fudan.edu (Wang Xiao-yun)
Date: 22 Oct 2002 18:53:13 -0700
Links: << >>  << T >>  << A >>
albert_ross@hotmail.com (Albert Ross) wrote in message news:<31b425a3.0210220137.534ef44a@posting.google.com>...
> The Xilinx guidelines recommend one HF cap per supply pin (VCCINT,
> VCCO, VCCAUX), yet the power pins are mostly in the centre of the
> chip. Assuming one via per pin, how have people managed to place
> decouplers close to these pins on the underside of the board to
> minimise trace length? Is it adequate to place the decouplers around
> the periphery of the chip, or is the only solution to use buried /
> blind vias with caps underneath the chip?
> Having viewed the recommended standard routing diagrams in the Virtex
> II databook it shows there is no unused area in the centre of the chip
> as there are in some of the BG packages for Virtex E.
> Has anyone got any words of wisdom?
> 'Bert Ross

I don't think the rule 'one cap per supply pin' is always an effective
pratice to follow, unless you are using double-layer PCB. As John_H
has pointed out, a good PCB stackup will significantly improve your
board decoupling capability.
My solution is to first estimate the maximum transient current of the
chip and the maximal supply voltage droop which can be tolerated. With
those 2 values available, you are able to calculate out the target
impedance your power distribution system has to meet. And you can use
the target impedance to determine the capacitor value and quantity
needed for your system.
There are actually a lot of heated discussion about the power
distribution decoupling for high-speed devices in the internet forum.
If you are interested in more details of the scheme, SI-LIST
(http://www.qsl.net/wb6tpu/) is a very helpful place to go. You can
find a lot of related information in its mail archive and pdf
presentation contributed by some gurus who have dedicated deeply in
this area.
If you have MathCAD available, you can download a worksheet made by me
from the following link:
http://philharmania.diy.163.com/Downloads/DecouplingCapacitor.mcd
This worksheet calculate decoupling capacitors based on the spice
model from KEMET and articles in SI-LIST. I made it briefly for my own
use so it may not be handy for others, but you are welcome to have a
try.

Article: 48701
Subject: LCD driver implement with FPGA
From: "Reala" <->
Date: Wed, 23 Oct 2002 10:10:14 +0800
Links: << >>  << T >>  << A >>
Is this possible to implement a LCD driver/controller by FPGA?
According to my understanding, LCD driver have some Analog part (eg. the
output pin for driving the LCD, Bias voltage). It seems that it is a
problem.

Is there any example about the LCD driver design which it can find in the
internet?

Thanks ^_^



Article: 48702
Subject: Re: LCD driver implement with FPGA
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 23 Oct 2002 15:33:23 +1300
Links: << >>  << T >>  << A >>
Reala wrote:
> 
> Is this possible to implement a LCD driver/controller by FPGA?
> According to my understanding, LCD driver have some Analog part (eg. the
> output pin for driving the LCD, Bias voltage). It seems that it is a
> problem.
> 
> Is there any example about the LCD driver design which it can find in the
> internet?

 The Philips data, on their PCF85xx family of LCD driver chips covers
this quite well.
 You can see the waveforms for various MUX ratios.

- jg

Article: 48703
Subject: Re: LCD driver implement with FPGA
From: Ray Andraka <ray@andraka.com>
Date: Wed, 23 Oct 2002 02:40:16 GMT
Links: << >>  << T >>  << A >>
Yes you can.  Basically with LCDs, you have to make sure you don't apply any
DC bias.  What that means is that you drive both sides of the element
alternately.  An xor arrangement usually works fine for this.

Reala wrote:

> Is this possible to implement a LCD driver/controller by FPGA?
> According to my understanding, LCD driver have some Analog part (eg. the
> output pin for driving the LCD, Bias voltage). It seems that it is a
> problem.
>
> Is there any example about the LCD driver design which it can find in the
> internet?
>
> Thanks ^_^

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 48704
Subject: Serial PROM Configuration
From: "Sanjay Patil" <sanjay@cg-coreel.com>
Date: Wed, 23 Oct 2002 09:04:36 +0530
Links: << >>  << T >>  << A >>
Hi,
In my current design i am using multiple XC18VXX seires PROMS to configure
the FPGA in master serial mode. I have one JTAG connector for the FPGA and
one for the serial PROMS. I connected the 3 PROMS in daisy chain.
This is how i connected the PROMS

JTAG_TDI--------> PROM1_TDO------PROM2_TDO------PROM3_TDO------JTAG_TDO

AND if the FPGA is connected to the PROMS (MASTER SERIAL MODE)  in the
following way


FPGA_DIN<-------------PROM1_DOUT-<----------------PROM2_DOUT<---------------
------PROM3_DOUT

On power on FPGA reads the data from PROM1 and then from PROM2 and then from
PROM3 IN MASTER serial mode. If this is the case the FPGA bitstream file
should be split into three parts. PROM1 holds the first part, PROM2 holding
the second part and the PROM3 holding the remaining data.

I would like to know how the FPGA bitstream file is split into three parts
and sequence in which the PROMS gets programmed through JTAG mode. My
understanding referring to the chain one is that PROM1 which is the first
PROM connected directly to the FPGA is programmed first. Once it gets
programmed it suppose to transfer whatever comeson TDI on TDO which is goes
as TDI to PROM2 and so on...

But one of XILINX apllication note says PROM3 gets programmed first then
PROM 2 and finally PROM1.  I am not understanding how this will happen.
Please give some explanation on how exactly Bitstream file gets programmed
to Multiple PROMS.

Can anybody help me.
--Sanjay



Article: 48705
Subject: Re: Altera FPGA and EPLD Download ByteBlaster
From: hamilton <hamilton@dont.do.it.here.com>
Date: Tue, 22 Oct 2002 21:38:16 -0600
Links: << >>  << T >>  << A >>
All one man shops use Paypal as their only payment system.


Rene Tschaggelar wrote:

> Why is the price of 48$ that hard to find ?
>
> Rene
>
> James Wang wrote:
> > Hi,
> >
> > We are making Download ByteBlasterMV for Altera FPGA and EPLD
> > configuration/programming. It's reliable, affordale and suitable for
> > PLD development and somebody who want's to learn PLD. Details please
> > check at: http://www.minford.ca.


Article: 48706
Subject: Re: High Performance FPGA's - Xilinx and ??????
From: "Brian Guralnick" <innerdimension@videotron.ca>
Date: Wed, 23 Oct 2002 00:21:22 -0400
Links: << >>  << T >>  << A >>
Take a look at Altera's Cyclone.

http://www.altera.com/products/devices/cyclone/cyc-index.jsp

2PLLs, 480Mhz DDR ram interface, 8 pin dual use boot prom & very cheap.


____________
Brian Guralnick
innerdimension@hotmail.com
(514) 624-4003


"M Pedley" <Pedley@talk21.com> wrote in message news:b34821cd.0210220446.655db7d3@posting.google.com...
> Are there any other companies other than Xilinx that produce FPGA's to
> match there latest Virtex II designs.  I require 400 MHz DDR (800
> Mbps) line side, with a 200MHz core containing at least 400 Kbits of
> RAM.  It is for a communications protocol so features similar to
> Xilinx's DCM's that can centre a clock to a data eye (i.e. Phase
> shifting) and perform lane deskew.
>
> I have nothing against Xilinx but just interested to see if anyone
> else offered this kind of specification.  Google search for High
> Performance FPGA's didn't give me any useful results.
>
> Also, interested to hear anyones recommendations or concerns about the
> claims that Xilinx make about their FPGAs, as an ASIC designer they
> seem a bit too good!?
>
> Regards,
>
> Matt



Article: 48707
Subject: Re: LCD driver implement with FPGA
From: "Blackie Beard" <BlackBeard@FearlessImmortalWretch.com>
Date: Wed, 23 Oct 2002 04:31:21 GMT
Links: << >>  << T >>  << A >>
OK, let me see.  Reala wrote he needs to
drive some bias voltage, and Ray says that
with LCDs, you have to make sure you don't
apply any DC bias.  You must be talking two
different things.  If you do need to drive a DC
bias, and it's not something that could cause
critical failure, I suppose you could control
the duty cycle into an RC network.  Usually
the analog control is adjusted one time and
left, though.  I've done an alphanumeric LCD
module that boots the controller chip and
accepts commands, if you want some code
for that, let me know...  It's parameterized
for oscillator speed (most AN LCD's are
very slow).

BB
===============================

"Ray Andraka" <ray@andraka.com> wrote in message
news:3DB60BF8.3813828C@andraka.com...
> Yes you can.  Basically with LCDs, you have to make sure you don't apply
any
> DC bias.  What that means is that you drive both sides of the element
> alternately.  An xor arrangement usually works fine for this.
>
> Reala wrote:
>
> > Is this possible to implement a LCD driver/controller by FPGA?
> > According to my understanding, LCD driver have some Analog part (eg. the
> > output pin for driving the LCD, Bias voltage). It seems that it is a
> > problem.
> >
> > Is there any example about the LCD driver design which it can find in
the
> > internet?
> >
> > Thanks ^_^
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>



Article: 48708
Subject: Verilog simulation performance on dual-CPU Linux?
From: eda_dude <dont@reply.net>
Date: Wed, 23 Oct 2002 05:00:07 GMT
Links: << >>  << T >>  << A >>
(My real question is at the bottom of this post...the stuff
 in between is just a background filler to explain why I'm
 asking.)

Late last year, our company assembled a dual-CPU Pentium3-S 1.26GHz
(the 'S' model has 512K L2 on-die cache), with 4096MB PC133 CL3 
registered SDRAM, Seagate 80GB 7200rpm ATA/100 disk, and Redhat 7.2.

We (actually ME) religiously keep the base Redhat 7.2 installation
up to date with the latest kernel RPMs from Redhat's update mirror.

Using Cadence NC-Verilog as the test application, I ran some 
head-2-head benchmarks to compare our dual-CPU Linux vs our
Sun Blade-1000 2/750 (dual Sun US3-750MHz)

First, running *1* job only (per system.)...
In 'small' RTL simulations (whose executable footprint apparently fit 
inside the P3's L2-cache), the Pentium3 beat the Blade by 20-30%.
It's hard to quantify 'small', because coding-style and testbench
architecture contribute to the sim's overall 'execution complexity.'

In our 'medium' RTL simulation (this was a chip which synthesizes to
~150Kgates), the Blade easily outran the Pentium3 by 50-70%!  The
Blade's larger 8MB L2-cache really helps, here.

In back-annotated gate-level simulation (of the medium-RTL design), 
the Blade and Pentium3 were about dead even...most likely the active
data-set trashes the L2-cache on both platforms.

...
Now, if I launch *TWO* jobs simultaneously (on both platforms),
the Blade scales almost linearly -- Let's say job-A runs by itself
for 5 minutes, and job-B runs by itself for 5 minutes.  If I run
both at the same time, both jobs complete in the same time (5min.)

The Pentium3 really fell apart here -- if I run both jobs at the same
time, both jobs take about 30-50% longer to complete.  This is a
really sub-linear scaling.
...

Soon, we will need to buy additional compute resources.  One option
is to simply buy single-CPU Linux boxes, and run one job per box.
For us, this is a hassle/inconvenience, because our network 
infrastructure/management makes it cumbersome to have so many indiv
Linux machines.

The second option is to buy dual-CPU Linux boxes.  But our
sour experience shows the job-load scaling on the dual Pentium3-S 
is quite poor.  

My question is, for running multiple instances of a single-threaded 
program (an NC-Verilog job will only use 1 CPU during execution),
which platform is better?  A dual AMD Athlon-MP, or a dual
Pentium4-Xeon?  

(We'd buy server-motherboards with DDR memory 
slots.  And we already know the Sun Blade scales excellently, but 
it's a bit expensive.)

[P.S., I do have a single-CPU AthlonXP 1700+ Linux box, PC2100 DDR.
  The 'small' RTL Verilog job runtime was nearly identical to the
 Pentium3.  Design_Compiler synthesis runtimes on both machines are
 equal, as well.  Either Linux box is 30-50% faster than the Blade.]

Article: 48709
Subject: Flash Programmer
From: "geeko" <jibin@ushustech.com>
Date: Wed, 23 Oct 2002 10:43:56 +0530
Links: << >>  << T >>  << A >>
Hi All
    I would like to know about various Flash Programmers /Erasers available



Article: 48710
Subject: Re: LCD driver implement with FPGA
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Wed, 23 Oct 2002 06:09:50 GMT
Links: << >>  << T >>  << A >>
On Wed, 23 Oct 2002 04:31:21 GMT, "Blackie Beard"
<BlackBeard@FearlessImmortalWretch.com> wrote:

>OK, let me see.  Reala wrote he needs to
>drive some bias voltage, and Ray says that
>with LCDs, you have to make sure you don't
>apply any DC bias.  You must be talking two
>different things.

>If you do need to drive a DC
>bias

No, this is never done as it damages the LCD.  Reala's "bias" is the
supply voltage for the drivers.  It determines the p-p voltage applied
to the LCD.  There is no DC component.

For a non-multiplexed (or direct drive) LCD, the backplane is driven
with a square wave, and the individual segments are driven with a
square wave that is either in phase or out of phase with the backplane
drive to turn the segment on or off respectively.  As Ray suggested,
this is done with an XOR per segment.
The contrast is determined by the p-p voltage, but for non-multiplexed
LCDs the voltage usually isn't that critical.
It may be feasible to drive this sort of LCD from an FPGA.

For a multiplexed LCD, there are multiple backplanes and multiple
segment lines.  There are multiple voltage levels (typically 4 levels,
e.g. at 0V, vbias/3, 2*vbias/3 and vbias) used on both the backplanes
and the segment lines.
It is not feasible to drive this sort of LCD from an FPGA.
As Jim suggested, the Philips LCD driver datasheets have good
information, e.g.:
http://www.semiconductors.philips.com/acrobat/datasheets/PCF8576C_7.pdf

Large dot matrix displays require a multiplexing ratio so high that
the contrast is unusably low.  This led to the development of TFT
displays, which have an individual driver for each (non-multiplexed)
pixel.

Regards,
Allan.

>, and it's not something that could cause
>critical failure, I suppose you could control
>the duty cycle into an RC network.  Usually
>the analog control is adjusted one time and
>left, though.  I've done an alphanumeric LCD
>module that boots the controller chip and
>accepts commands, if you want some code
>for that, let me know...  It's parameterized
>for oscillator speed (most AN LCD's are
>very slow).
>
>BB
>===============================
>
>"Ray Andraka" <ray@andraka.com> wrote in message
>news:3DB60BF8.3813828C@andraka.com...
>> Yes you can.  Basically with LCDs, you have to make sure you don't apply
>any
>> DC bias.  What that means is that you drive both sides of the element
>> alternately.  An xor arrangement usually works fine for this.
>>
>> Reala wrote:
>>
>> > Is this possible to implement a LCD driver/controller by FPGA?
>> > According to my understanding, LCD driver have some Analog part (eg. the
>> > output pin for driving the LCD, Bias voltage). It seems that it is a
>> > problem.
>> >
>> > Is there any example about the LCD driver design which it can find in
>the
>> > internet?
>> >
>> > Thanks ^_^
>>
>> --
>> --Ray Andraka, P.E.
>> President, the Andraka Consulting Group, Inc.
>> 401/884-7930     Fax 401/884-7950
>> email ray@andraka.com
>> http://www.andraka.com
>>
>>  "They that give up essential liberty to obtain a little
>>   temporary safety deserve neither liberty nor safety."
>>                                           -Benjamin Franklin, 1759
>>
>>
>
>


Article: 48711
Subject: Re: LCD driver implement with FPGA
From: "Reala" <->
Date: Wed, 23 Oct 2002 17:34:34 +0800
Links: << >>  << T >>  << A >>
Thank you for all of your quick reply.
I am very happy if you can share the code with me. My email is
realareala@yahoo.com.hk
Thank you.

ar...for my understanding, LCD is driven by AC , because DC will damage the
LCD.
For simple LCD (eg. 7-segment, TN), we need 5V and 0V for On/OFF only.
So, it seems that it is no a problem to implement by FPGA. However, i do not
have any experience about design LCD driver/controller, so I want to find
some resources about this.

For higher mux LCD (128x64, STN Scheme B), it may be driven by output
pin(connected to
LCD) with 4 different voltages (eg. 5V, 3V, 2V, 0V).
(I means that the output pin output 4 different voltages)
Can the FPGA output pin different voltages? It seems not?

Moreover, for high speed operation (update 128 X 64 X 50 pixel per sec
50hz frame frequency). It may be a problem because we turn on and off the
pixel.....
I am not sure the output pin of FPGA can handle this or not...^_^

Reala
"Blackie Beard" <BlackBeard@FearlessImmortalWretch.com> wrote in message
news:tCpt9.512$IU6.334@nwrddc03.gnilink.net...
> OK, let me see.  Reala wrote he needs to
> drive some bias voltage, and Ray says that
> with LCDs, you have to make sure you don't
> apply any DC bias.  You must be talking two
> different things.  If you do need to drive a DC
> bias, and it's not something that could cause
> critical failure, I suppose you could control
> the duty cycle into an RC network.  Usually
> the analog control is adjusted one time and
> left, though.  I've done an alphanumeric LCD
> module that boots the controller chip and
> accepts commands, if you want some code
> for that, let me know...  It's parameterized
> for oscillator speed (most AN LCD's are
> very slow).
>
> BB
> ===============================
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3DB60BF8.3813828C@andraka.com...
> > Yes you can.  Basically with LCDs, you have to make sure you don't apply
> any
> > DC bias.  What that means is that you drive both sides of the element
> > alternately.  An xor arrangement usually works fine for this.
> >
> > Reala wrote:
> >
> > > Is this possible to implement a LCD driver/controller by FPGA?
> > > According to my understanding, LCD driver have some Analog part (eg.
the
> > > output pin for driving the LCD, Bias voltage). It seems that it is a
> > > problem.
> > >
> > > Is there any example about the LCD driver design which it can find in
> the
> > > internet?
> > >
> > > Thanks ^_^
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> >  "They that give up essential liberty to obtain a little
> >   temporary safety deserve neither liberty nor safety."
> >                                           -Benjamin Franklin, 1759
> >
> >
>
>







Article: 48712
Subject: Re: LCD driver implement with FPGA
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Wed, 23 Oct 2002 11:48:59 +0200
Links: << >>  << T >>  << A >>
I am a bit confused with all of this, or perhaps it is just the type of LCD
display that is being used. The one that I have used in the past (attached
to a microcontroller) runs off a 5 volt DC supply and has a small
microcomputer on board which accepts commands loaded into its instruction
register... non multiplexing. Each digit has a memory space which you write
data to. No need for any square wave inputs... or am I just barking at the
wrong end of the stick?

adrian


> >OK, let me see.  Reala wrote he needs to
> >drive some bias voltage, and Ray says that
> >with LCDs, you have to make sure you don't
> >apply any DC bias.  You must be talking two
> >different things.
>
> >If you do need to drive a DC
> >bias
>
> No, this is never done as it damages the LCD.  Reala's "bias" is the
> supply voltage for the drivers.  It determines the p-p voltage applied
> to the LCD.  There is no DC component.
>
> For a non-multiplexed (or direct drive) LCD, the backplane is driven
> with a square wave, and the individual segments are driven with a
> square wave that is either in phase or out of phase with the backplane
> drive to turn the segment on or off respectively.  As Ray suggested,
> this is done with an XOR per segment.
> The contrast is determined by the p-p voltage, but for non-multiplexed
> LCDs the voltage usually isn't that critical.
> It may be feasible to drive this sort of LCD from an FPGA.
>
> For a multiplexed LCD, there are multiple backplanes and multiple
> segment lines.  There are multiple voltage levels (typically 4 levels,
> e.g. at 0V, vbias/3, 2*vbias/3 and vbias) used on both the backplanes
> and the segment lines.
> It is not feasible to drive this sort of LCD from an FPGA.
> As Jim suggested, the Philips LCD driver datasheets have good
> information, e.g.:
> http://www.semiconductors.philips.com/acrobat/datasheets/PCF8576C_7.pdf
>
> Large dot matrix displays require a multiplexing ratio so high that
> the contrast is unusably low.  This led to the development of TFT
> displays, which have an individual driver for each (non-multiplexed)
> pixel.
>
> Regards,
> Allan.
>
> >, and it's not something that could cause
> >critical failure, I suppose you could control
> >the duty cycle into an RC network.  Usually
> >the analog control is adjusted one time and
> >left, though.  I've done an alphanumeric LCD
> >module that boots the controller chip and
> >accepts commands, if you want some code
> >for that, let me know...  It's parameterized
> >for oscillator speed (most AN LCD's are
> >very slow).
> >
> >BB
> >===============================
> >
> >"Ray Andraka" <ray@andraka.com> wrote in message
> >news:3DB60BF8.3813828C@andraka.com...
> >> Yes you can.  Basically with LCDs, you have to make sure you don't
apply
> >any
> >> DC bias.  What that means is that you drive both sides of the element
> >> alternately.  An xor arrangement usually works fine for this.
> >>
> >> Reala wrote:
> >>
> >> > Is this possible to implement a LCD driver/controller by FPGA?
> >> > According to my understanding, LCD driver have some Analog part (eg.
the
> >> > output pin for driving the LCD, Bias voltage). It seems that it is a
> >> > problem.
> >> >
> >> > Is there any example about the LCD driver design which it can find in
> >the
> >> > internet?
> >> >
> >> > Thanks ^_^
> >>
> >> --
> >> --Ray Andraka, P.E.
> >> President, the Andraka Consulting Group, Inc.
> >> 401/884-7930     Fax 401/884-7950
> >> email ray@andraka.com
> >> http://www.andraka.com
> >>
> >>  "They that give up essential liberty to obtain a little
> >>   temporary safety deserve neither liberty nor safety."
> >>                                           -Benjamin Franklin, 1759
> >>
> >>
> >
> >
>



Article: 48713
Subject: Re: High Performance FPGA's - Xilinx and ??????
From: Pedley@talk21.com (M Pedley)
Date: 23 Oct 2002 03:45:49 -0700
Links: << >>  << T >>  << A >>
Thanks,

The Altera Stratix does look quite good.  I was possibly being a bit
ambitious with my original spec as Xilinx only claim 800Mbps outputs
when using their own fixed netlist cores.  As long as it can run at
311MHz, 622Mbps Output Data Rate then that should be fine.

Cost is not really an issue (as far as i know), i am under the
impression that these FPGAs cost upto a few thousand dollars??, we are
looking for the highest spec FPGA that best suits our requirements
(High Speed Data comms with strict jitter tolerances).  It is going to
be used for simulating an ASIC without the time and money involved in
immediately producing a test chip (around $1million!).

Matt

Article: 48714
Subject: Re: LCD driver implement with FPGA
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Wed, 23 Oct 2002 12:21:40 GMT
Links: << >>  << T >>  << A >>
On Wed, 23 Oct 2002 17:34:34 +0800, "Reala" <-> wrote:

>Thank you for all of your quick reply.
>I am very happy if you can share the code with me. My email is
>realareala@yahoo.com.hk
>Thank you.
>
>ar...for my understanding, LCD is driven by AC , because DC will damage the
>LCD.
>For simple LCD (eg. 7-segment, TN), we need 5V and 0V for On/OFF only.
>So, it seems that it is no a problem to implement by FPGA. However, i do not
>have any experience about design LCD driver/controller, so I want to find
>some resources about this.
>
>For higher mux LCD (128x64, STN Scheme B), it may be driven by output
>pin(connected to
>LCD) with 4 different voltages (eg. 5V, 3V, 2V, 0V).
>(I means that the output pin output 4 different voltages)
>Can the FPGA output pin different voltages? It seems not?

No they can't.

It gets worse.  For a high multiplexing ratio, the supply voltage for
the drivers must be quite high, much higher than an FPGA can handle,
in order to get enough average voltage on to the LCD segments.
A quick web search reveals that large display panels need up to some
tens of volts.

The voltages also need to be adjustable under software control (to
adjust the contrast) and also to allow for temperature compensation.

This web site seems to have a lot of information:
http://www.samsungelectronics.com/semiconductors/tft_lcd/technology/electronic_aspects/electronic_aspects.htm

>Moreover, for high speed operation (update 128 X 64 X 50 pixel per sec
>50hz frame frequency). It may be a problem because we turn on and off the
>pixel.....
>I am not sure the output pin of FPGA can handle this or not...^_^

SSO?  This shouldn't be a problem, as you can use low drive strength
outputs and you can also skew them by a few ns without affecting the
display.

Regards,
Allan.

>Reala
>"Blackie Beard" <BlackBeard@FearlessImmortalWretch.com> wrote in message
>news:tCpt9.512$IU6.334@nwrddc03.gnilink.net...
>> OK, let me see.  Reala wrote he needs to
>> drive some bias voltage, and Ray says that
>> with LCDs, you have to make sure you don't
>> apply any DC bias.  You must be talking two
>> different things.  If you do need to drive a DC
>> bias, and it's not something that could cause
>> critical failure, I suppose you could control
>> the duty cycle into an RC network.  Usually
>> the analog control is adjusted one time and
>> left, though.  I've done an alphanumeric LCD
>> module that boots the controller chip and
>> accepts commands, if you want some code
>> for that, let me know...  It's parameterized
>> for oscillator speed (most AN LCD's are
>> very slow).
>>
>> BB
>> ===============================
>>
>> "Ray Andraka" <ray@andraka.com> wrote in message
>> news:3DB60BF8.3813828C@andraka.com...
>> > Yes you can.  Basically with LCDs, you have to make sure you don't apply
>> any
>> > DC bias.  What that means is that you drive both sides of the element
>> > alternately.  An xor arrangement usually works fine for this.
>> >
>> > Reala wrote:
>> >
>> > > Is this possible to implement a LCD driver/controller by FPGA?
>> > > According to my understanding, LCD driver have some Analog part (eg.
>the
>> > > output pin for driving the LCD, Bias voltage). It seems that it is a
>> > > problem.
>> > >
>> > > Is there any example about the LCD driver design which it can find in
>> the
>> > > internet?
>> > >
>> > > Thanks ^_^
>> >
>> > --
>> > --Ray Andraka, P.E.
>> > President, the Andraka Consulting Group, Inc.
>> > 401/884-7930     Fax 401/884-7950
>> > email ray@andraka.com
>> > http://www.andraka.com
>> >
>> >  "They that give up essential liberty to obtain a little
>> >   temporary safety deserve neither liberty nor safety."
>> >                                           -Benjamin Franklin, 1759
>> >
>> >
>>
>>
>
>
>
>
>
>


Article: 48715
Subject: Re: High Performance FPGA's - Xilinx and ??????
From: hamish@cloud.net.au
Date: 23 Oct 2002 13:20:00 GMT
Links: << >>  << T >>  << A >>
In comp.arch.fpga M Pedley <Pedley@talk21.com> wrote:
> The Altera Stratix does look quite good.  I was possibly being a bit
> ambitious with my original spec as Xilinx only claim 800Mbps outputs
> when using their own fixed netlist cores.  As long as it can run at
> 311MHz, 622Mbps Output Data Rate then that should be fine.

I've done 700Mbs rate (350 MHz clock) in VirtexII-5 in my own code. It's
not all that difficult to do; just keep the levels-of-logic down and
hand place the flip flops to remove any chance of the placing letting
you down. I never tried for any faster.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 48716
Subject: Re: Silly Virtex 2 Pro question...
From: mrand@my-deja.com (Marc Randolph)
Date: 23 Oct 2002 06:24:56 -0700
Links: << >>  << T >>  << A >>
nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote in message news:<ap40j8$gm4$1@agate.berkeley.edu>...
> The Xilinx Answer Record states that the RocketI/Os on the V2Pro have
> been tested and verified to work with 1000BASE-SX (fiber Gb ethernet,
> multimode fiber).
> 
> The media for 1000BASE-T however is a 4 pair differential signaling,
> rather than the serial send/receive of the fiber standards.
> 
> Are there low cost solutions for driving 1000BASE-T ethernet using the
> RocketI/Os?

Howdy Nicholas,

The signaling put out on the cable of a 1000Base-T link is not digital
in any way, shape, or form - so it can't be connected directly to an
FPGA.  To interface to a 1000Base-T cable, you need a SERDES
[serializer/deserializer] from a chip maker like Marvell, Broadcom, or
a few others.

Note that many companies (mistakenly, IMO) call their device a
transceiver rather than a SERDES.

Have fun,

   Marc

Article: 48717
Subject: Re: slow slew rate signal...
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Wed, 23 Oct 2002 14:34:46 +0100
Links: << >>  << T >>  << A >>
On Tue, 22 Oct 2002 08:55:22 -0700, Peter Alfke <peter@xilinx.com>
wrote:

>I support Austin's idea of filtering the input signal with a digital low-pass
>filter.
>But there may also be another solution.
>You don't like to add a Schmitt trigger because that would change the pc-board.
>
>Well, it doesn't have to.
>Depending on the output impedance of your optocoupler, you can achieve
>Schmitt-trigger performance if you drive the input signal non-inverted back
>onto the same pin. Make the output drive as week as you can ( 2 mA) which means
>about 100 to 200 Ohm.
>If the optocoupler output impedance is in the 50 to 100 Ohm range, you might
>have a nice hysteresis on the input...
>
Alternatively, since opto-couplers are usually open collector style
outputs... is it just the rising edge (controlled by a pull-up resistor)
or also the falling edge that cause problems?

The state machine could go through intermediate states ( filtering the
input as others have suggested) ... in the first intermediate state it
could enable its output buffer to accelerate the rise time (and/or fall
time) through the transition region, then disable the output again until
the next detected rising (and/or falling) edge.

- Brian


Article: 48718
Subject: Re: High Performance FPGA's - Xilinx and ??????
From: "Brian Guralnick" <innerdimension@videotron.ca>
Date: Wed, 23 Oct 2002 10:05:03 -0400
Links: << >>  << T >>  << A >>
If you want speed, go for the Altera Mercury, or Xilinx's latest stuff.

____________
Brian Guralnick
innerdimension@hotmail.com
(514) 624-4003


"M Pedley" <Pedley@talk21.com> wrote in message news:b34821cd.0210230245.3e5080db@posting.google.com...
> Thanks,
>
> The Altera Stratix does look quite good.  I was possibly being a bit
> ambitious with my original spec as Xilinx only claim 800Mbps outputs
> when using their own fixed netlist cores.  As long as it can run at
> 311MHz, 622Mbps Output Data Rate then that should be fine.
>
> Cost is not really an issue (as far as i know), i am under the
> impression that these FPGAs cost upto a few thousand dollars??, we are
> looking for the highest spec FPGA that best suits our requirements
> (High Speed Data comms with strict jitter tolerances).  It is going to
> be used for simulating an ASIC without the time and money involved in
> immediately producing a test chip (around $1million!).
>
> Matt



Article: 48719
Subject: Re: High Performance FPGA's - Xilinx and ??????
From: "Brian Guralnick" <innerdimension@videotron.ca>
Date: Wed, 23 Oct 2002 10:08:55 -0400
Links: << >>  << T >>  << A >>
However, for the 400Kbit internal ram, the Altera Stratix is probably the best & fastest solution.  To get anything else cost worthy
with over 400Kbit, you will need to connect to ZBTRam.

____________
Brian Guralnick
innerdimension@hotmail.com
(514) 624-4003


"M Pedley" <Pedley@talk21.com> wrote in message news:b34821cd.0210230245.3e5080db@posting.google.com...
> Thanks,
>
> The Altera Stratix does look quite good.  I was possibly being a bit
> ambitious with my original spec as Xilinx only claim 800Mbps outputs
> when using their own fixed netlist cores.  As long as it can run at
> 311MHz, 622Mbps Output Data Rate then that should be fine.
>
> Cost is not really an issue (as far as i know), i am under the
> impression that these FPGAs cost upto a few thousand dollars??, we are
> looking for the highest spec FPGA that best suits our requirements
> (High Speed Data comms with strict jitter tolerances).  It is going to
> be used for simulating an ASIC without the time and money involved in
> immediately producing a test chip (around $1million!).
>
> Matt



Article: 48720
Subject: data sheets for tda5247ht
From: "a" <hermine.kowka@laposte.net>
Date: Wed, 23 Oct 2002 16:15:57 +0200
Links: << >>  << T >>  << A >>
Sir ,
I am looking for the datasheets of the device TDA5247HT (I COULDN4T FIND IT
ON THE PHILIPS WEB SITE).
yours faithfully ,
hermine.kowka@laposte.net



Article: 48721
Subject: ngdbuild - command line in xilinx' ISE tools
From: furia1024@wp.pl (Jerzy)
Date: 23 Oct 2002 07:17:05 -0700
Links: << >>  << T >>  << A >>
Hello
Does someone use Xilinx' tools without GUI.
I've got problem with translting ie:
 
ngdbuild -dd c:/projekty/ise/mizar_50_final/_ngo -nt timestamp -p
xcv300e-bg432-8 x_test.ngc x_test.ngd

generates:

ngdbuild:  version C.22
Copyright (c) 1995-1999 Xilinx, Inc.  All rights reserved.

Command Line: ngdbuild -dd c:/projekty/ise/mizar_50_final/_ngo -nt
timestamp -p
xcv300e-bg432-8 x_test.ngc x_test.ngd 

ERROR:NgdBuild:205 - Undefined keyword "QUIET" in option string!
ERROR:NgdBuild:253 - Launcher: Error parsing NetlisterTopOptions
   "[$IGNORE_LOCS] [$ADD_PADS] [$QUIET] {-l $LIBRARIES} $INFILE
$OUTFILE" for
   rule MOD_RULE
ERROR:NgdBuild:205 - Undefined keyword "QUIET" in option string!
ERROR:NgdBuild:253 - Launcher: Error parsing NetlisterTopOptions "[-p
$PART] -u
[...]

What's going on? In GUI everything goes right.

Greatings

furia

Article: 48722
Subject: Re: Nios and quartus linux version
From: Prager Roman <rprager@frequentis.com>
Date: Wed, 23 Oct 2002 14:30:21 GMT
Links: << >>  << T >>  << A >>
 wrote:
> Hi all,
> As anybody tried to use Nios dev. tools and
> quartus on a Linux workstation ?
> What are the cons and pros ?
> Are the tools easy to use ? Are there special things to take care off ?
> Is the use of the RedHat 7.1 mandatory or is it possible to
> use those EDA soft with other linux distributions such as 
> Mandrake (9.0 for instance) or Suse or whatever ?
> Thanks very much for your comments.
> Stephane
I used it with Suse 7.2, no problems 

But I did not get the serial interface for the NIOS monitor working, and of
course I am missing Leonardo. So I am not using it anymore. 
But it looks and feels exactly the same as the Windows versions. I did not
test it long enough to find some bugs.

Roman

Article: 48723
Subject: PCI ARBITER
From: DRENGER@EVS.CO.IL (DRENGER GABI)
Date: 23 Oct 2002 07:54:02 -0700
Links: << >>  << T >>  << A >>
Hi all,

I am looking for a PCI arbiter
"core" that could be droped in a ALTERA  FPGA

   THANK'S

     Gabi

Article: 48724
Subject: Re: slow slew rate signal...
From: phil_j_connor@hotmail.com (Phil Connor)
Date: 23 Oct 2002 07:55:43 -0700
Links: << >>  << T >>  << A >>
Hi Leon,

As others have mentioned use a simple majority voting system to 
de-bounce your slow changing input

ie. (approximate VHDL)

Process  (clock, reset)
delayedsignal_1 <= input;           --this happens on the first clock
delayedsignal_2 <= delayedsignal_1; --this happens on the next clock
delayedsignal_3 <= delayedsignal_2; --and this on the next
delayedsignal_4 <= delayedsignal_3; -- etc 
delayedsignal_5 <= delayedsignal_4;
....
....


if delayedsignal_1 = '1' and delayedsignal_2='1' and ........
         then output<='1'; --when they are all 1 you get 1

elsif delayedsignal_1 = '0' and delayedsignal_2='0' and ........
         then output<='0'; --when they are all 0 you get 0

else null; --make a latch  --otherwise it remembers
end if;

end process


If you like you can make a slow clock using the excellent clock
divider in the FAQ pages. Use this slow clock in the above process and
then the signals can be as slow as you like.

I've found with state machines you have to register all the inputs and
all the outputs or else you get glitches.

Best of Luck

Phil



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