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 36000

Article: 36000
Subject: Re: S/PDIF interface for FPGA
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 25 Oct 2001 14:12:41 -0700
Links: << >>  << T >>  << A >>
Andy Peters <andy@exponentmedia.deletethis.com> writes:
> Do yourself a favor, and don't directly use the Crystal
> MCLK/LRCLK/BCLK/data outputs to drive a converter.  Use a FIFO in
> between, and generate your clocks locally.  You'll cut the jitter down.

I wrote:
> And potentially introduce slips, since your sample rate may not match
> the source.  :-(

Andy Peters <andy@exponentmedia.deletethis.com> writes:
> No, you clock your incoming data into a FIFO, and you have a
> local-generated clock on the read side that runs at the same frequency
> as the recovered clock, but it's from an oscillator and not a PLL, so
> the hope is that the jitter on the clock feeding your DAC (the only
> place you really need to worry about jitter) should be lower.

Oh.  When you said "generate your clocks locally", I thought you meant
a local oscillator completely asynchronous to the incoming data stream.

Now a stupid question:

Assuming that the incoming AES data stream is from a source with reasonable
timing (i.e., crystal locked), why is generating a local clock with a PLL
expected to have better jitter performance than the clock recovered from the
AES stream?  For instance, a CD player already times its output based on
a crystal clock, by using a FIFO between the CD demodulator/decoder and
the DAC & digital outputs.  They servo the spindle motor speed to the
FIFO depth, so with a reasonable FIFO size the motor speed control doesn't
have to be extremely precise.  Why would there be much more jitter in the
digital output than you have if you used a PLL and FIFO to reclock the
data at the receiving end?



Article: 36001
Subject: Re: GAL compiler
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 26 Oct 2001 10:19:24 +1300
Links: << >>  << T >>  << A >>
Bertram Geiger wrote:
> 
> > could anybody say me where to find a simple free GAL (especially 16V8)
> > compiler for MS-DOS?
> >
> search for "easyAbel", might be its still somewhere around on the web or
> ask on the university
> Its simple and works fine up to 22v10

 Looking into this, has good news 
There is a DOS c 1992 Abel, also called Ez-ABEL.
it supports a ABEL subset, relevent today are 16V8/20V8/22V10

and bad news..

It gags on some newer ABEL files, seems it is a subset ABEL
( not surprising c 1992 :)

It could still have uses, BUT the .PLA output files, from AHDL2PLA.EXE,
are encrypted.

If it could create readable PLA files, it could have a place in the tool
box.

Anyone know about getting usable PLA files, from this tool chain ?

-jg

Article: 36002
Subject: Re: GAL compiler
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 26 Oct 2001 10:24:06 +1300
Links: << >>  << T >>  << A >>
Gunther May wrote:
> 
> Hello,
> 
> could anybody say me where to find a simple free GAL (especially 16V8)
> compiler for MS-DOS?
> 
> Thank you in forward,
> Gunther May

 The ATMEL WinCUPL, has the CUPL engine in the /shared directory, and
that runs from the DOS prompt / command line.
 This supports 16V8/20V8/22V10/750 and 150x via .PLA and fitters.

 I think it's 32 bit, so an ancient DOS may have problems?

-jg

Article: 36003
Subject: Probing BGA Designs
From: donald.stauffer@kodak.com (Don Stauffer)
Date: 25 Oct 2001 14:46:55 -0700
Links: << >>  << T >>  << A >>
Does anyone have experience debugging FPGA designs in BGA packages at
the board-level? Since there are no pins, what have people found that
works? Any ideas are greatly appreciated, including advice on DFT at
the board level (unused I/O routed to test pins, SignalTap/ChipScope,
etc.).

Thanks,
Don

Article: 36004
Subject: FCCM02 Call for Papers
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 25 Oct 2001 22:32:09 GMT
Links: << >>  << T >>  << A >>

		   C A L L    F O R    P A P E R S

			   THE TENTH ANNUAL
		 IEEE SYMPOSIUM ON FIELD PROGRAMMABLE
		      CUSTOM COMPUTING MACHINES
		       Napa Valley, California
		      April 21 - April 24, 2002

			 http://www.fccm.org


Note the return to Napa Valley!  For details, please visit our web site.


PURPOSE: To bring together researchers to present recent work in the
use of reconfigurable logic as computing elements.  This symposium
will focus primarily on the current opportunities and problems in this
new and evolving technology for computing.  Contributions are
solicited on all aspects of custom computing, including but not
limited to:

Architecture of reconfigurable computing devices and systems,
including coprocessors, attached processors, reconfigurable
systems-on-chip and hybrids.

Languages, compilation techniques, tools, and environments for
programming and run time support;

Applications of reconfigurable computing, including the use of
reprogrammable logic in mobile communications, network infrastructure
and other embedded systems;

Implications of nanotechnology and reconfigurable computing on
one another, possible forms, system implications;

Novel use of reconfigurability, including evolvable hardware;

Prototyping for system modeling and architecture emulation.

SUBMISSIONS: FCCM has a tradition of presenting both full length
papers and high quality posters.  Authors are invited to send
submissions for either full length papers (10 page maximum) or
extended abstracts (2 page maximum) for posters by January 11, 2002,
to Jeffrey Arnold.  Please indicate whether you seek consideration as
a full paper or as a poster.  Notification of acceptance will be sent
by the beginning of March.  Final papers and poster abstracts will be
due on the first day of the Symposium.  The proceedings will be
published following the Symposium.

Authors are encouraged to submit PDF or Postscript manuscripts by FTP.
Format and submission instructions are available on the FCCM web page
(www.fccm.org), or authors can contact Jeffrey Arnold (jmarnold@znet.com).

Authors are also encouraged to bring demonstrations of their work.
Space will be made available during the demo event to be held
Monday, April 22.  Details will be available on the web page.

SPONSORSHIP: The IEEE Computer Society and the Technical Committee on
Computer Architecture.

CO-CHAIRS:
Kenneth L. Pocek
Intel
Mail Stop RN6-18
2200 Mission College Boulevard
Santa Clara, California  95052
Voice: 408-765-6705  Fax: 408-765-5165
kenneth.pocek@intel.com

Jeffrey M. Arnold
Adaptive Silicon, Inc.
985 University Ave., Suite 31
Los Gatos, CA 95032
Voice: 408-335-2712  Fax: 408-899-8905
jarnold@adaptivesilicon.com


PROGRAM COMMITTEE:
Peter Athanas, Virginia Tech.
Donald Bouldin, University of Tennessee, Knoxville
Duncan Buell, University of South Carolina
Michael Butts, Cadence
Steve Casselman, Virtual Computer Corp.
Andre DeHon, California Institute of Technology
Apostolos Dollas,  Technical Univ. of Crete		
Philip Friedin, Fliptronics
Scott Hauck, University of Washington
Brad Hutchings, Brigham Young Univ.
Tom Kean, Algotronix, Ltd.
Phil Kuekes, HP Labs.
Philip Leong, Chinese University of Hong Kong
Wayne Luk, Imperial College
John McHenry, NSA
Robert Parker, Institute for Information Sciences
Viktor Prasanna, University of Southern California
Herman Schmit, Carnegie Mellon University
Mark Shand, Compaq System Research Center
Satnam Singh, Xilinx
Stephen Smith, QuickSilver Technology
Roger Woods, The Queen's University of Belfast




Article: 36005
Subject: Re: 2/3 trellis code in vhdl
From: Bob Cain <arcane@znet.com>
Date: Thu, 25 Oct 2001 16:42:26 -0700
Links: << >>  << T >>  << A >>


This is too much of a coincidence.  I have two new topics in my
newsreader, one immediately after the other, both beginning with 2/3 and
totally unrelated to each other.  They say anything will happen
eventually but today?


Bob
-- 

"Things should be described as simply as possible, but no simpler."

                                             A. Einstein


////////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

 To contribute your unused processor cycles to the fight against cancer:

     http://www.intel.com/cure

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////////

Article: 36006
Subject: Re: LUT Glitches
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 25 Oct 2001 23:47:10 GMT
Links: << >>  << T >>  << A >>
Andy Peters <andy@exponentmedia.deletethis.com> writes:

>glen herrmannsfeldt wrote:
>> 
>> The original question asked about asynchronous logic, which doesn't
>> have a metastability problem.  Asynchronous logic, also called self
>> timed logic, runs as fast as gates can change.  Look up self-timed
>> logic somewhere.

>OK, so you've traded potential metastability in synchronous logic for
>potential race conditions in asynchronous logic.

>pick yr poison.

I thought self-timed logic didn't have a race condition problem.

Note that 'asynchronous logic' can have other meanings, including
ones that have race conditions, so I prefer the term
'self-timed logic.'   I believe that self-timed logic can't have
race conditions.  

As previously stated, though, it is sensitive to glitches.  
If a gate input changes, but the gate output is independent
of that change, the gate output should not glitch.

An FPGA lookup table representing a gate with more than two inputs,
does not necessarily have this property.  

I will try a simple description of self-timed logic, as it
was explained to me about twenty years ago, and someone
can correct it if I am too far off.  Each signal has three states,
normally represented with two wires.  The third state is the
indeterminate state, when the final value isn't yet known.  
It only goes to the final state when the final value is known, so
no race conditions.  Hysteresis is applied in the right place to
eliminate race conditions, such that each signal must go through
the indeterminate state before it can go to the final state.

The result is that without a clock, and without race conditions,
each output gets to its final value as fast as the signals can
propagate through the logic.  If a flip-flop goes metastable the
rest of the logic waits until it goes to a stable state.

A web search came up with:

http://www.theseus.com/PDF/japan_paper.pdf

which seems to have a reasonable description.

-- glen

Article: 36007
Subject: Re: transferring data between related clocks
From: Hamish Moffatt <hamish_moffatt@agilent.com>
Date: Fri, 26 Oct 2001 10:08:39 +1000
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> YOu can buy a little more margin by synthesizing a 175 MHz clock enable
> in the 350 MHz clock domain, then using that to effectively sample the
> 175 MHz data in the middle of the sample.  The synthesized clock enable
> has to be synchronized to your 175 MHz clock, obviously.  To do that,
> sample your 175 MHz clock with the falling edge of the 350 MHz clock,
> then retime that to the rising edge.  These 2 flip-flops should be
> floorplanned so that the delay between them does not exceed your allowed
> time.  This is a variation on what you are doing in alternative #2,
> except here you have only one signal with the really tight timing.
> 
> Another consideration is to either not use single ended I/O on the same
> IO Bank as the clock.  Single ended I/Os on the same bank seem to add a
> considerable amount of jitter to the internal clock because of the I/O
> rail fluctuations, especially for outputs.
> 
> hamish@cloud.net.au wrote:
> > 3. Generate an enable signal at 175 MHz and sample it using
> >    the falling edge of the 350 MHz. Same problem as #2,
> >    but with only 1-2 bits. I did try this, with hand placement
> >    of the FFs, and got the delay down to 1.41 ns, which is
> >    impressive (effectively over 700 MHz performance), but
> >    probably not enough. Using the enable signal, the data
> >    bits have a full 350 MHz period of setup and hold (less skew).


Thanks for the suggestion. Actually, this is what I had tried in
suggestion #3 (which I quoted above). It's my preferred solution,
but the best I could do with hand-placement was 1.41 ns from
rising(175) to falling(350) to rising(350), and after adding
jitter, probably doesn't make 350.



cheers,
Hamish
-- 
Hamish Moffatt                   Email: hamish_moffatt@agilent.com
R&D Engineer,                    Phone: +61 3 9210 5782 (T210-5782)
Advanced Networks Division       Fax:   +61 3 9210 5550
Agilent Technologies             Web:	http://www.agilent.com/

Article: 36008
Subject: DSP on FPGA Opinions Needed->Earn $100
From: Dave Millman <dsp@tactics.com>
Date: Thu, 25 Oct 2001 17:32:25 -0700
Links: << >>  << T >>  << A >>
An EDA company is researching user's requirements for implementing DSP
on FPGAs. If you have completed a signal processing design on FPGAs, or
are now working on one, we'll pay you $100 to participate in a telephone
interview.

During the interview, we will ask you to discuss:

   * How many DSP on FPGA designs you have done
   * Why you chose to use FPGAs instead of standard DSP chips
   * What tools are you using and how well they are working
   * How current tools could be improved

If you are interested, send an email to dsp@tactics.com with this
information:

   * Your name
   * The phone number to reach you
   * The best time to reach you at that phone number

If you have any questions, please feel free to send them to the same
address. PLEASE DO NOT RESPOND ON THE NEWS GROUP!

In return for your time and opinions, we will send $100 to all
participants who complete the interview. We are an engineering market
research firm that has been retained by an EDA company to help them
develop new tools. Your opinions will be delivered straight to the team
developing the new product. In the end, the result will be better tools
that work the way you want them to.

Thank you for your time.


Article: 36009
Subject: Xilinx XST vs FPGA Express?
From: David Rogoff <david@therogoffs.com>
Date: 25 Oct 2001 18:51:48 -0700
Links: << >>  << T >>  << A >>

Need some opinions:

I've been using ISE3.1/FPGA Express on a PC.  I'm about to upgraded to
ISE4.1 but I'm not sure which way to go.  There is a Solaris version,
which would be great in many ways, but there is no FPGA Express for
Unix, only XST.  So, I'd like information on the performance of XST
compared to FPGA Express.

Thanks,

 David

Article: 36010
Subject: Re: DSP on FPGA Opinions Needed->Earn $100
From: Ray Andraka <ray@andraka.com>
Date: Fri, 26 Oct 2001 02:45:40 GMT
Links: << >>  << T >>  << A >>
And how long is the inteview.  If it is an all day thing (extreme example, I
know) it is hardly worth the stipend you are offering.

Dave Millman wrote:

> An EDA company is researching user's requirements for implementing DSP
> on FPGAs. If you have completed a signal processing design on FPGAs, or
> are now working on one, we'll pay you $100 to participate in a telephone
> interview.
>
> During the interview, we will ask you to discuss:
>
>    * How many DSP on FPGA designs you have done
>    * Why you chose to use FPGAs instead of standard DSP chips
>    * What tools are you using and how well they are working
>    * How current tools could be improved
>
> If you are interested, send an email to dsp@tactics.com with this
> information:
>
>    * Your name
>    * The phone number to reach you
>    * The best time to reach you at that phone number
>
> If you have any questions, please feel free to send them to the same
> address. PLEASE DO NOT RESPOND ON THE NEWS GROUP!
>
> In return for your time and opinions, we will send $100 to all
> participants who complete the interview. We are an engineering market
> research firm that has been retained by an EDA company to help them
> develop new tools. Your opinions will be delivered straight to the team
> developing the new product. In the end, the result will be better tools
> that work the way you want them to.
>
> Thank you for your time.

--
--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: 36011
Subject: Re: LUT Glitches
From: Bob Perlman <bob@cambriandesign.com>
Date: Fri, 26 Oct 2001 05:08:22 GMT
Links: << >>  << T >>  << A >>
Hi - 

On 24 Oct 2001 02:18:47 GMT, gah@ugcs.caltech.edu (glen
herrmannsfeldt) wrote:

>Bob Perlman <bob@cambriandesign.com> writes:
>
>>You can build glitch filters with tapped delay lines and majority
>>detection logic, but with an important caveat.  These filters will
>>eliminate pulses shorter than X ns and pass pulses longer than Y ns,
>>but X and Y aren't the same number.  In between X and Y, the circuit
>>can misbehave; there's a range of pulse durations that can produce
>>glitches at the output of the filter.  
>
>>If there were such a thing as a perfect glitch filter, we could build
>>a metastable-proof flip-flop by filtering out runt pulses.  Were it
>>that it were.
>
>The original question asked about asynchronous logic, which doesn't
>have a metastability problem.  Asynchronous logic, also called self
>timed logic, runs as fast as gates can change.  Look up self-timed
>logic somewhere.

I wasn't responding to the original question (this is Usenet, after
all), but to the comment about building glitch filters from tapped
delay lines.  Nor was I claiming that self-timed logic was inherently
susceptible to metastability.

What do I think of self-timed logic?  Read this:

http://www.isdmag.com/editorial/2000/feedback0007.html

Bob Perlman

Article: 36012
Subject: Using xsvf file configures Xilinx FPGA
From: "ggang1" <ggang1@hitel.net>
Date: Fri, 26 Oct 2001 14:50:42 +0900
Links: << >>  << T >>  << A >>
Hi...
Device   : XCV400E
Purpose: Xlinix In-system programming using an embedded micom...

I am in trouble..so I have some question.
I make a XSVF file from SVF file according to APPLICATION NOTE.
but XSVF file format doesn't use a program source.
Program source is described by ARRAY.
for example...
-------------------------
 example ------------------------------------------------
const unsigned char dataFpga[] = {
255,255, 98,125,
22,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,2
55,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,2
55,255,255,255,255,
  0,  0,  6, 34,  0,  0,  0, 98,  0, 34,  4,  0,  0,  0,  4, 98,  0, 34,  4,
0,  0,  0,  0, 98,  0, 98,  0,  0,  0,  0,  0,  0,  4,  0,  0,  0,  0,  0,
0, 34,  0,  0,  0,  0,  0,  0,252,
  0,  0,  0, 64,  0,  0,  0,  0,  0, 64,  2,  0,  0,  0,  2,  0,  0, 64,  2,
0,  0,  0,  0, 64,  0, 64,  0,  0,  0,  0,  0,  0,  2,  0,  0,  0,  2,  0,
0, 64,  0,  0,  0,  0,  0,  0,152,
  0,  0,  0,  0,  2, 64,  0,  0,  2,  0,  0, 64,  0, 64,  0,  0,  2,  0,  0,
64,  0, 64,  2,  0,  2,  0,  2,  0,  2, 64,  2, 64,  0,  0,  2, 64,  2,  0,
2,  0,  2, 64,  2, 64,  0,  0,252,
  0,  0,  2, 66,  2, 64,  2, 64,  2, 64,  2, 66,
}
----------------------------------------------------------------------------
---------
I wanna that format.
I have used the MAX+ tool supporting that funtionality.
you know? How do I get the data?

APPLICATION NOTE say to me that most embedded processor development system
software automatically converts included binary files to the appropriate
format.
but Tornado(VxWorks)system including even ElftoHex funtionality doesn't have
that.

plz...help me...



Article: 36013
Subject: Re: transferring data between related clocks
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Fri, 26 Oct 2001 05:51:10 GMT
Links: << >>  << T >>  << A >>
On Thu, 25 Oct 2001 11:41:05 -0700, Austin Lesea
<austin.lesea@xilinx.com> wrote:

>Continuing,
>
>The max skew in a 2V6000 is 200 ps, but as Peter points out, smaller devices have
>smaller skew in relation to their size.  A 2V1000 is ~ .4 times less skew (~85 ps)
>One can guess at the dimension ratio by examining the X by Y size of the CLB's
>(96x88 vs 40x32, or .41 times less skew).

Hi Austin,

Is this skew between different loads on a single BUFG, or is that skew
between different BUFGs?

Is there any guaranteed value for skew between different BUFGs, given
that those BUFGs are driven from the same DCM?

Thanks,
Allan.


>Actual measurements confirms these values, but we tend to use the largest value in
>the data sheet, rather than specify eveything per device.  The per device
>information is reserved for the speeds files when appropriate.
>
>In Virtex II we actually turn off parts of the clock tree that are unused, so there
>is a major power savings if the 350 MHz clock tree is constrained to a local area
>(perhaps using RLOC's).  If all CLB's and IOB's can be localized, the power savings
>is quite real.  If everything must run at 350 MHz, you better invest in a serious
>heatsinking solution!
>
>Use of clock enable saves less power, as everything is switching right up, and
>including logic, into the heart of the CLB.
>
>Austin
>
>Peter Alfke wrote:
>
>> Here are some thoughts:
>>
>> hamish@cloud.net.au wrote:
>>
>> > In a design I'm working on at the moment, I have new data on every
>> > rising edge of a 175 MHz clock and I need to transfer it to
>> > be synchronous to a 350 MHz clock. No uncertainty in the
>> > 350 MHz data is acceptable.
>> >
>> > To generate the clocks, I have an external 350 MHz source,
>> > and I'm using the CLK0 and CLKDV (divided by 2) outputs on
>> > a DCM. I'm using a Xilinx 2V6000-5.
>> >
>> > I have global buffers for each clock, but I expect there
>> > will be some skew between the clocks, since the 350 MHz
>> > clock is lightly loaded (200-300 FFs), compared to the
>> > 175 MHz clock (2500 FFs). So I might violate the hold
>> > time on the 350 MHz FFs if I'm not careful.
>>
>> I think the loading ( if it has any effect at all  ) would help you: It would
>> move the 175 MHz data a little later. When the source clock is late and the
>> receive clock is early, you avoid all hold time issues, but you lose
>> performance.  So, no hold-time issues here.
>>
>> I would run everything off the 350 MHz clock and generate a 175 MHz clock enable
>> off that clock, and use it for the "175 MHz" portion.
>> Global clock distribution skew has always been good, but is very good in
>> Virtex2. Count on less than 200 ps, perhaps even less than 100 ps.
>>
>> One obvious drawback to this suggestion of using 350 MHz clock for the many
>> slower places, is increased power consumption.
>>
>> Peter Alfke
>>
>> >
>> >
>


Article: 36014
Subject: Re: Recommend a book
From: #BASUKI ENDAH PRIYANTO# <PH892987@ntu.edu.sg>
Date: Fri, 26 Oct 2001 14:18:12 +0800
Links: << >>  << T >>  << A >>
Hi,

From my experience, this book is very useful especially if eventually,
you will use Xilinx FPGA.

Introductory VHDL from Simulation to Synthesis
by
Sudhakar Yalamanchili.

Best regards,

Basuki E. Priyanto

E-mail: basuki@ieee.org
ICQ: 79534411
________________________________________________
Don't judge the book from the cover


:-----Original Message-----
:From: Srinivasan Venkataramanan 
:[mailto:srinivasan@siliconsystems.co.in]
:Posted At: Thursday, 25 October, 2001 6:09 PM
:Posted To: fpga
:Conversation: Recommend a book
:Subject: Re: Recommend a book
:
:
:Hi Adrian,
:        Try:
:
:Vhdl for Programmable Logic
:by Kevin Skahill,
:
:ISBN: 0805895736
:
:It is a great book for beginners in VHDL and has couple of chapters on
:Programmable logic (which to be honest I skipped as I am in ASIC
:domain).
:
:HTH,
:Srinivasan
:
:--
:Srinivasan Venkataramanan
:ASIC Design Engineer
:Software & Silicon Systems India Pvt. Ltd. (An Intel company)
:Bangalore, India, Visit: http://www.simputer.org)
:
:
:"Noddy" <g9731642@campus.ru.ac.za> wrote in message
:news:1003995752.528025@turtle.ru.ac.za...
:> Hi,
:>
:> Could anyone give any advice as to which book to get to learn about
:> programming FPGA's. I have Ashenden's 'The Designer's Guide to
:VHDL'. This
:> is good for learning VHDL, but isn't very instructive as to
:programming
:> FPGA's with VHDL. I have been designing only with schematics as it
:is more
:> intuitive than VHDL if you don't have much reference material.
:>
:> Thanks
:>
:> Adrian
:>
:>
:>
:
:


Article: 36015
Subject: Re: S/PDIF interface for FPGA
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Fri, 26 Oct 2001 06:39:03 GMT
Links: << >>  << T >>  << A >>
On 25 Oct 2001 14:12:41 -0700, Eric Smith
<eric-no-spam-for-me@brouhaha.com> wrote:

>Andy Peters <andy@exponentmedia.deletethis.com> writes:
>> Do yourself a favor, and don't directly use the Crystal
>> MCLK/LRCLK/BCLK/data outputs to drive a converter.  Use a FIFO in
>> between, and generate your clocks locally.  You'll cut the jitter down.
>
>I wrote:
>> And potentially introduce slips, since your sample rate may not match
>> the source.  :-(
>
>Andy Peters <andy@exponentmedia.deletethis.com> writes:
>> No, you clock your incoming data into a FIFO, and you have a
>> local-generated clock on the read side that runs at the same frequency
>> as the recovered clock, but it's from an oscillator and not a PLL, so
>> the hope is that the jitter on the clock feeding your DAC (the only
>> place you really need to worry about jitter) should be lower.
>
>Oh.  When you said "generate your clocks locally", I thought you meant
>a local oscillator completely asynchronous to the incoming data stream.
>
>Now a stupid question:
>
>Assuming that the incoming AES data stream is from a source with reasonable
>timing (i.e., crystal locked), why is generating a local clock with a PLL
>expected to have better jitter performance than the clock recovered from the
>AES stream?  For instance, a CD player already times its output based on
>a crystal clock, by using a FIFO between the CD demodulator/decoder and
>the DAC & digital outputs.  They servo the spindle motor speed to the
>FIFO depth, so with a reasonable FIFO size the motor speed control doesn't
>have to be extremely precise.  Why would there be much more jitter in the
>digital output than you have if you used a PLL and FIFO to reclock the
>data at the receiving end?

If we have a signal that has come from a clean clock, and it's already
been through 1 PLL, why will adding another PLL make it better?

The jitter / phase noise at the output of a PLL has two components.
1.  There is intrinsic jitter.  This is the jitter at the output that
is present even when there is no input jitter.  This will come mostly
from the VCO.  The feedback in the PLL will tend to suppress this
jitter, but only within the loop bandwidth of the PLL.  The PLL acts
as a high pass filter for this jitter.

2.  There is jitter transfer.  This is the transfer function from
jitter at the input to jitter at the output of a PLL.  This will
usually be approximately a 2nd order low pass filter response, with
the cutoff freq at the PLL loop bandwidth.
There's a zero as well, so it might approximate a 1st order lowpass
over some of its (jitter) frequency range.


Consider the clock recovery in the S/PDIF rx chip.  (I guess) this
will have an on-chip PLL using a ring osc or perhaps a DLL.  These
aren't particularly low noise devices.  The loop bw will be fairly
wide so that it can lock quickly and track incoming jitter.
So the clock at the output of the rx chip can be expected to have some
jitter on it, because (1) it's inherently noisy (because of the type
of oscillator), and (2) it doesn't do much to suppress that noise
(because of the wide loop bw).

Consider the second PLL, the one we're putting on the output of the
FIFO.  It can use a VCXO as the oscillator.  These can be made with
incredibly low jitter (although you have to pay a lot for the really
low noise ones).  You can also make the loop bandwidth of this PLL
(almost) arbitrarily low, so that the intrinsic jitter at the output
is basically the same as the open loop VCXO jitter, and the jitter
from the input clock is suppressed (at frequencies higher than the
loop bw).

I have to say that I've never built an S/PDIF interface, but I have
designed a few ISDN and SONET/SDH interfaces.  The jitter behaviour is
much the same, even if the numbers are a bit different.

Regards,
Allan.

Article: 36016
Subject: Re: Xilinx XST vs FPGA Express?
From: "Tobias Stumber" <tobias.stumber@de.bosch.com>
Date: Fri, 26 Oct 2001 09:09:45 +0200
Links: << >>  << T >>  << A >>
"David Rogoff" <david@therogoffs.com> schrieb im Newsbeitrag
news:3d47gocr.fsf@therogoffs.com...
>
> Need some opinions:
>
> I've been using ISE3.1/FPGA Express on a PC.  I'm about to upgraded to
> ISE4.1 but I'm not sure which way to go.  There is a Solaris version,
> which would be great in many ways, but there is no FPGA Express for
> Unix, only XST.  So, I'd like information on the performance of XST
> compared to FPGA Express.

I used FPGA Express and Alliance3.1i on PC. I now did all my designs with
FPGA Express 3.6.1 and ISE4.1i AND with XST and ISE4.1i.
The XST synthesis maps better to xilinx technology and one design used
"only" 66% LUTs instead of 81% with FPGA Express. The timing performance
is the same. (In all cases my constraints were met. I can not tell you how
the
max. reachable frequency differs.)
Design using the Xilinx PCI core with XST synthesis are very tricky since
this
flow is not officially supported by xilinx. But it's possible.
Be aware that the XST synthesis has problems with tri-state IO buffers that
are
inferred in a hierarchical submodule. You have to allow XST to flatten the
design
to get error-free results.
But ... it's free and it's good !!

Tobias



Article: 36017
Subject: Re: Cheap programming of XC2018?
From: Peter Heitzer <hep09515@rrzs42.uni-regensburg.de>
Date: 26 Oct 2001 07:18:39 GMT
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote:
> I know of no source for the old sw.  You might find someone with a used copy,
> but you'll have to make sure you get the dongle, and a valid license file.
Dongle does not sound good. I don't want to spend a lot of time for
looking for somebody with an old sw with dongle. 


Article: 36018
Subject: WinXP Pro and Xilinx Foundation 3.3.8
From: "Simon Leung" <leungks@remove_this_word.csee.uq.edu.au>
Date: Fri, 26 Oct 2001 17:22:35 +1000
Links: << >>  << T >>  << A >>
Hello,

I've installed Xilinx Foundation v3.3.8 on Windows XP (as an experiment).  I
installed V3.1 first and then apply the Service Pack 8.

If I install the MultiLNX cable support, Windows XP will boot up with a blue
screen of error, and must be boot to "last known good configuration".
(WinXP crashes at boot up - A problem  has been detected and Windows has
been shut down to prevent  damage to your computer. ... Technical
information: *** STOP: 0x0000007E (0xc0000005, 0xF78A8CB5,  0xF7AFB8C0,
0xF7AFB5C0).)

If I install with only the parallel port support without MulitLNX, there is
no problem.

Are there anyone else with similar experience?

Regards,

Simon Leung
The University of Queensland, Australia.



Article: 36019
Subject: Re: S/PDIF interface for FPGA
From: Robert Staven <robertst.stopthespam@tihlde.org>
Date: Fri, 26 Oct 2001 09:58:47 +0200
Links: << >>  << T >>  << A >>
> the hope is that the jitter on the clock feeding your DAC (the only
> place you really need to worry about jitter) should be lower.

I don't feed the signal to a DAC :-)
It's going to a noiseshaper and then a PWM.
(And a 'swiching' poweramp after that, so the audio
stays 'digital' until a LP in front of the speaker)

The jitter thing is kinda 'religiously' theme for some audio people.
But for me, it's ok as long the jitter (to the 'DAC') stays withing
(the equal to) 1/2 - 1 LSB of my signal.

   )RST(


Article: 36020
Subject: Re: Probing BGA Designs
From: Ben Popoola <o.m.popoola@sussex.ac.uk>
Date: Fri, 26 Oct 2001 11:29:29 +0100
Links: << >>  << T >>  << A >>


Don Stauffer wrote:

> Does anyone have experience debugging FPGA designs in BGA packages at
> the board-level? Since there are no pins, what have people found that
> works? Any ideas are greatly appreciated, including advice on DFT at
> the board level (unused I/O routed to test pins, SignalTap/ChipScope,
> etc.).
>
> Thanks,
> Don


Article: 36021
Subject: Re: Probing BGA Designs
From: Ben Popoola <o.m.popoola@sussex.ac.uk>
Date: Fri, 26 Oct 2001 11:31:19 +0100
Links: << >>  << T >>  << A >>
Hi,
   I suggested that you learn about the JTAG interface of IC's. A good
place to start is the texas instruments web site (www.ti.com) and look
for the downloadedable book ' The JTAG Primer' there.

Ben

Don Stauffer wrote:

> Does anyone have experience debugging FPGA designs in BGA packages at
> the board-level? Since there are no pins, what have people found that
> works? Any ideas are greatly appreciated, including advice on DFT at
> the board level (unused I/O routed to test pins, SignalTap/ChipScope,
> etc.).
>
> Thanks,
> Don


Article: 36022
Subject: ILA CHIPSCOPE
From: William L Hunter Jr <wlhunterjr@home.com>
Date: Fri, 26 Oct 2001 14:26:56 GMT
Links: << >>  << T >>  << A >>
Hi

I am in the process of purchasing ILA CHIPSCOPE DEBUG KIT (with
MULTILINX cable) and was wondering what type of connector I need to
design into the board?  I assume this uses the JTAG port.  Is there a
recommended JTAG connector or is a convential non-shrouded header
acceptable??

I would also like to get some feedback from users of ILA CHIPSCOPE.

Thanks in advance
Bill


Article: 36023
Subject: Foundation 3.1I+SP8 vs 4.1ISE
From: V R <spame_me_not@wouldliketoknowaboutxilinxtools.com>
Date: Fri, 26 Oct 2001 14:29:13 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hey all.

Does Foundation 4.1ISE support any more devices than Foundation 3.1I +
SP8 (or whatever the latest service pack is)?

What are the feelings on XST synthesis vs. Synplicity Synplify Pro 6.24?

Thanks,
VR.

Article: 36024
Subject: Problem with IOBUF in WEBPACK 4.1
From: seilebost@aol.com (olivier JEAN)
Date: 26 Oct 2001 07:45:52 -0700
Links: << >>  << T >>  << A >>
Hi everybody.

 At first, i thanks the person who send me a answer about mixing two
clk.

My problem is : 
 I've written a generic code vhdl and I have wanted to transform it to
use the characterics about XILINX FPGA.
I have used the IOPAD about I/O from chips. But when I want to
generate Post-Map Simulation Model, I have the following error message
:
ERROR:NgdBuild:466 - bidirect pad net 'd<0>' has illegal connection

I use the WEBPACK XILINX VERSION 4.1

 Anybody can help me ?

  Thanks.
             Olivier.



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