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 31550

Article: 31550
Subject: Re: ORCAD Capture Symbols
From: Chris Eilbeck <chris@yordas.demon.co.uk>
Date: Wed, 30 May 2001 02:51:36 +0100
Links: << >>  << T >>  << A >>
In article <3B144CCA.D9CF761F@aracnet.com>, eteam@aracnet.com says...
> Chris,
> 
> Could you elaborate on the problem?  Was this a layout program
> issue, a netlister issue, etc. etc. ?

What I did was a fairly large design for a multipath channel simulator 
which was to be realised using Xilinx XV series devices.  I did all the 
VHDL/simulation/place&route, no problem at all.  Happy with that.  Then I 
tried to use the Generate Part function in Orcad on the EDIF file (which 
I think is what you were suggesting) but of course there's nothing in 
that file which describes any of the power, ground or dedicated pins on 
the device.  So you can use the generated part to draw up a schematic but 
when you generate a netlist from it and try to tie this to a PCB 
footprint you find you have a whole load of pins on the footprint which 
do not have matching entries in the netlist.

At this point I decided it would be easier to just generate the part I 
wanted by hand including all the pins which weren't used explicitly in 
the EDIF.

I hope this explains the problem I found.  Maybe there is a way round it 
or it has been fixed in version 9.2 but seeing as they junked Express in 
this release and I rather liked it I stuck at 9.1.

Chris
-- 
Chris Eilbeck                             mailto:chris@yordas.demon.co.uk

Article: 31551
Subject: Re: Fun with DLLs.
From: korthner@hotmail.com (K.)
Date: 29 May 2001 18:58:22 -0700
Links: << >>  << T >>  << A >>
Austin,
Thanks for the reponse and advice.  Please see my comments below.

Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3B13175A.519EF536@xilinx.com>...
> The DLL requires the next clock input rising edge to be exactly where it is
> supposed to be, +/- 350 ps (LF mode).  If it isn't, it stops.  If the clocks
> are switched ahead of a PLL, then the PLL's output will change in frequency
> slowly enough for the DLL to track it.  This technique is used by many
> customers (PLL ahead of DLL for clock discontinuity smoothing).  A DLL can
> track incredibly fast, ~60ps per clock edge!  That adds up pretty fast for say
> 100 edges = +/-6 ns total period change.  There are some setting s that need
> to be optimized (jitter filters).

So if I switch clocks ahead of a DLL, I am not going to get a smooth
transition from the one clock to the other clock.  (The two clocks are
nominally the same frequency +/- 100ppm).

But if I switch clocks ahead of a PLL, I *will* get a smooth
transition from the old clock to the new clock?  So it looks as though
I'm better to not use the FPGA's DLL at all in this case.

> > 2. How well do the simulation models of the DLLs in the unisim library
> > model the real DLLs?
> 
> The logic funtion is there, but the timing relationships are fixed, and not
> really useful for what you have in mind.

I was afraid of that.

> > 3. If I use the same device in the same package with the same place &
> > route for the FPGA on all line cards, what can I expect my worst case
> > device-to-device clock skew to be?
> 
> In Virtex E, the error in the DLL to the global clock bus is a fixed amount,
> and is less than 100 ps.  There is some error from the global clock bus to any
> CLB and IOB on chip as well.  Consult the timing report for details.  I
> believe is is another 100 ps.

I think I will try the following:
Use the FPGA as a simple switch, two clock inputs and a select signal
into an LUT-3, with one output to a output pin, and then feed that to
a PLL.

When I switch from one clock source to the other, the PLL should shift
gently, right?

If I have a spartan-II on each card, and have the same circuit in each
spartan-II (with the same IOB, and the CLB in the same spot, close to
the 4 pins involved), what would you expect the Device-to-device skew
to be?  I'm not concerned about the delay through the FPGA, since all
cards will have the same FPGA.  The data sheets & timing reports have
the worst case delay, but don't include the error, as far as I can
see.  If they are in the datasheet/timing report, please direct me to
where.

Thanks!

-Kent

Article: 31552
Subject: Re: Fun with DLLs.
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 30 May 2001 11:11:13 +0900
Links: << >>  << T >>  << A >>


Peter Alfke <palfke@earthlink.net> writes:
> Anders is basically right. That's not what this circuit was intended to do.
> It was meant to switch between two free-running clocks, or to
> enable/disable a clock. No problem with "disabling" it: You just don't
> connect the second input and don't use the select input.
> 
> If I remember right ( I am at home without access to documentation ) you
> can switch away from a dead clock if it is parked at one of its two levels,
> but not at the other.
> I maintain, it's a nice circuit when you switch between two free running
> clock frequencies, e.g. to save power. Beats our classical recommendation
> of using CE and always running the clock full-speed everywhere.
> 
> Tack för hjälpen, Anders.
> 
> Peter Alfke, Xilinx Applications


Peter,

With this circuit of yours, you can switch between clock nicely, but you can not 
the feed the results into a DLL, can you?  if I understand correctly, the input 
to a DLL must come from a Clock input pin, or another clock?

Thanks.
-Kent

Article: 31553
Subject: Re: Peripheral for Microcontroller
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 30 May 2001 11:23:56 +0900
Links: << >>  << T >>  << A >>
"Greg Cary" <gcary@multifeeder.com> writes:
> I am designing a multi-function peripheral for a microcontroller using a
> Xilinx Spartan II.  I have created an initial design that uses the read and
> write signals from the microcontroller in an asynchronous fashion. The VHDL
> compiler warns about using these signals as clocks, so I'm wondering if this
> is the best design approach.  

Hi, Greg.

This is a topc that has been discussed at length here.  I might suggest you 
look at www.fpga-faq.com.  I suggest looking at the thread "Searching the 
Archive" started by Philip Freiden.

> I was thinking I would use the write signal to
> clock the data into the Xilinx, and then run it through some logic to
> synchronize it with the Xilinx clock (which will be the same as the
> processor's clock).  The microcontroller has a clock output signal, but I'm
> not sure if the write or read strobes are synced with the clock.  I would
> think the latter would be the preferred approach if the microcontroller's
> read and write strobes are derived from the microcontroller's clock.

I would be very suprised if the read and write strobes were not derived from 
the CPU's clock.  If you have a clock from the CPU that you can connect to
the FPGA, it makes your job really easy . . . you simply sample the control 
signals on a clock edge (rising or falling, depending on the CPU timing.)

The following can detect a risaing edge: You can extend it to falling 
edges if required.

 if (WriteStrobe = '1') and (WriteStrobe_delayed = '0') then

I very much suggest sitting down with the CPU's timing diagram, and figuring 
out how everything relates to the CPU's clock before trying to design  your 
interface.

Regards,
-Kent



Article: 31554
Subject: Re: ORCAD Capture Symbols
From: bob elkind <eteam@aracnet.com>
Date: Tue, 29 May 2001 19:28:27 -0700
Links: << >>  << T >>  << A >>
Chris,

I understand your frustration.  At the same time I cringe at the
thought of entering 100s of pin numbers and names by hand.

I can't speak for version 9.1, but Capture 9.2 certainly solves the problem
you describe.  by selecting the .PIN or the .LCA file (you get to choose
from a variety of design file options), the complete pin
list is available for merging  into the schematic symbol; including power,
dedicated special purpose, and unconnected pins.  it works well.

Bob Elkind
eteam@aracnet.com

Chris Eilbeck wrote:

> In article <3B144CCA.D9CF761F@aracnet.com>, eteam@aracnet.com says...
> > Chris,
> >
> > Could you elaborate on the problem?  Was this a layout program
> > issue, a netlister issue, etc. etc. ?
>
> What I did was a fairly large design for a multipath channel simulator
> which was to be realised using Xilinx XV series devices.  I did all the
> VHDL/simulation/place&route, no problem at all.  Happy with that.  Then I
> tried to use the Generate Part function in Orcad on the EDIF file (which
> I think is what you were suggesting) but of course there's nothing in
> that file which describes any of the power, ground or dedicated pins on
> the device.  So you can use the generated part to draw up a schematic but
> when you generate a netlist from it and try to tie this to a PCB
> footprint you find you have a whole load of pins on the footprint which
> do not have matching entries in the netlist.
>
> At this point I decided it would be easier to just generate the part I
> wanted by hand including all the pins which weren't used explicitly in
> the EDIF.
>
> I hope this explains the problem I found.  Maybe there is a way round it
> or it has been fixed in version 9.2 but seeing as they junked Express in
> this release and I rather liked it I stuck at 9.1.
>
> Chris
> --
> Chris Eilbeck                            mailto:chris@yordas.demon.co.uk


Article: 31555
Subject: Re: Fun with DLLs.
From: Peter Alfke <palfke@earthlink.net>
Date: Wed, 30 May 2001 04:02:08 GMT
Links: << >>  << T >>  << A >>


Kent Orthner wrote:

> Peter,
>
> With this circuit of yours, you can switch between clock nicely, but you can not
> the feed the results into a DLL, can you?  if I understand correctly, the input
> to a DLL must come from a Clock input pin, or another clock?

Kent, I don't think that is a problem, the problem is elsewhere: You should never
feed a sudden jump in frequency into a DLL. It goes crazy and loses lock.
I talked with Austin, and we agreed that you must put two DLLs, one for each clock,
in front of the mux. And you will get a glitch-free output, but of course one with
a gap whenever you switch. The gap is less than one clock period.

I have lost track of what you really want to achieve...

Peter

>
>
> Thanks.
> -Kent


Article: 31556
Subject: Re: FPGA consultant needed
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Wed, 30 May 2001 05:17:25 GMT
Links: << >>  << T >>  << A >>

"Austin Franklin" <austin@dar54kroom.com> wrote in message
news:9eutmp$e97$1@slb6.atl.mindspring.net...

>
> > The legal strategy seems to be mostly about spreading confusion amongst
> the
> > jury.  I gather the trial was something like this:  "Look at the Xilinx.
> It
> > has lookup tables.  Look at the Altera.  What do we see?  Lookup tables!
> > A-ha!"
>
> That is, of course, completely ridiculous.  The "strategy" is to explain
> things to the jury in such a way that they understand it, and can reach a
> fair decision.  I take it you have no first hand knowledge of how cases
like
> this work, or I don't believe you'd be saying this.
>
>
So you are saying that lawyers attempt to present juries unbiased
statistical facts so that they can come to a just, fair, conclusion.  I had
the notion they used subterfuge and emotion to win at all costs.  I must be
very naive about the legal system.



Article: 31557
Subject: Re: Fragen zu PCI und FPGA
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Wed, 30 May 2001 05:32:36 GMT
Links: << >>  << T >>  << A >>
Mario,
Etwas ist nicht klar.  Warum brauchen sie ein FPGA?  Der 9052 hat Lokal-Bus
fuer Lokal-Speicher.  Koennen Sie nicht direkt die SRAM mit dem 9052
anbinden?  Das waere einfacher.  Man braucht viellecht noch eine Processor,
der 9052 zu programmieren.
-Kevin

"T-Online" <Mario.Heike.Niklas@t-online.de> wrote in message
news:3B109F88.356B08B7@t-online.de...
> Wer hat Erfahrung mit der Anbindung eines FPGA auf einem PCI - Board an
> den PCI - Bus. Dazu benutze ich den PLX Baustein PCI 9052. Ich möchte
> einen SRAM, das mit dem FPGA verbunden ist über den PCI -Bus auslesen.
> Wer hat Tipps oder auch Beispielprogramme in VHDL die dieses
> bewerkstelligen. Worauf muss ich beim programmieren des FPGA achten.
>
> Danke
>
> Mario Giffel
>
>



Article: 31558
Subject: Re: Fun with DLLs.
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 30 May 2001 15:00:15 +0900
Links: << >>  << T >>  << A >>

> Kent Orthner wrote:
> > With this circuit of yours, you can switch between clock nicely, but you can not
> > the feed the results into a DLL, can you?  if I understand correctly, the input
> > to a DLL must come from a Clock input pin, or another clock?

Peter Alfke <palfke@earthlink.net> writes:
> Kent, I don't think that is a problem, the problem is elsewhere: You should never
> feed a sudden jump in frequency into a DLL. It goes crazy and loses lock.
> I talked with Austin, and we agreed that you must put two DLLs, one for each clock,
> in front of the mux. And you will get a glitch-free output, but of course one with
> a gap whenever you switch. The gap is less than one clock period.

Okay.  I think I understand all the issues now.  
What I guess I need is a PLL after the switch, not a DLL.  (I'm not sure how a DLL 
works, so I didn't know if it would go crazy with a sudden clock switch or not.)


> I have lost track of what you really want to achieve...

My fault!  I'm primarily interested in clock synchronizing for a redundant 
system, in which case the circuit described in your XCell article is not 
appropriate.  But once I look at the article, I wanted to know the question 
above, even though it isn't applicable to my redundancy problem.

Thanks for the advice!

-Kent


Article: 31559
Subject: Re: Peripheral for Microcontroller
From: "wei yao" <wei@yahoo.com>
Date: Wed, 30 May 2001 06:15:57 GMT
Links: << >>  << T >>  << A >>
I don't know if there is a general rule for your problem; it's very
microcontroller dependent.  In general, It's not a good idea to use
read/write signals as a clock.  You could, however, use the read/write as a
latch enable signals.  I've actually done both ways, i.e., asyn and sync.
As an example, one of the processors I used, The TI 5402 DSP, has read/write
signals that has a timing relationship to the clock from -2ns to +3 ns.  If
you program the peripheral access as zero-wait, the processor will clock in
the data on the rising edge of the read/write, which has only one clock
cycle duration.  Because the DSP was operated at a very slow clock
frequency(20MHz), I was able to use the neg clock edge to sample the RDB/WRB
signals, and present the data(or clock in) the data at the clock rising
edge.  It's very typical synchronous design, and the process is very
straighforward.  The tradeoff is you cannot scale the circuit to a higher
speed, whereas an asyn design usually has more margin in that regard.
However, you need to pay much more attention to the signal glitches.  Just
my 0.02.

Wei

"Greg Cary" <gcary@multifeeder.com> wrote in message
news:UxSQ6.2712$YC5.200296@news.uswest.net...
> I am designing a multi-function peripheral for a microcontroller using a
> Xilinx Spartan II.  I have created an initial design that uses the read
and
> write signals from the microcontroller in an asynchronous fashion. The
VHDL
> compiler warns about using these signals as clocks, so I'm wondering if
this
> is the best design approach.  I was thinking I would use the write signal
to
> clock the data into the Xilinx, and then run it through some logic to
> synchronize it with the Xilinx clock (which will be the same as the
> processor's clock).  The microcontroller has a clock output signal, but
I'm
> not sure if the write or read strobes are synced with the clock.  I would
> think the latter would be the preferred approach if the microcontroller's
> read and write strobes are derived from the microcontroller's clock.
>
> What is the preferred design approach when interfacing with the read and
> write signals of a microcontroller?
>
> Thank you very much,
>
> Greg Cary
>
>
>
>



Article: 31560
Subject: Re: Fragen zu PCI und FPGA
From: T-Online <Mario.Heike.Niklas@t-online.de>
Date: Wed, 30 May 2001 08:19:36 +0200
Links: << >>  << T >>  << A >>
Danke für ihr Interesse !
An dem FPGA ist ein Lasersensorkopf angeschlossen der daten liefert. Diese
Daten werden über das FPGA in das SRAM geschrieben. Dort möchte ich diese Daten
mit den beschriebenen Bausteinen auslesen. Dabei geht es nicht um die Software
die den PCI-Bus ansteuert, sondern nur um das FPGA-Design.

Mario

Kevin Neilson schrieb:

> Mario,
> Etwas ist nicht klar.  Warum brauchen sie ein FPGA?  Der 9052 hat Lokal-Bus
> fuer Lokal-Speicher.  Koennen Sie nicht direkt die SRAM mit dem 9052
> anbinden?  Das waere einfacher.  Man braucht viellecht noch eine Processor,
> der 9052 zu programmieren.
> -Kevin
>
> "T-Online" <Mario.Heike.Niklas@t-online.de> wrote in message
> news:3B109F88.356B08B7@t-online.de...
> > Wer hat Erfahrung mit der Anbindung eines FPGA auf einem PCI - Board an
> > den PCI - Bus. Dazu benutze ich den PLX Baustein PCI 9052. Ich möchte
> > einen SRAM, das mit dem FPGA verbunden ist über den PCI -Bus auslesen.
> > Wer hat Tipps oder auch Beispielprogramme in VHDL die dieses
> > bewerkstelligen. Worauf muss ich beim programmieren des FPGA achten.
> >
> > Danke
> >
> > Mario Giffel
> >
> >


Article: 31561
Subject: Help with vhd
From: "Frederic Darre" <darre@irit.fr>
Date: Wed, 30 May 2001 09:55:45 +0200
Links: << >>  << T >>  << A >>
Hello, I have many files .vhd that I downloaded on the net.
But when I compile them, I can't specifiy in project manager to see all the
files in the same time (cause warning and error).
How to use 5 files in vhdl for one chip (a serial port RS232) if someone
have a prog for this please help me.
Thanks Fred
(excuse my english i am a poor french)



Article: 31562
Subject: Re: Xilinx Installation and Java Errors on Pentium 4
From: Lasse Langwadt Christensen <langwadt@ieee.org>
Date: Wed, 30 May 2001 00:56:36 -0700
Links: << >>  << T >>  << A >>
Shane Tow wrote:
> 
> I am trying to install Xilinx Alliance 3.x Software on a Pentium 4 system.
> During installation I receive a message that states "java.exe has caused
> errors and has been closed ..."  According to the Xilinx website this is due
> to the fact that the Pentium 4 isn't compatible with the Java Runtime
> Environment and that the latest version needs to be downloaded form the Sun
> website.  I did this, and I still get the same error.  Has anyone ran into
> this problem and been able to solve it?  Or does Xilinx have a patch for
> their software?
> 
> Thanks,
> 
> Shane

I done it, as far as I remember it goes something like this; 

-download the new java runtime and install it, 

-copy the entire alliance install CD to the HD

-replace the java runtime in the alliance installation (on the HD)
 with the new one  

-run the alliance installation from the HD


-Lasse
-- Lasse Langwadt Christensen, 
-- PHX,AZ


Article: 31563
Subject: Re: ORCAD Capture Symbols
From: rotemg@mysticom.com (Rotem Gazit)
Date: 30 May 2001 01:04:40 -0700
Links: << >>  << T >>  << A >>
I use the following technique to generate Orcad symbols for large
FPGAs .

1) 
download the device pinout table from
http://www.xilinx.com/products/virtex/ vepackages.htm or
v2packages.htm.
Alternatively you can use:
> partgen -v YOURDEVICE
Don't count on the printed data sheet it sometimes contains errors
(for example I found an error on 405ebg560 data sheet pinout table ).

2)
Read the pinout text file into your favorite spreadsheet SW (I use
Microsoft excel).
You now have to decide how do you want your symbol to look like.
For parts with more than 100 I/Os I suggest to use  "heterogeneous
symbols"  ( It means that you have more than one symbol for  the SAME
device).
I usually use 6 symbols: one for power , one  for configuration and
one for every two I/O banks (including the GCLK and the VCCO ).
You need to arrange the spreadsheet in groups correlated to the number
of symbols you need ( I use "Sort By" -> "bank number" and than by
"pin type").

3) here is the trick:
In Capture select "New Part", Place -> "Pin Array" and draw as many
pins as you need.
Now, select all the pins and than press Ctrl+E. You get a little
spreadsheet  with the pins names and numbers.
select all the spreadsheet and press Ctrl+Insert. Switch to the Excel
and paste the data in an empty sheet.
Copy the real pin names from the Original sheet you created and paste
them instead of the automatic pin names.
Mark the new data , switch back to Capture and press Shift+Insert.
Repeat step  (3)  for each of the heterogeneous symbols.

I used that technique many times on Windows , I don't know if it can
be done in other OS.
It takes no more than 30 min. to create a new Symbol for a > 400 I/O
FPGA .
 


-----------------------------------------------------------------------
Rotem Gazit  
  ***  MystiCom Ltd. ***
mailto:rotemg@mysticom.com      http://www.mysticom.com
-----------------------------------------------------------------------

Article: 31564
Subject: Help: RAM clear in one clock cycle
From: "Huang" <xyhuang@sc.mcel.mot.com>
Date: Wed, 30 May 2001 16:43:50 +0800
Links: << >>  << T >>  << A >>
Hi all,

I just got a design document from system architect, and found something
unusual: A BLOCK of RAM is cleared in one clock cycle.

Can anyone tell me how to implement RAM in FPGA that can be cleared in this
way?

Thanks





Article: 31565
Subject: Re: ORCAD Capture Symbols
From: Chris Eilbeck <chris@yordas.demon.co.uk>
Date: Wed, 30 May 2001 10:48:05 +0100
Links: << >>  << T >>  << A >>
In article <3B145ACB.BA2D780B@aracnet.com>, eteam@aracnet.com says...
> Chris,
> 
> I understand your frustration.  At the same time I cringe at the
> thought of entering 100s of pin numbers and names by hand.
> 
> I can't speak for version 9.1, but Capture 9.2 certainly solves the problem
> you describe.  by selecting the .PIN or the .LCA file (you get to choose
> from a variety of design file options), the complete pin
> list is available for merging  into the schematic symbol; including power,
> dedicated special purpose, and unconnected pins.  it works well.

Thanks for that.  It sounds like I'll need to do some cludge to give me 
Capture and Layout v9.2 and stick with Express v9.1

Chris
-- 
Chris Eilbeck                             mailto:chris@yordas.demon.co.uk

Article: 31566
Subject: Re: Help with vhd
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 30 May 2001 19:00:45 +0900
Links: << >>  << T >>  << A >>
Hi, Frederic.

It sounds to me like you are missing a top level file.  You should have a 
top-level file somewhere that 'instantiates' all the other blocks.  That 
top level will have one set of input & output pins that you can connect 
to the sub-blocks input & outputs any way you feel like.

Hope this helps.
-Kent

"Frederic Darre" <darre@irit.fr> writes:
> Hello, I have many files .vhd that I downloaded on the net.
> But when I compile them, I can't specifiy in project manager to see all the
> files in the same time (cause warning and error).
> How to use 5 files in vhdl for one chip (a serial port RS232) if someone
> have a prog for this please help me.
> Thanks Fred
> (excuse my english i am a poor french)

Article: 31567
Subject: Re: Fun with DLLs.
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Wed, 30 May 2001 20:30:04 +1000
Links: << >>  << T >>  << A >>
Kent Orthner wrote:
> 
> I'm perhaps doing something really dumb, and trying to use an FPGA
> for something it's not meant to do.  But to a guy with a hammer,
> everything looks like a nail, right?
> 
> I'm implementing a redundant system.  On each card, (There's about 6
> cards in a chassis) there will be two nominally 52MHz clock inputs.
> The system controller will select which of the two clocks to use.
> 
> I'm thinking of using an FPGA on each card to perform the clock
> switching.  If I feed the switched clock into a DLL, then I imagine
> that the transition from one clock to the other has to be pretty smooth.
> 
> I imagine the setup as follows (Using Spartan-II):
> 
> Clk0 an Clk1 and Select are input pins, all going to a LUT3, which drives
> ClkSelected.  I can not connect this to a DLL, so I drive it off-chip, and
> then back on-chip, to *then* connect it to a DLL.  The output of the DLL
> then goes outside to the real world where it drives a 'zero delay clock
> buffer', which drives all of the devices on that card.
> 
> I have a couple of questions that hopefully someone can help me with:
> 
> 1. Is this a really stupid way of doing it?  Should I simply forget
> about using a FPGA for this?
> 
> 2. How well do the simulation models of the DLLs in the unisim library
> model the real DLLs?
> 
> 3. If I use the same device in the same package with the same place &
> route for the FPGA on all line cards, what can I expect my worst case
> device-to-device clock skew to be?
> 
> 4. Any other comments or suggestions would be greatly appreciated.
> 
> Thanks in advance.

Hi Kent,

Is that "nominally 52MHz" clock really 51.840MHz?  If it's being used
for SONET/SDH timing, there are all sorts of restrictions regarding the
rate of change of frequency, and the size of phase hits, etc.

Implementing SONET/SDH clock switching is non-trivial.

There are several commercial SETS (umm, Sonet Equipment Timing Source?)
chips that will manage your clock switching for you, e.g.
http://www.semtech.com/products/sets.html
(I know that it is definitely possible to do one in an FPGA with an
external VCXO.)

The requirements (for SDH, at least) are in ITU-T G.707, G.810, 811,
812, etc.

OTOH, if this is not related to network clock switching, my apologies.

Regards,
Allan.

Article: 31568
Subject: Is anybody using FPGAs for scientific computing?
From: "Roberto R. Osorio" <osorior@imec.be>
Date: Wed, 30 May 2001 14:42:56 +0200
Links: << >>  << T >>  << A >>
This is just a question.

Is anybody using FPGAs to execute scientific programs?
Is it possible to find small cores in the programs that can
be mapped onto a FPGA and obtain good speed-up?
Which is the main problem, computing or IO bandwidth?

If you are doing that, which are the results? Which kind
of programs are you focused in: optimization, genetics,
matrix computation, simulation, weather forecast...?

regards




Article: 31569
Subject: Re: Xilinx Installation and Java Errors on Pentium 4
From: "Shane Tow" <shane_tow@yahoo.com>
Date: Wed, 30 May 2001 09:06:00 -0400
Links: << >>  << T >>  << A >>
Thanks for the help.  I found the same answer on the Xilinx website and gave
it a try and it worked.

Now, hopefully my place and route times will be much faster.  What has your
experience with par times been with the Pentium 4?

Thanks,

Shane








Article: 31570
Subject: Re: Fun with DLLs.
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 30 May 2001 07:26:55 -0700
Links: << >>  << T >>  << A >>
Allan,

I second that.

I worked for a company that build BITS clocks for SONET, and the switchover was
not a pretty spec.  You could move less than X ns in y ms, which led to PLL's
with poles at > 0.1 Hz.  This led to really bad short term stability problems
from the PLL having such a terrible and slow response time.

If I had it to do over again, I would use a synthesizer running at 300 MHz to
synthesize the 51.84 MHz (a digital locked loop with the A or B 51.85 as a
reference input to be tracked), and then digitally slew the DDFS synthesizer
from one frequency to the other.  I would then remove the synthesis jitter with
a PLL following.

Austin

Allan Herriman wrote:

> Kent Orthner wrote:
> >
> > I'm perhaps doing something really dumb, and trying to use an FPGA
> > for something it's not meant to do.  But to a guy with a hammer,
> > everything looks like a nail, right?
> >
> > I'm implementing a redundant system.  On each card, (There's about 6
> > cards in a chassis) there will be two nominally 52MHz clock inputs.
> > The system controller will select which of the two clocks to use.
> >
> > I'm thinking of using an FPGA on each card to perform the clock
> > switching.  If I feed the switched clock into a DLL, then I imagine
> > that the transition from one clock to the other has to be pretty smooth.
> >
> > I imagine the setup as follows (Using Spartan-II):
> >
> > Clk0 an Clk1 and Select are input pins, all going to a LUT3, which drives
> > ClkSelected.  I can not connect this to a DLL, so I drive it off-chip, and
> > then back on-chip, to *then* connect it to a DLL.  The output of the DLL
> > then goes outside to the real world where it drives a 'zero delay clock
> > buffer', which drives all of the devices on that card.
> >
> > I have a couple of questions that hopefully someone can help me with:
> >
> > 1. Is this a really stupid way of doing it?  Should I simply forget
> > about using a FPGA for this?
> >
> > 2. How well do the simulation models of the DLLs in the unisim library
> > model the real DLLs?
> >
> > 3. If I use the same device in the same package with the same place &
> > route for the FPGA on all line cards, what can I expect my worst case
> > device-to-device clock skew to be?
> >
> > 4. Any other comments or suggestions would be greatly appreciated.
> >
> > Thanks in advance.
>
> Hi Kent,
>
> Is that "nominally 52MHz" clock really 51.840MHz?  If it's being used
> for SONET/SDH timing, there are all sorts of restrictions regarding the
> rate of change of frequency, and the size of phase hits, etc.
>
> Implementing SONET/SDH clock switching is non-trivial.
>
> There are several commercial SETS (umm, Sonet Equipment Timing Source?)
> chips that will manage your clock switching for you, e.g.
> http://www.semtech.com/products/sets.html
> (I know that it is definitely possible to do one in an FPGA with an
> external VCXO.)
>
> The requirements (for SDH, at least) are in ITU-T G.707, G.810, 811,
> 812, etc.
>
> OTOH, if this is not related to network clock switching, my apologies.
>
> Regards,
> Allan.


Article: 31571
Subject: Re: Spartan2 PCI-IP Core @ power-up
From: "Zimba" <zimba@zamba.com>
Date: Wed, 30 May 2001 16:27:40 +0200
Links: << >>  << T >>  << A >>
> We do this in our FPGA board. As you seem to be german, you can look it
> up:
> http://www.em.informatik.uni-frankfurt.de/~prak/platine/index.html

Two questions:
- Are you using your own PCI core or a Xilinx core?
- Is this board for sale or is it possible to get better readable files of
the schematics and PCB (gerber would be nice) so that I can make my own? It
seems to be exactly what I am looking for in order to develop a W2K driver
for the Spartan II PCI core.

Clemens



Article: 31572
Subject: Re: Help: RAM clear in one clock cycle
From: Ray Andraka <ray@andraka.com>
Date: Wed, 30 May 2001 14:40:34 GMT
Links: << >>  << T >>  << A >>
I hope it is a small block.  You'll have to implement the RAM as an array of
flip-flops to get the single cycle clear.  The block RAMs and CLB RAMs do not
have a clear input, so they cannot be cleared in a single cycle.  If the access
is in a known pattern however, you can fake it by gating the read data until the
RAM has been re-written.

Huang wrote:
> 
> Hi all,
> 
> I just got a design document from system architect, and found something
> unusual: A BLOCK of RAM is cleared in one clock cycle.
> 
> Can anyone tell me how to implement RAM in FPGA that can be cleared in this
> way?
> 
> Thanks

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com

Article: 31573
Subject: Re: Is anybody using FPGAs for scientific computing?
From: Kolja Sulimma <kolja@sulimma.de>
Date: Wed, 30 May 2001 16:59:37 +0200
Links: << >>  << T >>  << A >>
> Is anybody using FPGAs to execute scientific programs?

Yes

> Is it possible to find small cores in the programs that can
> be mapped onto a FPGA and obtain good speed-up?
> Which is the main problem, computing or IO bandwidth?

The EXTERNAL bandwidth of an FPGA is not much higher than that of a
processor.
Therefore, you will only see very large performance gains for algorithms
that have a rather low IO requirement.
On the otherhand, the internal bandwidth of an FPGA can be extreme. For
example in my diploma thesis I used a shallow  stack that could accept
3000 Bits in a single clock cycle.

The main problem is tools. Many applications can be implemented with
very high performance in an FPGA if you have a good engineer. The
difference between a good and a bad design are bigger in hardware than
in software. Also, with bad designers you are more likely to fail
completely in hardware design than in software.

> If you are doing that, which are the results? Which kind
> of programs are you focused in: optimization, genetics,
> matrix computation, simulation, weather forecast...?

You would like to have algorithms that parallelize well into so called
systolic structures, this means that each computing element only
comunicates with a constant amount of neighbours. This is often the case
for dynamic programming algorithms.
Compared to a processor, you are going to look better for tasks that do
not map well to the large word width of processors. (DNA Matching for
example works on 4-Bit data, fault simulation on 2-Bit data)
Also, bit oriented operations that do not map well to the CPUs
instruction set will do fine. (cryptography)
Also SIMD algorithms are good, but there is other hardware for this
(vector computers, thinking machines, ...)

Andre Dehon did a quantitative analysis of this in his PhD thesis:
http://www.cs.caltech.edu/~andre/

You actually can buy FPGA based computers that are more than a factor of
1000 faster than CPU implementations for the following tasks:
- DNA sequence matching (Smith-Waterman-Algorithm)
- fault simulation (test pattern generation)
- network packet switching
- decryption/encryption of DES, Rijndal, ...
- computer vision

For everything that involves large data words or floating point
computations, the results will not be as extreme.

Some pointers are in Andre's thesis. A list of hardware used for this is
here:
http://www.io.com/~guccione/HW_list.html

Kolja Sulimma





Article: 31574
Subject: Re: Fragen zu PCI und FPGA
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Wed, 30 May 2001 16:11:35 GMT
Links: << >>  << T >>  << A >>
Alles klar.  Am einfachsten is ein dual-port SRAM zu benutzen.  An dieser
Weise darf die FPGA die Daten an einer Seite (Port) das dual-port SRAM
liefern.  Die andere Seite (Port) des SRAMs waere direkt mit 9052
angeschlossen.  Es ist also nicht noetig, ein kompliziert Anschluss zwischen
FPGA und 9052 machen.  Diese dual-port SRAM darf ausserlich sein, oder
besser, wenn sie nicht so viel SRAM brauchen, durfen Sie z.B. Xilinx
blockRAM benutzen.

-Kevin

"T-Online" <Mario.Heike.Niklas@t-online.de> wrote in message
news:3B1490F8.8E645D42@t-online.de...
> Danke für ihr Interesse !
> An dem FPGA ist ein Lasersensorkopf angeschlossen der daten liefert. Diese
> Daten werden über das FPGA in das SRAM geschrieben. Dort möchte ich diese
Daten
> mit den beschriebenen Bausteinen auslesen. Dabei geht es nicht um die
Software
> die den PCI-Bus ansteuert, sondern nur um das FPGA-Design.
>
> Mario
>
> Kevin Neilson schrieb:
>
> > Mario,
> > Etwas ist nicht klar.  Warum brauchen sie ein FPGA?  Der 9052 hat
Lokal-Bus
> > fuer Lokal-Speicher.  Koennen Sie nicht direkt die SRAM mit dem 9052
> > anbinden?  Das waere einfacher.  Man braucht viellecht noch eine
Processor,
> > der 9052 zu programmieren.
> > -Kevin
> >
> > "T-Online" <Mario.Heike.Niklas@t-online.de> wrote in message
> > news:3B109F88.356B08B7@t-online.de...
> > > Wer hat Erfahrung mit der Anbindung eines FPGA auf einem PCI - Board
an
> > > den PCI - Bus. Dazu benutze ich den PLX Baustein PCI 9052. Ich möchte
> > > einen SRAM, das mit dem FPGA verbunden ist über den PCI -Bus auslesen.
> > > Wer hat Tipps oder auch Beispielprogramme in VHDL die dieses
> > > bewerkstelligen. Worauf muss ich beim programmieren des FPGA achten.
> > >
> > > Danke
> > >
> > > Mario Giffel
> > >
> > >
>
>





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