Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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. joeArticle: 48726
"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 FalkArticle: 48727
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. > > joeArticle: 48728
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
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: 48730Oversampling 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
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
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
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
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, PatrickArticle: 48735
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
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 LLCArticle: 48737
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
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
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
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
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.eduArticle: 48742
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.eduArticle: 48743
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. > --SanjayArticle: 48744
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
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
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
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 > > GabiArticle: 48748
> 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) ); endmoduleArticle: 48749
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:
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