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 53925

Article: 53925
Subject: Re: Tristate pins + Inputs => External Pullup ?
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 27 Mar 2003 09:57:03 -0800
Links: << >>  << T >>  << A >>

Rajeev wrote:
> 
> When an FPGA pin is tri-stated (high-Z), is the input buffer for
> that pin connected or disconnected to the pin ?
The input buffer is always connected to the pin. If you do not use the
input signal, you ignore it inside the Xilinx FPGA. (I cannot speak for Altera)
> 
> What I'm thinking is: if it's connected, the pin may float to a voltage where
> the input buffer draws high current, and I had better provision the pin with
> an external pullsup/down.
Well, the worst-case current is "only" a few mA, and causes power
consumption, but never any damage.
With Xilinx, there are optional internal pull-up and pull-down resistors
( 50...100kilohm), even an internal weak keeper that maintains the
previously-drive logic level.
This was all incorporated for the reason you stated, and also to reduce
system noise.
> 
> (Families of interest to me are: Spartan2, 2E, Stratix.)

I do not know about Stratix. 
We call it (affectionately...) a "Virtex-II copy", so it might be similar...

Peter Alfke, Xilinx Applications

Article: 53926
Subject: Can input rate change internal programming ?
From: mhelshou@yahoo.com (Mohammed Hamed)
Date: 27 Mar 2003 10:05:46 -0800
Links: << >>  << T >>  << A >>
Hi All,

I'm using an XESS XSA-50 board carrying a spartan II chip. The board
comes with a couple of tutorials, one of them drives a seven segment
display decoder with 4 bits from the parallel port. The board comes as
well with a small utility (XSPORT) that can output bits to the
parallel port, and in another mode can increment the output by one
when a certain button is pressed.

When trying this tutorial everything worked fine, and the seven
segment display accurately reflected what's being sent on the parallel
port. Then I tried pressing the button that keeps incrementing the
output and kept my hand on the keyboard which made the count proceed
at the keyboard typmatic rate. After some time the display became
corrupt and I couldn't get it back to reflect the bits on the parallel
port. I had to cut off power on the board, repower, and reprogram it,
and everything became well again.

My wonder is, the corrupt display should be something related to the
internal FPGA programming, because only 4 lines of the PP are
connected to the FPGA, and the 7seg decoder is programmed to display
all the combinations (0-F), so it can be caused of a non-handled input
combination. So I wonder how programming can change due to the fast
rate of the parallel port output. Another possibility that the high
rate made the electric characteristic of PP output (current, voltage)
change that the FPGA couldn't handle. Can this happen ? do you have
another explanation ?

Regards,

Article: 53927
Subject: How can I fix module inputs
From: mhelshou@yahoo.com (Mohammed Hamed)
Date: 27 Mar 2003 10:13:36 -0800
Links: << >>  << T >>  << A >>
Hi All,

Sorry I'm new to this. Can I fix a certain input to a module or a
certain FPGA pin using constraints file or in HDL code? I want to do
this for testing, so that for example when implementing DES encryption
I don't have to connect real FPGA pins to logic 1 or 0. Instead I want
to fix those pins from the Verilog/VHDL code and reprogram it.

I hope this is not a homework thing, if so just point me to where to
look.

Thank you,

Article: 53928
Subject: Re: How failures happen, and how they don't
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Thu, 27 Mar 2003 10:28:20 -0800
Links: << >>  << T >>  << A >>
Michael,

Faults are things like oxide break down, or junction breakdown.

They are most likely from weak or originally defective oxides or junctions
that eventually broke from eventual overstress (due to their original weak
nature).

These kinds of defects can not be totally avoided.  One can burn in devices,
one can overstress devices, but lately there is a lot of data that shows
that doing so actually increases field failure rates (if you stress too
much, if you stress not much at all, it does very little for the long term
failure rate).

This whole subject has nothing to do with FPGAs, so you should research
semiconductor reliability.

Soft fails are another issue, and the following link covers that:

 http://www.xilinx.com/support/techxclusives/1000-techX35.htm

Austin

Michael Garvie wrote:

> Given your FIT rates for high temperature, high moisture, electrical
> overstress, or purely random; what is the fault mode induced?  Are these
> localized and permanent?  Or do they go away with scrubbing?  Or are
> they at the FPGA subsystem level?
> Regards,
> Miguel
>
> Austin Lesea wrote:
>
> > I suggest that if you have suddenly experienced a failure, that is the
> > kind of failure known as "random" and fits well within our FIT rate
> > predictions.
> >
> > As everyone knows, failures do happen, and if the designers, industry
> > and foundries could prevent that from happening, we would all be
> > happier when we have to design fail-safe systems.
> >
> > So, until then, fail safe systems fail, by failing to fail safely.
> >
> > Austin


Article: 53929
Subject: Mixed VHDL and Verilog with Xilinx ISE
From: "Dave Colson" <dscolson@rcn.com>
Date: Thu, 27 Mar 2003 14:30:11 -0500
Links: << >>  << T >>  << A >>
Hello,

I am looking for an app note or something to explain how to do mixed
vhdl and verilog design using Xilinx ISE software.

For instance I have an processor in vhdl code and want to integrate
that into my verilog design.

Dave C.



Article: 53930
Subject: Re: Differential LVPECL Inteface of Spartan IIE
From: sanket@insight.memec.co.in (Xilinx FAE from Insight SANKET)
Date: 27 Mar 2003 11:31:58 -0800
Links: << >>  << T >>  << A >>
Hi Wang,
I agree with you. Also,the input clamp diodes will become
forward-biased if VIN exceeds VCCO by the diode threshold voltage
(~0.5V); therefore, leaving VCCO disconnected or setting it to an
excessively low voltage could lead to a distorted input signal. To
avoid this, VCCO should be greater than the input high voltage (plus
any overshoot), less the 0.5V diode voltage. For example, if the
maximum input high voltage is 2.5V (including overshoot), VCCO should
be greater than 2.5V - 0.5V = 2.0V.
The above is true for Virtex-II family and I think it should be true
for Spartan-IIE family as well.
Austin Lesea and  Peter Alfke are the right persons to comment on
this.
Need your suggestions as well on this.

I hope this helps.
Regards,
SANKET.

Wang Xiao-yun <wangxy@fudan.ANTISPAM.edu> wrote in message news:<3E82D188.4080803@fudan.ANTISPAM.edu>...
> Hi, Sanjay,
> Thanks for your post, but I beg to differ.
> 
> A termination is used to ensure the signal integrity on a transmission 
> line instead of providing bias current. In a true (P)ECL interface, I 
> don't think the res. network suggested in the XAPP133 will work, because 
> the supposed emitter-follower outputs do not have a current path to the 
> bias voltage. (of course, Xilinx might include bias resistors inside the 
> chip, but I don't think it's available in Spartan 2E)
> Based on my understanding, striping out the PI network on the 
> transmitter side will only increase the signal swing seen by the 
> receiver. In another word, Voh and Vol will be even improved without the 
> PI. The PI may also serve to absorb the reflection resulted from the 
> impedance mismatch, but I don't think it's the main purpose.
> The only purpose for the PI seems only to tweak the voltage swing within 
> PECL spec. to interface with other standard devices, but will the 
> Spartan 2E receiver require the trick? That's what I want to know.
> 
> For the second question, I may not have stated clearly. I would like to 
> know wether a termination of 50ohm to VCCO - 2V (nominally 1.3V in the 
> case of LVPECL) is also fine for the buffer, instead of supplying 2V to 
> VCCO.
> 
> Thanks.
> 
> sanjay wrote:
> > Hi,
> > Answer to your first question.
> > Why we need a termination? To ensure that all pins are getting some pull up
> > or Pull down current, so that it will not go into high impedance or any
> > undefined state before configuring the device. The Termination Res. network
> > given in App Note 133 is by considering the Spartan -II E Device
> > Characteristics all together. It gives a Min. High and Low Identification on
> > the pin.
> > So its recommended not to change it.
> > 
> > Secondly you asked  with Vcco of 2 V and 50 Ohm Termination, Logically
> > speaking it should give Power saving. But this VCCOof 2V is not supported on
> > Spartan -IIE for LVEPCL.
> > 
> > Thanks
> > Sanjay
> >

Article: 53931
Subject: Re: Differential LVPECL Inteface of Spartan IIE
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Thu, 27 Mar 2003 11:37:10 -0800
Links: << >>  << T >>  << A >>
You are correct,

Austin

Xilinx FAE from Insight SANKET wrote:

> Hi Wang,
> I agree with you. Also,the input clamp diodes will become
> forward-biased if VIN exceeds VCCO by the diode threshold voltage
> (~0.5V); therefore, leaving VCCO disconnected or setting it to an
> excessively low voltage could lead to a distorted input signal. To
> avoid this, VCCO should be greater than the input high voltage (plus
> any overshoot), less the 0.5V diode voltage. For example, if the
> maximum input high voltage is 2.5V (including overshoot), VCCO should
> be greater than 2.5V - 0.5V = 2.0V.
> The above is true for Virtex-II family and I think it should be true
> for Spartan-IIE family as well.
> Austin Lesea and  Peter Alfke are the right persons to comment on
> this.
> Need your suggestions as well on this.
>
> I hope this helps.
> Regards,
> SANKET.
>
> Wang Xiao-yun <wangxy@fudan.ANTISPAM.edu> wrote in message news:<3E82D188.4080803@fudan.ANTISPAM.edu>...
> > Hi, Sanjay,
> > Thanks for your post, but I beg to differ.
> >
> > A termination is used to ensure the signal integrity on a transmission
> > line instead of providing bias current. In a true (P)ECL interface, I
> > don't think the res. network suggested in the XAPP133 will work, because
> > the supposed emitter-follower outputs do not have a current path to the
> > bias voltage. (of course, Xilinx might include bias resistors inside the
> > chip, but I don't think it's available in Spartan 2E)
> > Based on my understanding, striping out the PI network on the
> > transmitter side will only increase the signal swing seen by the
> > receiver. In another word, Voh and Vol will be even improved without the
> > PI. The PI may also serve to absorb the reflection resulted from the
> > impedance mismatch, but I don't think it's the main purpose.
> > The only purpose for the PI seems only to tweak the voltage swing within
> > PECL spec. to interface with other standard devices, but will the
> > Spartan 2E receiver require the trick? That's what I want to know.
> >
> > For the second question, I may not have stated clearly. I would like to
> > know wether a termination of 50ohm to VCCO - 2V (nominally 1.3V in the
> > case of LVPECL) is also fine for the buffer, instead of supplying 2V to
> > VCCO.
> >
> > Thanks.
> >
> > sanjay wrote:
> > > Hi,
> > > Answer to your first question.
> > > Why we need a termination? To ensure that all pins are getting some pull up
> > > or Pull down current, so that it will not go into high impedance or any
> > > undefined state before configuring the device. The Termination Res. network
> > > given in App Note 133 is by considering the Spartan -II E Device
> > > Characteristics all together. It gives a Min. High and Low Identification on
> > > the pin.
> > > So its recommended not to change it.
> > >
> > > Secondly you asked  with Vcco of 2 V and 50 Ohm Termination, Logically
> > > speaking it should give Power saving. But this VCCOof 2V is not supported on
> > > Spartan -IIE for LVEPCL.
> > >
> > > Thanks
> > > Sanjay
> > >


Article: 53932
Subject: Re: DSP-FPGA interface
From: "Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it>
Date: Thu, 27 Mar 2003 19:57:22 GMT
Links: << >>  << T >>  << A >>
"Mike Shonle" <mike@psychonic.net> ha scritto nel messaggio
news:To-dndAX1_vqth6jXTWcrg@speakeasy.net...

> Why not use one of the TI dsp chips with built-in PWM &
> encoder reading,
> like the 320F2407?

'f2407 is a fixed point DSP and has something between 100 and 200 MIPS,
while c67xx family is floating point and some models go beyond 2000
MFLOPS. They aren't exactly equivalent. ;)

Anyway, if you don't need to do high-speed communication between DSP and
FPGA, you can do everything asynchronous (i.e. by not using the DSP
CLKOUT signal). With a 10$ Spartan II and a 54xx DSP, I reached 80 MB/s
transfer rate (40 MHz read/write cycle) without using CLKOUT, only with
the strobe signals.

--
Lorenzo



Article: 53933
Subject: Re: Differential LVPECL Inteface of Spartan IIE
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 28 Mar 2003 09:03:06 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> You are correct,
> 
> Austin
> 
> Xilinx FAE from Insight SANKET wrote:
> 
> > Hi Wang,
> > I agree with you. Also,the input clamp diodes will become
> > forward-biased if VIN exceeds VCCO by the diode threshold voltage
> > (~0.5V); therefore, leaving VCCO disconnected or setting it to an
> > excessively low voltage could lead to a distorted input signal. To
> > avoid this, VCCO should be greater than the input high voltage (plus
> > any overshoot), less the 0.5V diode voltage. For example, if the
> > maximum input high voltage is 2.5V (including overshoot), VCCO should
> > be greater than 2.5V - 0.5V = 2.0V.

 There is also the detail of Common Mode voltage range of the
differential
input. Commonly, this is not a fancy rail-rail comparitor, but uses
P-FETs on
the IPs, so you get a common mode range from 0V to
Vcc-(ThresholdRelatedValue)
 Presumably, Vcco powers the IO comparitor, so Vcco should be
comfortably
above the peak linear region IP swing. The Xilinx experts will fill in
the
details for particular models.

-jg

Article: 53934
Subject: Re: FPGA specs
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Thu, 27 Mar 2003 22:05:19 GMT
Links: << >>  << T >>  << A >>

"Kolja Sulimma" <kolja@bnl.gov> wrote in message
news:25c81abf.0303260445.2e029c67@posting.google.com...
> > > So in the real world, gates are not a good way to measure a chip.  You
> > > will do much better to fit your design to the chip and see how well it
> > > fits.  Or at least do a preliminary job of estimating by trying to
> > > "guesstimate" the details of how your design will fit in the chip.

(snip)

> It should also be noted that these numbers usually include an
> unexpected factor of two:
> A 2-input AND gate counts as two equivalant gates,
> a 3-input and counts as three, and so on.
> (Apperently someone decided that it would be to complicated
>  to call a 3-input gate 1.5 eqivalent gates.)
>
> This nomenclature does not come from marketing but from academia and
> is related to the literal count metric for circuit size.
>
> A Flip-Flop typically counts as 6 gates.
> And some vendors count a 4kBit Block-RAM as 4096 Flip-FLops.

As far as I know, the convention since CMOS is to count the transistors and
divide by the number in a two input NAND gate, which is 4 for CMOS.  For
reasonably N, an N input CMOS NAND gate takes 2N transistors.

In TTL, an AND gate is pretty much a NAND followed by an inverter, and
probably does count as two.   But in TTL, an N input NAND takes the same
number of transistors and a 2 input NAND.

If one wanted a count of logic complexity, (how hard it is to design), as
opposed to how hard it is to fit on a chip, the numbers might be different.
Also, they work out completely differently for FPGA's.

-- glen



Article: 53935
(removed)


Article: 53936
(removed)


Article: 53937
Subject: Re: Tristate pins + Inputs => External Pullup ?
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Thu, 27 Mar 2003 23:03:31 -0000
Links: << >>  << T >>  << A >>
Peter Alfke wrote

> With Xilinx, there are optional internal pull-up and pull-down resistors
> ( 50...100kilohm), even an internal weak keeper that maintains the
> previously-drive logic level.

Is the weak keeper engaged under all circumstances?
It certainly seems that way if I look at the pins
with a very high impedence probe.



Article: 53938
Subject: Re: FPGA specs
From: kolja@bnl.gov (Kolja Sulimma)
Date: 27 Mar 2003 15:25:31 -0800
Links: << >>  << T >>  << A >>
Inspired by Goedel I conclude that there are more gate count metrics
then there are design to measure....

According to this application note:
http://www.xilinx.com/xapp/xapp059.pdf
Peter is right (at least for Xilinx measurements)

Here are the numbers:
Function Gate_Count
NAND2    1
MUX2     4
XOR3     6
XOR4     9
FA       9
DFF      6
DFF+Reset 8
DFF+R+CE 12

Kolja Sulimma

Peter Alfke <peter@xilinx.com> wrote in message news:<3E81E8A1.3D9ABC13@xilinx.com>...
> When I was involved, we reduced everything to 2-input gates, and a 2-XOR
> became 4 gates.
> Kolja Sulimma wrote:
> > A 2-input AND gate counts as two equivalant gates, a 3-input and
> > counts as three, and so on.

Article: 53939
Subject: Re: Differential LVPECL Inteface of Spartan IIE
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Thu, 27 Mar 2003 15:45:46 -0800
Links: << >>  << T >>  << A >>
Jim,

It is a 'fancy' rail to rail cmos diff amp, but it still prefers to stay out
of cutoff for fastest speed & performance, but it functions fine rail to
rail.

Austin

Jim Granville wrote:

> Austin Lesea wrote:
> >
> > You are correct,
> >
> > Austin
> >
> > Xilinx FAE from Insight SANKET wrote:
> >
> > > Hi Wang,
> > > I agree with you. Also,the input clamp diodes will become
> > > forward-biased if VIN exceeds VCCO by the diode threshold voltage
> > > (~0.5V); therefore, leaving VCCO disconnected or setting it to an
> > > excessively low voltage could lead to a distorted input signal. To
> > > avoid this, VCCO should be greater than the input high voltage (plus
> > > any overshoot), less the 0.5V diode voltage. For example, if the
> > > maximum input high voltage is 2.5V (including overshoot), VCCO should
> > > be greater than 2.5V - 0.5V = 2.0V.
>
>  There is also the detail of Common Mode voltage range of the
> differential
> input. Commonly, this is not a fancy rail-rail comparitor, but uses
> P-FETs on
> the IPs, so you get a common mode range from 0V to
> Vcc-(ThresholdRelatedValue)
>  Presumably, Vcco powers the IO comparitor, so Vcco should be
> comfortably
> above the peak linear region IP swing. The Xilinx experts will fill in
> the
> details for particular models.
>
> -jg


Article: 53940
Subject: Re: Tristate pins + Inputs => External Pullup ?
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Thu, 27 Mar 2003 15:47:09 -0800
Links: << >>  << T >>  << A >>
Tim,

Your choice.

The HSWAP_EN pin on Virtex II and II Pro enables the weak pullups while the
part is configuring.  After that, they are enabled if you have set the
attribute of the IO pin to do so.

Austin

Tim wrote:

> Peter Alfke wrote
>
> > With Xilinx, there are optional internal pull-up and pull-down resistors
> > ( 50...100kilohm), even an internal weak keeper that maintains the
> > previously-drive logic level.
>
> Is the weak keeper engaged under all circumstances?
> It certainly seems that way if I look at the pins
> with a very high impedence probe.


Article: 53941
Subject: XILINX FPGA as SUN Sparc coprocessor
From: machosri@yahoo.com (Sriram)
Date: 27 Mar 2003 15:52:48 -0800
Links: << >>  << T >>  << A >>
Hi ,
Well the basic question is that I would like to interface a XILINX
Virtex fpga on a fpga development board to a SUN machine .I want the
FPGA to act as a hardware accelerator,wherein I can do computationally
intensive parts of an algorithm on the fpga and the rest on the SUN
workstation.So thus there will have to be an interface through
interrupts when i come across those functions to be done using
hardware.The result of these hardware operations has to be stored in a
memory which should be accessible by the SUN workstation,through a
common bus.

I was thinking that I could perhaps use the PCI/SBus interface for
this purpose and wanted to find out about any off the shelf products
and help from
somebody who perhaps has done somethng similar.

Thanks,
Sriram

Article: 53942
Subject: Re: XILINX FPGA as SUN Sparc coprocessor
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Fri, 28 Mar 2003 10:01:20 +1000
Links: << >>  << T >>  << A >>
Sriram wrote:
> Hi ,
> Well the basic question is that I would like to interface a XILINX
> Virtex fpga on a fpga development board to a SUN machine .I want the
> FPGA to act as a hardware accelerator,wherein I can do computationally
> intensive parts of an algorithm on the fpga and the rest on the SUN
> workstation.So thus there will have to be an interface through
> interrupts when i come across those functions to be done using
> hardware.The result of these hardware operations has to be stored in a
> memory which should be accessible by the SUN workstation,through a
> common bus.
> 
> I was thinking that I could perhaps use the PCI/SBus interface for
> this purpose and wanted to find out about any off the shelf products
> and help from
> somebody who perhaps has done somethng similar.

Hi Sriram,

What you propose is certainly feasible.  You should check the traffic on 
this newsgroup from the last couple of days, and make sure you read the 
thread about FPGA coprocessors.  It covers a lot of interesting concepts 
that are relevant to your inquiry.  It's easy to get carried away saying 
"I'm putting the inner loop of my algorithm on an FPGA and I'll get a 
100x speedup" but forgetting that the hardest part may be the IO 
involved in getting data to and from the FPGA.  You start needing things 
like DMA controllers, bus mastering and so on.  Things can get very 
complex, very quickly.

I think that discussion also covered some of the commercial vendors of 
PCI-based FPGA coprocessor/accelerator cards.  Nallatech , Annapolis 
Micro Systems are a couple.  I'm not sure about driver support for Suns 
though.

Regards,

John


Article: 53943
Subject: Question about case statement in XilinX webpack
From: Jan Panteltje <panteltje@yahoo.com>
Date: Fri, 28 Mar 2003 00:22:25 GMT
Links: << >>  << T >>  << A >>
Hi, when I write something like this:

(lots of stuff in example snipped)

module lcd_text_driver(clock, text, text_strobe,
        lcd_e, lcd_rw, lcd_rs,
        lcd_read_data, lcd_write_data, lcd_dir, test);

input clock;
output lcd_e, lcd_rw, lcd_rs;
output [3:0] lcd_write_data;

reg lcd_e, lcd_rw, lcd_rs;
reg [3:0] lcd_write_data;
reg [19:0] state;

parameter [5:0] lcd_idle =           6'b00_0000;
parameter [5:0] lcd_function =       6'b00_0001;
parameter [5:0] lcd_display_on_off = 6'b00_0010;
//etc...

always @(posedge clock)
begin
case(state)
lcd_idle:
        // snipped etc...         
        state <= #1 lcd_function;

lcd_function:
        begin
        lcd_e <= #1 1;
        lcd_write_data [3:0] <= #1 4'b0010;
        // snipped etc...
        state <= #1 lcd_display_on_off;
        end
lcd_display_on_off:
        begin
        lcd_e <= #1 1;

        // commenting this out cause error to dissappear.  
        lcd_write_data [3:0] <= #1 4'b0000;
        // snipped etc...

        state <= # lcd_idle;
        end
//etc...
endcase
endmodule

The 'lcd_write data' causes xst(4) to report a 'multiple sourced' error.
The same thing on iverilog syntesizes OK.

If I comment out 'lcd_write_data [3:0] <= #1 4'b0000;' in one of
each 'cases' xste is OK.
Is it not allowed to use a reg of more then 1 bit wide in a case in webpack?
Or what am I doing wrong?

JP


Article: 53944
Subject: Re: Differential LVPECL Inteface of Spartan IIE
From: Wang Xiao-yun <wangxy@fudan.ANTISPAM.edu>
Date: Fri, 28 Mar 2003 08:53:21 +0800
Links: << >>  << T >>  << A >>
Thank you all for your insightful comments.

I will do my design as following:

The VCCO will be supplied with 3V3, which is suggested from the 
datasheet. (Actually, this is the main reason I choose LVPECL instead of 
LVDS to avoid using extra 2V5)
The LVPECL interconnection between Spartan2E will be dealt with as 
(standard) LVDS style. That means the PI network on the transmitter side 
will be removed and only the 100ohm end termination will be provided. In 
this case, the receiver may see a rail-to-rail voltage swing (0 - 3V3?) 
but I expected it will not cause further harm based on the information 
provided.
The large voltage swing will cause more problems of crosstalk, but I'm 
not going to run the pair at very high datarate and I'm sure it can be 
tolerated.
On the other hand, I will be more comfortable without the PI network, 
because I expect it would become a big burden when I'm going to use more 
than 80 diff. pairs on a single chip.

Will this scheme work?

Austin Lesea wrote:
> Jim,
> 
> It is a 'fancy' rail to rail cmos diff amp, but it still prefers to stay out
> of cutoff for fastest speed & performance, but it functions fine rail to
> rail.
> 
> Austin
> 


Article: 53945
Subject: Re: Differential LVPECL Inteface of Spartan IIE
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 28 Mar 2003 13:08:10 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Jim,
> 
> It is a 'fancy' rail to rail cmos diff amp, but it still prefers to stay out
> of cutoff for fastest speed & performance, but it functions fine rail to
> rail.

Good to hear that - is that true of all DiffMode Xilinx FPGAs ?
Any plots of Speed vs common mode ? 
 - we have an app that could use rail-rail tolerance, 
but may still use external LVDS to get
ESD protection ( or add more ESD protection to the FPGA )

-jg

Article: 53946
Subject: Re: Can ModelSim PE/SE and XE coexist?
From: Bassman59a@yahoo.com (Andy Peters)
Date: 27 Mar 2003 17:21:02 -0800
Links: << >>  << T >>  << A >>
kenm@morro.co.uk (Ken Morrow) wrote in message news:<20f8de50.0303231355.40cf7aef@posting.google.com>...
> I am currently using ModelSim 5.6e PE on a PC licensed from a dongle.
> 
> Unfortunately, this will only allow one instance of ModelSim to simulate
> at a time. This is currently proving a problem as I am running some big sims.
> I cannot do any other sims on small blocks for the few hours that my big sims
> are running.
> 
> A year or so ago I tried using ModelSim XE along with PE on the same PC,
> but never managed to get them both to work at the same time.
> 
> Has anyone tried this recently with any sucess?

Just a suggestion: get another computer.  You'll slow down BOTH sims
if you get both running at the same time.

--a

Article: 53947
Subject: Re: Question about case statement in XilinX webpack
From: Kevin Brace <kev0inbrac1eusen2et@ho3tmail.c4om>
Date: Thu, 27 Mar 2003 21:46:28 -0600
Links: << >>  << T >>  << A >>
Jan,

I am not exactly sure what is causing this problem, but there are there
things I don't like with your RTL code.

1) The state machine doesn't have a way to reset itself.

"always @(posedge clock)" section doesn't contain a reset input to
initialize the state machine.
I will change that to,

__________________________________________________________
always @ (posedge clock or negedge reset_n) begin
    if (reset_n == 1'b0) begin
        state <= #1 lcd_function;

// And you may want to reset bunch of other FFs here.

    end
    else begin
        case(state)
            lcd_idle: begin
                if () begin


            end

            lcd_function: begin

            // snipped
                state <= #1 lcd_display_on_off;
            end

            lcd_display_on_off: begin

            // snipped
                state <= # lcd_idle;
            end
       endcase
    end
end
__________________________________________________________


2) The bit length of state[19:0] register and the state machine states
(lcd_idle, lcd_function, lcd_display_on_off) don't match.

        I suppose this is a problem of Verilog that the bit length
matching isn't strict unlike VHDL (Despite that, I still prefer Verilog
over VHDL.).
Either you will like to enlarge those state machine states to 20 bits,
or shorten the state register to 6 bits.


3) Your state machine doesn't have a default state in your case
statement.

        Somewhere in your case statement, you will like to add a default
state.


__________________________________________________________
default: begin
    state <= #1 lcd_function;

end
__________________________________________________________


         I am not sure if this default statement is needed (I am sure
someone else who is more familiar about Verilog than myself can answer
that.), but it is safer to have one.


Kevin Brace (If someone wants to respond to what I wrote, I prefer if
you will do so within the newsgroup.)


Jan Panteltje wrote:
> 
> Hi, when I write something like this:
> 
> (lots of stuff in example snipped)
> 
> module lcd_text_driver(clock, text, text_strobe,
>         lcd_e, lcd_rw, lcd_rs,
>         lcd_read_data, lcd_write_data, lcd_dir, test);
> 
> input clock;
> output lcd_e, lcd_rw, lcd_rs;
> output [3:0] lcd_write_data;
> 
> reg lcd_e, lcd_rw, lcd_rs;
> reg [3:0] lcd_write_data;
> reg [19:0] state;
> 
> parameter [5:0] lcd_idle =           6'b00_0000;
> parameter [5:0] lcd_function =       6'b00_0001;
> parameter [5:0] lcd_display_on_off = 6'b00_0010;
> //etc...
> 
> always @(posedge clock)
> begin
> case(state)
> lcd_idle:
>         // snipped etc...
>         state <= #1 lcd_function;
> 
> lcd_function:
>         begin
>         lcd_e <= #1 1;
>         lcd_write_data [3:0] <= #1 4'b0010;
>         // snipped etc...
>         state <= #1 lcd_display_on_off;
>         end
> lcd_display_on_off:
>         begin
>         lcd_e <= #1 1;
> 
>         // commenting this out cause error to dissappear.
>         lcd_write_data [3:0] <= #1 4'b0000;
>         // snipped etc...
> 
>         state <= # lcd_idle;
>         end
> //etc...
> endcase
> endmodule
> 
> The 'lcd_write data' causes xst(4) to report a 'multiple sourced' error.
> The same thing on iverilog syntesizes OK.
> 
> If I comment out 'lcd_write_data [3:0] <= #1 4'b0000;' in one of
> each 'cases' xste is OK.
> Is it not allowed to use a reg of more then 1 bit wide in a case in webpack?
> Or what am I doing wrong?
> 
> JP

Article: 53948
Subject: Re: Mixed VHDL and Verilog with Xilinx ISE
From: Kevin Brace <kev0inbrac1eusen2et@ho3tmail.c4om>
Date: Thu, 27 Mar 2003 22:08:48 -0600
Links: << >>  << T >>  << A >>
Dave,

Synthesize the VHDL module without I/O pads being added.
Synthesize the Verilog portion of it a black box of the VHDL module
written in Verilog.


Kevin Brace (If someone wants to respond to what I wrote, I prefer if
you will do so within the newsgroup.)



Dave Colson wrote:
> 
> Hello,
> 
> I am looking for an app note or something to explain how to do mixed
> vhdl and verilog design using Xilinx ISE software.
> 
> For instance I have an processor in vhdl code and want to integrate
> that into my verilog design.
> 
> Dave C.

Article: 53949
Subject: Re: Mixed VHDL and Verilog with Xilinx ISE
From: Kevin Brace <kev0inbrac1eusen2et@ho3tmail.c4om>
Date: Thu, 27 Mar 2003 22:34:42 -0600
Links: << >>  << T >>  << A >>
Oops, I forgot to mention that you need to tell NGDBUILD where the
netlist generated from the VHDL part of the design is located.


Kevin Brace (If someone wants to respond to what I wrote, I prefer if
you will do so within the newsgroup.)



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