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 20125

Article: 20125
Subject: Re: Has anyone created VHDL code to interface to a 68HC11 SPI port yet?
From: thompson@ren.eecis.udel.edu (Tyrone Thompson)
Date: 27 Jan 2000 21:10:36 GMT
Links: << >>  << T >>  << A >>
In article <kLMj4.353$425.17897@typhoon-la.pbi.net>,
Don Golding <dgolding@angelusresearch.com> wrote:
>I am rather new to VHDL and FPGA.  I want to hook a XC4005 using Xilinx
>Foundation 1.5 tools and talk to the FPGA through a 68HC11.
>Currently, I am taking a course in VHLD at UCI.
>
>
>Master/Slave arangement...
>
>Thanks
>Don Golding
>
>
>

Unless you are missing at least an "E" on the end of XC4005 you will not be
able to use the Foundation 1.5 tools with this FPGA. In order to work with
the original XC4k series you have to use the XACT place and route tools which
are only supported up to Foundation 1.3.

HOw do I know this? I inherited a project with an XC4008 soldered on!

How this helps.

Tyrone

-- 
--------------
thompson@eecis.udel.edu				University of Delaware
Tyrone Thompson					EE Graduate Student

Article: 20126
Subject: Re: GSR in HDL on instantiated flip-flop primitives
From: Ray Andraka <randraka@ids.net>
Date: Fri, 28 Jan 2000 00:15:50 GMT
Links: << >>  << T >>  << A >>
Thanks,

The SRL'16s do initialize ok in simulation if you use the INIT generic.  The
problem was applying an initial value to an instantiated flip-flop paired in
the same CLB and to an instantiated FDRE.

Simon Bacon wrote:

> If you end up writing your own sim model to check out pre-tools,
> this may help:
>
> ------------------------------------------------------------------------
> -----
> -- synthesis translate_of
> ------------------------------------------------------------------------
> -----
> library IEEE;
> use IEEE.STD_LOGIC_1164.all;
>
> entity SRL16E is
>   port (D   : in STD_ULOGIC;
>         CE  : in STD_ULOGIC;
>         CLK : in STD_ULOGIC;
>         A0  : in STD_ULOGIC;
>         A1  : in STD_ULOGIC;
>         A2  : in STD_ULOGIC;
>         A3  : in STD_ULOGIC;
>         Q   : out STD_ULOGIC := '0' );   -- or 'U'
> end SRL16E;
>
> architecture MySim of SRL16E is
>   -- choose you preferred initialisation value here
>   signal SHIFT_REG : std_logic_vector (15 downto 0) := (others=>'0');
> begin
>   ReadBehavior : process(A0, A1, A2, A3, SHIFT_REG)
>     variable LENGTH : integer;
>     variable ADDR : std_logic_vector(3 downto 0);
>   begin
>     ADDR := (A3, A2, A1, A0);
>     LENGTH := ToInteger(ADDR); -- choose your preferred version of
> ToInteger()
>     Q <= SHIFT_REG(LENGTH);    -- could add 'after 1 ns' to make the sim
> more readable
>   end process ReadBehavior;
>
>   WriteBehavior : process (CLK)
>   begin
>     if rising_edge(CLK) then
>       if CE='1' then
>         for I in 15 downto 1 loop
>           SHIFT_REG(I) <= SHIFT_REG(I-1);
>         end loop;
>         SHIFT_REG(0) <= D;
>       end if;
>     end if;
>   end process WriteBehavior;
> end MySim;
> ------------------------------------------------------------------------
> -----
> -- synthesis translate_on
> ------------------------------------------------------------------------
> -----
>
> Ray Andraka <randraka@ids.net> wrote
> > The problem is not the implementation on the physical silicon, it is a
> > simulation issue.  This application is rather long filter and the FDRE
> and
> > SRL16Es are in the delay path, so it needs to run a substantial number
> of
> > cycles to flush the X's out in the simulation.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 20127
Subject: Re: ADC to DSP... FIFO?
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 27 Jan 2000 16:18:48 -0800
Links: << >>  << T >>  << A >>
Here is what I would do:
Get the simplest and cheapest A/D converter chips, and solve all your
formatting and FIFO jobs in one FPGA, like the Xilinx XC4005XL or XCS05XL
for  under $10.- ( depending on quantity) For really deep (4k) FIFO
buffering I would use the smallest Spartan-II chip, which has dual-ported
BlockRAM.
FPGAs offer you all the flexibility you could possibly ask for, and they
are not expensive any more.

Peter Alfke, Xilinx Applications
=============================
Lee Cao wrote:

> Help!!!
>
> I am looking for a way to acquire 11 channels of 12-bit data at 11kHz.
> The DSP I am using is a Texas Instrument TMS320C32, the 60MHz one.
>
> The DSP needs to do quite a bit of number crunching so I was hoping
> that there could be some way of automating/buffering the incomining
> data from the ADC at the rate of approximately 200kBytes/s.  I don't
> think that having the DSP interrupted 11,000 times per second to
> service the ADC is going to work.
>
> In the name of saving space and cost, I was looking for ADCs with
> buffering FIFO built into it.  So far, I found a Texas Instrument
> THS1206, which is a 4 channel 1.5Msps/channel 12-bit ADC with a
> 16-word FIFO built in.  This means I can take up to four samples
> before the ADC have to be serviced by the DSP.  But this chip is
> around $15.00 a piece, which means I would be spending $40+ on
> three of them just to cover 11 channels.
>
> Do I have any other options?  I don't need the 1.5Msps/channel
> rate of the THS1206.  Is there a less expensive ADC out there with
> multichannel input, built-in MUX, S&H, 12-bit resolution, FIFO,
> and at least 11ksps/channel?
>
> If not, what are my other options at interfacing the ADC front
> end circuitry to the DSP?  Would I need a PLD logic of some sort
> with enough flip-flops to act as a data buffer?
>
> Thanx
>
> --
> Lee Cao

Article: 20128
Subject: Re: Altera Quartus vs Xilinx Place and Route tools (help needed)
From: Ray Andraka <randraka@ids.net>
Date: Fri, 28 Jan 2000 00:25:23 GMT
Links: << >>  << T >>  << A >>
The PLL should give you more flexibility, as you are not restricted to the
specific divide/multiply ratios.  Realistically though, it is an analog
circuit and that has lots of extra baggage.  For starters, the transistors
have to have relatively tightly controlled (relative to a digital circuit)
parameters in the active region for the thing to oscillate right.  On top
of that, it is working in a noisy digital environment so there are
considerations there.  I've done PLLs with dedicated chips, and there's
enough to worry about there without ahving to worry about digital stuff on
the same chip, or about compromising digital performance vs PLL
performance.  Bottom line is it is a tricky design problem at best, and a
customer support nightmare at worst.  I'll take the limited functionality
of the digital DLL as my choice for an on chip clock management unit,
thanks.

Magnus Homann wrote:

> Ray Andraka <randraka@ids.net> writes:
>
> > Oh, one more thing, The DLL is implemented basically as delay gates
> > with feedback, which allows it to be done in the same process as the
> > SRAM technology for the rest of the chip, with virtually nothing
> > extra added to the process or yield testing.  It's a totally digital
> > circuit.  That means the incremental cost of adding the DLL is
> > virtually nothing after the NRE.
>
> Yup, that's what Xilinx told me too. Altera has a different view on
> the subject, though...  :-)
>
> Who is right?
>
> Homann
> --
> Magnus Homann, M.Sc. CS & E
> d0asta@dtek.chalmers.se

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 20129
Subject: Re: Altera Quartus vs Xilinx Place and Route tools (help needed)
From: allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman)
Date: Fri, 28 Jan 2000 01:14:44 GMT
Links: << >>  << T >>  << A >>
On Thu, 27 Jan 2000 15:26:31 GMT, Ray Andraka <randraka@ids.net>
wrote:

>Oh, one more thing,  The DLL is implemented basically as delay gates with
>feedback, which allows it to be done in the same process as the SRAM
>technology for the rest of the chip, with virtually nothing extra added to the
>process or yield testing.  It's a totally digital circuit.  That means the
>incremental cost of adding the DLL is virtually nothing after the NRE.
>
>Contrast that with a PLL, which by nature is an analog animal.  That means
>extra care is required in the fab, as there are parameters that have to be met
>which would not have to be met for a strictly digital circuit.

Ray, I disagree with your statements about DLLs and PLLs.  Both are
implemented with delay lines made from gates.  Both use feedback to
adjust the gate delay.  Both have an analog loop filter (but the DLL
loop filter is simpler).

About the only difference is that the PLL has the output of its delay
line fed back to the input to make a ring oscillator.  The DLL has its
input connected to the input clock signal.  This should give the DLL
better jitter performance, but the quoted specs (A vs X) are
identical.

(BTW, I'm making some guesses about the implementations.  It is
possible that they have been implemented in other ways.)

Regards,
Allan.

>Magnus Homann wrote:
>
>> Steve Dewey <steve@s-dewey123.demon.co.uk> writes:
>>
>> > One point in this debate is that Xylinx seem to put the DLLs into ALL
>> > the Virtex and Spartan parts. Altera definitely only puts them into
>> > certain speed grades/packages/device sizes. So you have to pay extra and
>> > probably not use the speed grade, package, or device size that you
>> > thought.
>>
>> Well, wont you have to pay extra for the Xilinx DLLs all the time too?
>>
>> Homann
>> --
>> Magnus Homann, M.Sc. CS & E
>> d0asta@dtek.chalmers.se
>
>--
>-Ray Andraka, P.E.
>President, the Andraka Consulting Group, Inc.
>401/884-7930     Fax 401/884-7950
>email randraka@ids.net
>http://users.ids.net/~randraka
>
>

Article: 20130
Subject: Re: ADC to DSP... FIFO?
From: "Saddle" <saddle@bigpond.com>
Date: Fri, 28 Jan 2000 14:27:16 +1000
Links: << >>  << T >>  << A >>
I'm not knowledgable on the Texas part, but doing it with a DSP like a
ADSP2181, you can get the SPORT port on it to obtain the data directly into
"circular" memory from serial ADCs without processor intervention. In our
last project, we collect 14 bit data from 128 sensors continously at < 5usec
per sample, without the processor doing anything. I'd be suprised if you
couldn't do that in a Texas part as well.

Regards,

Saddle


Lee Cao <ligeng@NOSPAMleecao.com> wrote in message
news:MPG.12fa7a0ba5f0a8d898970f@news.erols.com...
>
> Help!!!
>
> I am looking for a way to acquire 11 channels of 12-bit data at 11kHz.
> The DSP I am using is a Texas Instrument TMS320C32, the 60MHz one.
>
> The DSP needs to do quite a bit of number crunching so I was hoping
> that there could be some way of automating/buffering the incomining
> data from the ADC at the rate of approximately 200kBytes/s.  I don't
> think that having the DSP interrupted 11,000 times per second to
> service the ADC is going to work.
>
> In the name of saving space and cost, I was looking for ADCs with
> buffering FIFO built into it.  So far, I found a Texas Instrument
> THS1206, which is a 4 channel 1.5Msps/channel 12-bit ADC with a
> 16-word FIFO built in.  This means I can take up to four samples
> before the ADC have to be serviced by the DSP.  But this chip is
> around $15.00 a piece, which means I would be spending $40+ on
> three of them just to cover 11 channels.
>
> Do I have any other options?  I don't need the 1.5Msps/channel
> rate of the THS1206.  Is there a less expensive ADC out there with
> multichannel input, built-in MUX, S&H, 12-bit resolution, FIFO,
> and at least 11ksps/channel?
>
> If not, what are my other options at interfacing the ADC front
> end circuitry to the DSP?  Would I need a PLD logic of some sort
> with enough flip-flops to act as a data buffer?
>
> Thanx
>
> --
> Lee Cao


Article: 20131
Subject: Re: Altera Quartus vs Xilinx Place and Route tools (help needed)
From: Ben Sanchez <ben_sanchez@worldnet.att.net>
Date: Thu, 27 Jan 2000 21:44:01 -0800
Links: << >>  << T >>  << A >>
Peter,

I'm designing a circuit that receives a copy of a 120 MHz sample clock
(used in radio astronomy, and locked to an atomic standard at the
observatory, typically an H Maser) along with the sample data.  The
input samples and clock are fed to an XCV050 and the clock is passed
through one of the DLL's and into the chip for use in the input side of
a FIFO/Packer setup, the CLKDV output of that CLKDLLHF is passed to the
two CLKDLLs on the other side of the chip, on of which redrives the now
60 MHz clock for the rest of the board's data path and the other passing
it into the Virtex for the output side of the FIFO/Packer and other
logic.

The question is, with the extremely low jitter at the input, how much
will be added by the two levels of CLKDLLHF and CLKDLL that it goes
through?  I'm curious because at the board's final output I'm using that
60 MHz clock to drive a serializer, which multiplies it up to 1440 MHz
internally, and has pretty tight jitter specs in order to maintain
reliable lock at the Rx end and a low BER.  (It's an HP G-Link in case
you're familiar with it)

Is there a potential problem?  Until now I had been convinced that there
was not going to be, which may even have been an idea I got from you
when we discussed the subject during the break in one of the classes you
guys hold there at Xilinx. (Can't remember why I thought that now,
hoping I had a good reason)

Thanks,
Ben Sanchez

Peter Alfke wrote:
> 
> Magnus Homann wrote:
> 
> >
> >
> > Yup, that's what Xilinx told me too. Altera has a different view on
> > the subject, though...  :-)
> >
> > Who is right?
> 
> It's an interesting battle. Here are my views:
> 
> In an ideal world without any noise, ground bounce, and processing
> problems, the PLL would have some advantages, since it can multiply the
> incoming frequency by any factor, and it can suppress incoming jitter (
> if that is desirable).
> 
> Now let's leave the idealized world and enter the real world:
> 
> Keeping the spontaneous jitter of an RC-based on-chip VCO under control
> is a very difficult task. I know; I cut my teeth on TV-tuner and citizen
> band analog PLLs many years ago, and there we had the luxury of using LC
> oscillators, which I find easier to keep clean. Putting a sensitive and
> delicate analog circuit onto any notoriously noisy digital chip is asking
> for trouble. First, the analog parameters of the PLL transistors must be
> controlled ( and what happens when the process migrates to smaller
> geometries? ), and then you need separate ground/Vcc pins and decoupling,
> and you still don't know how much spontaneous jitter is being generated.
> Combining digital and analog is like moving a rock band into an old folks
> home. They just don't like each other.
> 
> The DLL is a 100% digital circuit; its output jitter has a well-defined
> max value, and no extra supply connections are needed.
> 
> I for one feel much more comfortable in the predictable digital world of
> the DLL.
> 
> Peter Alfke, Xilinx Applications
Article: 20132
Subject: Re: Altera Quartus vs Xilinx Place and Route tools (help needed)
From: Peter Alfke <palfke@earthlink.net>
Date: Fri, 28 Jan 2000 06:36:10 GMT
Links: << >>  << T >>  << A >>
Hi, Ben.
The way I understand your circuit, each DLL will introduce a max jitter of
less than 50 picoseconds. I'll think about this tomorrow at work, but I think
the jitter is additive or orthoganal( square root) additive. Looks like you
pick up, worst case a jitter of almost 100 ps at the DLL output. You
understand the rest better than I.
But you don't have to worry about additional analog jitter...

Is that an answer? It's getting late here...

Peter Alfke

Ben Sanchez wrote:

> Peter,
>
> I'm designing a circuit that receives a copy of a 120 MHz sample clock
> (used in radio astronomy, and locked to an atomic standard at the
> observatory, typically an H Maser) along with the sample data.  The
> input samples and clock are fed to an XCV050 and the clock is passed
> through one of the DLL's and into the chip for use in the input side of
> a FIFO/Packer setup, the CLKDV output of that CLKDLLHF is passed to the
> two CLKDLLs on the other side of the chip, on of which redrives the now
> 60 MHz clock for the rest of the board's data path and the other passing
> it into the Virtex for the output side of the FIFO/Packer and other
> logic.
>
> The question is, with the extremely low jitter at the input, how much
> will be added by the two levels of CLKDLLHF and CLKDLL that it goes
> through?  I'm curious because at the board's final output I'm using that
> 60 MHz clock to drive a serializer, which multiplies it up to 1440 MHz
> internally, and has pretty tight jitter specs in order to maintain
> reliable lock at the Rx end and a low BER.  (It's an HP G-Link in case
> you're familiar with it)
>
> Is there a potential problem?  Until now I had been convinced that there
> was not going to be, which may even have been an idea I got from you
> when we discussed the subject during the break in one of the classes you
> guys hold there at Xilinx. (Can't remember why I thought that now,
> hoping I had a good reason)
>
> Thanks,
> Ben Sanchez
>
> Peter Alfke wrote:
> >
> > Magnus Homann wrote:
> >
> > >
> > >
> > > Yup, that's what Xilinx told me too. Altera has a different view on
> > > the subject, though...  :-)
> > >
> > > Who is right?
> >
> > It's an interesting battle. Here are my views:
> >
> > In an ideal world without any noise, ground bounce, and processing
> > problems, the PLL would have some advantages, since it can multiply the
> > incoming frequency by any factor, and it can suppress incoming jitter (
> > if that is desirable).
> >
> > Now let's leave the idealized world and enter the real world:
> >
> > Keeping the spontaneous jitter of an RC-based on-chip VCO under control
> > is a very difficult task. I know; I cut my teeth on TV-tuner and citizen
> > band analog PLLs many years ago, and there we had the luxury of using LC
> > oscillators, which I find easier to keep clean. Putting a sensitive and
> > delicate analog circuit onto any notoriously noisy digital chip is asking
> > for trouble. First, the analog parameters of the PLL transistors must be
> > controlled ( and what happens when the process migrates to smaller
> > geometries? ), and then you need separate ground/Vcc pins and decoupling,
> > and you still don't know how much spontaneous jitter is being generated.
> > Combining digital and analog is like moving a rock band into an old folks
> > home. They just don't like each other.
> >
> > The DLL is a 100% digital circuit; its output jitter has a well-defined
> > max value, and no extra supply connections are needed.
> >
> > I for one feel much more comfortable in the predictable digital world of
> > the DLL.
> >
> > Peter Alfke, Xilinx Applications

Article: 20133
Subject: LVPECL I/O interface
From: "K" <k@k.net>
Date: Fri, 28 Jan 2000 00:36:46 -0600
Links: << >>  << T >>  << A >>
Hi.

I am working on a project that requires interfacing LVPECL I/Os from an ASIC
to the FPGA. The FPGA I/Os are LVCMOS, LVTTL.  Can anybody guide me on how
to approach this problem.  Unfortunately I cannot use a LVPECL based FPGA
such as Virtex-E).

Thanks

Karen






Article: 20134
Subject: ARM core?
From: "¹Ú±¸¿ë" <hereim@maru.comtec.re.kr>
Date: Fri, 28 Jan 2000 17:52:58 +0900
Links: << >>  << T >>  << A >>
hi, friends.
what is the ARM core? Is there any site or Book for this question?
thanks, good day!!


Article: 20135
Subject: Re: LVPECL I/O interface
From: Ben Sanchez <ben_sanchez@worldnet.att.net>
Date: Fri, 28 Jan 2000 00:56:26 -0800
Links: << >>  << T >>  << A >>
Motorola has a great line of ECL, PECL, LVECL, and LVPECL devices.  The
best IMHO are the ECLinPS or 'Eclipse' line (because they are fully
differential, all the way through the internal logic and out again
(except for things like special single ended devices and/or translators
like this) and so when they operate, even at GHz operating frequencies,
they have di/dt nearly zero.

Now, sales pitch aside (kidding, I'm just a user) the device you need is
one I use frequently to convert high speed clocks distributed in LVPECL
to LVTTL/LVCMOS for use at the target device.  It is the MC100LVELT23
Dual Differential LVPECL to LVCMOS (LVTTL compatible) Translator.

See the following URL on Motorola's web site for info...

http://scgproducts.motorola.com/ProdSum.asp?base=MC100LVELT23

Enjoy,

Ben Sanchez

K wrote:
> 
> Hi.
> 
> I am working on a project that requires interfacing LVPECL I/Os from an ASIC
> to the FPGA. The FPGA I/Os are LVCMOS, LVTTL.  Can anybody guide me on how
> to approach this problem.  Unfortunately I cannot use a LVPECL based FPGA
> such as Virtex-E).
> 
> Thanks
> 
> Karen
Article: 20136
Subject: Re: ADC to DSP... FIFO?
From: russell shaw <russell@webaxs.net>
Date: Fri, 28 Jan 2000 21:23:54 +1100
Links: << >>  << T >>  << A >>
Ah, but the bit that should be free is most expensive (the software that
gives you the privelidge of using said cheep chips).
 

Peter Alfke wrote:
> 
> FPGAs offer you all the flexibility you could possibly ask for, and they
> are not expensive any more.
> 
> 

-- 
*******************************************
*   Russell Shaw, B.Eng, M.Eng(Research)  *
*   Electronics Consultant                *
*      email: russell@webaxs.net          *
*      Australia                          *
*******************************************
Article: 20137
Subject: Re: Why Sinplicity make combinatorial loops from latches ?
From: Bonio Lopez <bonio.lopezNOboSPAM@gmx.ch.invalid>
Date: Fri, 28 Jan 2000 02:46:01 -0800
Links: << >>  << T >>  << A >>
But I have anothe problem, I get not latches  but compinatorial logic
with loops


In article <86pmg8$3kb$1@info3.fnal.gov>, husby@fnal.gov (Don Husby)
wrote:
> Bonio Lopez <bonio.lopezNOboSPAM@gmx.ch.invalid> wrote:
> > but simpisity synthesize some memory cells (quite many of them)
> as
> > combinatorial loops.
> I saw this happen when the number of memory words was not exactly
> a power
> of 2.  For example, I had a memory array defined as (16 downto 0)
> instead
> of (15 downto 0).  Synplicity tried to synthesize the extra memory
> word as
> flip-flops instead of LUT-SRAM.  If I increased the size to (31
> downto 0)
> it would use the SRAM.
> --
> Don Husby <husby@fnal.gov>
> http://www-ese.fnal.gov/people/husby
> Fermi National Accelerator Lab                          Phone:
> 630-840-3668
> Batavia, IL 60510                                         Fax:
> 630-840-5406



* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!

Article: 20138
Subject: Re: ADC to DSP... FIFO?
From: Keith Wootten <Keith@wootten.demon.co.uk>
Date: Fri, 28 Jan 2000 14:11:48 +0000
Links: << >>  << T >>  << A >>
In article <MPG.12fa7a0ba5f0a8d898970f@news.erols.com>, Lee Cao
<ligeng@NOSPAMleecao.com> writes

[snipped]

>Help!!!
>
>I am looking for a way to acquire 11 channels of 12-bit data at 11kHz.
>The DSP I am using is a Texas Instrument TMS320C32, the 60MHz one.
>
>The DSP needs to do quite a bit of number crunching so I was hoping 
>that there could be some way of automating/buffering the incomining
>data from the ADC at the rate of approximately 200kBytes/s.  I don't
>think that having the DSP interrupted 11,000 times per second to 
>service the ADC is going to work.

Why not? - that's about 90 us, which is a lot of instructions.  It
sounds a lot simpler and more deterministic than messing about with
external buffering.

I'm a great stack machine fan, where interrupt overheads are usually
very small (you don't need to stack registers, they're already there),
but I'm sure a register-based processor can do it with appropriate
register allocation.

Cheers
-- 
Keith Wootten
Article: 20139
Subject: Re: licenses
From: "Keith Jasinski, Jr." <jasinski@mortara.com>
Date: Fri, 28 Jan 2000 08:34:00 -0600
Links: << >>  << T >>  << A >>
This guy is posting an offer to pirate any package for you, but only some.
If he did them ALL, THAT would be immoral.

Give me a break!

--
Keith F. Jasinski, Jr.
kfjasins@execpc.com
<eda1000@my-deja.com> wrote in message news:86pu80$g47$1@nnrp1.deja.com...
> I offer perfectly valid licenses for all tools protected by FLEXlm.
> Imagine having the latest editions of ModelsimEE, Synplify, Renoir,
> Visual HDL... You name it!!! The price is negotiable and very low. The
> licenses offered are any type you wish and for any time period, however
> I will not issue licenses with the HOSTID=ANY, since I find it immoral.
>
> I will ofcourse send you a temporary license to any prog before payment.
>
> Please use these addresses: eda1000@my-deja.com or eda1000@hotmail.com
>
> I expect these accounts to be shut down very soon, due to the nature of
> this posting, so I will send new postings regularly with my current e-
> mail address. Please look out for eda1000 in the body of the message.
>
> I gurantee that you will not be dissatisfied.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


Article: 20140
Subject: Program Xilinx Through TI DSP Serial McBSP
From: Mike Horwath <mikeh@merge.com>
Date: Fri, 28 Jan 2000 08:54:42 -0600
Links: << >>  << T >>  << A >>
Has anyone used TI serail McBSP to program Spartan XL.  If so how did
you accomplish this?

Thanks-

Mike

Article: 20141
Subject: Re: LVPECL I/O interface
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Fri, 28 Jan 2000 09:58:16 -0500
Links: << >>  << T >>  << A >>


Ben Sanchez wrote:

> Motorola has a great line of ECL, PECL, LVECL, and LVPECL devices.  The
> best IMHO are the ECLinPS or 'Eclipse' line (because they are fully
> differential, all the way through the internal logic and out again
> (except for things like special single ended devices and/or translators
> like this) and so when they operate, even at GHz operating frequencies,
> they have di/dt nearly zero.
>
> Now, sales pitch aside (kidding, I'm just a user) the device you need is
> one I use frequently to convert high speed clocks distributed in LVPECL
> to LVTTL/LVCMOS for use at the target device.  It is the MC100LVELT23
> Dual Differential LVPECL to LVCMOS (LVTTL compatible) Translator.
>
> See the following URL on Motorola's web site for info...
>
> http://scgproducts.motorola.com/ProdSum.asp?base=MC100LVELT23
>
> Enjoy,
>
> Ben Sanchez
>
> K wrote:
> >
> > Hi.
> >
> > I am working on a project that requires interfacing LVPECL I/Os from an ASIC
> > to the FPGA. The FPGA I/Os are LVCMOS, LVTTL.  Can anybody guide me on how
> > to approach this problem.  Unfortunately I cannot use a LVPECL based FPGA
> > such as Virtex-E).
> >
> > Thanks
> >
> > Karen

Having just completed a design with similar constraints (PECL signals into a 3.3
volt FPGA) I can agree with this statement.  Actually there is a whole family of
parts available depending on required speed, direction of signal flow, and number
of channels.  A second vendor to consider is Micrel.  The positives are a slightly
different product spectrum and lower cost (at least at the small purchase quantity
level.)  Motorola (now OnSemi) has the advantage of having a faster line of new
products and generally better availability.  In general the two basic part
numbering schemes are very similar and the pin-outs are identical.  Lately the
OnSemi web site has been highly uncooperative as far as downloading data sheets.
A possible alternative source might be Fairchild.  I don't know if they have any
low voltage PECL translators.  (By the way, that is what these parts are listed
as, LVPECL to LVTTL translators or vice versa).  The Fairchild parts are also
second sourced by Micrel.  The best stocking distributor for Micrel ECL family
parts that I have found is Future.  I don't work for them but I have been quite
impressed with the assistance they are willing to give the little guy.


Article: 20142
Subject: Re: LVPECL I/O interface
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Fri, 28 Jan 2000 09:58:48 -0500
Links: << >>  << T >>  << A >>


Ben Sanchez wrote:

> Motorola has a great line of ECL, PECL, LVECL, and LVPECL devices.  The
> best IMHO are the ECLinPS or 'Eclipse' line (because they are fully
> differential, all the way through the internal logic and out again
> (except for things like special single ended devices and/or translators
> like this) and so when they operate, even at GHz operating frequencies,
> they have di/dt nearly zero.
>
> Now, sales pitch aside (kidding, I'm just a user) the device you need is
> one I use frequently to convert high speed clocks distributed in LVPECL
> to LVTTL/LVCMOS for use at the target device.  It is the MC100LVELT23
> Dual Differential LVPECL to LVCMOS (LVTTL compatible) Translator.
>
> See the following URL on Motorola's web site for info...
>
> http://scgproducts.motorola.com/ProdSum.asp?base=MC100LVELT23
>
> Enjoy,
>
> Ben Sanchez
>
> K wrote:
> >
> > Hi.
> >
> > I am working on a project that requires interfacing LVPECL I/Os from an ASIC
> > to the FPGA. The FPGA I/Os are LVCMOS, LVTTL.  Can anybody guide me on how
> > to approach this problem.  Unfortunately I cannot use a LVPECL based FPGA
> > such as Virtex-E).
> >
> > Thanks
> >
> > Karen

Having just completed a design with similar constraints (PECL signals into a 3.3
volt FPGA) I can agree with this statement.  Actually there is a whole family of
parts available depending on required speed, direction of signal flow, and number
of channels.  A second vendor to consider is Micrel.  The positives are a slightly
different product spectrum and lower cost (at least at the small purchase quantity
level.)  Motorola (now OnSemi) has the advantage of having a faster line of new
products and generally better availability.  In general the two basic part
numbering schemes are very similar and the pin-outs are identical.  Lately the
OnSemi web site has been highly uncooperative as far as downloading data sheets.
A possible alternative source might be Fairchild.  I don't know if they have any
low voltage PECL translators.  (By the way, that is what these parts are listed
as, LVPECL to LVTTL translators or vice versa).  The Fairchild parts are also
second sourced by Micrel.  The best stocking distributor for Micrel ECL family
parts that I have found is Future.  I don't work for them but I have been quite
impressed with the assistance they are willing to give the little guy.


Article: 20143
Subject: Spartan XL
From: Rastislav Struharik <rasti74@iname.com>
Date: Fri, 28 Jan 2000 15:59:09 +0100
Links: << >>  << T >>  << A >>
Hi everyone,

For my next project I am planing to use Xilinx SpartanXL in 240-pin or
208-pin PQFP package. For the prototyping phase I would like to use
some kind of an adapter or even better socket that converts PQFP into
thruhole type device for easier handling. 
I have found a company named NPLAS that offers PQFP sockets. As an
answer to my enquiry they gave me these two part numbers:
PQFP 208pin socket:  OTQ-208-0.5-01
PQFP 240pin socket:  OTQ-240-0.5-01
but in the following text they stated that they are uncertain that the
sockets would fit Xilinx PQFP's.

Has anyone used these sockets, and if so do they fit Xilinx PQFP
packages?
Can anyone suggest me some other manufacturer of PQFP sockets or give
me some other alternative?

Thanks in advance

Rastislav Struharik
Article: 20144
Subject: Re: ARM core?
From: Tim Tyler <tt@cryogen.com>
Date: Fri, 28 Jan 2000 15:19:54 GMT
Links: << >>  << T >>  << A >>
"¹Ú±¸¿ë" <hereim@maru.comtec.re.kr> wrote:

: what is the ARM core? Is there any site or Book for this question?

http://www.arm.com/

Strewth, that globe is getting mighty small these days ;-)

ARM Architecture Reference Manual - D. Jaggar;
ARM System Architecture - S.Furber;
The ARM RISC Chip, A Programmer's Guide A. van Someron & C. Atack.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  tt@cryogen.com

Many are cold, but few are frozen.
Article: 20145
Subject: Re: Atmel config PROMs
From: Werner Dreher <dreher@informatik.uni-tuebingen.de>
Date: Fri, 28 Jan 2000 16:48:53 +0100
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
 
> I used these parts a couple of years ago & they were fine EXCEPT for one
> problem. The first byte of config data was only loaded into the serialiser
> on power-up and not every time RESET was asserted. In fact it was much
> worse than this since even a power cycle didn't always load the first byte
> correctly.
> [...]

This problem may be solved. I use Atmel AT17C128 and AT17C256, they work
fine, after reset also.

- Werner
Article: 20146
Subject: Xilinx vs Altera
From: Shawki Areibi <sareibi@uoguelph.ca>
Date: Fri, 28 Jan 2000 11:24:19 -0500
Links: << >>  << T >>  << A >>
We are introducing a new course on Digital Design at the School of
Engineering
at the University of Guelph. We would like to choose between the Altera
MAXII-Plus and the Xilinx Foundation Series Software.
Anyone with the experience of using the two systems? Which is better to
use
by the students (i.e simpler to use e.t.c)
Thanks,
Shawki Areibi

--
Shawki Areibi
Assistant Professor
School of Engineering
University of Guelph
Guelph, Ont, Canada N1G 2W1
Tel: (519) 824-4120
Fax: (519) 836-0227


Article: 20147
Subject: Re: ADC to DSP... FIFO?
From: csjacobs@my-deja.com
Date: Fri, 28 Jan 2000 16:40:56 GMT
Links: << >>  << T >>  << A >>


> >I am looking for a way to acquire 11 channels of 12-bit data at
11kHz.
> >The DSP I am using is a Texas Instrument TMS320C32, the 60MHz one.
> >
> >The DSP needs to do quite a bit of number crunching so I was hoping
> >that there could be some way of automating/buffering the incomining
> >data from the ADC at the rate of approximately 200kBytes/s.  I don't
> >think that having the DSP interrupted 11,000 times per second to
> >service the ADC is going to work.



Why don't you just use the on-board dma controller?  I'm not a user of
the c32, but I looked and it has 2 dma controllers.    I use this
method on the other non-TI chips all the time.   all you have to do is
set up a few registers in your DSP, wire up a few external dma control
pins, and you're good to go.   Then you don't need any fifo's at all.
Just a thought

Craig Jacobs


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 20148
Subject: Re: ADC to DSP... FIFO?
From: Jerry Avins <jya@ieee.org>
Date: Fri, 28 Jan 2000 12:18:31 -0500
Links: << >>  << T >>  << A >>
russell shaw wrote:
> 
> Ah, but the bit that should be free is most expensive (the software that
> gives you the privelidge of using said cheep chips).
> 
> 
> Peter Alfke wrote:
> >
> > FPGAs offer you all the flexibility you could possibly ask for, and they
> > are not expensive any more.
> >
> >
> 
> --
> *******************************************
> *   Russell Shaw, B.Eng, M.Eng(Research)  *
> *   Electronics Consultant                *
> *      email: russell@webaxs.net          *
> *      Australia                          *
> *******************************************

Doesn't Altera let you have a limited-time license free?

Jerry
-- 
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Article: 20149
Subject: Re: Altera Quartus vs Xilinx Place and Route tools (help needed)
From: Ray Andraka <randraka@ids.net>
Date: Fri, 28 Jan 2000 17:41:52 GMT
Links: << >>  << T >>  << A >>
I hadn't considered a VCO made as a ring oscillator.  I'll have to noodle on that.
I'm pretty sure the DLL's loop filter function can be done digitally pretty easily
(require more than one phase miss before moving to a new delay tap).

Allan Herriman wrote:

> On Thu, 27 Jan 2000 15:26:31 GMT, Ray Andraka <randraka@ids.net>
> wrote:
>
> >Oh, one more thing,  The DLL is implemented basically as delay gates with
> >feedback, which allows it to be done in the same process as the SRAM
> >technology for the rest of the chip, with virtually nothing extra added to the
> >process or yield testing.  It's a totally digital circuit.  That means the
> >incremental cost of adding the DLL is virtually nothing after the NRE.
> >
> >Contrast that with a PLL, which by nature is an analog animal.  That means
> >extra care is required in the fab, as there are parameters that have to be met
> >which would not have to be met for a strictly digital circuit.
>
> Ray, I disagree with your statements about DLLs and PLLs.  Both are
> implemented with delay lines made from gates.  Both use feedback to
> adjust the gate delay.  Both have an analog loop filter (but the DLL
> loop filter is simpler).
>
> About the only difference is that the PLL has the output of its delay
> line fed back to the input to make a ring oscillator.  The DLL has its
> input connected to the input clock signal.  This should give the DLL
> better jitter performance, but the quoted specs (A vs X) are
> identical.
>
> (BTW, I'm making some guesses about the implementations.  It is
> possible that they have been implemented in other ways.)
>
> Regards,
> Allan.
>
> >Magnus Homann wrote:
> >
> >> Steve Dewey <steve@s-dewey123.demon.co.uk> writes:
> >>
> >> > One point in this debate is that Xylinx seem to put the DLLs into ALL
> >> > the Virtex and Spartan parts. Altera definitely only puts them into
> >> > certain speed grades/packages/device sizes. So you have to pay extra and
> >> > probably not use the speed grade, package, or device size that you
> >> > thought.
> >>
> >> Well, wont you have to pay extra for the Xilinx DLLs all the time too?
> >>
> >> Homann
> >> --
> >> Magnus Homann, M.Sc. CS & E
> >> d0asta@dtek.chalmers.se
> >
> >--
> >-Ray Andraka, P.E.
> >President, the Andraka Consulting Group, Inc.
> >401/884-7930     Fax 401/884-7950
> >email randraka@ids.net
> >http://users.ids.net/~randraka
> >
> >

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka




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