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
2017JanFebMarApr2017

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 41375

Article: 41375
Subject: Re: ByteblasterMV EPM7064S voltage problem
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Tue, 26 Mar 2002 23:39:36 GMT
Links: << >>  << T >>  << A >>


sunny wrote:
> 
> altera's byteblaster did include the 74hc244. the byteblastermv consists of an 74ls244. the schematic should be ok and it should work fine with the ls part. I assume that your cable is more than 20cm in length. shorten the cable and it will work fine.

NO, the byteblasterMV has a 74HC244. 74LS244 won't work at lower than 5V.

The MV schematic has no VCC-GND bypass cap, even tho the real dongle has.
Make sure you add one.

Article: 41376
Subject: Re: failure rate of Xilinx chips
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Tue, 26 Mar 2002 17:49:58 -0600
Links: << >>  << T >>  << A >>
vlad@comsys.ntu-kpi.kiev.ua wrote:

> Hi All ,
> Where can I find information about numerical characteristic of failure
> rate of Xilinx Chips(Spartan2, Virtex series)? This information is
> needed for calculation  reliability index of entire device.

I'd be interested in hearing any stories of end-user problems with
devices
containing Xilinx CPLDs or FPGAs.  I am about at the Beta-test stage
with several products that attach to a PC's parallel port, and use some
XC9572 CPLDs and some XCS10 and XCS30 Spartan 5V parts.
One customer in particular has blitzed quite a few of these chips, and
I'm trying to identify the cause long distance.  I seem to see symptoms
of blown I/O pins, and he seems to indicate that it works until he
unplugs something, so ESD is almost certain.  So, I'm wondering
if anyone has some experience with the ESD sensitivity of these
chips compared to other 74HC type logic, for instance.

There are some substantial reasons why I don't want to put ESD
suppression devices on all signal lines on every board.

Jon


Article: 41377
Subject: Re: Help with Xilinx CoolRunner Problem
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Tue, 26 Mar 2002 18:11:43 -0600
Links: << >>  << T >>  << A >>
Mik e Payne wrote:

> Falk,
>
> I've got the Keil monitor programmed into the interal flash of the
> AT89S8252.  I can use the dScope program to read/write to the SRAM. I
> can write to some locations so I've put a small looping program that
> continuously writes 0x00 to location 0x00ff.  I run this program and
> then us a Tek 2246 100Mhz scope to examine the signals.
>
> The write to SRAM will fail if 6 or more of the low address/data lines
> have to transition from a '1'(for the low address) to a '0' (for the
> data to write).

Oh, man!  This very clearly looks like a ground bounce type of problem.
Your comments on the board construction in another response makes
me wonder how much decoupling capacitance is available to the CPLD.
I use a minimum of 4 .1 uF chip caps for an XC9572 CPLD, I would think the
CoolRunner would need more.  I place these as close to the pairs of power
and ground pins as I can, then couple the ground pins together with .1"
thick traces if possible.  I haven't had any problems with the chips
glitching with this arrangement, but I did make a good effort to make the
power, and especially ground pin connections short and wide.

As for the micro and ram chips, whatever decoupling and ground
bus connections you made are entirely your own hand work.

> Signals going into the CPLD look good.  Signals comming out of the
> CPLD have noise, I see spikes and ringing on those signals.

This seems to be a pretty good indication that a signal which is used
to clock a latch or FF is acting as if edges are ocurring when they
shouldn't.  You might look at some data sheets to check the logic
thresholds - does the CoolRunner have a logic threshold selection
for the input pin?  (Some Xilinx chips allow you to select this, but
I think it is global to the whole chip.)

Jon


Article: 41378
Subject: Re: Handel-C useless.. Move to SystemC
From: "Kelvin Hsu" <qijun@okigrp.com.sg>
Date: Wed, 27 Mar 2002 08:48:05 +0800
Links: << >>  << T >>  << A >>
Handel C and SystemC are targetted at different device. Handel C is for FPGA
and
can give computing engineering guys faster processor, and integrate with
their CPU...
SystemC is intended for ASIC...if I am not wrong...none of the computing
people
would make an ASIC only to make his signal processing faster.
If you are designing a chip, HandelC is the wrong choice.


Email: qijun@okigrp.com.sg
"Jeanan Del" <go_stock_boy@yahoo.com> wrote in message
news:5e59ca1f.0203261002.5fb42c34@posting.google.com...
> When is Celoxica going to kill of this useless proprietary Handel-C
> language in favor of moving to the industry standard SystemC ?? I've
> done a couple of experiments with DK1 3.0 and the language is painful
> to use, doesn't leverage C++ and once I do soemthing in Handel-C, I
> can't use with any other design or verification tools, like I can with
> SystemC.  There's a germ of value in Celoxica stuff but not while it
> is encumbered by a dead-end proprietary language.
>
> When are these guys going to get real ??



Article: 41379
Subject: Re: I2C Slave sampling edge
From: Philip Freidin <philip@fliptronics.com>
Date: Wed, 27 Mar 2002 01:13:45 GMT
Links: << >>  << T >>  << A >>
Both specifications are correct. I believe you are mis-interpreting
the Philips spec . Let me try and clarify.

On 25 Mar 2002 21:27:10 -0800, jaime.aranguren@ieee.org (Jaime Andres Aranguren
Cardona) wrote:
>Hi,
>
>On Xilinx' App Note XAP333 is an design of a I2C Master/Slave
>peripheral for a uProcessor, which I've used as basis for designing a
>slave device. They say on pag 12 that everything (the state machine
>and associated counters and shift registers are clocked on the falling
>edge of SCL, 'cause on heavy loaded systems the rise time of the SCL
>line may be very slow and that is dangerous on a clock a signal,
>'cause it can generate noise on it.

So stuff changes after the falling SCL edge. If the new data settles
fast enough ( in less than 1/2 the cycle time, assuming the clock
is symetric 50/50) then the data is stable prior to the next rising
edge, and will remain stable at least until the next SCL falling edge.

Since nothing is done on the rising edge, there is no setup requirement
to it. (But the Philips spec does state a requirement)

>However, on Philips I2C bus Specification v2.1 Jan-2000, pag 8 they
>say the data on the SDA line must be stable during the HIGH period of
>the clock.

Read this again. It says "stable while high" which is not a conflict
with the Xilinx info. The data could also be stable prior to going high,
i.e. went stable while low, remained stable during low to high SCL
transition, remained high till after next SCL high to low transition.

The full text of the relevant section in the Philips spec is:

   6.1 Data validity
   The data on the SDA line must be stable during the HIGH
   period of the clock. The HIGH or LOW state of the data line
   can only change when the clock signal on the SCL line is
   LOW (see Fig.4).

which means that it changes after a SCL high to low transition.

On the next page, fig 4 shows data valid prior to a rising SCL
transition, stable during SCL high, and changing after a high to
low SCL transition. 

>What would to recommend for an I2C slave on a Xilinx XC4010XL and/or a
>XCS05XL?
>Sampling on the falling edge (like Xilinx AppNote does) or sampling on
>he rising edge (as Philips specification suggests)?

As you can see above, Philips does not mandate sampling on the
rising edge. If you look at the timing tables on page 32, and the
timing diagram Fig 31, you will see that because data must be high
before the SCL low to high transition, you could use either edge.

Since the falling edge is the cleaner edge, you should use it.

In case you are wondering, Philips (the company) does not pay me
royalties on this part of their product line.

>Thanks a lot.

Sure.

Philip Freidin


Philip Freidin
Fliptronics

Article: 41380
Subject: Re: How to activate 5V PCI I/O pads in FLEX10KE/ACEX1K?
From: "Peter Ormsby" <faepete.deletethis@attbi.com>
Date: Wed, 27 Mar 2002 02:11:27 GMT
Links: << >>  << T >>  << A >>
Kevin,

For 5V PCI, just leave the I/Os in the default state.  The 3.3V PCI clamping
diodes default to off, so the standard LVCMOS/LVTTL I/O setting is what you
need.  If you want to verify the setting, you can check though the
assignment organizer or the compiler settings menu to see that 3.3V PCI is
not selected.

If you need 5V clamping diodes, you need to implement them externally.

-Pete-

Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in
message news:a7p9n7$rij$1@newsreader.mailgate.org...
>         I am wondering how I can activate 5V PCI I/O pads in Altera
> FLEX10KE/ACEX1K.
...snip...
> Thanks,
>
> Kevin Brace (In general, don't respond to me directly, and respond
> within the newsgroup.)



Article: 41381
Subject: Re: ByteblasterMV EPM7064S voltage problem
From: "Arbitrary" <wackedy@XXXhotmail.com>
Date: Wed, 27 Mar 2002 03:18:34 GMT
Links: << >>  << T >>  << A >>
I am using a 5 meter long cable from the computer to the Byteblaster perhaps
this is the cause of my problem. I thought that 5 meters was the longest
recommendend cable length and since the table I work on is about 5 meters
away from my computer this is what I used. I tried running a thick wire from
the chassis of the computer to the circuit power supply but to no avail. To
bad I was really hoping that I could have the programmer next to my work
table. Anyone know of a way to resolve this other than using a shorter
cable? I also checked that the chip I used was a 74HC244 which it should be
according to the schematic in the ByteblasterMV manual. Anyway thanks for
all the help you have given me.

Arbitrary



Article: 41382
Subject: Re: question on LFSR
From: Ray Andraka <ray@andraka.com>
Date: Wed, 27 Mar 2002 04:17:31 GMT
Links: << >>  << T >>  << A >>
You need to shift zeros (or some other initialization) into the SRL16 in order
to get it into a known state.  It takes 16 clocks to do that, of course if you
don't use the last taps then you can shift less.   A second SRL16 can be used in
the initialization logic to aid in generating that 16 clock long clear pulse.


Kevin Neilson wrote:

> I'm glad this point has been brought up because I wanted to make an
> averaging filter using SRLs but I'm worried about what will happen if the
> Xilinx gets reset.  The accumulator will reset to zero, but the values in
> the SRL delay line won't.  That means that after a reset, the output of the
> averaging filter will be offset by the sum of all the values in the SRL
> delay lines.  How should I clear out all the data after a reset?
> -Kevin
>
> "Ken Chapman" <chapman@xilinx.com> wrote in message
> news:3CA0B2AB.78F52ED6@xilinx.com...
> > Dear Ray,
> >
> > I agree that a really safe design should also consider upsets. My tech
> Xclusive on
> > the subject of resets in designs is very much about safe design
> techniques. The
> > whole concept of a one-hot state machine is an issue if you need to trap
> the cases
> > of 'n-hot' and 'cold states'. In these cases I would favour an encoded
> state machine
> > (not that many people carry out full illegal state analysis on those
> either).
> >
> > In my design for a UART state machine described in part 2 of my TechX, I
> > deliberately design the state machine to go 'cold' at the end of
> processing a
> > character. The next start bit on the serial line is then used to inject
> the next
> > 'hot' state. In this way, any induced error can be made to be short lived.
> >
> > The efficiency offered by the SRL16E could also be exploited to provide
> redundancy.
> > 3 state machines working in parallel with a majority voting system for
> each output
> > control bit (a LUT3) would be nice. In this way, we do not have to
> tolerate the
> > error condition at all.
> >
> > Seems like we have got away from LFSR counters a bit, but a good thread
> anyway.
> >
> > Regards,
> >
> > Ken
> >
> >
> >
> > Ray Andraka wrote:
> >
> > > I agree, the SRL16 is a wonder drug.  I don't however like to use it as
> a closed
> > > loop state machine as described by Ken because such a design will not
> self
> > > recover in the event of an upset.  The SRL16 only gets initialized on
> > > configuration, so if for some reason you get an upset (and in the .15
> micron it
> > > does sometimes happen), your state machine carries that upset state bit
> until
> > > the device is reconfigured.  In my book, that is poor design practice.
> As soon
> > > as you add the logic to detect the illegal states, the size gets
> considerably
> > > larger (it may be more advantageous to use TMR here).
> >

--
--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: 41383
Subject: Re: Too many clocks
From: "Jason T. Wright" <ruminat@pacbell.net>
Date: Tue, 26 Mar 2002 20:19:57 -0800
Links: << >>  << T >>  << A >>
Better is subjective.  For some applications, the skew on the clock is not an
issue, so there is no need to route the clock through a global buffer.  For other
applications, if there is a very high fanout on the low-speed clock, skew may
become an issue if the low speed clock is used as an enable.

General rules are for general cases; for each design, one has to weigh the
trade-offs (sometimes this takes 0 ps, sometimes hours or ....)

Jason

Ray Andraka wrote:

> A better way to handle those slow clocks is to bring them in on regular I/O
> through a register clocked by your local master clock (typically many times
> faster than the slow clock), then detect the edges of the slow clock
> synchronously to create clock enables for the data 'clocked' by the slow clock.
>
> Niv wrote:
>
> > I have a design with more than 4 clocks, the Virtex max., (but some are very
> > slow, < 1MHz).
> >
> > LeoSpec insists on putting BUFG's on all the clocks, which causes Xilinx PAR
> > to throw a wobbler.
> >
> > The design now has a 40MHz master clk into a CLKDLL, which produces 2
> > internal clocks with BUFG's, which is wanted, and 4 other clocks, only 2 of
> > which need BUFG's.  The other 2 clocks are low freq. and low fanout.
> >
> > The old design worked fine with 6 external clks; LeoSpec just sorted it out
> > somehow;  But now with 5 external clks, the master one to a DLL, it all goes
> > to pot!
> >
> > Anyone got any bright ideas please?
> >
> > i.e. How do I force some of my clocks NOT to use BUFG's & IBUFG's,  just use
> > IBUF's instead?
> >
> > TIA, Niv.
>
> --
> --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: 41384
Subject: Re: Handel-C useless.. Move to SystemC
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Wed, 27 Mar 2002 04:55:00 GMT
Links: << >>  << T >>  << A >>
Jeanan Del wrote:

> When is Celoxica going to kill of this useless proprietary Handel-C
> language in favor of moving to the industry standard SystemC ?? I've
> done a couple of experiments with DK1 3.0 and the language is painful
> to use, doesn't leverage C++ and once I do soemthing in Handel-C, I
> can't use with any other design or verification tools, like I can with
> SystemC.  There's a germ of value in Celoxica stuff but not while it
> is encumbered by a dead-end proprietary language.

Should Celoxica try to make the language into a standard (like Verilog
went from proprietary to IEEE STD)?  Is there a SystemC synthesis tool
that gives as good of results?  Or is it whole idea hopeless?

I'm in the process of evaluating these sorts of tools, and would like to
hear as many opinions as I can, especially if you have used the tools
you are talking about for something real.


-- 
Phil Hays

Article: 41385
Subject: Re: clock source
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 27 Mar 2002 00:57:26 -0500
Links: << >>  << T >>  << A >>
Cypress makes several chips that will output a 200 MHz clock using a PLL
based on a clock at any standard low speed.  You can use a 10 MHz
crystal and generate several clocks of different frequencies using a
CY22393, for example.  The frequency can be programmed in the one time
EPROM and can be changed (in volatile memory) after power up via a two
wire serial interface (I2C).  

I am using two of these on my board to generate several different clocks
from one crystal.  


"Sławomir Balon" wrote:
> 
> Hi!
> I'm looking for fast clock source (200MHz) for epm7032b, it will produce
> four phase shifted by 90 degree 50MHz clocks. What oscilator should i use?
> Crystal oscilators offer ends at 120MHz, i didn't ever use any plls at that
> high freq's. I'm open for any ideas...
> BTW how they make lets say: 1GSPS in oscilloscopes (i know that on
> repetitions but how they get those phase shifts for ADCs? - ECL??)
> 
> thanx
> Slawek

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 41386
Subject: Re: I2C Slave sampling edge
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 27 Mar 2002 01:21:18 -0500
Links: << >>  << T >>  << A >>
The speed of the clock rising edge vs the falling edge is a red
herring.  The problem with the slow edge is not that noise will cause
double clocking if you use the rising edge, but that noise will cause
double clocking PERIOD!  Even if you use the falling edge to clock the
register, any noise during the slow rising edge will still cause a
falling clock edge and double clock your data.  

The only advantage of using the falling edge to clock your data has to
do with noise generation.  The logic that changes states on either edge
will generate some noise.  If that is on a slow edge, it will be more
likely to double clock.  But if you have other things going on in your
CPLD or FPGA, then you will be making noise at all times and you will
still be sensitive to the noise on the rising edge. 

Your real problem is the slow rising edge, PERIOD.  Do something with
it, like buffering it so it is not slow going into the FPGA and use
hysteresis in the buffer so it will not be sensitive to the noise.  

Do any of the Xilinx Spartan inputs have hysteresis?  If so, you won't
need a buffer.  

BTW, stable data on the high phase means you either have to clock data
on the rising edge with 0 setup time, or you have to clock data on the
falling edge with 0 hold time.  0 hold time can be accomodated in the
Xilinx parts with an added internal delay element.  At least this was
true of the XC4000 series.  I assume the Spartan parts still have it
since they are based on the XC4000 chips. 

But as Philip observed, it would be hard to change data at any time
other than following the falling edge which would imply lots of setup
time on the rising edge.  Go figure...



Jaime Andres Aranguren Cardona wrote:
> 
> Hi,
> 
> On Xilinx' App Note XAP333 is an design of a I2C Master/Slave
> peripheral for a uProcessor, which I've used as basis for designing a
> slave device. They say on pag 12 that everything (the state machine
> and associated counters and shift registers are clocked on the falling
> edge of SCL, 'cause on heavy loaded systems the rise time of the SCL
> line may be very slow and that is dangerous on a clock a signal,
> 'cause it can generate noise on it.
> 
> However, on Philips I2C bus Specification v2.1 Jan-2000, pag 8 they
> say the data on the SDA line must be stable during the HIGH period of
> the clock.
> 
> What would to recommend for an I2C slave on a Xilinx XC4010XL and/or a
> XCS05XL?
> Sampling on the falling edge (like Xilinx AppNote does) or sampling on
> he rising edge (as Philips specification suggests)?
> 
> Thanks a lot.
> 
> PS/ I would appreciate your replies also be sent to
> jaime.aranguren@ieee.org

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 41387
Subject: Re: ByteblasterMV EPM7064S voltage problem
From: "Tuomo Auer" <tuomo.auer@removethis.hut.fi>
Date: Wed, 27 Mar 2002 09:09:06 +0200
Links: << >>  << T >>  << A >>
"sunny" <sunshine@sunrise.at> wrote in message
news:ee75d1e.1@WebX.sUN8CHnE...
> altera's byteblaster did include the 74hc244. the byteblastermv consists
of an 74ls244. the schematic should be ok and it should work fine with the
ls part. I assume that your cable is more than 20cm in length. shorten the
cable and it will work fine.

Sorry, Sunny, I just open and check my original ByteBlaster (not MV). There
is 74LS244 in original ByteBlaster...

--
Tuomo Auer



Article: 41388
Subject: Re: ByteblasterMV EPM7064S voltage problem
From: "Tuomo Auer" <tuomo.auer@removethis.hut.fi>
Date: Wed, 27 Mar 2002 09:41:10 +0200
Links: << >>  << T >>  << A >>
I have 3 meter extension cord between PC and original 5V ByteBlaster. It has
worked well. Check that there are no ground current flowing between PC and
your power supply supplying your circuit board. You can test this connecting
a multimeter in AC amps mode between the case of your PC and ground of your
circuit board (systems powered and no cables between computer and your
system). There can easily be ac-current between units

1) if you have ungrounded PC (outlet without safety ground) and if there is
a connection between the ground your circuit board and safety ground (the
case) of PSU supplying your board. This because of leakage current from the
live of mains to ungrounded computer case thru EMI filter capacitors in the
power supply of the computer.

2) if both PC and your circuit board have a connection to safety ground but
electrical system in your building uses only two wires (live and neutral,
safety connected to neutral in outlets). In this case use single outlet (or
an extension ac-cord to split one outlet) to power both the PC and your
circuit board.

In all cases use grounding wire between your computer and ground of your
circuit board. And connect this wire before connecting the programming cable
and remove this cord after disconnectind the programming cable.

--
Tuomo Auer



Article: 41389
Subject: Re: failure rate of Xilinx chips
From: vlad@comsys.ntu-kpi.kiev.ua
Date: Wed, 27 Mar 2002 10:14:19 +0200
Links: << >>  << T >>  << A >>
Thank you very much .
 
Best regards, Vladislav Vasilenko .

Peter Alfke wrote:
> 
> There is a 200+ page reliability report on the web at
> 
> http://www.xilinx.com/products/qa_data/relreprt.pdf
> 
> start by looking at pages 10 and 19
> Happy reading  :-)
> 
> BTW, I found this by going to the public Xilinx website and using its
> search facility to look for "reliability report". Simple, isn't it.
> 
> Peter Alfke, Xilinx Applications
> =======================================
> vlad@comsys.ntu-kpi.kiev.ua wrote:
> 
> > Hi All ,
> > Where can I find information about numerical characteristic of
> > failure
> > rate of Xilinx ?hips(Spartan2, Virtex series)? This information is
> > needed for calculation  reliability index of entire device.
> >
> > --
> > Best regards,
> >  Vladislav Vasilenko
> > Hardware engineer. National Technical University of Ukraine
> >
> > mailto:vlad@comsys.ntu-kpi.kiev.ua

Article: 41390
Subject: Re: simple Free FPGA tool
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Wed, 27 Mar 2002 02:34:22 -0600
Links: << >>  << T >>  << A >>
I have been working on a PCI IP core for a year or so.
I do realize that spending one year sounds like a lot of time, but it is
a hobby project where I started from not knowing anything about how an
FPGA works.
Regardless, I now know a lot more about FPGAs and PCI than a year ago,
and the PCI IP core seems to work okay, although I haven't fully
debugged it yet.
Are you saying that Spartan-II is too expensive to be used in an MP3
player?
I heard that Actel's eX FPGA is used in some MP3 players, so I guess it
is not impossible to use an FPGA in cost sensitive products.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)



Kelvin Hsu wrote:
> 
> Hi, Kevin:
> 
> I am not sure what kind of hobby project do you do? Do you have any
> facilities to fabricate them out? I tend to like making some mp3 player or
> motor control toys out of an FPGA chip but it seems impossible to make
> into hardware as it's a lot of money when converted to my currency. I am
> using ISE Webpack from Xilinx. Its really a great tool anyway.
> 
> --
> Best Regards,
> -----------------------------------------------------------------
> Xu Qijun
> Engineer
> OKI Techno Centre (S) Pte Ltd
> Tel: 770-7049 Fax: 779-1621
> Email: qijun@okigrp.com.sg

Article: 41391
Subject: Re: ByteblasterMV EPM7064S voltage problem
From: "Dan Oprisan" <dandy1313@yahoo.com>
Date: Wed, 27 Mar 2002 10:05:57 +0100
Links: << >>  << T >>  << A >>

"Tuomo Auer" <tuomo.auer@removethis.hut.fi> schrieb:

> I have 3 meter extension cord between PC and original 5V ByteBlaster. It
has
> worked well.

I am using a self-made extension of about 2 meter. I had problems
programming 5V devices although with 3.3V devices it worked perfectly. Now
that I changed computers, it works fine with 5V devices.
IMHO cable length matters depending also on the type of parallel port used.



Article: 41392
Subject: Re: Xilinx 4.2i not working on my design
From: "David Frith" <david.frith@ffei.co.uk>
Date: Wed, 27 Mar 2002 09:23:36 -0000
Links: << >>  << T >>  << A >>
"Jon Schneider" <jon@axisREmilMOVEton.ltd.uk> wrote in message
news:memo.20020326164009.35965A@xxx.cix.co.uk...
> David,
>
> It sounds a bit like a machine problem. I suggest you at least run
> memtest86 (http://www.memtest86.com/) on it.
>
> Jon
>

You may very well be right. My machine is an 800MHz Athlon processor and I
notice some of the known problems with the Xilinx software are about
problems running on Athlon processors.

What puzzles me is how I can run 4.1i through with no problems and yet the
exact same input files on 4.2i break ngdbuild.

I think there is some conflict between the 4.2i software and some dll that
needs updating.

Regarding the comment about completing a project in the same version of
software - that's what I do normally. This was a simple test to see how much
better 4.2i works on a known design. Unfortunately it's failed the test :-)
:-(

Thanks for all your help.

David



Article: 41393
Subject: XPower & Power Estimator Spreadsheet
From: Andy_J_Dow@hotmail.com (Andy Dow)
Date: 27 Mar 2002 01:24:45 -0800
Links: << >>  << T >>  << A >>
Hi,

I am working on a design in a Virtex 2. It is a FIR filter and uses
the emebedded multipliers. I have used the Xpwr batch program on this
design with a VCD file generated by my testbench running in ModelSim.
I think I have included all the nets in the design as I have used the
"vcd add -r /i0/*"  which should recurse into the blocks and looking
at the VCD file it seems OK. The testbench runs test data through the
filter. XPwr give me an estimated power value for this. I have also
got hold of the Excel spreadsheet Power Estimator for the V2. I have
filled this out, maybe not as accurately as possible but should be
roughly correct, and this gives me a value but it seems to be much
higher.

As anyone else done a comparison? Know which value to use? Or am I
just missing the point?

Any help would be gratefully received.

Thanks

Andy Dow

Article: 41394
Subject: Re: clock multiplier
From: sunny <sunshine@sunrise.at>
Date: Wed, 27 Mar 2002 02:58:32 -0800
Links: << >>  << T >>  << A >>
Internally : Dont do it!

Externally : Take a look on IDT´s or Cypress' web pages.

Article: 41395
Subject: How can I add constrains?
From: "deerlux" <deerlux@hotmail.com>
Date: Wed, 27 Mar 2002 19:42:30 +0800
Links: << >>  << T >>  << A >>
I want to implement a counter of 160Mhz internal clock.The clock of external
is 80Mhz and doubled by the DLL of Xilinx SpartanII.After I implemented it I
found the maxium frenquency reported by ISE4.1 is about 140 MHz.In this
instance, can I implement 160MHz counter?If no,how can I add constrains to
my design.Which is more important the constrain before synthesis or after
synthesis?
--
_________________________________________

Deerlux White

ICQ#:147863330



SMS: (Send an SMS message to my ICQ): +2783142147863330

More ways to contact me: http://wwp.icq.com/147863330

_________________________________________



Article: 41396
Subject: How to probe internal signals from Xilinx netlist?
From: "Kelvin Hsu" <qijun@okigrp.com.sg>
Date: Wed, 27 Mar 2002 20:17:53 +0800
Links: << >>  << T >>  << A >>
Hi,

I am doing gate level simulation and I realized that it is so difficult to
probe internal signals since they are
all changed into a strange format and the format is also keeping changing
everytime I re-run the simulation.

Is there any method so that I can have the internal signal names to be fixed
in the simulation( I mean the
registers)...I think in Synopsys I can see the format they write netlists.
But Xilinx is lot of messy.

Thanks.



module whatever(
);
  input clk_12m;
  output buffer_full2;
  input rxd;
  output clk_out;
  wire IO33_OBUF;
  wire rxd_out_OBUF;
  wire rxd_1_OBUF;
  wire rst_n_IBUF;
  wire \clockrecovery/beta_tmp_0 ;
  wire \clockrecovery/x_0 ;
  wire \clockrecovery/x_1 ;                // This is the result my
definition of reg [7:0] x;
  wire \clockrecovery/beta_tmp_1 ;
  wire \clockrecovery/Mmult_beta_X_x_inst_lut2_20 ;
  wire \clockrecovery/N1682 ;
  wire \clockrecovery/Mmult_beta_X_x_inst_cy_88 ;
  wire \clockrecovery/x_2 ;




Article: 41397
Subject: Re: synplify, quartus II 2.0
From: "slarty" <slarty@wp.pl>
Date: Wed, 27 Mar 2002 14:28:20 +0100
Links: << >>  << T >>  << A >>
I confirm - this solution is right. My LS crashed in the same way and I
received such advice directly from Altera support. Now everything works
fine.

> as far as I know, LeonardoSpectrum 2002a crashing after startup has to do
> with the windows versions you're using, international or US.
>
> Try to set the following Windows environment variable:
>
> Name of the variable:     TZ
> Value of the variable:        GST-1GDT
>
> Regards
> Wolfgang




Article: 41398
Subject: Re: Missing Timing by 30,000 ns
From: "Serkan Dinmez" <sdinmez@mgeo.aselsan.com.tr>
Date: Wed, 27 Mar 2002 06:13:31 -0800
Links: << >>  << T >>  << A >>
Hi all,
I am using a XC2V1000 in my design.I am trying to achieve a 30 MHz clk from a 20 MHz one, using CLKFX.  

I have tried the code below.The
LOCKED pin of the DCM stays always 
at '0' and at CLKFX I see the default x4 clkin signal.

Neither Leonardo S. nor Xilinx D.Mgr
gave error message.I have also investigated DCM with FPGA Editor,
everything seemed normal.

So far I could not understand the
problem.

I would like to hear your comments
or advices.
Regards,
Serkan Dinmez

The VHDL code is as below:

library IEEE;
use IEEE.std_logic_1164.all;
library UNISIM;
use UNISIM.VCOMPONENTS.all;

entity DCM_TOP is
port (
clock_in : in std_logic;
clock_out : out std_logic;
LOCKED: out std_logic
);
end DCM_TOP;

architecture XILINX of DCM_TOP is

signal low, high : std_logic;

signal clock : std_logic;
signal clk1: std_logic;
signal clk1_buf: std_logic;
signal READ_CLK: std_logic;

attribute DLL_FREQUENCY_MODE : string;
attribute DUTY_CYCLE_CORRECTION : string;
attribute STARTUP_WAIT : string;
attribute DFS_FREQUENCY_MODE : string;
attribute CLKFX_DIVIDE : string;
attribute CLKFX_MULTIPLY : string;
attribute CLK_FEEDBACK : string;
attribute CLKOUT_PHASE_SHIFT : string;
attribute PHASE_SHIFT : string;

attribute DLL_FREQUENCY_MODE of dcm1: label is
"LOW";
attribute DUTY_CYCLE_CORRECTION of dcm1: label is
"TRUE";
attribute STARTUP_WAIT of dcm1: label is "TRUE";
attribute DFS_FREQUENCY_MODE of dcm1: label is
"LOW";
attribute CLKFX_DIVIDE of dcm1: label is "2";
attribute CLKFX_MULTIPLY of dcm1: label is "3";
attribute CLK_FEEDBACK of dcm1: label is "1X";
attribute CLKOUT_PHASE_SHIFT of dcm1 : label is
"FIXED";
attribute PHASE_SHIFT of dcm1: label is "0";

component IBUFG
port (
I : in std_logic;
O : out std_logic
);
end component;
component BUFG
port (
I : in std_logic;
O : out std_logic
);
end component;
component DCM
port (
CLKFB : in std_logic;
CLKIN : in std_logic;
DSSEN : in std_logic;

PSCLK : in std_logic;
PSEN : in std_logic;
PSINCDEC : in std_logic;
RST : in std_logic;
CLK0 : out std_logic;
CLK90 : out std_logic;
CLK180 : out std_logic;
CLK270 : out std_logic;
CLK2X : out std_logic;
CLK2X180 : out std_logic;
CLKDV : out std_logic;
CLKFX : out std_logic;
CLKFX180 : out std_logic;
LOCKED : out std_logic;
PSDONE : out std_logic;
STATUS : out std_logic_vector (7 downto 0));
end component;

begin

low<='0'; 
high<='1';

clock_out <= READ_CLK;
U1 : IBUFG port map ( I => clock_in, O => clock);

dcm1: DCM port map (
CLKFB => clk1_buf,
CLKIN => clock,
DSSEN => low,
PSCLK => low,
PSEN => low,
PSINCDEC => low,
RST=> low,
CLK0 => clk1,
CLKFX=>READ_CLK,
LOCKED => LOCKED
);

U2:BUFG port map (I => clk1 , O => clk1_buf );

end XILINX;

Article: 41399
Subject: Re: question on LFSR
From: Ken Chapman <chapman@xilinx.com>
Date: Wed, 27 Mar 2002 14:25:29 +0000
Links: << >>  << T >>  << A >>
Dear Kevin,

The trick is to tell the accumulator to ignore what is coming out of the shift
register for a number of cycles following the release of your reset. The masking
AND gates to do this should be absorbed into the LUTs forming the accumulator (
effectively performs A + [B.mask] in each LUT). An SRL16 can be used to remember
how long it is since the reset was released. In this way you don't need to
'flush' the shift register.

The control logic would set a flip-flop driving the 'mask' input on the start of
reset (active high). The reset signal would also enter an SRL16 adjusted to a
suitable length. The flip-flop would only be reset when it sees a high to low
transition come out of the SRL16. The only cause for concern would be if you
applied a reset whilst midway through the previous reset.

A real flip-flop based shift register with the first D input connected to GND
and all flip-flops forced to SET with the applied reset signal would be an
easier design to control the 'mask' signal. See last diagram in the following
TechX about resets.....

http://www.xilinx.com/support/techxclusives/global-techX19.htm

This also avoids any reset issues. It will probably be larger, but as it is only
1-bit wide it still means that your data path offers the major saving in area
via those wonderful SRL16E's.

Hope this helps.

Ken




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
2017JanFebMarApr2017

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