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 28675

Article: 28675
Subject: Re: Best design for asyn. interface DSP <-> FPGA?
From: "Chris G. Schneider" <cgs-news@cgschneider.com>
Date: Sat, 20 Jan 2001 10:08:29 +0100
Links: << >>  << T >>  << A >>
Ray Andraka wrote:

> It can be done without block rams.  Depending on what the registers hold, you
> may not need synchronizing logic (a mode bit for instance often can be set
> without timing consequence if the processor it controls is idle).  Let's assume
> you need to write synchronously into a sytem with an async DSP write.  The DSP
> write occurs on a write strobe that is async to any clocks you have.
>
> What you do is let the DSP write pulse clock an input register(s) that
> essentially gets written with the DSP data.  You might also want to write a few
> bits of the address so you can figure out where the data is supposed to go.  So
> far, we're not doing anything to get into the timing of our FPGA logic, this is
> all self timed from the DSP (you may want to connect the write pulse to a clock
> buffer).

This is nearer to the solution I thought of, thanks Ray. I just wonder how many FF
you can use safely when its clock is not connected to a dedicated pin, or if all
clock buffers are in use already. Setting a LOWSKEWNET will help. But what are your
experiences?


> For readback, internally select the register using just the address,
> as it comes earlier, then turn on the output buffers with the qualified read.

Yes, but you have to take care on the read signal as well, may be I forgot to
mention, that the DSP data bus is a bidirectional one. This is exactly where my
problem occurs: I use async. logic for read accesses and depending on the mood of
the tools glitches are produced at the external data bus. I don't know how to
control them without FFs.

> Now, if you need the data syncrhonized to your FPGA clock, you toggle an
> additional flip-flop with the write pulse, so that each time a write occurs, the
> toggle flop changes to the opposite state.  You synchronize that toggle flop
> output to the FPGA clock domain through a flip-flop or two, and then drive a
> state machine that generates a 1 clock wide write pulse each time it sees that
> synchronized toggle change state.  That write pulse can then be used to
> synchronously and safely copy the data captured in the write register to another
> register in your FPGA clock domain.  The only requirement is you have to
> guarantee the capture register is not changed before the transfer occurs, which
> can usually be done by making sure the local clock goes through at least 3 or 4
> cycles in the fastest possible DSP write time (if not, you can assemble several
> DSP writes into a long word and transfer only after the nth write).

Good idea, I don't think that the writing of the data is a problem anymore.

> Reading back can be a little trickier, but the same sort of set up can be used.

I am not sure what you mean. For readback I can use the address to select a
register, in parallel I can generate a read pulse to store the selected data in an
output register. If the read signal is deasserted, the output can be tristated
aynchronously.

> Here, it helps if the read address is known ahead of time.

Sure, some kind of a piplined read would be perfect, unfortunately the DSP does not
support such kind of transfers. To be honest, the address is valid only a few ns
before the read access, so this won't help much.

So I just can forget about implementing a read-after-write feature, beause pipeling
takes a lot of time. It is very likely that a read after write to same register
would result in reading the old data instead of the new one.

We discussed three differnt aspects up to now:

1)  registers for external control: best without synchronizing

2) data streams best with asyn. FIFO

3) data to be used internally sync at internal clock.

All of these problems occur in my design. Using the internal synchronization seems
to be a solution for all of this three situations.

Best regards,

Chris

> "Chris G. Schneider" wrote:
> >
> > Peter Alfke wrote:
> >
> > ? Chris, you may want to look at an article about crossing asynchronous
> > ? clock boundaries that I published about a year ago. Mayeb it helps
> > ? you.
> > ?
> > ? http://www.isdmag.com/editorial/2000/design0003.html
> > ?
> > ? Peter Alfke, Xilinx Applications
> > ? ================================
> >
> > Peter,
> >
> > I have just reread your nice article. The asynchonous FIFO is a perfect
> > solution when it comes to streams of data that the FPGA processes.
> >
> > In my application  FPGA registers are maped into the DSP memory. These
> > registers can set hardware switches, and in some cases the DSP data will
> > be
> > transfered to a synchronous FIFO through a pipeline, or the other way
> > round: data from an other FIFO can be read by the DSP as well.
> >
> > Using synchronous FIFOs forced me to operate these FIFOs at the speed of
> >
> > the DSP interface (120MHz), but the real data rates are much lower.
> >
> > The fastest part in my design are the DSP interfaces, all other stuff is
> >
> > much much slower.
> >
> > The DSP is able to write to a register and read from it in the next
> > access. The effictive data rate of the DSP is about 25 MHz, but DSP
> > write strobes are very short (12 ns), and the DSP expects to valid data
> > 23 ns after read assertion which is less than 3 clock cycles at 120 MHz.
> >
> > This is the reason for choosing an asynchronous read access. But
> > unfortunately, async. logic can produce glitches, this may be a problem.
> >
> > I don't know how to use async. FIFOs in this case. I cannot implement a
> > FIFO for each register bank, and the read after a write access makes the
> >
> > use of FIFOs difficult.
> >
> > I have to implement a lot of these kind of interfaces and I am looking
> > for a clean solution. May a cache build of BlockRAM be a possiblity?
> > My Virtex-E has some free RAM cells left. The DSP can have fast access
> > to the cache, and all write accesses to the registers can be pipelined
> > then. But what external clock can be used for this cache? There is just
> > the read and write signal of the DSP.
> >
> > Originally I thought of this as a school book example, because mapping
> > FPGA registers into DSP memory seems to be pretty standard. I'm not sure
> >
> > any more.
> >
> > Best regards,
> >
> > Chris
> >
> > ?
> > ? "Chris G. Schneider" wrote:
> > ?
> > ?? I want to design an interface between a DSP and a FPGA. The DSP
> > ?? should
> > ?? be able to access FPGA registers, via the DSP parallel port. The
> > ?? DSP parallel port has address, data, chip select, read and write
> > ?? lines.
> > ?? Just the usual stuff.
> > ??
> > ?? I just designed this interface, but I am not happy with the results
> > ?? in
> > ?? terms of speed and design stability. So I  want to ask this audience
> > ?? for
> > ?? some design hints.
> > ??
> > ?? 1) Write access: I just synchronize the DSP write signal and
> > ?? generate an
> > ?? internal write strobe to fetch the data. Is it a better solution to
> > ?? use
> > ?? the write signal to store the data in a register and then
> > ?? synchronize
> > ?? the register contents to the internal clock? This makes it possible
> > ?? to
> > ?? detect very short write strobes of the DSP and to reduce the number
> > ?? of
> > ?? WS, in the application.
> > ??
> > ?? 2) Read access: I use a async. read access at the moment. Is it
> > ?? possible
> > ?? to make this work synchronously? The problem is that synchronizing
> > ?? just
> > ?? eats up a lot of time, and timing constraints of modern DSP are
> > ?? pretty
> > ?? tight. There will be a problem if the FPGA does not release the DSP
> > ?? data
> > ?? bus fast enough, because read and write accesses can appear very
> > ?? soon
> > ?? after each other.
> > ??
> > ?? Any suggestions, or literature tips?
> > ??
> > ?? --
> > ?? chris
> > ?
>
> --
> -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  or http://www.fpga-guru.com

--
To be shocked is not worth while.




Article: 28676
Subject: Clear Logic and ALTERA
From: "Eugeny M. Zubok (Studio Sound, Ltd.)" <zubok@concord.ru>
Date: Sat, 20 Jan 2001 16:36:50 +0300
Links: << >>  << T >>  << A >>
    Hello,

    Recently I read about Clear Logic Inc. (www.clear-logic.com) which
products ASIC's pin and speed compartible with the same ALTERA chips.
Is anybody worked with Clear Logic? What are the oppinions?

    I heard that ALTERA files suit against Clear Logic in 1999. This
press release from ALTERA web-site:

    "Altera Files Suit Against Clear Logic for Unlawful Use of
Altera's Technology
    San Jose, Calif., November 16, 1999--Altera Corporation (Nasdaq:
ALTR), a leading supplier of high-density programmable logic devices
(PLD), filed suit against Clear Logic, Inc. today in Federal District
Court in San Jose. The case alleges that Clear Logic is unlawfully
using Altera's chip technology. Altera alleges that Clear Logic has
unlawfully appropriated Altera's registered mask work technology in
violation of the federal mask work statute and that Clear Logic has
unlawfully interfered with Altera's customer relations. Altera is
confident of victory because Clear Logic had admitted in its own
literature on many occasions that its technology is "identical". Clear
Logic has never asked for or been given a license for the use of this
technology. The suit asks for compensatory damages, punitive damages,
and an injunction to stop Clear Logic from unlawfully using Altera's
technology."

WHAT THE FINAL OF THIS STORY?

Thank you, Eugeny M. Zubok


Article: 28677
Subject: Re: Synplicity newsgroup?
From: "Jan Gray" <jsgray@acm.org>
Date: Sat, 20 Jan 2001 17:23:11 GMT
Links: << >>  << T >>  << A >>
"Andrew Dauman" <andrew@synplicity.com> wrote in message
news:3A6905E8.C3C1BD9A@synplicity.com...
> It should be "news.synplicity.com",  can netscape see that?
> The server name did not change, it may be a "cache" problem (i.e.
> name mapping records are not all updated yet). If so, try 209.157.48.251,

I too have been unable to connect to news.synplicity.com for two weeks or
so, but this explicit IP address does seem to work.

Jan Gray, Gray Research LLC



Article: 28678
Subject: Re: DSP->FPGA development board
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Sat, 20 Jan 2001 12:26:35 -0500
Links: << >>  << T >>  << A >>
bjorn_lindegren@my-deja.com wrote:
> 
> Hi
> 
> I'm looking for a development borad whith a DSP and a FPGA 'Xilinx, a
> big one....Spartan II or something'.
> 
> I want this board to have a A/D and a D/A converter for analog sampling.
> 
> If you know any board like this, I will be thankefull for know about it.
> 
> Regards
> 
> Björn Lindegren
> 
> Sent via Deja.com
> http://www.deja.com/

You may be interested in our PC104C31 DSP board. This is a PC/104 board
capable of operating as a bus slave (uart emulation), bus master or
stand alone. The DSP is the TMS320C31 running at up to 80 MHz for 80
MFLOPS. This board uses AIO modules to provide analog IO with an 8
channel, 16 bit 96 KSPS codec module to be available in another month.
The AIO modules connect to the DSP through 30K and 4K gate Lucent FPGAs.
There is also 256K words of 0 wait state SRAM and 2 MB of Flash memory. 

If you need faster analog IO, we would be willing to discuss the design
a custom AIO module. 

You can view further information at http://www.arius.com/ or you can
drop me an email. 


-- 

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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
URL http://www.arius.com

Article: 28679
Subject: Re: Synplicity newsgroup?
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Sat, 20 Jan 2001 19:22:07 GMT
Links: << >>  << T >>  << A >>
On Sat, 20 Jan 2001 17:23:11 GMT, "Jan Gray" <jsgray@acm.org> wrote:

>"Andrew Dauman" <andrew@synplicity.com> wrote in message
>news:3A6905E8.C3C1BD9A@synplicity.com...
>> It should be "news.synplicity.com",  can netscape see that?
>> The server name did not change, it may be a "cache" problem (i.e.
>> name mapping records are not all updated yet). If so, try 209.157.48.251,
>
>I too have been unable to connect to news.synplicity.com for two weeks or
>so, but this explicit IP address does seem to work.
>
>Jan Gray, Gray Research LLC
>

The weird thing is "ping news.synplicity.com" says unknown host but
"ping -a 209.157.48.251" says the IP address is news.synplicity.com. I
think somehow DNS records got messed up.

Muzaffer

FPGA DSP Consulting
http://www.dspia.com

Article: 28680
Subject: Re: Virtex-II officially launched
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Sat, 20 Jan 2001 14:34:21 -0500
Links: << >>  << T >>  << A >>
Terry Hicks wrote:
> Rick Filipkiewicz wrote:
> > Are Xilinx going to avoid the SpartanII mistake of letting a few major
> > customers soak up all the Virtex-II production leaving those of us
> > reliant on the disti's completely out of luck ? [lead time > 20 weeks =>
> > no design in]
> >
> > [Anybody remember Ray's joke about the SpartanII T-shirt ?]
> 
> I have to second Rick's comment.  How about it?  No small quantities= no
> design in.  I am currently designing a device which would benefit from a
> small Virtex-E device due to the LVPECL i/o capability.  I don't think I
> will use one, as I cannot trust the availability of the Virtex-E parts.  I

I have a couple of questions about these new parts. Of course
availability is a big one. As others have said, if you can't get parts
for prototypes, you can't use them in production. Anyone know of the
expected availability and price of a low end VirtexII? I would be
interested in the XC2V40-4FG256C or XC2V80-4FG256C.

It looks like the Xilinx power on current requirement is still 500 mA
like the SpartanII chips. Any chance that this will be reduced as the
parts are further characterized? 

-- 

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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
URL http://www.arius.com

Article: 28681
Subject: Re: About programming cables
From: Bill Lenihan <lenihan3weNOSPAM@earthlink.net>
Date: Sat, 20 Jan 2001 21:21:08 GMT
Links: << >>  << T >>  << A >>
We have/had a MultiLinx cable for JTAG programming Virtex FPGAs, and it
worked well for a while, but (a) was surprisingly slow, (b) appears to have
died (though we don't know of any electrical overstress that our target h/w
could have applied to it), and (c) is expensive. In retrospect, I like the
JTAG Parallel Cable III Model DLC5 much better. We just got another one,
and it only costs $95.

"Juan M. Rivas" wrote:

> I'm looking for a Progrmming Cables from Xilinx, for a stand alone FPGA
> proyect:  Does anyone know wher I can by one, and which one is good?
>
> I've been looking for the Multilinx, and the Xcheqer,  but I can't
> decide...Besides I can't find where to find them (Always out of stock)
>
> Suggestions???
>
> Thanks all

--
==============================
William Lenihan
lenihan3weNOSPAM@earthlink.net
.... remove "NOSPAM" when replying
==============================



Article: 28682
Subject: Re: Synplicity newsgroup?
From: Bill Lenihan <lenihan3weNOSPAM@earthlink.net>
Date: Sat, 20 Jan 2001 21:24:27 GMT
Links: << >>  << T >>  << A >>
It never even occured to me that there would be a Synplicity newsgroup
.... their s/w is too damn easy to use!

Utku Ozcan wrote:

> What happened to Synplicity's newsgroup?
> The newsgroup browser tells that the server is down...
>
> Utku

--
==============================
William Lenihan
lenihan3weNOSPAM@earthlink.net
.... remove "NOSPAM" when replying
==============================



Article: 28683
Subject: Re: Virtex-II officially launched
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Sat, 20 Jan 2001 15:43:59 -0800
Links: << >>  << T >>  << A >>


Rick Collins wrote:

> Anyone know of the
> expected availability and price of a low end VirtexII? I would be
> interested in the XC2V40-4FG256C or XC2V80-4FG256C.
>
> It looks like the Xilinx power on current requirement is still 500 mA
> like the SpartanII chips. Any chance that this will be reduced as the
> parts are further characterized?
>

I will check prices and availability, obviously I personally encounter no
problem in that regard :-)
I am glad to report that the power-on current is in the 40 mA range, ten times
lower than on previous generations. It took some doing, but ity has been done.

Peter Alfke, Xilinx Applications


Article: 28684
Subject: Re: Virtex-II officially launched
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Sun, 21 Jan 2001 01:49:36 -0500
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Rick Collins wrote:
> 
> > Anyone know of the
> > expected availability and price of a low end VirtexII? I would be
> > interested in the XC2V40-4FG256C or XC2V80-4FG256C.
> >
> > It looks like the Xilinx power on current requirement is still 500 mA
> > like the SpartanII chips. Any chance that this will be reduced as the
> > parts are further characterized?
> >
> 
> I will check prices and availability, obviously I personally encounter no
> problem in that regard :-)
> I am glad to report that the power-on current is in the 40 mA range, ten times
> lower than on previous generations. It took some doing, but ity has been done.
> 
> Peter Alfke, Xilinx Applications

I am no chip designer, but since they are a smaller and newer
generation, I would expect the VirtexII to be cheaper than the Spartan
II for a given number of gates. But I overlooked a couple of things with
the VirtexII parts. They have much less IO for a given size than the
other logic I have considered. I would have to go to an XC2V250 to get
enough IOs for our design. 

I doubt that it will be practical to use five XC2V250s on our board in
place of five XC2S50s. But the SpartanII chips use too much power on
current. So I expect that I will be back where I started, needing to use
the Altera 1K parts. But I may be able to use one XC2S50-5FG256C and
four XC2V40-4CS144C. I need to look at the IO requirements in detail.

We will see how the pricing turns out. But once we pick a family, we
will be sticking with that vendor for a number of boards since they will
all use compatible FPGA designs. 


-- 

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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
URL http://www.arius.com

Article: 28685
Subject: Re: About JTAG
From: "Alain Cloet" <nospam@tijd.com>
Date: Sun, 21 Jan 2001 12:02:20 +0100
Links: << >>  << T >>  << A >>
A good program which could help:
http://www.ti.com/sc/data/jtag/scanedu.exe

Greetings,
Alain

"Juan M. Rivas" <jmrivas@media.mit.edu> wrote in message
news:3A68638B.4FED9C3C@media.mit.edu...
> Hi all!
>
> Does anyone know about a good book or article to understand JTAG and
> boundary scan?  What I've found so far is not really clear...
>
> Thanks
>
> Attn. Juan



Article: 28686
Subject: UK parts
From: jms@geriatrix.circlesXXXXXquared.com
Date: 21 Jan 2001 13:53:41 +0000
Links: << >>  << T >>  << A >>
I seem to be having difficulty finding an online supplier for one off
quantities of Xilinx FPGA/CPLDs in the UK. Specifically Spartans. And
preferebly at £few like their press release implies !

I've found are the XC95xxx on RS and that's about it.

Xilinx's site suggests two online suppliers, one of which's page
doesn't seem to work and the other only delivers in the U.S.

Any suggestions ?

Or another make with free development tools (but not Actel because
their desktop SW didn't agree with me) ?

	Jon

Article: 28687
Subject: xc95108 funny behaviour
From: "Ralf A. Eckhardt" <a.eckhardt@t-online.de>
Date: Sun, 21 Jan 2001 14:54:00 +0100
Links: << >>  << T >>  << A >>
Hello,

I need help in understanding the following problem: 

Within a complex XC95108-7 design, an input signal is supposed
to be latched and transferred to an output pin.
The latched signal will also be used as input term elsewhere.

|  FF	   PIN output ISTYPE 'REG_D,BUFFER';
|   :
|  FF.CLK = mainclock.pin   (pin 9)
|  FF.D   = input.pin

Sporadically, this simple function fails, i.e. the /output/
stays at 0 where it should follow the input's 1.
The other terms in the design using 'FF.Q' do also see the 
same logical level as found at the /outpit/ pin.
This failure occurs sporadically and seldom (1 failure per
1 million clocks)

** What could produce this failure? **

* The clock provided by a special clock distributor MPC947, which 
is driven by a 30MHz integrated xtal-oscillator.
* There are no glitches visible (500Msamples/sec, storage scope, 
100MHZ Bandwidth, large persisting time) at the input.pin.
* Power also looks clean. There is 0.1 microfarad on each power pin 
to the GND plane. 
* Exchanging the chip by a new one does not help.

Could the following have something to do with it:

On the same chip there are 32 pins driving a kind of data bus.
The same bus is also driven by another chip (#2) while the databus
pins of the first chip (#1) are forced to tristate:
 
| DATA1.OE = enable.pin	       (eqn. for chip #1)
| DATA2.OE = !enable.pin       (eqn. for chip #2)

Now it might be possible, that both chips are driving the bus
simultaneously for ~ a nanosecond during the transition of the 
/enable/ signal. This transition occurs with ~ 4MHz frequency.

Could that mess up the core of the XC95108 so much that the 
FF - function (descibed at the top of the arcicle) fails?
Does the temporary 'short circuit' lead to a drop of the 
internal power of the chip?
Is 0.1 microfarad on each power-supply-pin enough or should it 
be considerably more?

Many thanks in advance!

Ralf.
-- 
	Ralf A. Eckhardt
	a.eckhardt@t-online.de


Article: 28688
Subject: Re: xc95108 funny behaviour
From: Greg Neff <gregneff@my-deja.com>
Date: Sun, 21 Jan 2001 15:12:16 GMT
Links: << >>  << T >>  << A >>
In article <3A6AE9F8.C8A1CDF7@t-online.de>,
  a.eckhardt@t-online.de wrote:
(snip)
>
> Could the following have something to do with it:
>
> On the same chip there are 32 pins driving a kind of data bus.
> The same bus is also driven by another chip (#2) while the databus
> pins of the first chip (#1) are forced to tristate:
>
> | DATA1.OE = enable.pin	       (eqn. for chip #1)
> | DATA2.OE = !enable.pin       (eqn. for chip #2)
>
> Now it might be possible, that both chips are driving the bus
> simultaneously for ~ a nanosecond during the transition of the
> /enable/ signal. This transition occurs with ~ 4MHz frequency.
>
> Could that mess up the core of the XC95108 so much that the
> FF - function (descibed at the top of the arcicle) fails?
> Does the temporary 'short circuit' lead to a drop of the
> internal power of the chip?

I doubt that this is your problem, but I still would design to avoid
bus contention.  If you can't do it with a synchronous state machine,
then some cross-coupled feedback will probably suffice.  Buffer the
enable signal through the CPLD, so that you have a delayed copy of
enable from each chip.  Use the delayed enable from one chip as a
second enable for the other chip.  This will prevent the second chip
from enabling until the delayed enable from the other chip changes
state.  Don't use a fast output for the delayed enable.  You will have
to check the timing, but this will probably do the trick.  I guess the
equations would look something like this:

In chip 1:
enable_2 = !enable
DATA1.OE = enable * enable_1

In chip 2:
enable_1 = enable
DATA2.OE = !enable * enable_2

> Is 0.1 microfarad on each power-supply-pin enough or should it
> be considerably more?

This should be OK.

Have you checked to make sure that the input data meets the input setup
and hold time requirements?

Are you using a multi-layer board with ground and VCC planes?

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com
http://www.deja.com/

Article: 28689
Subject: Is the Xilinx XCV200 in the FG456 package cavity UP or DOWN?
From: "Austin Franklin" <austin@dark99room.com>
Date: Sun, 21 Jan 2001 11:19:00 -0500
Links: << >>  << T >>  << A >>
It appears that the FG456 parts are cavity UP, but I want to make sure
before doing my pinouts...

The floorplanner gives the low number, low letter in the upper left.  The
FPGA Editor gives the low number, low letter in the upper left.  The package
drawing shows low number, low letter in the upper left (top view of
package).  That to me, means this is a cavity up part.

The BG352 is a cavity down part...since the floorplanner gives the low
number low letter in the in the upper RIGHT .  The FPGA Editor gives the low
number, low letter in the upper RIGHT.  The package drawing shows the low
number, low letter in the upper left (top view of package).  That, to me,
means this is a cavity DOWN part...since the die has to be flipped to line
up the die pins with the package pins.

Both the FPGA Editor and the Floorplanner are both 'die' view, it would
appear.  When doing floorplanning, at least for me, I would prefer the
Floorplanner be a TOP view (or give you the option of die view or top view),
so I can lay my chip out without having to flip everything over to really
see how it lines up with the outside world...

I REALLY wish they had a chart that showed the orientation of the die in
each package...and I've mentioned this to them many a time.

Any comments?





Article: 28690
Subject: Re: UK parts
From: "Mike H." <mikeh@spamlessimageproc.com>
Date: Sun, 21 Jan 2001 17:04:00 -0000
Links: << >>  << T >>  << A >>

<jms@geriatrix.circlesXXXXXquared.com> wrote in message
news:wkofx19fkq.fsf@geriatrix.circlesXXXXXquared.com...
> I seem to be having difficulty finding an online supplier for one off
> quantities of Xilinx FPGA/CPLDs in the UK. Specifically Spartans. And
> preferebly at £few like their press release implies !


I've had no trouble getting small quantities of Xilinx parts (at reasonable
prices) from the company formerly known as Micro-Call, now Insight-Memec.

They don't have online ordering (yet), but give 'em a call on 01296 330061.

....It must be said, however, that since Memec restructured their UK
operations into Insight, Impact, and Unique, it all seems to have gone
a bit pear-shaped....

IMHO, of course.

MH.




Article: 28691
Subject: Re: xc95108 funny behaviour
From: "Ralf A. Eckhardt" <a.eckhardt@t-online.de>
Date: Sun, 21 Jan 2001 18:20:20 +0100
Links: << >>  << T >>  << A >>
Greg Neff wrote:

> I doubt that this is your problem, but I still would design to avoid
> bus contention.  If you can't do it with a synchronous state machine,
> (...)

Effectively, I do this synchoneously. The /enable/ input 
is fed directly from a D-latch which is clocked by the mainclock.
Nevertheless I am concerned about different delays between
DATA1.OE-->off in Chip#1 and DATA2.OE-->on in Chip#2.
That problem remains the same, synchroneously or asynchroneously.

> then some cross-coupled feedback will probably suffice.  Buffer the
> enable signal through the CPLD, so that you have a delayed copy of
> enable from each chip.  (...)
> I guess the equations would look something like this:
> (...)
> DATA1.OE = enable * enable_1
> (...)

Good Idea! This makes sure, that both outputs cannot be driven
simultaneously. I will try that. Unfortuatelly, this will require
redesign of an existing PCB as new wires are to be drawn.
And, to tell the whole story, in fact there are not 2 but 3 drivers
to synchronize, (roughly: DATA1.OE = enable * enable_2 * enable_3), 
but well, the whole thing needs redesign anyway.

After all the question remains: can such a bad bus-design 
affect the proper function of other logical blocks on the chip?

> Don't use a fast output for the delayed enable. 

I am using ABEL(FOUNDATION 2.1) for the design and as far as I
can see the compiler reports each output to be in the 'fast mode'.
How do I switch to 'slow' mode?

> Have you checked to make sure that the input data meets the input
> setup and hold time requirements?

The input comes asynchroneously (changes slowly, stable for
microseconds) and the D-FF is supposed to synchronize it. 
If the hold time is not met, I would expect the data to be 
latched at the following rising clock (33ns later). 
But it comes /never/ or 10..20 cycles later.

Might metastability be a serious problem here?

> Are you using a multi-layer board with ground and VCC planes?

Multilayer with GND plane. No Vcc-Plane, but thick connections
(1-2mm) with SMD-Cer-Caps blocking at each Vcc-Pin.


Thanks for your help;
Ralf.
-- 
        Ralf A. Eckhardt
        a.eckhardt@t-online.de

Article: 28692
Subject: Re: UK parts
From: "Gary Watson" <gary2@nexsan.com>
Date: Sun, 21 Jan 2001 17:51:36 -0000
Links: << >>  << T >>  << A >>
<jms@geriatrix.circlesXXXXXquared.com> wrote in message
news:wkofx19fkq.fsf@geriatrix.circlesXXXXXquared.com...
> I seem to be having difficulty finding an online supplier for one off
> quantities of Xilinx FPGA/CPLDs in the UK. Specifically Spartans. And
> preferebly at £few like their press release implies !
>
> I've found are the XC95xxx on RS and that's about it.
>
> Xilinx's site suggests two online suppliers, one of which's page
> doesn't seem to work and the other only delivers in the U.S.
>
> Any suggestions ?
>
> Or another make with free development tools (but not Actel because
> their desktop SW didn't agree with me) ?
>

I've been thinking about starting a FPGA user's group in the UK, and one of
the things it would have is small quantities of parts available to
experimenters and maybe demo boards.  Another idea I've thought about is
making a proto board around the Spartan II XC2S150-FG456 and the
XC18V01SO20, but unlike the others I've seen, there would be no other logic,
just footprints for several pitches of common connectors (0.1", 2mm hard
metric, HD-68, etc) for each I/O pin....


--

Gary Watson
gary2@nexsan.com  (you should leave off the digit two for email)
Nexsan Technologies Ltd.
Derby DE21 7BF  ENGLAND
UK-based Engineers: See our job postings at
http://www.nexsan.com/pages/careers.htm





Article: 28693
Subject: Re: xc95108 funny behaviour
From: "Paul Taylor" <p.taylor@ukonline.co.uk>
Date: Sun, 21 Jan 2001 18:34:36 -0000
Links: << >>  << T >>  << A >>
I designed a board with five 95108 CPLD's on.

Had spare tracks running between 1-2,1-3,1-4,1-5, 2-3, 2-4, 2-5, 3-4, 3-5,
4-5.
Very useful when you need extra signals!

The prototype of this board had only 1 short mod wire due to this!

Paul.

"Ralf A. Eckhardt" <a.eckhardt@t-online.de> wrote in message
news:3A6B1A54.97388C5C@t-online.de...
> Greg Neff wrote:
>
> > I doubt that this is your problem, but I still would design to avoid
> > bus contention.  If you can't do it with a synchronous state machine,
> > (...)
>
> Effectively, I do this synchoneously. The /enable/ input
> is fed directly from a D-latch which is clocked by the mainclock.
> Nevertheless I am concerned about different delays between
> DATA1.OE-->off in Chip#1 and DATA2.OE-->on in Chip#2.
> That problem remains the same, synchroneously or asynchroneously.
>
> > then some cross-coupled feedback will probably suffice.  Buffer the
> > enable signal through the CPLD, so that you have a delayed copy of
> > enable from each chip.  (...)
> > I guess the equations would look something like this:
> > (...)
> > DATA1.OE = enable * enable_1
> > (...)
>
> Good Idea! This makes sure, that both outputs cannot be driven
> simultaneously. I will try that. Unfortuatelly, this will require
> redesign of an existing PCB as new wires are to be drawn.
> And, to tell the whole story, in fact there are not 2 but 3 drivers
> to synchronize, (roughly: DATA1.OE = enable * enable_2 * enable_3),
> but well, the whole thing needs redesign anyway.
>
> After all the question remains: can such a bad bus-design
> affect the proper function of other logical blocks on the chip?
>
> > Don't use a fast output for the delayed enable.
>
> I am using ABEL(FOUNDATION 2.1) for the design and as far as I
> can see the compiler reports each output to be in the 'fast mode'.
> How do I switch to 'slow' mode?
>
> > Have you checked to make sure that the input data meets the input
> > setup and hold time requirements?
>
> The input comes asynchroneously (changes slowly, stable for
> microseconds) and the D-FF is supposed to synchronize it.
> If the hold time is not met, I would expect the data to be
> latched at the following rising clock (33ns later).
> But it comes /never/ or 10..20 cycles later.
>
> Might metastability be a serious problem here?
>
> > Are you using a multi-layer board with ground and VCC planes?
>
> Multilayer with GND plane. No Vcc-Plane, but thick connections
> (1-2mm) with SMD-Cer-Caps blocking at each Vcc-Pin.
>
>
> Thanks for your help;
> Ralf.
> --
>         Ralf A. Eckhardt
>         a.eckhardt@t-online.de



Article: 28694
Subject: Re: UK parts
From: "Dan" <daniel.deconinck@sympatico.ca>
Date: Sun, 21 Jan 2001 19:29:22 GMT
Links: << >>  << T >>  << A >>


The three North American distributors have fairly good stock. They have
online stock and prices.

http://www.marshall.com/

http://www.insight-electronics.com/cgi-bin/catalog.cgi?origin=order_page

http://www.nuhorizons.com/
--
Sincerely
Daniel DeConinck
High Res Technologies, Inc.





Article: 28695
Subject: Designing fractional counters?
From: "jam" <jami@g.fiway.com>
Date: Sun, 21 Jan 2001 19:53:30 -0000
Links: << >>  << T >>  << A >>
Hi,

    Any ideas on the best design for a down counter that can decrement in
programmed steps from a pre programmed start point, at zero it should assert
a flag and loop back to the start point and down count again. In otherwords
a fractional counter were you can programme the denominator and numerator,
so the flag will go high at the programmed fraction of the clock rate.



Thanks

Ja





Article: 28696
Subject: HDLmaker users guide updated
From: bjrosen <bjrosen@polybus.com>
Date: Sun, 21 Jan 2001 21:02:37 GMT
Links: << >>  << T >>  << A >>
There is a new users guide for HDLmaker available at

http://www.polybus.com/hdlmaker/users_guide

HDLmaker is an open source Verilog/VHDL code generator with extensive
support for Xilinx FPGAs. HDLmaker is licensed under the terms of the
BSD license.


Sent via Deja.com
http://www.deja.com/

Article: 28697
Subject: Firewire bus driven/received by Xilinx using LVDS
From: "Dan" <daniel.deconinck@sympatico.ca>
Date: Sun, 21 Jan 2001 22:58:12 GMT
Links: << >>  << T >>  << A >>
Is it possible to directly drive/receive a IEEE1394 firewire bus from the
LVDS outputs of a Xilinx FPGA ?

Also, where is a good place to learn more about the firewire standard ?

Sincerely
Daniel DeConinck
High Res Technologies, Inc.





Article: 28698
Subject: Re: Virtex-II officially launched
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Sun, 21 Jan 2001 17:30:19 -0800
Links: << >>  << T >>  << A >>
Hi, Rick, see my comments below:

Rick Collins wrote:

> I am no chip designer, but since they are a smaller and newer
> generation, I would expect the VirtexII to be cheaper than the Spartan
> II for a given number of gates.

In the long run, this may be true, but in the short run, a new and faster family
with many new features will initially be priced higher. Virtex-E was an exception.


> But I overlooked a couple of things with
> the VirtexII parts. They have much less IO for a given size than the
> other logic I have considered. I would have to go to an XC2V250 to get
> enough IOs for our design.

Unfortunately, your requirements fall into the big hole betweenXC2V80 and '250.
And you are right, per logic function, Virtex-II offers fewer I/O, but many
additional features.

>
> I doubt that it will be practical to use five XC2V250s on our board in
> place of five XC2S50s. But the SpartanII chips use too much power on
> current.

Sorry for that. Can you perhaps stagger the Vcc to teh 5 chips? The power-on
current lasts only milliseconds...

> So I expect that I will be back where I started, needing to use
> the Altera 1K parts. But I may be able to use one XC2S50-5FG256C and
> four XC2V40-4CS144C. I need to look at the IO requirements in detail.

I would be aggressive and integrate higher. I cannot believe you need all those I/O
when you put it all in one chip, like the XC2V1000.
You get  432 I/O,  >10,000 Logic Cells = flip-flops, where the XC2S50 has only
1,728.

And, the XC2V1000 is alreadyavailable ( in very limited quantity )
The '40 and '1000 were the first ones "out of the oven", all others will be coming
soon.

I think I have already touted the superior features of Virtex-II before.

Good luck!

Peter


Article: 28699
Subject: Re: Designing fractional counters?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Sun, 21 Jan 2001 17:37:47 -0800
Links: << >>  << T >>  << A >>
If you look at this design not as a counter, but as a presettable accumulator (
accumulating negativve values), it will look far more natural = trivial.

Peter Alfke, Xilinx Applications
==========================================
jam wrote:

> Hi,
>
>     Any ideas on the best design for a down counter that can decrement in
> programmed steps from a pre programmed start point, at zero it should assert
> a flag and loop back to the start point and down count again. In otherwords
> a fractional counter were you can programme the denominator and numerator,
> so the flag will go high at the programmed fraction of the clock rate.
>
> Thanks
>
> Ja




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