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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 46875

Article: 46875
Subject: Re: Modelsim-Altera gate level simulation
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 10 Sep 2002 10:18:10 -0700
Links: << >>  << T >>  << A >>
Prashant wrote:

> Now I'm trying to simulate the gate level netlist for the
> design. The simulation takes a long time compared to RTL and I figured
> that was due to a lot of factors including not having the complete
> version for Modelsim.


Even with the full version, gate level is >10x slower.



> Is there a way to load a specific internal signal instead of all of
> them in Modelsim ?


do
add wave -r /*

to see everything.
Search for the signals you want, and copy the names for a script like:

##############
add wave *
# Top level signals
add wave /test_hdlc/ck_bytes/dut/octet_valid

# My buried signal

run -all
#############


> How do people using Modelsim for gate level simulations troubleshoot
> their gate level designs ?


Do static timing first and you may not have to.
The static timer gives much more specific data on problem delays.
Once static timing is working you should see no problems at the
gate level for synchronous designs.

Gate level debug tools include code breakpoints,
wave watching and temporarily inserting print or report statements.


     -- Mike Treseler


Article: 46876
Subject: Re: C/C++ to Verilog/VHDL ?!
From: "Frank Andreas de Groot" <nospam@nospam.com>
Date: Tue, 10 Sep 2002 17:26:43 GMT
Links: << >>  << T >>  << A >>
Actually, Olivier, when I was granted to be a beta tester for Forge a week
ago, I thought I had been told that this was for a 1-year period. Turns out
that the licence will expire next week...

All this talk in vain, I'll have to learn Verilog!

I was hoping to parallelize the algorithm as much as possible by coding in
Java long lists of if's against constants etc.

Frank



"Pierre-Olivier Laprise" <plapri@tesserae.McRCIM.McGill.EDU> wrote in
message news:hlpf9.23$Go6.1999@charlie.risq.qc.ca...
>   If your algorithm is that big, perhaps, it isn't suited to FPGA
> implementation?



Article: 46877
Subject: Re: XCR3384XL availability
From: ldoolitt@recycle.lbl.gov (Larry Doolittle)
Date: Tue, 10 Sep 2002 18:06:44 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Tue, 10 Sep 2002 09:53:02 -0700, Peter Alfke <peter@xilinx.com> wrote:
>For the IC manufacturer, 5-V tolerance is an awful requirement, leading to all sorts
>of ugly compromises between chip size (cost), speed, and reliability. And 3.3-V
>tolerance is heading the same way.

I dread the day you can't get state-of-the-art FPGAs with 3.3V-tolerant I/O.
Maybe I should buy stock in companies that sell voltage-translation IC's.  >:->

       - Larry

Article: 46878
Subject: Re: XCR3384XL availability
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 10 Sep 2002 11:29:30 -0700
Links: << >>  << T >>  << A >>
Larry,

Would you invest in a buggy whip factory because automobiles make obsolete the horse and
carriage?

It is a delicate balance:  we must offer the cutting edge technology, yet be able to look
over our shoulder and interface with last year's chips.  At some point we lose the
backward compatibility convenience (ie 5V) as we slide down Moore's curves.

Austin

Larry Doolittle wrote:

> On Tue, 10 Sep 2002 09:53:02 -0700, Peter Alfke <peter@xilinx.com> wrote:
> >For the IC manufacturer, 5-V tolerance is an awful requirement, leading to all sorts
> >of ugly compromises between chip size (cost), speed, and reliability. And 3.3-V
> >tolerance is heading the same way.
>
> I dread the day you can't get state-of-the-art FPGAs with 3.3V-tolerant I/O.
> Maybe I should buy stock in companies that sell voltage-translation IC's.  >:->
>
>        - Larry


Article: 46879
Subject: Saving results with modelsim
From: "Yan" <chan_jurgens@planet.nl>
Date: Tue, 10 Sep 2002 20:56:15 +0200
Links: << >>  << T >>  << A >>
Hi,
It is possible to save simulation results with modelsim, instead of running
the simulation again when needed?
Yan



Article: 46880
Subject: Re: OrCAD 9.2 Capture Part Library For SpartanXL&18VXX
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 10 Sep 2002 18:59:46 -0000
Links: << >>  << T >>  << A >>
>Although it may sound lazy, I can understand the desire to look for an
>Orcad part. If you draw your own part, then you run the risk of making
>an error in the pinout. ..,

Can you read a drawing with that many pins connected to a generic
part?  For FPGAs, I've always worked with schematic parts that were
specialized to each application.

What you really want is a database from the part vendor that
tells you which pins on the package are used for what, and 
another file for each design that assigns signals to pins.

Then you need software that will merge them together and
make a constraints file (or whatever) that will tell the
placer where to connect things and make another set of
files that are part descriptions for your schematic capture
package.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 46881
Subject: Re: XCR3384XL availability
From: ldoolitt@recycle.lbl.gov (Larry Doolittle)
Date: Tue, 10 Sep 2002 19:25:19 +0000 (UTC)
Links: << >>  << T >>  << A >>
I wrote:
>> I dread the day you can't get state-of-the-art FPGAs with
>> 3.3V-tolerant I/O. Maybe I should buy stock in companies
>>  that sell voltage-translation IC's.  >:->

To which Austin Lesea replied:
>Would you invest in a buggy whip factory because automobiles make
>obsolete the horse and carriage?
>It is a delicate balance:  we must offer the cutting edge technology,
>yet be able to look over our shoulder and interface with last year's
>chips.

Poor analogy.  This year's FPGA may obsolete last year's FPGA,
but there are still a tremendous array of chips that the FPGA
is still supposed to interface to.  Some of them may well be
"last year's", others simply won't move to 0.11nm technology
for technical or economic reasons.  Typical chips in this
category are ADCs, DACs, stepping or servo motor drivers,
and communication PHY layers.  Heck, even driving an LED is
problematic below 3V.

>At some point we lose the backward compatibility convenience
>(ie 5V) as we slide down Moore's curves.

Losing 5V tolerance doesn't bother me much, because 3.3V CMOS can
drive traditional 5V chips (because of their 1.8V nominal thresholds),
translating from 5V to 3.3V is a simple matter of two resistors,
and the industry has been using 3.3V for many years.  A sudden
shift down from 3.3V would bother me.

        - Larry

Article: 46882
Subject: Re: XCR3384XL availability
From: ldoolitt@recycle.lbl.gov (Larry Doolittle)
Date: Tue, 10 Sep 2002 19:29:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Tue, 10 Sep 2002 19:25:19 +0000 (UTC), Larry Doolittle wrote:
>[chop] there are still a tremendous array of chips that the FPGA
>is still supposed to interface to.  Some of them may well be
>"last year's", others simply won't move to 0.11nm technology
                                            ^^^^^^
Oops.  I guess 3.3V compatibility will be the least of our
concerns in 2025, eh?  Of course I meant 0.11um, a.k.a. 110 nm.

      - Larry

Article: 46883
Subject: Re: atmel CPLD documentation
From: eccles@a-znet.com (George Eccles)
Date: Tue, 10 Sep 2002 19:53:28 GMT
Links: << >>  << T >>  << A >>
On Tue, 10 Sep 2002 17:00:05 GMT, Troy Schultz <tschultz@canada.com>
wrote:

>George Eccles wrote:
>> I am considering using an Atmel ATF15xx series CPLD.  This would be my
>> first PLD of any sort, and I'm a little bit floundering.  For
>> instance, the part data sheet says that outputs can be configured for
>> "open-collector" (open drain?) operation; but, I don't find any
>> mention of that in the  "Programmer's Reference Guide".
>> 
>> Is there other documentation on these parts?  Or, is there a better
>> way to learn this stuff?
>> 
>> Thanks,
>> George
>> 
>> 
>> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
>> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
>> -----==  Over 80,000 Newsgroups - 16 Different Servers! =-----
>
>Last spring I started out with the Atmel ATF15xxx series, mostly due to 
>their logic doubling feature.  I ran into a large number of problems 
>with their software.

Was that WinCUPL?  If so, do you know what rev it is?  They're
currently at 5.2.16.  

Thanks,
George




-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

Article: 46884
Subject: Re: XCR3384XL availability
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 10 Sep 2002 13:24:27 -0700
Links: << >>  << T >>  << A >>
It's all a matter of trade-offs.
For highest density, speed, reliability and lowest cost, you will have to
sacrifice some backward compatibility, and many users are more than happy
to do that.
Others will settle for slightly less agressive specs and enjoy the
compatibility.
As they say, "you cannot have your cake and eat it".
(Is this a more appropriate analogy?)
If there is a market opportunity, somebody will design and make chips to
fill it.
(Capitalism 101).

Peter Alfke, Xilinx Applications
===========================
Larry Doolittle wrote:

> I wrote:
> >> I dread the day you can't get state-of-the-art FPGAs with
> >> 3.3V-tolerant I/O. Maybe I should buy stock in companies
> >>  that sell voltage-translation IC's.  >:->
>
> To which Austin Lesea replied:
> >Would you invest in a buggy whip factory because automobiles make
> >obsolete the horse and carriage?
> >It is a delicate balance:  we must offer the cutting edge technology,
> >yet be able to look over our shoulder and interface with last year's
> >chips.
>
> Poor analogy.  This year's FPGA may obsolete last year's FPGA,
> but there are still a tremendous array of chips that the FPGA
> is still supposed to interface to.  Some of them may well be
> "last year's", others simply won't move to 0.11nm technology
> for technical or economic reasons.  Typical chips in this
> category are ADCs, DACs, stepping or servo motor drivers,
> and communication PHY layers.  Heck, even driving an LED is
> problematic below 3V.
>
> >At some point we lose the backward compatibility convenience
> >(ie 5V) as we slide down Moore's curves.
>
> Losing 5V tolerance doesn't bother me much, because 3.3V CMOS can
> drive traditional 5V chips (because of their 1.8V nominal thresholds),
> translating from 5V to 3.3V is a simple matter of two resistors,
> and the industry has been using 3.3V for many years.  A sudden
> shift down from 3.3V would bother me.
>
>         - Larry


Article: 46885
Subject: Re: XCR3384XL availability
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 10 Sep 2002 16:25:39 -0400
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> rickman wrote:
> 
> >
> > I read up on the Mach4384V and it seems it is 5 volt tolerant if you use
> > the LVCMOS IO type and don't use more than 64 pins this way.
> 
> > I need TTL
> > input/outputs (5 volt compatible) and I need about 90 of them.  Any
> > solution other than to use two chips?
> 
> The most likely problem area is the "5-V tolerance". The manufacturer does not want
> you to apply 5.5 V to the inputs, since this might, in the long run, overstress the
> dielectric.
> A series resistor is no help, since there is no current...
> So ask yourself: Does the "TTL" driver really drive 5.5 V or even 5 V?
> Bipolar TTL stays one (or two) diode drop(s) below Vcc, which might be safe, but I
> would add a bleeding resistor to ground to be sure.( 10 to 100 kilohm). True CMOS
> does drive to the Vcc rail.

The problem is not the driving level, but overshoot.  There are lots of
things I can't control on the bus, so to make a robust board they need
to be guarded against.  Resistors are not a good solution because they
take up too much space on the board.  Instead of 90+ resistors I would
prefer to use TTL buffer chips.  


> For the IC manufacturer, 5-V tolerance is an awful requirement, leading to all sorts
> of ugly compromises between chip size (cost), speed, and reliability. And 3.3-V
> tolerance is heading the same way.
> There is a price you pay for all the great capabilities of the newest parts. If it
> doesn't fit, use the old-fashiond parts.

That is the idea, but I don't call a part that was introduced earlier
this year "old-fashioned".  I had to beg to get a sample of the
XCR3256XL in the 256 FPBGA package just three or four months ago.  If I
would have wanted them any earlier, I would have had to sleep with
someone...  :)  How can that be an old-fashioned part?  


> And BTW, idle current (quiescent current) is also going up, since transistors are
> not completely cut off at the low supply voltages ( 1.5 V and below). One nanoamp
> times hundred million transistors becomes real current  :-)

Another reason to work with more conventional designs.  The bleeding
edge stuff has its place, but it takes a long time for the old standards
to go away. 

-- 

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: 46886
Subject: Re: XCR3384XL availability
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 10 Sep 2002 13:29:03 -0700
Links: << >>  << T >>  << A >>
Larry,

And soon, 65 nm, and then even smaller.....

Of course, someone should comment that the IO ring is (was) .35u for
awhile, just to address the backwards compatibility.  But as performance
demands increase, even there we must consider mainstream foundry
processes (like the 0.25u/0.13u low-K all copper for Virtex II Pro from
IBM/UMC), rather than consider inventing a process that is not in the
"mainstream" of CMOS logic.

One can just about ask for anything, but getting the price, performance,
and yield that you desire is a lot easier to do if all of the other
ASICs, ASSPs use the same process.

- Don't think of today.  'Today' is gone far too soon (as you point
out:  a real cliche but true).  Manufacturers can not wait more than 1
year before they go for the shrink, otherwise they leave themselves open
to competition.  To say "I won't shrink to the next process" is similar
to saying "I am going to stop breathing now."

Besides, we have Virtex for 5V compatibility, Virtex II for 3.3V, Virtex
II Pro for 3.3 V compatibility, and so on.  We will provide solutions
for those situations where there just has to be backwards compatability.

Austin


Larry Doolittle wrote:

> On Tue, 10 Sep 2002 19:25:19 +0000 (UTC), Larry Doolittle wrote:
> >[chop] there are still a tremendous array of chips that the FPGA
> >is still supposed to interface to.  Some of them may well be
> >"last year's", others simply won't move to 0.11nm technology
>                                             ^^^^^^
> Oops.  I guess 3.3V compatibility will be the least of our
> concerns in 2025, eh?  Of course I meant 0.11um, a.k.a. 110 nm.
>
>       - Larry


Article: 46887
Subject: Re: XCR3384XL availability
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 10 Sep 2002 16:34:52 -0400
Links: << >>  << T >>  << A >>
Larry Doolittle wrote:
> To which Austin Lesea replied:
> >At some point we lose the backward compatibility convenience
> >(ie 5V) as we slide down Moore's curves.
> 
> Losing 5V tolerance doesn't bother me much, because 3.3V CMOS can
> drive traditional 5V chips (because of their 1.8V nominal thresholds),
> translating from 5V to 3.3V is a simple matter of two resistors,
> and the industry has been using 3.3V for many years.  A sudden
> shift down from 3.3V would bother me.

That is ok when you have control over your interfaces, but I don't think
you can use simple 3.3 volt logic with a 5 volt TTL bidir bus by using a
couple of resistors.  If the 3.3 volt chip is not 5 volt tolerant, you
are SOL.  

-- 

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: 46888
Subject: Re: XCR3384XL availability
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 10 Sep 2002 14:03:49 -0700
Links: << >>  << T >>  << A >>


rickman wrote:

> That is the idea, but I don't call a part that was introduced earlier
> this year "old-fashioned".  I had to beg to get a sample of the
> XCR3256XL in the 256 FPBGA package just three or four months ago.

I remember, I helped you with that :-)

> If I
> would have wanted them any earlier, I would have had to sleep with
> someone...  :)

Please, not with me...

> How can that be an old-fashioned part?

It's all relative, and the scales are not the same for different families, technologies,
and companies.

> > And BTW, idle current (quiescent current) is also going up,

> Another reason to work with more conventional designs.  The bleeding

> edge stuff has its place, but it takes a long time for the old standards
> to go away.

You bet, and that's why we keep devices in production fo many, many years. I think you
can still by some XC3000-family parts ( introduced 1987).
We do not force anybody to jump on the newest bandwagon...

Peter Alfke



Article: 46889
Subject: Re: XCR3384XL availability
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 11 Sep 2002 09:06:41 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Larry,
> 
> And soon, 65 nm, and then even smaller.....
> 
> Of course, someone should comment that the IO ring is (was) .35u for
> awhile, just to address the backwards compatibility.  But as performance
> demands increase, even there we must consider mainstream foundry
> processes (like the 0.25u/0.13u low-K all copper for Virtex II Pro from
> IBM/UMC), rather than consider inventing a process that is not in the
> "mainstream" of CMOS logic.
> 
> One can just about ask for anything, but getting the price, performance,
> and yield that you desire is a lot easier to do if all of the other
> ASICs, ASSPs use the same process.
<snip> 

 Just for an 'other industry' reality check on this,
take a look at

http://www.goalasic.com/productguide.html

 They are able to offer 100V and 300V pins, on what I believe is
0.35u core process.

- jg

Article: 46890
Subject: Re: XCR3384XL availability
From: ldoolitt@recycle.lbl.gov (Larry Doolittle)
Date: Tue, 10 Sep 2002 21:13:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Tue, 10 Sep 2002 16:34:52 -0400, rickman <spamgoeshere4@yahoo.com> wrote:
>Larry Doolittle wrote:
>> 
>> Losing 5V tolerance doesn't bother me much, because 3.3V CMOS can
>> drive traditional 5V chips (because of their 1.8V nominal thresholds),
>> translating from 5V to 3.3V is a simple matter of two resistors, [chop]
>
>That is ok when you have control over your interfaces, but I don't think
>you can use simple 3.3 volt logic with a 5 volt TTL bidir bus by using a
>couple of resistors.  If the 3.3 volt chip is not 5 volt tolerant, you
>are SOL.  

True.  I haven't had to interface to a TTL bidir signal recently.
Either direction by itself is OK, if you know what you are doing
at PC board layout time.

So, who makes an (~8)-channel, fast bi-directional level converter,
between 1.5-2.5V and 3.3-5.0V, with a convenient flow-through pin-out,
in an SOIC/TSSOP, that costs much less than a mid-range (e.g., XC2S300E)
FPGA?

       - Larry

Article: 46891
Subject: Looking for programming algorithm for Xilinx 18v00 family
From: n1ist@panix.com (Michael Ardai)
Date: 10 Sep 2002 17:15:14 -0400
Links: << >>  << T >>  << A >>
I have a design that uses Xilinx 18v00 PROMs (18V01 and 18V04) to boot
some FPGAs.  I would like to be able to field-update them thru their 
JTAG port but would rather not embed Xilinx's eisp software in my system.
Does anyone have any info on the programming algorithm for these or
similar PROMs?  I already can handle sending and receiving TAP commands
and data.  

Thanks.
/mike
n1ist@arrl.net


Article: 46892
Subject: Re: C/C++ to Verilog/VHDL ?!
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 11 Sep 2002 09:53:03 +1200
Links: << >>  << T >>  << A >>
Frank Andreas de Groot wrote:
> 
> You are right but my problem is twofold, first I don't know VHDL, I bought a
> book about digital design and VHDL and it's pretty straightforward, but the
> main thing is, my "algorithm" is huge in hardware, I couldn't easily make
> that within a year... If I would specify it in C, it would be several nested
> loops with lots of pattern recognition and very complex decisions. No way I
> will ever get that to work in VHDL. And I need to tweak it all the time,
> radically change it maybe, and I can start all over again in VHDL...
> We are talking about a newbie here, trying to put some major artificial
> intelligence into a FPGA...
> 
> My idea was to code in C/Java, get a slow but working FPGA fast to play
> with, slowly learn VHDL at the same time, and replace more and more of my
> C/Java by handcoded VHDL. Comparable to coding a quick prototype, a proof of
> concept in Visual Basic, and then refining routine by routine, after which
> you hand-optimize it in assembly...

Sounds like you would be better to try and code in parallel as much as
possible, and work with a view to deploy it to multiple processors.
If the code is not stable, then FPGA migration is unlikely to be
usefull.

Focus on tight inner functions, coded in ASM, and then move those 
critcal functions to FPGA hardware. 
( very like a custom floating point unit, or any co-processor )

Keep the outer SW shell in C, and run that in C on a 'FPGA processor',
which
can be soft or hard cored, DSP or RISC.

 
> In 1 week I'll get the board and I'm very anxious to get started...
> I'll sure try to code some Verilog or VHDL myself. I *need* the end result
> to be as fast as possible. It might even be that there is no gain at all
> when using a high-level procedural language converter...

I also noted this announcement, which could have relevence to this.
Seems this silicon support would assist parallel design, as will 
the tools that this will spawn.

# The Intel president also confirmed the long-expected 3.06-GHz Pentium
4 
# in the fourth quarter that will also be the first desktop processor to 
# use the firm's HyperThreading technology. This allows a single 
# processor to appear as dual processors, and has been used in 
# Intel servers since February to achieve a 30% performance 
# gain over uniprocessor chips. 

- jg

Article: 46893
Subject: Re: FPGA comes with a DAC?
From: Neil Franklin <neil@franklin.ch.remove>
Date: 11 Sep 2002 00:21:39 +0200
Links: << >>  << T >>  << A >>
"Cool Morning ..." <Far@East.Design> writes:

> I am looking for an FPGA chip which has a built-in DAC. My intend
> it to build a portable with three chips only, A compact-flash, an FPGA
> containing the MP3 decoder
>
> What's the SIMPLEST approach possible to make a portable MP3 player
> in today's technology?

With ->ANY<- FPGA you can implement an Sigma-Delta DAC in the FPGAs
normal logic gates. So I doubt you will find an FPGA with hardwired
DAC circuits.

Specific for Virtex: http://www.xilinx.com/xapp/xapp154.pdf

They there show an minimal FPGA+R+C circuit. For audio you will need
an second R parallel to the C (acts with first R as voltage divider
3.3->0.12V) and possibly an second C after the R-C connection point
(to get rid of DC component, depends on your amplifier chip).


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer
- Make your code truely free: put it into the public domain

Article: 46894
Subject: Re: FPGA comes with a DAC?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 11 Sep 2002 10:45:47 +1200
Links: << >>  << T >>  << A >>
Neil Franklin wrote:
> 
> "Cool Morning ..." <Far@East.Design> writes:
> 
> > I am looking for an FPGA chip which has a built-in DAC. My intend
> > it to build a portable with three chips only, A compact-flash, an FPGA
> > containing the MP3 decoder
> >
> > What's the SIMPLEST approach possible to make a portable MP3 player
> > in today's technology?
> 
> With ->ANY<- FPGA you can implement an Sigma-Delta DAC in the FPGAs
> normal logic gates. So I doubt you will find an FPGA with hardwired
> DAC circuits.
> 
> Specific for Virtex: http://www.xilinx.com/xapp/xapp154.pdf
> 
> They there show an minimal FPGA+R+C circuit. For audio you will need
> an second R parallel to the C (acts with first R as voltage divider
> 3.3->0.12V) and possibly an second C after the R-C connection point
> (to get rid of DC component, depends on your amplifier chip).

 You would also benefit from feeding the pulse stream through a 
TinyLogic gate, with special clean supply rails.
 The GND and VCC noise on a FPGA is unlikely to give a 
viable audio noise floor.
 Any Vcc/Gnd noise is fed straight thru the RC integrator, and this
is internal (noisier) vcc.gnd, not the pins.

-jg

Article: 46895
Subject: Re: XCR3384XL availability
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 11 Sep 2002 11:40:25 +1200
Links: << >>  << T >>  << A >>
Larry Doolittle wrote:
> 
<snip> 
> So, who makes an (~8)-channel, fast bi-directional level converter,
> between 1.5-2.5V and 3.3-5.0V, with a convenient flow-through pin-out,
> in an SOIC/TSSOP, that costs much less than a mid-range (e.g., XC2S300E)
> FPGA?
> 

 On-Semi and Fairchild come close, with ~ $1 for 16 bit cross-voltage 
buffers/latches, in TSSOP48 packages.
 1.5-3.3, or 2.5 - 5 are OK, 1.5 - 5 is a bigger ask, due to
threshold shifts - you could always cascade two ;)

 -jg

Article: 46896
Subject: Re: XCR3384XL availability
From: mikeandmax@aol.com (Mikeandmax)
Date: 11 Sep 2002 01:42:35 GMT
Links: << >>  << T >>  << A >>
Rickman continues..........
>
>> oops, affiliation and all that stuff -
>> 
>> Michael Thomas
>> LSC SFAE
>> for the latest info on Lattice products - http://www.latticesemi.com
>
>Mike,
>
>I read up on the Mach4384V and it seems it is 5 volt tolerant if you use
>the LVCMOS IO type and don't use more than 64 pins this way.  I need TTL
>input/outputs (5 volt compatible) and I need about 90 of them.  Any
>solution other than to use two chips?  
>
>I am also finding rather high list pricing.  What is a reasonable
>expectation for pricing on the LC4256V-10F256BC and LC4384V-10F256C?  I
>can ask the distis, but I usually get list price unless I do a real song
>and dance and I just need a realistic budgetary number.  
>
>-- 
>
>Rick "rickman" Collin

man, I missed the thread for 2 days, you guys have gone crazy!  Rick, I did
reply tonight via email to get you in touch with a local resource - I agree,
disty pricing never seems to bear much relation to what you finally get quoted,
after some fancy dancing.  I looked at pricing and see about a 30% difference
in the 1k price between the LC4256V-75F256BC
and the LC4384V-75F256C
the 4256 offers 160 I/O
the 4384 offers 192 I/O
I probably won't get beat up to say both prices are below $32 - my email gives
you your local FAE contact, who can also help with the technology side.  We
don't offer commercial speed as slow as 10ns in either device - both are
available industrial at 10ns tho :) (geez, now 10ns is too slow?)
TTL I/O isn't quite the same as 5.5v rail to rail, (our max rating) as Peter A.
pointed out.  Let us look into it with you.

Michael Thomas
LSC SFAE 

 

Article: 46897
Subject: problem with tri state bus
From: anjanr@yahoo.com (Anjan)
Date: 10 Sep 2002 21:07:12 -0700
Links: << >>  << T >>  << A >>
Hi
I am interfacing a xilinx virtex with DSP over a tristatable bus.
InPAR simulation the data bus goes to the final value after
propagating over few X for small time(10 ns). There is no bus conflict
also. The sample code is as follows
if enable
bus<=mem(conv_int(address_input));
else
bus Z
what could be the source of problem and will it cause problem in h/w.

Article: 46898
Subject: Re: Metastability numbers
From: "glen herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Wed, 11 Sep 2002 05:07:55 GMT
Links: << >>  << T >>  << A >>

"Hal Murray" <hmurray@suespammers.org> wrote in message
news:unr0sa79g80m4f@corp.supernews.com...

(snip of diagram impossible to read on a proportionally spaced font)
>
> What are you trying to do?
>
> I don't see any point in testing this circuit.  That is I
> think we understand things well enough to predict the
> answer.
>
> I'd much rather have Peter collecting data at low voltage and
> high temperatures or working on other types of chips.  Sure,
> if he runs out of other things to try, checking this would
> be good.
>
>
> This is potentially interesting if CLK is running slowly.
> Peter's numbers show that you need ~2000 pS, and that assumes
> tight routing.  If your clock is twice that and you know it's a
> 50-50 duty cycle, then the above circuit is safe and it saves
> a half cycle.
>
>   I would normally put the bubble on the first FF.  This way
>   you only get a 1/2 cycle for Qo to get to the rest
>   of the logic and that might be a long path.  (But the tools
>   should be able to check that.)
>
>
> In general, being tricky around metastability is asking
> for troubles.  It's much safer to have a clean circuit
> that is easy to check by eye.  If you try to be tricky,
> you might forget things like the 50-50 clock requirement,
> or somebody who takes over your design might miss it...
>
This reminds me of the 8086, 8087, 8088 which use a 33% duty
cycle clock.  I wonder which tricks they used.  Note that the 80287
also uses a 33% duty cycle clock, asynchronous to the 80286's
50% clock.

-- glen




Article: 46899
Subject: Re: FPGA comes with a DAC?
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Wed, 11 Sep 2002 05:19:01 GMT
Links: << >>  << T >>  << A >>
On 11 Sep 2002 00:21:39 +0200, Neil Franklin <neil@franklin.ch.remove>
wrote:

>"Cool Morning ..." <Far@East.Design> writes:
>
>> I am looking for an FPGA chip which has a built-in DAC. My intend
>> it to build a portable with three chips only, A compact-flash, an FPGA
>> containing the MP3 decoder
>>
>> What's the SIMPLEST approach possible to make a portable MP3 player
>> in today's technology?
>
>With ->ANY<- FPGA you can implement an Sigma-Delta DAC in the FPGAs
>normal logic gates. So I doubt you will find an FPGA with hardwired
>DAC circuits.
>
>Specific for Virtex: http://www.xilinx.com/xapp/xapp154.pdf
>
>They there show an minimal FPGA+R+C circuit. For audio you will need
>an second R parallel to the C (acts with first R as voltage divider
>3.3->0.12V) and possibly an second C after the R-C connection point
>(to get rid of DC component, depends on your amplifier chip).

For audio you need a different DAC (despite what the app note says).
XAPP154 describes a first order delta sigma modulator.  Audio usually
uses at least a second order modulator.

Regards,
Allan.



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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