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 30100

Article: 30100
Subject: Re: Globals are plenty fast
From: brimdavis@aol.com (BriMDavis)
Date: 23 Mar 2001 05:24:58 GMT
Links: << >>  << T >>  << A >>

Austin wrote:
>The 'problem' here is that Virtex and Virtex E has 4 and 8 
>respectively global clock resources so that in some cases 
>where they want multiple banks of I/O's running at 622 Mb/s,
>they run out of clocks (and DLL's).  Altera has even fewer 
>clock resources.

  I believe the 'problem' to which Rick was referring is 
not that he had too many clock domains, but that the Xilinx 
sanctioned Virtex-E method of doing 622 MHz input data, as 
described in XAPP233, requires a separate, non-global, 
intentionally-delayed-by-1-ns, half-rate clock input pin 
adjacent to every two data pins. 

  If the data source provides 16 data bits and one 622 MHz
clock, this can be a bit tricky to accomplish on the board.

>So, the assumption is incorrect. The global clocks are quite
>adequate for the 311 MHz required for DDR at 622 Mb/s in Virtex E.
>There are many products  running at 155 MHz in Virtex, and 311 MHz
>(622 Mb/s DDR) in Virtex E with one clock per 8 to 16 IO's.

  The global clocks are adequate for the XAPP233 Virtex-E 
DDR output mux macros, but I haven't noticed any Xilinx app.
notes stating that the global clock can be used to realize
the necessary timing for the input demux structure, across
16 inputs, on a Virtex-E, at 311 MHz DDR. ( for instance,
XAPP245 shows a 320 MHz DDR demux with one non-global
input clock pin per 8 RX bits, with 700 ps external delay )

  It looks like the incorporation of the DDR mux/demux into the
IOBs in Virtex-II will make life much easier. 

  I'm also glad to see that the new Virtex-II LVDS I/O are
actually differential in all of hardware, software, and the
primitive and simulation libraries.

  My past experiences with LVDS I/O support in the first few
releases of Virtex-E software could best be summarized by the
following riddle ;-)

  Q: How many Xilinx software engineers does it take to count
     the input pins on a Virtex-E differential input buffer?

  BTW, have MAP & PAR for Virtex-II eliminated the previous
requirement to manually lock down ALL I/O's, of any type,
if ANY differential I/O buffers are used?


Brian Davis


Article: 30101
Subject: Re: TBUFs in Virtex and later chips, going out of fashion, what instead
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Fri, 23 Mar 2001 05:39:11 -0000
Links: << >>  << T >>  << A >>

>The mux's don't have to drive across the whole chip.  Maybe they need to drive
> to one of the CLB's that may be reached by the directs, doubles (or hexes),
> making the amount of logic that can be reached quickly, large.

I'm still not getting it.

My picture is that I have a register on the left side of the chip
and another register on the right side.  Sprinkled in the middle
are various registers and counters.

I want to be able to load the register on the left from any of the
others, including the one on the right.  Same in the other direction.

This is easy to understand with TBUFs.  I might not like the answers,
but it's easy to floor plan things so all the routing is as good as
it will get.  The pattern is clock, enable, tbuf drives longline,
setup, clock.

This fits well with a style that thinks of the problem as a
specialized CPU like gizmo that gets driven my a microcoded
engine.  Most of the changes go into the microcode.  The instruction
format includes a field to specify which register drives the bus
and another field for which register gets loaded.  (Occasional
hacks are handy to load several registers on the same cycle.)


Are you using a mux in front of each register you want to load, or
a shared mux feeding all the registers?

  If I assume a mux in the middle, then the nasty case is clock,
  routing-to-mux, delay through mux, delay through long-line like
  routing to get all over the chip, setup, clock.

  If I assume a mux in front of each register, the pattern is
  the same but some things have been pushed around.  I'd guess
  the timing will be similar.


Perhaps your test cases go faster because you didn't put registers
that far apart so you don't have to route across the whole chip.

If so, then the problem isn't TBUFs, it's the long line across
the whole chip that they are driving.  I could easily see that
FPGA are now big enough that having a bus span the whole chip
isn't useful very often.

Did you try your test cases on a smaller chip?


Perhaps TBUFs feeding not-so-long lines that only go part way
across the chip would be interesting (aka faster).  I'm assuming
there would be a pair of good TBUFs at the segment junction that
I could use to cennect them and/or put a register there to
pipeline things.

  My straw man (not much thought) is that the right length
  would be to match the register transfer timing to what it
  takes to get through a (pipelined) RAM or multiply stage.

Or maybe short segments collapses to something mux like if
you have lots of local/medium routing resources.

-- 
These are my opinions, not necessarily my employeers.  I hate spam.


Article: 30102
Subject: Re: Globals are plenty fast
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Fri, 23 Mar 2001 00:47:59 -0500
Links: << >>  << T >>  << A >>
Austin,

You can say that your parts will do the job. But when Xilinx came in to
consult on the job, they said that the only way their product could
clock data in at 622 MHz was to use 8 copies of the clock with one
running to two adjacent data input pins. So the issue would seem to be
one of internal routing of such a high speed clock. 

You are saying that you can input a 322 MHz clock and use both edges to
clock the data in. I can't say why no one suggested that solution at the
time this project was being conceived. I also can't say how practical
this approach is in the application. 

The Altera parts are running on the board just fine. They use an ~80 MHz
clock on the IO and use the PLL internally to regenerate the 622 MHz
clock. The ~80 MHz clock is generated on the board from the 622 clock
and is needed elsewhere. 

What I do know is that these guys are not slouches. They are some very
good engineers and have no preference between Xilinx and Altera. They
regularly use both vendors and only choose one vendor's parts if there
is no way to use the other's. Otherwise the choice is made on price. 

So if the info we got was wrong, you may want to send your FAE's back to
school. 



Austin Lesea wrote:
> 
> Rick,
> 
> I have not come to bury PLL's, but to praise them.  In some applications, they are the
> best way to solve the problem.  Just be sure they work with the rest of the system.
> 
> The 'problem' here is that Virtex and Virtex E has 4 and 8 respectively global clock
> resources  so that in some cases where they want multiple banks of I/O's running at
> 622 Mb/s, they run out of clocks (and DLL's).  Altera has even fewer clock resources.
> 
> The Virtex II has 16 global clock resources.  From any clock input to any IO FF the
> maximum skew is +/-75 ps.  The global clocks run quite nicely at 420 MHz (along with
> the DCM's) for the 840 Mb/s SPI POS 4 application.
> 
> So, the assumption is incorrect.  The global clocks are quite adequate for the 311 MHz
> required for DDR at 622 Mb/s in Virtex E.  There are many products  running at 155 MHz
> in Virtex, and 311 MHz (622 Mb/s DDR) in Virtex E with one clock per 8 to 16 IO's.
> 
> At 622 MHz, I think you are well out of the datasheet specifications on the clock
> resurces and interconnect for any FPGA out there.  It seems that for bit rates >500
> Mb/s, or clock rates > 500 MHz, everything will be done by serializer/deserializers on
> chip, or "specialized" logic (ie dedicated hardware interfaces) due to the signal
> integrity nightmares, and the collision with trying to make a general IO do magic.
> 
> As an interesting aside, the input pins of anyone's package is typically series
> resonant at ~650 MHz.  What this means is that there is no signal on the input pin,
> yet the signal (may) makes it to the IOB (the magic of transmission lines).  Makes it
> really hard to debug!
> 
> Austin
> 
> Rick Collins wrote:
> 
> > Interesting that you mention the IO. At a company where I have done
> > work, they needed a 622 MHz interface. The Xilinx solution using Virtex
> > required multiple inputs for the clock. I assume that the global clock
> > routing was not up to the task at that speed. With 16 data bits and 8
> > clock inputs, the resync problem was so large that they ended up using
> > the Altera parts. They used 16 data inputs and a single ~80 MHz clock
> > input. A PLL ran the clock back up to 622 MHz and the input FFs all ran
> > off the same clock.
> >
> > So neither system really did what the designer wanted. But the Altera
> > solution was the simplest at the time.

-- 

Rick "rickman" Collins

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

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

Article: 30103
Subject: REQ. VHDL code for Single-pole IIR low-pass filter
From: nospam@nospam.net (David Nyarko)
Date: Fri, 23 Mar 2001 06:55:00 GMT
Links: << >>  << T >>  << A >>
Hi,
Any available code for a single-pole IIR lowpass filter implementation
in VHDL?

Filter equation:
y(n) = px(n)+(1-p)y(n-1)

The input are 16-bit 2's complement values
David

Article: 30104
Subject: PLACE and ROUTE
From: Manjunathan <mnathan@logiceastern.com>
Date: Thu, 22 Mar 2001 23:21:58 -0800
Links: << >>  << T >>  << A >>
Hello everybody,
   Iam having some sub blocks in my design, every block separtely works at 200 MZ and also every blocks are having registered Inputs and Ouputs.
    I would like to know is it possible to make the design(top level) to work at same frequency as the sub blocks.

   and also would like to know, does the place and route tool will do routing according to the timing constraint given while synthesis ?.

  is there any book or site which can give introduction about ,how to do manual place and route in XILINX tool 3.1i foundation series .  

regards ,
Manjunathan

Article: 30105
Subject: Re: what to do with I/O pins during powerup or during jtag programming
From: kfalser@REMOVETHISdurst.it (Klaus Falser)
Date: Fri, 23 Mar 2001 07:47:14 GMT
Links: << >>  << T >>  << A >>
On Fri, 23 Mar 2001 02:36:16 +0100, "Daniel Nilsson"
<danielnilsson@REMOVE_THIShem3.passagen.se> wrote:

>Hi.
>I have a cpld (xilinx xc9500) in my system, mainly used for controlling
>buffers, and I suspect I will need to add pull up or pull down resistors
>where appropriate to prevent damage on system because of strange levels on
>I/O pins during jtag programming or power-up.  Is it common practice to do
>like this, and if so, what are the appropriate values to add to force out
>pins to a safe level (to prevent bustranscievers from being turned on)
>during high-z ?
>
>/ Daniel Nilsson
>
>

Your resistor must be low enough to assure that 
when all the gates you are driving consume their 
maximum input current a valid level is still 
maintained. 

Usually (for CMOS logic like HCT with high impedance inputs)
10K - 100K should work well.

Best regards

Falser Klaus
R&D Electronics Department
Company	: Durst Phototechnik AG
	Vittorio Veneto Str. 59
	I-39042 Brixen
Voice	: +0472/810235
	: +0472/810111
FAX	: +0472/830980
Email	: kfalser@IHATESPAMdurst.it 

Article: 30106
Subject: Re: Do I need to tie unused CPLD pins to GND?
From: Gil Golov <golov@sony.de.REMOVE_THIS>
Date: Fri, 23 Mar 2001 09:32:03 +0100
Links: << >>  << T >>  << A >>
It is recommended to connect unused pins to ground to conduct heat from the chip
to the copper ground plane on the PCB. There are chip manufacturers  that ask you
to tie a few pins to group for that purpose.

Gil.


Pratip Mukherjee wrote:

> WebPack shows all the unused pin as TIE and explains that:
>         TIE  = Tie pin to GND or board trace driven to valid logic level
> My question is do I really have to? If so, can I somehow do that internal to
> the CPLD, without actually trying to run a trace (even worse, solder wires) to
> all the unused pins?
>
> Thanks.
>
> Pratip Mukherjee
> pratipm@hotmail.com


Article: 30107
Subject: Re: Looking for Processor Core info/advice
From: Kolja Sulimma <kolja@bnl.gov>
Date: Fri, 23 Mar 2001 09:48:31 +0100
Links: << >>  << T >>  << A >>
The general PIC architechture is from the 70s, so any patent issues should be
resolved by know.
But you might want to check for features that were added later to the
architechture.

Also, in most countries it is alomost impossible to protect ISAs.

CU,
        Kolja

Kent Orthner wrote:

> Does anyone know off-hand the licensing for these cores? Can we
> use a free 6502 core in a commercial product?  Ditto for PIC-
> compatabile cores.  I know that the licensing on Jan gray's
> web site (www.fpgacpu.org) specifies no commercial uses.
>
> Some of these other cores might be free but the instuction sets
> copyrighted?  (I'd like to put together a instructoin-compatable
> PIC core, but I can't figure out if I'd be allowed to use it. )
>
> Anyone know?
>
> -Kent
>
> > Gaston Biessener wrote:
> > > I am working on a product design that is tentatively  planned to be
> > > based around a Spartan-II device with a small Micro-P core implemented
> > > in the FPGA as the system controller.
>
> Phil Hays <spampostmaster@home.com> writes:
> > Might checkout:
> >
> > http://www.fpgacpu.org/
> >
> > http://tech-www.informatik.uni-hamburg.de/vhdl/vhdl.html
> >
> >
> > --
> > Phil Hays


Article: 30108
Subject: Timing analysis after implementation
From: Manjunathan <mnathan@logiceastern.com>
Date: Fri, 23 Mar 2001 00:54:51 -0800
Links: << >>  << T >>  << A >>
Hello Everybody !!

   after doing implementaion using XILINX tool,in post layout timing  report it showed us maximum frequeny is 191 MZ ,but in pad report it has given a net having delay of 8.711 ns. then how is possible to work under that much frequency.

    and we checked the net delay with fpga editor it showed the same(8.711 ns). i would like to know where is the error?.

thanks in advnce.

regards,
Manjunathan

Article: 30109
Subject: Re: Virtex Em on a board?
From: "Ralph Weir" <ralph@hunteng.demon.co.uk>
Date: Fri, 23 Mar 2001 08:55:19 -0000
Links: << >>  << T >>  << A >>
"Ray Andraka" <ray@andraka.com> wrote in message
news:3ABA5C75.68E00301@andraka.com...
> Does anyone know of any commercially available boards offered with the
XCV812E
> on it?  Looking for one for a fast prototype.
>

Hi Ray,

Hunt Engineering do one - http://www.hunteng.co.uk/info/fpga-dsp.htm and
follow the links to the FPGA2 module.  Can be coupled to ADC and so forth.

All the best,
Ralph Weir
Hunt Engineering
http://www.hunteng.co.uk



Article: 30110
Subject: Re: reduced precision floating point
From: Steven Derrien <sderrien@irisa.fr>
Date: Fri, 23 Mar 2001 11:25:34 +0100
Links: << >>  << T >>  << A >>


Pete Dudley wrote:
> 
> Has anyone tried implementing reduced precision floating point arithmetic in
> an fpga?
> 
> With the new Virtex II 18 bit multipliers it occurred to us that we could do
> floating point multiplies pretty efficiently if we reduced the mantissa size
> from 23 bits to say 17 so that the mantissa multiply would fit in the hard
> multipliers.
> 
> We want to miniaturize an algorithm that currently executs on a fabric of
> Mercury PowerPC nodes in floating point of course.


By the way,

I have some pipelined single precision fp add and mul edif module that I
might consider to make available (fro free of course) on the Web. The
module are targeted over the Virtex family and show relatively good
performance compared to commercial cores (see floating point library
www.annapmicro.com) : up to 112 Mhz for the FP mul on a virtexE-8.

However, since putting this on the web take me some of my very precious
time :)) , i won't bother doing it unless enough people are really
interested.


Steven 


> 
> --
> Pete Dudley
> Sandia Labs
> Albuquerque, NM
> padudle@sandia.gov

Article: 30111
Subject: Boundary Scan tools - price comparison
From: "Guy R. Paquet" <gpaquet@chrysalis-its.com>
Date: Fri, 23 Mar 2001 12:13:21 GMT
Links: << >>  << T >>  << A >>
Hi. I am looking for an unbiased price comparison of boundary scan tools
from the various vendors.
(JTAG, Asset, Corelis, Goepel, Intellitech, Acculogic,
etc. (any others??))
Any info. or web sites would be appreciated.




Article: 30112
Subject: Simplified ISP of XCR3256XL from BIF file fails
From: "Ian McCarthy" <ianmccarthy@casella.co.uk>
Date: Fri, 23 Mar 2001 12:39:30 -0000
Links: << >>  << T >>  << A >>
Originally I had a 5V target system containing a PZ5128, this was programmed
using the target CPU by bit-bashing the contents of a BIF file generated by
the XPLA programmer software (as detailed in XAPP326 - Simplified in-circuit
programming...).

This worked perfectly.

However now I have to use an XCR3256XL (3.3V) device in a 5V target system.

I've re-made the design in WebPACK from a schematic and created a new BIF
file.

Bit-bashing this file into the device has no effect what so ever.

The JTAG pins appear to be driven with the correct bit patterns.

The PORT_EN pin is connected to the CPU RESET signal (active low) which is
low as the system powers up and then goes high (although the port is also
reserved in the design configuration).

I've even put level translators in the TDI, TMS, TCK lines so the device
JTAG port is driven at 3.3V rather than 5V but to no avail.

Has anyone got any experience of this process with this device as at present
I can see no solution.

Many thanks in advance

Ian McCarthy
ianmccarthy@casella.co.uk




Article: 30113
Subject: Re: Parallel Port EPP
From: edick@hotmail.com (Richard Erlacher)
Date: Fri, 23 Mar 2001 15:09:46 GMT
Links: << >>  << T >>  << A >>
It doesn't have to be a kludge of any sort.  The strobes are generated
at the PC end in rigorous synchronization with the PC, and the entire
transfer and handshake can be accomplished with just a pair of
dual-rank registers on the nWAIT/RDY signal.  The strobes, as I wrote
before are preceded by settled data, so if you gate latches on the
data path and synchronize the handshake with the data path registers
downstream from the latches by clocking the registers from the rising
edge of nWAIT/RDY, yet leave the latches' gates open until the falling
edge of nWAIT/RDY all setup and hold times will be satisfied, yet the
task of synchronizing the data transfer between the host PC and the
downstream data path logic is effected with only two D-flops.  

In short, if you open the data gate with the occurence of one of the
derived strobes (DataRd, DataWr, AddRd, AddWr), and close it with the
falling edge of nWait/RDY, yet clock the downstream registers with the
handshake, generated from a dual-rank register also used to feed back
the OR of these strobes to the nWAIT/RDY signal, there's no risk of
metastabile results to speak of.  It's also pretty simple to do in a
CPLD.

Dick


On Mon, 19 Mar 2001 07:04:06 -0000, hmurray-nospam@megapathdsl.net
(Hal Murray) wrote:

>>I' like to use a CPLD/FPGA (Xilinx) to receive data from the parallel
>>port (EPP-mode) of my PC.
>>
>>Is it a good style to react direct on the edges of the port signals (e.
>>g. adress/data strobes) or would it be better to use a fast PLD-Clock to
>>sample the port and then to evaluate the signals in a clocked logic?
>
>I think you didn't provide a critical chunk of information.  What
>are your goals/priorities?
>
>What are the relative importances of  bandwidth, correctness, design time?
>...
>
>
>If you run all the async signals through the standard pair of FFs
>then you (probably) won't have any problems from metastability.
>
>That will cost you 1.5 cycles (average) of round trip time which
>turns into reduced bandwidth.
>
>If your top goal is max throughput, then you are almost forced
>to use some kludgy logic driven off the strobes.  Fortunately,
>that is (probably) small enough that you can get it right.
>
>-- 
>These are my opinions, not necessarily my employeers.  I hate spam.
>


Article: 30114
Subject: Software Pundits ASIC/FPGA
From: "Vikram Nagia" <vik@pundits.com>
Date: Fri, 23 Mar 2001 10:29:02 -0500
Links: << >>  << T >>  << A >>
Hello All,
Granted, you are the Brahma of software,the Vishnu of exemplary skills.
You still need a Pundit to changeyour corporate destiny.

So, you are the creator of pathbreaking software; the preserver of
competitive
capabilities. How come you still haven't been spotted by this Pundit based
in the US for the past eleven years? Software Pundits Inc. is a leading
provider of unique and innovative technology solutions for the top software
companies in the US. The likes of CISCO, Lucent, Alcatel, Bay Networks,
3Com, Ascend, Nortel and Seimens. With a strong clientele in the niche areas
of networking and telecom markets, and still expanding its market strengths


Hello,
 My name is Vikram. I represent Software Pundits,
 Burlington, MA. If you are looking for a challenging position in
 a cutting edge technology, we might be the answer
 for you.  We have projects in different parts of the
 country and we try to accomodate our
 pundits(Consultants)needs. I am very much
 interested in talking to you. My number is 781-229-6655 X
 229. If interested, please send me a copy of your
resume to speed up the process. Please call me or leave
 me your information to call you back at your
 convenience. Your time is very much appreciated
 Thanks

Vikram
Article on Pundits:
http://masshightech.com/displayarticledetail.asp?art_id=46311



Article: 30115
Subject: Re: Looking for Processor Core info/advice
From: Tom Dillon <tdillon@dilloneng.com>
Date: Fri, 23 Mar 2001 16:21:53 GMT
Links: << >>  << T >>  << A >>
On 3/22/2001, 4:56:31 PM, Eric Smith <eric-no-spam-for-me@brouhaha.com> =

wrote regarding Re: Looking for Processor Core info/advice:
> Tom Dillon <tdillon@dilloneng.com> writes:
> > We have worked with a open source 6502 core. We spent some time
> > optimizing it for the Spartan family.

> Can you make your Spartan optimized version available?

Yes. As soon as we get it to a released state it will be on our web site=
.

Regards,

Tom Dillon
Dillon Engineering, Inc.
http://www.dilloneng.com

Article: 30116
Subject: Accumulator - Core in XC4K
From: "Christian Martin" <christian.martin2@infineon.com>
Date: Fri, 23 Mar 2001 17:46:31 +0100
Links: << >>  << T >>  << A >>
Hello All,

I have a timing problem with a 41-bit accumulator in a XC40150XV
device. Due to the long carry path in the accu, I can not reach the desired
frequency. Acually I use the accu from the Xilinx Core Generator V1.5

Do someone know wether there is an alternative core module, which I can use.
I know, that there is a Carry-Lookahead Adder for faster operation.
Is it usefull to create an accumulator of this type of adder by hand, or is
there a core module available?

Christian Martin











Article: 30117
Subject: Re: what to do with I/O pins during powerup or during jtag programming
From: PeteD <pdowell@mil-x-dig.com>
Date: Fri, 23 Mar 2001 17:27:57 GMT
Links: << >>  << T >>  << A >>
Here's a direct quote from the Xilinx data book:
" All I/Os are 3-stated and pulled high by the IOB resistors during system
programming. If a particular signal must remain low during this time, then a 
pulldown resistor may be added to the pin". The internal pullup is about 10K.
-- 
Remove "-x-" from address to e-mail

Article: 30118
Subject: speech
From: "catherina" <floreq10@hotmail.com>
Date: Fri, 23 Mar 2001 19:42:10 -0000
Links: << >>  << T >>  << A >>
hello,

a simple question, how many bits should be allocated to cover the natural
speech signal dynamic ?

I have never seen an  implementation related to speech processing on FPGA.
Is that  because there is no need for Mhz speed ?






Article: 30119
Subject: tst
From: "catherina" <floreq10@hotmail.com>
Date: Fri, 23 Mar 2001 19:42:46 -0000
Links: << >>  << T >>  << A >>




Article: 30120
Subject: tst
From: "catherina" <floreq10@hotmail.com>
Date: Fri, 23 Mar 2001 19:45:00 -0000
Links: << >>  << T >>  << A >>
tst



Article: 30121
Subject: Re: speech
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Fri, 23 Mar 2001 21:23:03 +0100
Links: << >>  << T >>  << A >>
catherina schrieb:
> 
> hello,
> 
> a simple question, how many bits should be allocated to cover the natural
> speech signal dynamic ?

Normal telefone uses 12 bits compressed to 8 bits (A-law, U-law). But
ists also a matter of sampling frequency (8kHz for telephone)

> 
> I have never seen an  implementation related to speech processing on FPGA.
> Is that  because there is no need for Mhz speed ?

Depends on how fast you speak (Maybe the rappers need MHz performance
;-))))

-- 
MFG
Falk

Article: 30122
Subject: Re: Do I need to tie unused CPLD pins to GND?
From: mikeandmax@aol.com (Mikeandmax)
Date: 23 Mar 2001 20:51:23 GMT
Links: << >>  << T >>  << A >>

Klaus suggests->
>As for EVERY chip, EVERY unused should be tied to a defined 

Or perhaps, use a CPLD with internal programmable pullups on each pin.

Article: 30123
Subject: Re: PLACE and ROUTE
From: tider <tiderhuang@yahoo.com>
Date: Fri, 23 Mar 2001 15:50:47 -0800
Links: << >>  << T >>  << A >>
Hi,
The xilinx tool will do routing according to the timing constraint. For synthesis, there are many optimization options, and some can affect timing.
For manual place and route, see the Floorplanner and FPGA Editor manual.

Article: 30124
Subject: Call For Papers - Boston Synopsys Users' Group
From: Brian Kane <snug_tech@synopsys.com>
Date: Fri, 23 Mar 2001 18:58:38 -0500
Links: << >>  << T >>  << A >>
                              SNUG Boston 2000
                              September 10-12, 2001
                              Third Annual Synopsys Users Group
                              Boston Marriott Newton =

                              Newton, Massachusetts

CALL FOR PAPERS!
An Invitation to Contribute =

Share your experiences - the success of our users group depends on the
active participation of users who are willing to share their experiences
with others. If you have information on high-level or physical-design
methodology, or experiences with Synopsys tools that would be of
interest to other users, you are encouraged to present at SNUG Boston
2001. =


Abstracts will be accepted from March 7 to April 13, 2001. To submit
your abstract, contact the SNUG Boston Technical Committee at
snug_tech@synopsys.com. Please include the names of all authors, your
company, contact information (email, phone number, etc.) and the title
of your abstract.

*SNUG Author Deadlines*
March 12 - April 13, 2001 Call for Papers
April 27, 2001            Acceptance of Abstract
May 11 , 2001             In-Depth Outline due
June 8 , 2001             Draft Paper due
June 29 , 2001            Final Paper due for Print**
July 13, 2001             Draft Slides due
July 30 , 2001            Final Slides due for Print
September 10-12 , 2001    SNUG Boston 2001 Conference

For more information on authoring a SNUG paper, visit the SNUG Author's
kit: http://www.snug-universal.org/boston/akit.htm

Preliminary topics include: =


 Physical Synthesis/Timing Closure
Describe design methodologies, timing-closure flow solutions, lessons
learned, or tips related to the use of Synopsys Design Planning products
including Chip Architect, FlexRoute, PrimeTime=AE, or Physical Compiler. =


 Synthesis Strategies and Experiences
Users present ways to push Design Compiler? to achieve the best results
with respect to timing, area, power and/or runtime. These techniques
will include compile options, DC variables, and HDL coding styles for
synthesis. Users share experiences with automation techniques for
synthesis. Of special interest is exploration of changes and
enhancements to Design Compiler over the last few releases. We're also
interested in user papers that discuss experiences with Library
Compiler?. =


 Deep Submicron/Large Designs/Low Power
This session concentrates on the unique challenges of submicron and
low-power design techniques that may involve large design, deep
submicron and high-clock speeds. Papers provide experience with
automating scripts for submicron design, special techniques for managing
wireloading, and non-linear delay modeling. =


 Physical Analysis and Modeling for Deep Submicron SoC
This session is different than the Physical Synthesis session, listed
above, in that it invites structured-custom IC and ASIC designers to
share how Synopsys' Nanometer Analysis tools are implemented in their
flows. This session concentrates on recent and emerging challenges
related to mixed-signal design, and physical effects encountered while
using process technologies smaller than 0.18mm. In the race towards high
speed (GHz!) and low power (sub-volt!) designs, designers must have
solutions for accurate characterization, modeling, verification and
physical extraction. =


 FPGA & PLD Synthesis =

Concentrating on the unique challenges of programmable logic, the tricks
and techniques used for designing and synthesizing FPGAs or PLDs will be
presented. Incremental synthesis, fanout control, and floorplanning
issues relative to FPGAs will also be part of this section. =


 High-Level Verification/Simulation Techniques =

The higher the level a design is coded, the faster it can be simulated,
thus more verification can be done in the time-to-market window. But
there are many challenges to ensure that high-level verification also
meets your needs for properly testing the device. This session calls for
papers on behavioral system modeling approaches when given design
descriptions and performance goals. System-level strategies covering
design functional verification using HDLs and VCS? or VSS? are also
covered. Users share experiences in developing a test bed to verify
combined hardware and software systems for large complex designs. We're
also interested in user papers that discuss experiences with VERA=AE and
CoverMeter. Further discussion includes the verification/simulation
strategies to ensure design correctness. =


 Higher Levels of Abstraction/Behavioral Synthesis =

User experiences with behavioral synthesis are explored in this session.
Topics include high-level design techniques, behavioral scheduling,
datapath synthesis, pipeline retiming, and integration with other ASIC
design and verification tools. Other topics include the methodology for
top-down design and high-level techniques for DSP design. =


 Hardware/Software Co-design =

Authors are invited to submit original papers describing recent
experiences in designing and verifying embedded processor-based ASIC/SoC
systems. This includes the methodologies used, and tools required, to
handle tasks of verifying both the hardware and software before physical
prototypes are available for these systems. Authors are encouraged to
share their insights on the use of the Synopsys Eaglei=AE
hardware/software tools, Cyclone=AE, VSS, Flexmodels and VCS, and the
overall impact on the project. Explore system-design objectives: users
experience with system development, verification and integration. =


 Makefiles Methodology/Configuration Management =

This popular session addresses the increased effort to automate and
extend the synthesis process through scripting. The session includes
case studies by users who have taken advantage of the power of Make,
Perl and even Tcl to drive synthesis iterations, to extend dc_shell, and
to manage complex designs. =


 Design Reuse =

This session includes a practical methodology for design reuse and
Intellectual Property integration based on real-world experiences.
Issues and guidelines are explored. Does anybody really have a working
design reuse methodology in place? Let us know about it and how it
works. =


 Design-For-Test (DFT)
This session focuses on strategies and real-world experiences
implementing a manufacturing test strategy (DFT) for large SoC-type
designs. Various SCAN and isolation techniques are explored in the
context of core-based designs. Techniques used to interface a DFT
solution (full or partial) with synthesis and power will be included. =


 Module Compiler =

This session explores the use of Module Compiler? to achieve high
performance datapath designs, focusing on effective datapath synthesis
strategies, coding styles, and integration with other ASIC design tools.
User experiences with datapath synthesis are shared.

 Static Timing Analysis
This session explores strategies and user experiences using a static
verification flow, concentrating on highlights and lowlights of static
timing analysis using PrimeTime. =


 Formal Verification =

This session explores strategies and user experiences using a static
verification flow, concentrating on formal verification using
Formality=AE. =


------------------------
Brian Kane
Boston SNUG Technical Committee Chairperson



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