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 48725

Article: 48725
Subject: How full is too full?
From: joefrese@hotmail.com (Joe Frese)
Date: 23 Oct 2002 08:28:13 -0700
Links: << >>  << T >>  << A >>
i have a completed fpga design that is implemented on a spartan2
xc2s200.  the design uses 96% of the part, and the suggestion has been
made that as such the part is "too full" and that perhaps i should
consider moving to a larger part (the 300e, to be precise).

i'm curious: is this a common practice, to move to a larger part when
a certain percentage of the current device has been utilized?  if so,
what's the maximum percentage of a part that one should feel
comfortable using?  or, is it common and/or acceptable to ship a
product that features 99-100% fpga utilization?

thanks in advance for your input.

joe

Article: 48726
Subject: Re: slow slew rate signal...
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Wed, 23 Oct 2002 17:37:38 +0200
Links: << >>  << T >>  << A >>
"Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it> schrieb im Newsbeitrag
news:z6ht9.64192$RO.1623408@twister1.libero.it...
> "Leon de Boer" <ldeboer@attglobal.net> ha scritto nel messaggio
> news:3db567c7_3@news1.prserv.net...
>
> > SOLUTIONS I CANT DO THAT WOULD WORK
> > 1.) Put a schmidt trigger on the signal (requires board
> > change)
> > 2.) Slow the state machine down to go over the state
> > machine
>
> I had a very similar problem (a state machine fed by some optocoupled
> inputs). I solved it by putting a flip-flop on each state machine input,
> clocked by the state machine clock (maybe inverted, I don't remember).

I thnik this didnt SOLVE the problem, this additional FlipFlop made a nerver
working FSM into a working FSM, since you have to synchronize asynchronous
inputs before using them in a FSM!!!!

--
MfG
Falk





Article: 48727
Subject: Re: How full is too full?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 23 Oct 2002 08:53:55 -0700
Links: << >>  << T >>  << A >>
Joe,

If it fits, and if it works over voltage and temperature, and it meets
timing with a suitable margin, and you have not exceeded the SSO
(simultaneous switching outputs) guidelines, and it doesn't overheat while
running, there is no reason to go to a larger device.

We have seen designs that are as full as you suggest that work fine.

If you think that sometime in the future, the design may change, and the
changes may have to add logic, then it is a good idea to use a larger
device to anticipate the future.  Even debugging an almost full design may
take more time as even small changes may be hard to squeeze in.

After all, FPGAs are regularly accused of "wasting" 20 transistors for
every one that is actually used, so from that standpoint, 99% full is
still practically empty (impossible to use every transistor).

Austin


Joe Frese wrote:

> i have a completed fpga design that is implemented on a spartan2
> xc2s200.  the design uses 96% of the part, and the suggestion has been
> made that as such the part is "too full" and that perhaps i should
> consider moving to a larger part (the 300e, to be precise).
>
> i'm curious: is this a common practice, to move to a larger part when
> a certain percentage of the current device has been utilized?  if so,
> what's the maximum percentage of a part that one should feel
> comfortable using?  or, is it common and/or acceptable to ship a
> product that features 99-100% fpga utilization?
>
> thanks in advance for your input.
>
> joe


Article: 48728
Subject: Re: ngdbuild - command line in xilinx' ISE tools
From: "Ulises Hernandez" <ulises@britain.agilent.com>
Date: Wed, 23 Oct 2002 16:57:31 +0100
Links: << >>  << T >>  << A >>
Hi Jerzy,

Everything seems ok to me. Anyway this is an example I know that works.
"ngdbuild -p xcv100e-7-fg256 -uc ../lca_build/top.ucf -dd ..
../lca_build/top.edf top.ngd"
Not much differences to be honest, I don't use the NGC command and the -nt
timestamp is a default option so you don't need to specify it.

What tool version are you using?

Regards.

--
Ulises Hernandez


"Jerzy" <furia1024@wp.pl> wrote in message
news:dc3feced.0210230617.6adecf7e@posting.google.com...
> 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: 48729
Subject: Re: slow slew rate signal...
From: "Leon de Boer" <ldeboer@attglobal.net>
Date: Thu, 24 Oct 2002 00:01:49 +0800
Links: << >>  << T >>  << A >>
   No it's not metastability, this problem would exist on even normal logic
not only FPGA's. Lets say I am dealing with 3V logic in which a low is
anything below 1 volt and a high anything above 2 volts. So what happens if
I have a 1.5V signal? Well it could go to either level. Okay lets say for
arguement that because it can't decide 50% of the time it reports as high
and 50% low.

   Now lets say I have a slow slew signal that takes 3uS to slew from 0V to
3V. For 1uS the signal will be definitely low, for 1uS the signal will be in
this 50/50 undefined area and for 1uS the signal will be high. Now lets
sample this signal at 10Mhz which means I get 10 samples for every 1uS. The
first 10 samples in the 1uS while the signal is low will be low. The last 10
samples in the 1uS while the signal is high will be high. But the middle 1uS
in the 50/50 zone will return random samples so lets say it returns the
following HLLHHLLHHL for its ten samples based on 50/50 probability of high
or low

So my sampled signal looks like

LLLLLLLLLL HLLHHLLHHL  HHHHHHHHHH
{ 10 samples } { 10 samples    } { 10 Samples }
{ low period }  { 50/50 period } { high period }

Remember ignoring the slew the signal was
LLLLLLLLLLLLLLLLLHHHHHHHHHHHHHH

In the 50/50 zone (which is not a stable input level) multiple sampling will
cause extra pulses and thus any attempt to use with a state machine these
false edges will glitch the state machine.



"Ansgar Bambynek" <a.bambynek_xxx_@avm.de> wrote in message
news:3db56703$0$228$4d4ebb8e@businessnews.de.uu.net...
> Not absolutely sure what you mean by state machine glitches.
> What is the slew rate of your incoming signal and what is the frequency of
> this signal.
> Additionaly I think you are facing a metastability problem.
>
> If the frequency of your incoming signal is lower that the fsm's frequency
> you can use a sync stage. Just use 2 ffs  in series to sample the incoming
> data.
> The output of your second ff can be used to feed the fsm. You can also use
> these two ffs
> for edge detection.
>
> HTH
>
> Ansgar
>
> --
> Attention please, reply address is invalid, please remove "_xxx_" ro reply
>
>
> "Leon de Boer" <ldeboer@attglobal.net> schrieb im Newsbeitrag
> news:3db567c7_3@news1.prserv.net...
> > I ran into a problem which drove me nuts but when I thought about it, it
> > made sense.
> >
> > - I have a signal I am trying to monitor with a state machine
> > - The state machine runs at 25Mhz
> > - The signal to sample incoming comes through an opto coupler and has a
> slow
> > slew rate.
> > - If I sample the high slew clock at this fast rate the state machine
> > glitches.
> > - I understand (NOW!!) the state machine glitches because I sample while
> the
> > signal is in the undefined point anround half Vcc or whatever where the
> > input can't decided if it is low or high so sometimes 2 samples in here
> are
> > seen as high an low and thus my state machine glitches.
> >
> > SOLUTIONS I CANT DO THAT WOULD WORK
> > 1.) Put a schmidt trigger on the signal (requires board change)
> > 2.) Slow the state machine down to go over the state machine
> >
> > Can anyone think of a solution that I could implement in VHDL code so I
> > don't have to relay the board?
> >
> > TIA Leon
> >
> >
> >
> >
>
>



Article: 48730
Subject: Re: slow slew rate signal...
From: "Leon de Boer" <ldeboer@attglobal.net>
Date: Thu, 24 Oct 2002 00:03:05 +0800
Links: << >>  << T >>  << A >>
Oversampling is what I currently have anyhow.
The other ideas will work but I don't want to scrap the board I have done.


"Theron Hicks" <hicksthe@egr.msu.edu> wrote in message
news:ap3p76$1ds4$1@msunews.cl.msu.edu...
> Leon,
>     A few ideas...
> 1.     Can you oversample the data in some fashion and then look for more
> that just 1 changed bit?
> 2.    Can you use a different type of opto-coupler such as one with either
a
> higher gain or a built-in Schmidt trigger?
> 3.    Depending on the configuration could you use a non-opto isolator
such
> as the iso-loop parts from nve corp? http://www.nve.com  (I have used
these
> at 100 megabaud and they are available from Digikey.  Cost seems to be
> reasonable given Digikey as a distributor.)
>
> Theron
>
> "Leon de Boer" <ldeboer@attglobal.net> wrote in message
> news:3db567c7_3@news1.prserv.net...
> > I ran into a problem which drove me nuts but when I thought about it, it
> > made sense.
> >
> > - I have a signal I am trying to monitor with a state machine
> > - The state machine runs at 25Mhz
> > - The signal to sample incoming comes through an opto coupler and has a
> slow
> > slew rate.
> > - If I sample the high slew clock at this fast rate the state machine
> > glitches.
> > - I understand (NOW!!) the state machine glitches because I sample while
> the
> > signal is in the undefined point anround half Vcc or whatever where the
> > input can't decided if it is low or high so sometimes 2 samples in here
> are
> > seen as high an low and thus my state machine glitches.
> >
> > SOLUTIONS I CANT DO THAT WOULD WORK
> > 1.) Put a schmidt trigger on the signal (requires board change)
> > 2.) Slow the state machine down to go over the state machine
> >
> > Can anyone think of a solution that I could implement in VHDL code so I
> > don't have to relay the board?
> >
> > TIA Leon
> >
> >
> >
> >
>
>



Article: 48731
Subject: Re: slow slew rate signal...
From: "Leon de Boer" <ldeboer@attglobal.net>
Date: Thu, 24 Oct 2002 00:05:29 +0800
Links: << >>  << T >>  << A >>
That will work.
All I have to do is work out how many samples is need to exceed the maximum
slew time.

Thanks

"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3DB56A63.FD4EC5A0@xilinx.com...
> Leon,
>
> You are completely correct in your assesment of what is happening.
>
> One way to deal with slow rising signals that may have noise on them is to
add
> states to the state machine.  If it senses a 'high', it then goes to a
"check
> that it is really going high+1" state where on the next state machine
clock, it
> checks again to see if it is still high.  One might have to add as many as
128
> checks (or more) for high, or low, depending on the state machine clock
rate,
> and the rise and fall times of the slow signal.
>
> If any sample disagrees, then the state returns to the beginning where it
starts
> all over checking for a change.
>
> Austin
>
> Leon de Boer wrote:
>
> > I ran into a problem which drove me nuts but when I thought about it, it
> > made sense.
> >
> > - I have a signal I am trying to monitor with a state machine
> > - The state machine runs at 25Mhz
> > - The signal to sample incoming comes through an opto coupler and has a
slow
> > slew rate.
> > - If I sample the high slew clock at this fast rate the state machine
> > glitches.
> > - I understand (NOW!!) the state machine glitches because I sample while
the
> > signal is in the undefined point anround half Vcc or whatever where the
> > input can't decided if it is low or high so sometimes 2 samples in here
are
> > seen as high an low and thus my state machine glitches.
> >
> > SOLUTIONS I CANT DO THAT WOULD WORK
> > 1.) Put a schmidt trigger on the signal (requires board change)
> > 2.) Slow the state machine down to go over the state machine
> >
> > Can anyone think of a solution that I could implement in VHDL code so I
> > don't have to relay the board?
> >
> > TIA Leon
>



Article: 48732
Subject: Re: slow slew rate signal...
From: "Leon de Boer" <ldeboer@attglobal.net>
Date: Thu, 24 Oct 2002 00:06:49 +0800
Links: << >>  << T >>  << A >>
They are synchronized the 25Mhz is the system clock that's the reason for
sampling with the thing. That's not the issue the slew through the undefined
logic levels is the problem.

"Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message
news:3DB57068.5080702@flukenetworks.com...
> Leon de Boer wrote:
>
>
> > - I have a signal I am trying to monitor with a state machine
> > - The state machine runs at 25Mhz
> > - The signal to sample incoming comes through an opto coupler and has a
slow
> > slew rate.
> > - If I sample the high slew clock at this fast rate the state machine
> > glitches.
>
>
> Consider synchronizing all inputs to the state machine to the 25Mhz clock.
>
>      -- Mike Treseler
>
>
>



Article: 48733
Subject: Re: slow slew rate signal...
From: "Leon de Boer" <ldeboer@attglobal.net>
Date: Thu, 24 Oct 2002 00:09:39 +0800
Links: << >>  << T >>  << A >>
Yep that would work, not elegant but it would work. You are biasing the
input so in the undefined zone it goes to the current output level.

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3DB574EB.3286B6B4@xilinx.com...
> 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...
>
> Peter Alfke
> =================
> Leon de Boer wrote:
>
> > I ran into a problem which drove me nuts but when I thought about it, it
> > made sense.
> >
> > - I have a signal I am trying to monitor with a state machine
> > - The state machine runs at 25Mhz
> > - The signal to sample incoming comes through an opto coupler and has a
slow
> > slew rate.
> > - If I sample the high slew clock at this fast rate the state machine
> > glitches.
> > - I understand (NOW!!) the state machine glitches because I sample while
the
> > signal is in the undefined point anround half Vcc or whatever where the
> > input can't decided if it is low or high so sometimes 2 samples in here
are
> > seen as high an low and thus my state machine glitches.
> >
> > SOLUTIONS I CANT DO THAT WOULD WORK
> > 1.) Put a schmidt trigger on the signal (requires board change)
> > 2.) Slow the state machine down to go over the state machine
> >
> > Can anyone think of a solution that I could implement in VHDL code so I
> > don't have to relay the board?
> >
> > TIA Leon
>



Article: 48734
Subject: Re: High Performance FPGA's - Xilinx and ??????
From: Patrick Loschmidt <Patrick.Loschmidt@gmx.net>
Date: Wed, 23 Oct 2002 18:10:12 +0200
Links: << >>  << T >>  << A >>
hamish@cloud.net.au schrieb:
> 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.

I reached the same rate and to my opinion it is not possible to get a 
faster design due to the routing delays which are limited by the speed 
grade.

Regards,
Patrick


Article: 48735
Subject: Re: slow slew rate signal...
From: "Leon de Boer" <ldeboer@attglobal.net>
Date: Thu, 24 Oct 2002 00:11:29 +0800
Links: << >>  << T >>  << A >>
It's only the lifting edge because only the resistor is pulling it up. The
open collector shorts directly to ground so the fall is quite quick.
Regards Leon

"Brian Drummond" <brian@shapes.demon.co.uk> wrote in message
news:2a9dru86skarcgmo816k0i581ufpqoolre@4ax.com...
> 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: 48736
Subject: Re: More Newbie Questions - What teaching resources
From: "Jan Gray" <jsgray@acm.org>
Date: Wed, 23 Oct 2002 09:28:11 -0700
Links: << >>  << T >>  << A >>
Ralph Mason wrote
> I am on the lookout for simple introduction type resources to verilog and
> cpu design, XSOC is good but complicated for someone not totally familiar
> with the concepts.

Fair enough.  It's also living in the "XC4000E-era".

Please also consider the simpler, non-pipelined, literate Verilog GR0000
design (for Virtex- and derivatives) presented in "Designing a Simple
FPGA-Optimized RISC CPU and System-on-a-Chip"
(http://fpgacpu.org/papers/soc-gr0040-paper.pdf).

See also Ken Chapman's "Creating Embedded Microcontrollers (Programmable
State Machines)" series
(http://xilinx.com/support/techxclusives/PSM-techX25.htm), and the 4- and
8-bit processrs (GNOME and DWARF) in Vanden Bout's Practial Xilinx Designer
Lab Book (http://www.xess.com/XSE_lab_book.html).

There are also some other potentially useful links at
www.fpgacpu.org/links.html.

Jan Gray, Gray Research LLC



Article: 48737
Subject: ANN: Embedded processor for Tcl language
From: "Scott Thibault" <thibault@gmvhdl.com>
Date: Wed, 23 Oct 2002 16:29:58 +0000 (UTC)
Links: << >>  << T >>  << A >>
AcroDesign Technologies has announced results from its work on an embedded
processor for the Tcl language.  More information, and a recent presentation
is available at: http://www.gmvhdl.com/acrodesign/research.html#tob

--Scott Thibault
AcroDesign Technologies

[[Send Tcl/Tk announcements to tcl-announce@mitchell.org
  Announcements archived at http://groups.yahoo.com/group/tcl_announce/
  Send administrivia to tcl-announce-request@mitchell.org
  Tcl/Tk at http://tcl.tk/ ]]


Article: 48738
Subject: Re: slow slew rate signal...
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 23 Oct 2002 09:32:29 -0700
Links: << >>  << T >>  << A >>
It's hysteresis, the classical Schmitt trigger. The trick is to use the fairly
high output impedance of the 2mA output buffer in conjunction with the several
times lower (!!??) optocoupler output impedance to get a reasonable amount of
hysteresis.

But you can also play around in the digital domain, for example using an
up/down counter of appropriate length, clocked at 25 MHz, with up/down
controlled by a synchronizing flip-flop (important!) driven from your data
input. Make the counter dead-ended at both extremes. The MSB is your filtered
data.

Peter Alfke
=================
Leon de Boer wrote:

> Yep that would work, not elegant but it would work. You are biasing the
> input so in the undefined zone it goes to the current output level.
>
> "Peter Alfke" <peter@xilinx.com> wrote in message
> news:3DB574EB.3286B6B4@xilinx.com...
> > 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...
> >
> > Peter Alfke
> > =================
> > Leon de Boer wrote:
> >
> > > I ran into a problem which drove me nuts but when I thought about it, it
> > > made sense.
> > >
> > > - I have a signal I am trying to monitor with a state machine
> > > - The state machine runs at 25Mhz
> > > - The signal to sample incoming comes through an opto coupler and has a
> slow
> > > slew rate.
> > > - If I sample the high slew clock at this fast rate the state machine
> > > glitches.
> > > - I understand (NOW!!) the state machine glitches because I sample while
> the
> > > signal is in the undefined point anround half Vcc or whatever where the
> > > input can't decided if it is low or high so sometimes 2 samples in here
> are
> > > seen as high an low and thus my state machine glitches.
> > >
> > > SOLUTIONS I CANT DO THAT WOULD WORK
> > > 1.) Put a schmidt trigger on the signal (requires board change)
> > > 2.) Slow the state machine down to go over the state machine
> > >
> > > Can anyone think of a solution that I could implement in VHDL code so I
> > > don't have to relay the board?
> > >
> > > TIA Leon
> >


Article: 48739
Subject: Re: slow slew rate signal...
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 23 Oct 2002 09:39:39 -0700
Links: << >>  << T >>  << A >>
Just sense a High input with your input synchronizing flip-flop, and make it
drive the pin (as an output) High with 2 mA drive strength. Tristate the driver
after you have sensed a Low input. (kind of an upside-down open collector
output driver).
Should be an easy and effective fix.

Peter Alfke, Xilinx Applications

Leon de Boer wrote:

> It's only the lifting edge because only the resistor is pulling it up. The
> open collector shorts directly to ground so the fall is quite quick.
> Regards Leon
>
> "Brian Drummond" <brian@shapes.demon.co.uk> wrote in message
> news:2a9dru86skarcgmo816k0i581ufpqoolre@4ax.com...
> > 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: 48740
Subject: Re: LCD driver implement with FPGA
From: ray.gaita@starband.net (Raymond Gaita)
Date: 23 Oct 2002 10:42:02 -0700
Links: << >>  << T >>  << A >>
I wasn't sure if you were doing character or graphic LCD displays.

If you're doing passive panel displays, you might take a look at the
Triscend solution using their E5 parts.  They have a reference design
with schematics and a module for their device plus device drivers for
the embedded 8051 controller.
http://www.triscend.com/solutions/graphiclcd.htm

There is also a module in the Triscend FastChip software for
interfacing directly with a character-based LCD.

If you're just driving 7-segment LEDs, there's a separate module for
that, too.

Raymond Gaita
ray.gaita _at_ starband.net

"Reala" <-> wrote in message news:<ap50q1$l6d1@imsp212.netvigator.com>...
> 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: 48741
Subject: Re: How full is too full?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 23 Oct 2002 17:53:21 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <c176b8c2.0210230728.7c22fc87@posting.google.com>,
Joe Frese <joefrese@hotmail.com> wrote:
>i have a completed fpga design that is implemented on a spartan2
>xc2s200.  the design uses 96% of the part, and the suggestion has been
>made that as such the part is "too full" and that perhaps i should
>consider moving to a larger part (the 300e, to be precise).
>
>i'm curious: is this a common practice, to move to a larger part when
>a certain percentage of the current device has been utilized?  if so,
>what's the maximum percentage of a part that one should feel
>comfortable using?  or, is it common and/or acceptable to ship a
>product that features 99-100% fpga utilization?
>
>thanks in advance for your input.

A little adendum to the excellent advice from Austin Lea

The biggest problem with a full device actually arrises from the
toolflows:  you have no margin to add anything for fixes, and the
automatic tools, especially mapping and placement, tend to start
really bogging down on very-full devices.

There is a really nasty effect, as placement only operates on packed
slices, so when the part is really full, mapping has to be more
agressive on packing the slices, making bad packings (unrelated logic
in the same slice) much more common.  

This is NOT a problem if you are mapping and placing the bulk of the
design yourself.

The 300E requires a different voltage from the 200, is not 5V tolerant
on the I/Os, but IS a fair bit faster.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 48742
Subject: Re: More Newbie Questions - What teaching resources
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 23 Oct 2002 17:54:47 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <dwlt9.322$8o1.60767@news.xtra.co.nz>,
Ralph Mason <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote:
>I am on the lookout for simple introduction type resources to verilog and
>cpu design, XSOC is good but complicated for someone not totally familiar
>with the concepts.
>
>I really want a 4 bit project that has steps to figure out your self. where
>you enhance it etc and then perhaps convert it to 8 bit / pipe lined

Smaller bitwidth isn't any simpler, especially in the days of HDL/FPGA
design.

If anything, the funky encodings you need to do meaningful stuff with
4 or 8 bit instruction words are more annoying.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 48743
Subject: Re: Serial PROM Configuration
From: kayrock66@yahoo.com (Jay)
Date: 23 Oct 2002 11:03:05 -0700
Links: << >>  << T >>  << A >>
The Xilinx software splits the bitstream into multiple files.  Also,
is there a reason why you used 2 seperate JTAG connectors?

President, Quadrature Peripherals
Altera, Xilinx and Digital Design Consulting
email: kayrock66@yahoo.com
http://fpga.tripod.com
-----------------------------------------------------------------------------

"Sanjay Patil" <sanjay@cg-coreel.com> wrote in message news:<ap5547$rm5el$1@ID-164436.news.dfncis.de>...
> 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: 48744
Subject: Re: LCD driver implement with FPGA
From: "Blackie Beard" <BlackBeard@FearlessImmortalWretch.com>
Date: Wed, 23 Oct 2002 18:11:27 GMT
Links: << >>  << T >>  << A >>
Oh. Thanks for explaining the details.  I figured he
may have been referring to the analog voltage setting
which adjusts the viewing angle, as on AN types.

Thx,
BB

=======================================

"Allan Herriman" <allan_herriman.hates.spam@agilent.com> wrote in message
news:3db635f7.68707736@netnews.agilent.com...
> 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: 48745
Subject: Re: LCD driver implement with FPGA
From: "Blackie Beard" <BlackBeard@FearlessImmortalWretch.com>
Date: Wed, 23 Oct 2002 18:13:36 GMT
Links: << >>  << T >>  << A >>
Hi Reala;

Can you send a link to the data sheet of the LCD
you are using, so I know whether it's what I'm
thinking about, or not?  We may be talking apples
and oranges.  Thanks,

BB

====================================

"Reala" <-> wrote in message news:ap5qad$l8r237@imsp212.netvigator.com...
> 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: 48746
Subject: Re: Altera FPGA and EPLD Download ByteBlaster
From: kayrock66@yahoo.com (Jay)
Date: 23 Oct 2002 11:14:17 -0700
Links: << >>  << T >>  << A >>
Hey, thats a pretty sweet deal, $30 for a download cable!  That even
beats the E-bay guy at $60.

President, Quadrature Peripherals
Altera, Xilinx and Digital Design Consulting
email: kayrock66@yahoo.com
http://fpga.tripod.com
-----------------------------------------------------------------------------
hamilton <hamilton@dont.do.it.here.com> wrote in message news:<3DB619A8.8FCD1960@dont.do.it.here.com>...
> 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: 48747
Subject: Re: PCI ARBITER
From: "Blackie Beard" <BlackBeard@FearlessImmortalWretch.com>
Date: Wed, 23 Oct 2002 18:24:02 GMT
Links: << >>  << T >>  << A >>
I'd like the whole PCI Master core, myself.  If anyone
has it in Verilog, I'd sure like to get that for free.  Also,
I wonder if I could get USB, Firewire, PCMCIA and IDE.
I asked Palmchip, but they said I had to pay.  Darn.

BB

===========================================

"DRENGER GABI" <DRENGER@EVS.CO.IL> wrote in message
news:974ec56.0210230654.2b8af54e@posting.google.com...
> Hi all,
>
> I am looking for a PCI arbiter
> "core" that could be droped in a ALTERA  FPGA
>
>    THANK'S
>
>      Gabi



Article: 48748
Subject: Re: ISE vs. Foundation
From: eda_dude <dont@reply.net>
Date: Wed, 23 Oct 2002 18:45:54 GMT
Links: << >>  << T >>  << A >>
> Hi,
> 
> Basically, Foundation uses Synopsys for synthesis, and ISE uses
> Xilinx's own 'XST' for synthesis.  (IIRC, Foundation used Aldec for
> simulation, while ISE uses ModelSim.)
> 
> Xilinx pulled the plug on Foundation in May of this year.  XST seems
> to work "just fine" for SpartanII, and IIE.
> 
> Install ISE, and the FPGA Express package, and you can use either
> synthesiser.

Does XST support Verilog2001?  

I downloaded the Xilinx Webpack ISE 5.x (about 2 weeks ago), and as 
far as I could tell, XST rejected a simple Verilog array-instantiation
(I thought these were part of the old Verilog IEEE-1995.)

module foo( a, b, c);   // make a silly AND gate!
  input a;
  input b;
  output c;

  assign c = a & b;
endmodule


module bar( x, y, z );
  parameter WIDTH = 10;

  input [ WIDTH-1:0 ] x;
  input [ WIDTH-1:0 ] y;
  output [ WIDTH-1:0 ] z;

  // make a parallel array of foo's :
  //   arrayed_foo[0] -> assign z[0] = x[0] & y[0];
  //   arrayed_foo[1] -> assign z[1] = x[1] & y[1];
  //     ...

  // we make the parallel-array by using an 'array instantiation',
  // this works in Synopsys DC 2001.08 and later, and Cadence PKS 5

  foo arrayed_foo[ WIDTH-1:0 ] ( .a(x), .b(y), .c(z) );

endmodule

Article: 48749
Subject: Re: slow slew rate signal...
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 24 Oct 2002 07:46:39 +1300
Links: << >>  << T >>  << A >>
Leon de Boer wrote:
> 
>    No it's not metastability, this problem would exist on even normal logic
> not only FPGA's. Lets say I am dealing with 3V logic in which a low is
> anything below 1 volt and a high anything above 2 volts. So what happens if
> I have a 1.5V signal? Well it could go to either level. Okay lets say for
> arguement that because it can't decide 50% of the time it reports as high
> and 50% low.
> 
>    Now lets say I have a slow slew signal that takes 3uS to slew from 0V to
> 3V. For 1uS the signal will be definitely low, for 1uS the signal will be in
> this 50/50 undefined area and for 1uS the signal will be high. Now lets
> sample this signal at 10Mhz which means I get 10 samples for every 1uS. The
> first 10 samples in the 1uS while the signal is low will be low. The last 10
> samples in the 1uS while the signal is high will be high. But the middle 1uS
> in the 50/50 zone will return random samples so lets say it returns the
> following HLLHHLLHHL for its ten samples based on 50/50 probability of high
> or low
> 
> So my sampled signal looks like
> 
> LLLLLLLLLL HLLHHLLHHL  HHHHHHHHHH
> { 10 samples } { 10 samples    } { 10 Samples }
> { low period }  { 50/50 period } { high period }

 This solely digital theory is not well connected to how a real 
device behaves.
 All digital chips have analog elements, and at the detail levels,
behave
more analog in nature, than digital.

 A very good test source for slew problems, is a triangle generator.
 Feed this into a pin, and observe the output(s) as you vary the
frequency,
which gives a variaable slew rate.
 You can get info not in data sheets with this set-up.

-jg



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