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 27025

Article: 27025
Subject: Re: help on a simple ALU
From: "Qian Zhang" <qianz@cae.wisc.edu>
Date: Tue, 7 Nov 2000 19:44:59 -0600
Links: << >>  << T >>  << A >>
I remember there is some function
like CONV_INTEGER (UNSIGN ***)
Dont remember exactly
but there are such functions to turn the std_logic_vector to integer

Jim Patterson <jpatters@stny.rr.com> wrote in message
news:T4XK5.99848$JS3.15201591@typhoon.nyroc.rr.com...
> Just starting at the VHDL so be gentle.  I am doing a simple ALU for my
> class.  Having trouble with the various types in VHDL.  I am trying to do
a
> case statement on the control input (opcode).  When I get to the code that
> says to add, subtract, and, or,  etc.  I get errors.  The errors are
usually
> type mismatches.  It seems like some operations (add, subtract) what the
> inputs to be integers while other operations (and, or) what them to be
> bit_vectors or std_logic_vectors.  How can I do this?  I have tried
several
> different things and can't get it going.  I know this is simple and I am
> just missing something (I hope).  Thanks a bunch.
>
> --
> Jim Patterson
> jpatters@stny.rr.com
>
>


Article: 27026
Subject: Re: ANNOUNCE: New article about Network Processors
From: Michael Barr <mbarr@netrino.com>
Date: Wed, 08 Nov 2000 02:33:58 GMT
Links: << >>  << T >>  << A >>
Jerry Avins wrote:
> 
> Michael Barr wrote:
> >
> > I have just posted the article "NP Complete: An Introduction to Network
> > Processing" to the Netrino website.  It can be found at the following URL:
> >
> >         http://www.netrino.com/Articles/NetworkProcessors/
> >
>   ...
> 
> Michael,
> 
> A good pun is priceless! I hope, though, that you don't mean to imply
> that Network Processing is isomorphic to the Traveling Salesman Problem.

Draw your own conclusion.  ;-)

Cheers,
	Michael

Article: 27027
Subject: Re: 'event synthesis question
From: Muzaffer Kal <muzaffer@dspia.com>
Date: 08 Nov 2000 02:35:18 GMT
Links: << >>  << T >>  << A >>
"Qian Zhang" <qianz@cae.wisc.edu> wrote:
>
>Here I have a signal-- REALCONTROL,
> it changes at the rising clock cycle,
>and if it changes, the next following clock cycle
>other signals need to be changed correspondingly
>so I use
>         elsif REALCONTROL'event then
>                       CHANGEC:='1';
>          elsif REALPHASE'event then
>                     CHANGEP:='1';
>          end if;
>end process COUNTER_Gen;
>However sysopsis told me
>Checking...
> Error   L139/C0 : #0 Error: The 'event or 'stable attribute ( on line 139 )
> is supported only when the attribute is used in conformance with the style
>described in the Synopsys manual for the VHDL compiler.  (VHDL-2160)
> 1 error(s) 0 warning(s) found
>Can anyone do me a favor to tell me how to fix it?
>Thank you very very much!
>

For design compiler to recognize a register, you have to code it in a
certain way. I am not sure why you are checking REALCONTROL'event
twice above but assuming that's a typo, here is what you should do:

process (REALCONTROL) begin
	if REALCONTROL'event and REALCONTROL = '1' then
		CHANGEP <= '1';
	endif;
endprocess;

If you want a reset, you can do this:

process (REALCONTROL, rst) begin
	if rst = '1' then
		CHANGEP <= '0';
	elsif REALCONTROL'event and REALCONTROL = '1' then
		CHANGEP <= '1';
	endif;
endprocess;

Muzaffer
http://www.dspia.com

Article: 27028
Subject: PLL vs DLL
From: Anshuman Sharma <gte600f@prism.gatech.edu>
Date: 8 Nov 2000 03:30:25 GMT
Links: << >>  << T >>  << A >>
I'm working on designing a low level packet filter on an FPGA. Since it
needs run at very high speeds, which would be more advisable to use, PLL
or a DLL?

-- 
Anshuman Sharma
Georgia Institute of Technology

Article: 27029
Subject: Re: Spartan2 macros in WebPACK
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 07 Nov 2000 20:11:29 -0800
Links: << >>  << T >>  << A >>
Tim Jaynes <tim.jaynes@xilinx.com> writes:
> Macros can only be used if you have a schematic flow-
> If you had a supported schematic tool you could use them in an HDL flow by
> creating a netlist w/ hierarchical ports and instantiating that in your code,
> but as of now schematic entry in WebPACK only supports CPLDs.

Does this mean that I can't use RAM in my VHDL designs when using
WebPACK?  That would seem like quite a limitation.


Article: 27030
Subject: Re: 'event synthesis question
From: "Qian Zhang" <qianz@cae.wisc.edu>
Date: Tue, 7 Nov 2000 22:47:52 -0600
Links: << >>  << T >>  << A >>

Hi Muzaffer

Thank you very much!
However I still am not very clear,
here what if the REALCONTROL='0'?
Which means I dont care what REALCONTROL is,
only if it changes, I can let CHANGEC<=1.
Thanks again in advance

> wrote in message news:5tig0ts23g06hknbd8t811jnf95e75evj4@4ax.com...
> "Qian Zhang" <qianz@cae.wisc.edu> wrote:
> >
> >Here I have a signal-- REALCONTROL,
> > it changes at the rising clock cycle,
> >and if it changes, the next following clock cycle
> >other signals need to be changed correspondingly
> >so I use
> >         elsif REALCONTROL'event then
> >                       CHANGEC:='1';
> >          elsif REALPHASE'event then
> >                     CHANGEP:='1';
> >          end if;
> >end process COUNTER_Gen;
> >However sysopsis told me
> >Checking...
> > Error   L139/C0 : #0 Error: The 'event or 'stable attribute ( on line
139 )
> > is supported only when the attribute is used in conformance with the
style
> >described in the Synopsys manual for the VHDL compiler.  (VHDL-2160)
> > 1 error(s) 0 warning(s) found
> >Can anyone do me a favor to tell me how to fix it?
> >Thank you very very much!
> >
>
> For design compiler to recognize a register, you have to code it in a
> certain way. I am not sure why you are checking REALCONTROL'event
> twice above but assuming that's a typo, here is what you should do:
>
> process (REALCONTROL) begin
> if REALCONTROL'event and REALCONTROL = '1' then
> CHANGEP <= '1';
> endif;
> endprocess;
>
> If you want a reset, you can do this:
>
> process (REALCONTROL, rst) begin
> if rst = '1' then
> CHANGEP <= '0';
> elsif REALCONTROL'event and REALCONTROL = '1' then
> CHANGEP <= '1';
> endif;
> endprocess;
>
> Muzaffer
> http://www.dspia.com



Article: 27031
Subject: Re: ViewLogic ViewDraw questions
From: "Austin Franklin" <austin@darkroom89.com>
Date: 8 Nov 2000 06:49:05 GMT
Links: << >>  << T >>  << A >>

> > > Use logiblox or coregen to set a constant.
> >
> > Why not use a buf and tie power/ground on the input side to what ever
> your
> > constant wants to be?
> 
> This works just fine, but for large numbers the buffers take up a lot of
> room on the schematic sheet. Also, a logiblox constant is more readable
> from a documentation perspective.

That would not be an 'optimal' way to implement what I suggested.  I would
make a symbol, and put the bufs etc. under the symbol...and that documents
it pretty well if you put a number in the middle of the symbol, and name
the symbol something 'intelligent'.

Hierarchy should be part of any well drawn schematic, especially with
FPGAs, and making re-usable modules (such as constants, registers etc.)
will make your designs easier to do and easier to read.


Article: 27032
Subject: Re: Encoding of FSMs internal states
From: Michal Prokes <michal.prokes@asicentrum.cz>
Date: Wed, 08 Nov 2000 09:40:44 +0100
Links: << >>  << T >>  << A >>
Thank You,
but I know, How can I do it (encoding of internal states in VHDL).

I performed many test with encoding and I need some literature to comparing
my results to other. And the second reason is that I need some
cross-references into my diploma thesis about this problem.

MICHAL

yuryws@my-deja.com wrote:

> Look at chapter "Synthesis and Simulation Design Guide" after following
> the link below:
>     http://toolbox.xilinx.com/docsan/2_1i/
>
> In article <3A06C0EB.A4BCDFB6@asicentrum.cz>,
>   Michal Prokes <michal.prokes@asicentrum.cz> wrote:
> > Hello,
> > I'm student and I'm interested in encoding of internal states in FSMs
> > (finite state machine) in relation to realization these FSMs to Xilinx
> > FPGA.
> > I try to use different encoding of internal states (binary, gray,
> > johnson, onehot, twohots, fanin ... etc) and I woud like to find out
> > some relations between encoding and number of used CLBs, etc..
> >
> > So, could you send me some tips to literature or www links (about
> this)?
> >
> > Thanks,
> >
> > MICHAL  (michal.prokes@asicentrum.cz)
> >
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


Article: 27033
Subject: Re: Anything wrong with Xilinx website?
From: Jean-Marie Bussat <bussat@cern.ch>
Date: Wed, 08 Nov 2000 10:23:48 +0100
Links: << >>  << T >>  << A >>
"Frank Z.F Xie" wrote:
> 
> These days I failed to connect www.xilinx.com from here, does anybody have
> the same experience?
> 

Me too. Cannot connect since yesterday...

-- 
 +------------------------------------------------------------+
 | Jean-Marie Bussat - Dept. of physics, Princeton University |
 | CERN/EP - Bldg. 15-S-012 - CH-1211 GENEVA 23 - Switzerland |
 | Email: bussat@cern.ch                                      |
 | Tel: (41 22) 767 32 41              Fax: (41 22) 767 32 41 |
 +------------------------------------------------------------+
              http://suncmspri1.cern.ch:800/~bussat

Article: 27034
Subject: Re: Anything wrong with Xilinx website?
From: "Mike H." <mikeh@spamlessimageproc.com>
Date: Wed, 8 Nov 2000 12:40:51 -0000
Links: << >>  << T >>  << A >>

"Frank Z.F Xie" <frank.xie@latticesemi.com> wrote in message news:8uaa0m$int$1@info.sta.net.cn...
> These days I failed to connect www.xilinx.com from here, does anybody have
> the same experience?

I've been trying to download the latest service pack for the
last few days, but can't seem to get better than 1k bytes/sec
transfer rate.

MH


Article: 27035
Subject: Re: Anything wrong with Xilinx website?
From: Dirk Galda <galda@tu-harburg.de>
Date: Wed, 08 Nov 2000 14:04:27 +0100
Links: << >>  << T >>  << A >>
It seems that it strongly depends on time and location. I had no problem
downloading the new servies pack 5 which has approx. 50MB within serveral
minutes yesterday afternoon (CET) from Germany.

Dirk

"Frank Z.F Xie" schrieb:

> These days I failed to connect www.xilinx.com from here, does anybody have
> the same experience?
>
> --
>
> Zhengfan Xie

--
+----------------------------------+----------------------------------+
| Dirk Galda                       |                                  |
|                                  |                                  |
| TU Hamburg-Harburg               |                                  |
| Department of Telecommunications | Phone:  (++49)-40-42878-2745     |
| Eißendorfer Straße 40            | Fax:    (++49)-40-42878-2281     |
| 21073 Hamburg                    | mailto:galda@tu-harburg.de       |
| Germany                          | http://www.et2.tu-harburg.de     |
+----------------------------------+----------------------------------+



Article: 27036
Subject: Re: unique serial nr
From: "Gary Watson" <gary2@nexsan.com>
Date: Wed, 8 Nov 2000 14:43:42 -0000
Links: << >>  << T >>  << A >>

Bitgen has an option to load a 8 character hexidecimal number into the "User
ID Register" whatever the heck that is.  I've been looking through the
Xilinx docs and can't find an answer.  It might be a JTAG thing, and not
something inside the Virtex/Spartan which I can read once the device is
programmed.

Someone privately suggested to me that you could put the serial number in
the config prom after the config data, and use an external mux on cclk to
milk the bits out ot the config prom and into an I/O pin.   I'm concerned
about the MTBF reduction caused by using a low-tech part in such a critical
area, though it only has to work once, at power up...

--

Gary Watson
gary2@nexsan.com
Nexsan Technologies Ltd.
Derby DE21 7BF  ENGLAND
http://www.nexsan.com


"Hal Murray" <murray@pa.dec.com> wrote in message
news:8ua6pd$57s@src-news.pa.dec.com...
>
> > Is there any possibilty to create a bistream for a Xilinx spartan XCS30
with
> > a unique serial nr (e.g. in a register or hardwired)?
> >
> > I need approx 25000 systems/year and can not afford an extra component
like
> > the Dallas serial nr components.
>
> Somebody else asked the same thing on another thread.
>
> This seems like a good topic for a Xilinx APP note.
>
>
> It sounds like a reasonably straight forward thing to do.  Just put
> the serial number in a ROM.  You can either re-run the Xilinx tools
> to make the special bit stream for each device or you can work out
> how to do modify the basic bitstream.
>
> If I wanted to do it myself, I'd do something like this:
>
>   Put all 0s in the ROM.  Make your bits.
>
>   Change the ROM contents to 1.  Make the bits again and see which
>   bit(s) changed.
>
>   Repeat for all the other bits on the ROM.
>
> The bit stream may have a CRC to complicate things.  I couldn't find
> the details in the Virtex data sheet.  You can probably just XOR
> those changed bits too.  (CRCs are nice that way.)
>
>
> But you should really think about doing this.  You now have to make
> a separate bit stream for each device.  You have to make sure you get it
> right.  How bad is it if you get it wrong, for example by shipping two
> boxes with the same serial number?
>
> Also look into Ethernet HostID ROMs.
>
>
> --
> These are my opinions, not necessarily my employers.  I hate spam.
>



Article: 27037
Subject: renoir, acex + dpram
From: "Roland Manders" <roland.manders@philips.com>
Date: Wed, 8 Nov 2000 15:57:00 +0100
Links: << >>  << T >>  << A >>
Hi,

Can anyone tell me how to instantiate dpram by using renoir as entry
programs. I mean how can I infer
the package for the Altera ACEX in renoir.

Thanks.

Roland



Article: 27038
Subject: Boundary Scan fundamentals
From: "Alex Sherstuk" <sherstuk@iname.com>
Date: Wed, 8 Nov 2000 18:49:15 +0300
Links: << >>  << T >>  << A >>
Dear colleagues,

   I am looking for a good introductory document for doing boundary scan via
JTAG. I am intending to implement self-testing functionality on embedded
system comprising XILINX FPGA and TI DSP. So, I can not use "of the shelf"
hardware/software solution, and should start from the very beginning:
sequences of JTAG signals, JTAG command codes, ...
Where can I find such basic information?

Thanks,
   Alex Sherstuk




Article: 27039
Subject: WebPack problem
From: Wojciech Madejski <madej@via.gate.pl>
Date: Wed, 08 Nov 2000 17:15:50 +0100
Links: << >>  << T >>  << A >>
Hi,

I've instaled WebPack 3.2 on Silicon Graphics computer with Win NT4.0
(Service Pack 4) adn when I try to synthesize design I get information
about some errors
ERROR : VHP__3024 Cannot read library unit jc2_top. It has been stored
before the predefined library
                                     unit std_logic_1164 of library
ieee. Clean your dump directory and recompile your
                                     design again.
I don't know what to do to avoid this error.I'm waiting for your help

Thanks
Wojciech Madejski




Article: 27040
Subject: Re: Boundary Scan fundamentals
From: dave_bernard@my-deja.com
Date: Wed, 08 Nov 2000 16:22:13 GMT
Links: << >>  << T >>  << A >>
In article <8ubslk$1btff$1@ID-27424.news.dfncis.de>,
  "Alex Sherstuk" <sherstuk@iname.com> wrote:
> Dear colleagues,
>
>    I am looking for a good introductory document for doing boundary
scan via
> JTAG. I am intending to implement self-testing functionality on
embedded
> system comprising XILINX FPGA and TI DSP. So, I can not use "of the
shelf"
> hardware/software solution, and should start from the very beginning:
> sequences of JTAG signals, JTAG command codes, ...
> Where can I find such basic information?
>
> Thanks,
>    Alex Sherstuk
>

http://www-s.ti.com/sc/psheets/ssya002c/ssya002c.pdf

Regards,

  Dave


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27041
Subject: Global buffers in xc40000xla
From: prc <prc@eiv.ch>
Date: Wed, 08 Nov 2000 17:33:36 +0100
Links: << >>  << T >>  << A >>
I have a problem concerning the global buffers (BUFG) in a xc4062xla
fpga from xilinx. I have 2 clocks signals using them in a design (the
second clock is internal). I can see these buffers in the xnf netlist.
During Place & Route the design manager gives me a warning saying that
my internal clock is using non-dedicated resources.

Can somebody help me?

Thanks


Article: 27042
Subject: Re: PLL vs DLL
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 08 Nov 2000 09:46:54 -0800
Links: << >>  << T >>  << A >>

--------------20355C97D5FCEB4DF06F691F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anshuman,

The DLL is not a PLL.  A PLL is not the DLL.  They both have their
advantages and disadvantages.  Thanks for the opportunity to respond on this
topic.

Virtex Family DLL's

The DLL's in Virtex is an all digital device with a state machine, and
tapped delay line.  The result of using it is always predictable, and it
will always be the same on any chip ever manufactured.

It is unaffected by voltage, temperature, and process due to its design.

The jitter out of the CLK0 output is a fixed known amount +/- one tap (~40
ps).  DLL's do not filter out the input jitter, they pass it through.

The jitter input tolerance is as stated in the data sheet, and if exceeded,
the device will not assert the LOCK signal, or it will lose LOCK if it locks
at all.

All outputs (0, 90 degrees, 180 degrees, 270 degrees, 2X, CLKDV) behave in
this precise predictable digital fashion.

The absolute phase error of the DLL is constrained to a tap, combined with
the error in matching the two inputs (in and feedback) to the DLL (also very
small because the of the physical layout).

The DLL is designed to run as fast as the global clock buses, so speed
inside the FPGA is not an issue (can't go any faster).  The input range of
the DLL is much larger than that of a PLL.

PLL's

A phase locked loop is an analog device with a voltage or current controlled
oscillator (RC, LC, inverter ring, crystal, etc), a phase detector, and a
loop filter.  Each one is unique, and there may be significant variations in
lot to lot, and part to part.  It is not unusual to change components to
make PLL's work on the production floor.

PLL's are directly affected by voltage, temperature, process (and some claim
phases of the moon).

PLL's may have a lot, or no input jitter tolerance.  You have to look a Bode
Plot of the loop response to see if it is stable, and perform a number of
jitter tolerance and transfer tests on a number of units over temperature
and voltage.  You never really know if a PLL is locked (its analog!)

The jitter out of a PLL can be extremely small (a few ps), or very very
gross (~90 ps).  It depends entirely on the design, filter, oscillator
chosen, and how much of the digital signals disturb the operation of the
PLL's loop.  PLL's are able to filter out input jitter if designed properly.

PLL's have no outputs other than the oscillator output, which may be running
a twice the intended frequency to yield 180 degrees, or even higher if more
phases are required.

The phase error of the PLL varies with voltage, temperature, and process,
and is difficult to contrain when trying to de-skew clock signals.  It is
often unspecified due to the extreme difficulties in characterization and
test.

PLL's can run at arbitraily high speeds (GHz), but offer narrow ranges of
operation.

Which to use?

If you are dealing with digital signals, in the digital domain, and you are
processing and modifying these signals, then the DLL is a natural choice.

If you need to filter jitter, then you may have to use the PLL.  If that is
the case, an off-chip PLL, where you can use your own filter, and oscillator
may be the only way to go.

PLL's that are co-located with other digital logic tend to add as much
jitter as they are trying to remove.

If you are in a communications system, with carrier frequencies, IF's, up
converters, and down converters, you will be using many PLL's, and be
miserable for it....always waiting for that phone call: "line down, PLL's
not locking, again!"

Austin Lesea
Principal Engineer, FPGA Lab
Xilinx

Anshuman Sharma wrote:

> I'm working on designing a low level packet filter on an FPGA. Since it
> needs run at very high speeds, which would be more advisable to use, PLL
> or a DLL?
>
> --
> Anshuman Sharma
> Georgia Institute of Technology

--------------20355C97D5FCEB4DF06F691F
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Anshuman,
<p>The DLL is not a PLL.&nbsp; A PLL is not the DLL.&nbsp; They both have
their advantages and disadvantages.&nbsp; Thanks for the opportunity to
respond on this topic.
<p><b>Virtex Family DLL's</b>
<p>The DLL's in Virtex is an all digital device with a state machine, and
tapped delay line.&nbsp; The result of using it is always predictable,
and it will always be the same on any chip ever manufactured.
<p>It is unaffected by voltage, temperature, and process due to its design.
<p>The jitter out of the CLK0 output is a fixed known amount +/- one tap
(~40 ps).&nbsp; DLL's do not filter out the input jitter, they pass it
through.
<p>The jitter input tolerance is as stated in the data sheet, and if exceeded,
the device will not assert the LOCK signal, or it will lose LOCK if it
locks at all.
<p>All outputs (0, 90 degrees, 180 degrees, 270 degrees, 2X, CLKDV) behave
in this precise predictable digital fashion.
<p>The absolute phase error of the DLL is constrained to a tap, combined
with the error in matching the two inputs (in and feedback) to the DLL
(also very small because the of the physical layout).
<p>The DLL is designed to run as fast as the global clock buses, so speed
inside the FPGA is not an issue (can't go any faster).&nbsp; The input
range of the DLL is much larger than that of a PLL.
<p><b>PLL's</b>
<p>A phase locked loop is an analog device with a voltage or current controlled
oscillator (RC, LC, inverter ring, crystal, etc), a phase detector, and
a loop filter.&nbsp; Each one is unique, and there may be significant variations
in lot to lot, and part to part.&nbsp; It is not unusual to change components
to make PLL's work on the production floor.
<p>PLL's are directly affected by voltage, temperature, process (and some
claim phases of the moon).
<p>PLL's may have a lot, or no input jitter tolerance.&nbsp; You have to
look a Bode Plot of the loop response to see if it is stable, and perform
a number of jitter tolerance and transfer tests on a number of units over
temperature and voltage.&nbsp; You never really know if a PLL is locked
(its analog!)
<p>The jitter out of a PLL can be extremely small (a few ps), or very very
gross (~90 ps).&nbsp; It depends entirely on the design, filter, oscillator
chosen, and how much of the digital signals disturb the operation of the
PLL's loop.&nbsp; PLL's are able to filter out input jitter if designed
properly.
<p>PLL's have no outputs other than the oscillator output, which may be
running a twice the intended frequency to yield 180 degrees, or even higher
if more phases are required.
<p>The phase error of the PLL varies with voltage, temperature, and process,
and is difficult to contrain when trying to de-skew clock signals.&nbsp;
It is often unspecified due to the extreme difficulties in characterization
and test.
<p>PLL's can run at arbitraily high speeds (GHz), but offer narrow ranges
of operation.
<p><b>Which to use?</b><b></b>
<p>If you are dealing with digital signals, in the digital domain, and
you are processing and modifying these signals, then the DLL is a natural
choice.
<p>If you need to filter jitter, then you may <i>have</i> to use the PLL.&nbsp;
If that is the case, an off-chip PLL, where you can use your own filter,
and oscillator may be the only way to go.
<p>PLL's that are co-located with other digital logic tend to add as much
jitter as they are trying to remove.
<p>If you are in a communications system, with carrier frequencies, IF's,
up converters, and down converters, you will be using many PLL's, and be
miserable for it....always waiting for that phone call: <b><i>"line down,
PLL's not locking, again!"</i></b>
<p>Austin Lesea
<br>Principal Engineer, FPGA Lab
<br>Xilinx
<p>Anshuman Sharma wrote:
<blockquote TYPE=CITE>I'm working on designing a low level packet filter
on an FPGA. Since it
<br>needs run at very high speeds, which would be more advisable to use,
PLL
<br>or a DLL?
<p>--
<br>Anshuman Sharma
<br>Georgia Institute of Technology</blockquote>
</html>

--------------20355C97D5FCEB4DF06F691F--


Article: 27043
Subject: Re: Boundary Scan fundamentals
From: Brian Philofsky <brian.philofsky@xilinx.com>
Date: Wed, 08 Nov 2000 10:51:42 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------ACFD1FAC06600901C0C3498A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



I suggest looking at the Xilinx Boundary Scan/JTAG Technical Tips page at:
http://support.xilinx.com/support/techsup/journals/jtag/index.htm

Click on the "Getting Started" Link and hopefully many of your questions can be
answered there.


--  Brian




Alex Sherstuk wrote:

> Dear colleagues,
>
>    I am looking for a good introductory document for doing boundary scan via
> JTAG. I am intending to implement self-testing functionality on embedded
> system comprising XILINX FPGA and TI DSP. So, I can not use "of the shelf"
> hardware/software solution, and should start from the very beginning:
> sequences of JTAG signals, JTAG command codes, ...
> Where can I find such basic information?
>
> Thanks,
>    Alex Sherstuk

--------------ACFD1FAC06600901C0C3498A
Content-Type: text/x-vcard; charset=us-ascii;
 name="brian.philofsky.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brian Philofsky
Content-Disposition: attachment;
 filename="brian.philofsky.vcf"

begin:vcard 
n:Philofsky;Brian
tel;work:1-800-255-7778
x-mozilla-html:TRUE
url:http://www.xilinx.com
org:Xilinx, Inc.;Software Marketing
adr:;;2300 55th Street;Boulder;CO;80301;USA
version:2.1
email;internet:brianp@xilinx.com
title:Sr. Technical Marketing Engineer
fn:Brian Philofsky
end:vcard

--------------ACFD1FAC06600901C0C3498A--


Article: 27044
Subject: Re: PLL vs DLL
From: erika_uk@my-deja.com
Date: Wed, 08 Nov 2000 18:37:45 GMT
Links: << >>  << T >>  << A >>
hi,
is it right than the PLL is able to deliver also any ratio...but the Dll
just integer or integer+0.5

--Erika
In article <3A09918E.246A77FF@xilinx.com>,
  Austin Lesea <austin.lesea@xilinx.com> wrote:
>
> --------------20355C97D5FCEB4DF06F691F
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Anshuman,
>
> The DLL is not a PLL.  A PLL is not the DLL.  They both have their
> advantages and disadvantages.  Thanks for the opportunity to respond
on this
> topic.
>
> Virtex Family DLL's
>
> The DLL's in Virtex is an all digital device with a state machine, and
> tapped delay line.  The result of using it is always predictable, and
it
> will always be the same on any chip ever manufactured.
>
> It is unaffected by voltage, temperature, and process due to its
design.
>
> The jitter out of the CLK0 output is a fixed known amount +/- one tap
(~40
> ps).  DLL's do not filter out the input jitter, they pass it through.
>
> The jitter input tolerance is as stated in the data sheet, and if
exceeded,
> the device will not assert the LOCK signal, or it will lose LOCK if it
locks
> at all.
>
> All outputs (0, 90 degrees, 180 degrees, 270 degrees, 2X, CLKDV)
behave in
> this precise predictable digital fashion.
>
> The absolute phase error of the DLL is constrained to a tap, combined
with
> the error in matching the two inputs (in and feedback) to the DLL
(also very
> small because the of the physical layout).
>
> The DLL is designed to run as fast as the global clock buses, so speed
> inside the FPGA is not an issue (can't go any faster).  The input
range of
> the DLL is much larger than that of a PLL.
>
> PLL's
>
> A phase locked loop is an analog device with a voltage or current
controlled
> oscillator (RC, LC, inverter ring, crystal, etc), a phase detector,
and a
> loop filter.  Each one is unique, and there may be significant
variations in
> lot to lot, and part to part.  It is not unusual to change components
to
> make PLL's work on the production floor.
>
> PLL's are directly affected by voltage, temperature, process (and some
claim
> phases of the moon).
>
> PLL's may have a lot, or no input jitter tolerance.  You have to look
a Bode
> Plot of the loop response to see if it is stable, and perform a number
of
> jitter tolerance and transfer tests on a number of units over
temperature
> and voltage.  You never really know if a PLL is locked (its analog!)
>
> The jitter out of a PLL can be extremely small (a few ps), or very
very
> gross (~90 ps).  It depends entirely on the design, filter, oscillator
> chosen, and how much of the digital signals disturb the operation of
the
> PLL's loop.  PLL's are able to filter out input jitter if designed
properly.
>
> PLL's have no outputs other than the oscillator output, which may be
running
> a twice the intended frequency to yield 180 degrees, or even higher if
more
> phases are required.
>
> The phase error of the PLL varies with voltage, temperature, and
process,
> and is difficult to contrain when trying to de-skew clock signals.  It
is
> often unspecified due to the extreme difficulties in characterization
and
> test.
>
> PLL's can run at arbitraily high speeds (GHz), but offer narrow ranges
of
> operation.
>
> Which to use?
>
> If you are dealing with digital signals, in the digital domain, and
you are
> processing and modifying these signals, then the DLL is a natural
choice.
>
> If you need to filter jitter, then you may have to use the PLL.  If
that is
> the case, an off-chip PLL, where you can use your own filter, and
oscillator
> may be the only way to go.
>
> PLL's that are co-located with other digital logic tend to add as much
> jitter as they are trying to remove.
>
> If you are in a communications system, with carrier frequencies, IF's,
up
> converters, and down converters, you will be using many PLL's, and be
> miserable for it....always waiting for that phone call: "line down,
PLL's
> not locking, again!"
>
> Austin Lesea
> Principal Engineer, FPGA Lab
> Xilinx
>
> Anshuman Sharma wrote:
>
> > I'm working on designing a low level packet filter on an FPGA. Since
it
> > needs run at very high speeds, which would be more advisable to use,
PLL
> > or a DLL?
> >
> > --
> > Anshuman Sharma
> > Georgia Institute of Technology
>
> --------------20355C97D5FCEB4DF06F691F
> Content-Type: text/html; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> <html>
> Anshuman,
> <p>The DLL is not a PLL.&nbsp; A PLL is not the DLL.&nbsp; They both
have
> their advantages and disadvantages.&nbsp; Thanks for the opportunity
to
> respond on this topic.
> <p><b>Virtex Family DLL's</b>
> <p>The DLL's in Virtex is an all digital device with a state machine,
and
> tapped delay line.&nbsp; The result of using it is always predictable,
> and it will always be the same on any chip ever manufactured.
> <p>It is unaffected by voltage, temperature, and process due to its
design.
> <p>The jitter out of the CLK0 output is a fixed known amount +/- one
tap
> (~40 ps).&nbsp; DLL's do not filter out the input jitter, they pass it
> through.
> <p>The jitter input tolerance is as stated in the data sheet, and if
exceeded,
> the device will not assert the LOCK signal, or it will lose LOCK if it
> locks at all.
> <p>All outputs (0, 90 degrees, 180 degrees, 270 degrees, 2X, CLKDV)
behave
> in this precise predictable digital fashion.
> <p>The absolute phase error of the DLL is constrained to a tap,
combined
> with the error in matching the two inputs (in and feedback) to the DLL
> (also very small because the of the physical layout).
> <p>The DLL is designed to run as fast as the global clock buses, so
speed
> inside the FPGA is not an issue (can't go any faster).&nbsp; The input
> range of the DLL is much larger than that of a PLL.
> <p><b>PLL's</b>
> <p>A phase locked loop is an analog device with a voltage or current
controlled
> oscillator (RC, LC, inverter ring, crystal, etc), a phase detector,
and
> a loop filter.&nbsp; Each one is unique, and there may be significant
variations
> in lot to lot, and part to part.&nbsp; It is not unusual to change
components
> to make PLL's work on the production floor.
> <p>PLL's are directly affected by voltage, temperature, process (and
some
> claim phases of the moon).
> <p>PLL's may have a lot, or no input jitter tolerance.&nbsp; You have
to
> look a Bode Plot of the loop response to see if it is stable, and
perform
> a number of jitter tolerance and transfer tests on a number of units
over
> temperature and voltage.&nbsp; You never really know if a PLL is
locked
> (its analog!)
> <p>The jitter out of a PLL can be extremely small (a few ps), or very
very
> gross (~90 ps).&nbsp; It depends entirely on the design, filter,
oscillator
> chosen, and how much of the digital signals disturb the operation of
the
> PLL's loop.&nbsp; PLL's are able to filter out input jitter if
designed
> properly.
> <p>PLL's have no outputs other than the oscillator output, which may
be
> running a twice the intended frequency to yield 180 degrees, or even
higher
> if more phases are required.
> <p>The phase error of the PLL varies with voltage, temperature, and
process,
> and is difficult to contrain when trying to de-skew clock
signals.&nbsp;
> It is often unspecified due to the extreme difficulties in
characterization
> and test.
> <p>PLL's can run at arbitraily high speeds (GHz), but offer narrow
ranges
> of operation.
> <p><b>Which to use?</b><b></b>
> <p>If you are dealing with digital signals, in the digital domain, and
> you are processing and modifying these signals, then the DLL is a
natural
> choice.
> <p>If you need to filter jitter, then you may <i>have</i> to use the
PLL.&nbsp;
> If that is the case, an off-chip PLL, where you can use your own
filter,
> and oscillator may be the only way to go.
> <p>PLL's that are co-located with other digital logic tend to add as
much
> jitter as they are trying to remove.
> <p>If you are in a communications system, with carrier frequencies,
IF's,
> up converters, and down converters, you will be using many PLL's, and
be
> miserable for it....always waiting for that phone call: <b><i>"line
down,
> PLL's not locking, again!"</i></b>
> <p>Austin Lesea
> <br>Principal Engineer, FPGA Lab
> <br>Xilinx
> <p>Anshuman Sharma wrote:
> <blockquote TYPE=CITE>I'm working on designing a low level packet
filter
> on an FPGA. Since it
> <br>needs run at very high speeds, which would be more advisable to
use,
> PLL
> <br>or a DLL?
> <p>--
> <br>Anshuman Sharma
> <br>Georgia Institute of Technology</blockquote>
> </html>
>
> --------------20355C97D5FCEB4DF06F691F--
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27045
Subject: Re: 'event synthesis question
From: steve (Steve Rencontre)
Date: Wed, 8 Nov 2000 18:45 +0000 (GMT Standard Time)
Links: << >>  << T >>  << A >>
In article <8uaap3$gao$1@news.doit.wisc.edu>, qianz@cae.wisc.edu (Qian 
Zhang) wrote:

> Here I have a signal-- REALCONTROL,
>  it changes at the rising clock cycle,
> and if it changes, the next following clock cycle
> other signals need to be changed correspondingly
> so I use
>          elsif REALCONTROL'event then
>                        CHANGEC:='1';
>           elsif REALPHASE'event then
>                      CHANGEP:='1';
>           end if;
> end process COUNTER_Gen;
> However sysopsis told me
> Checking...
>  Error   L139/C0 : #0 Error: The 'event or 'stable attribute ( on line 
> 139 )
>  is supported only when the attribute is used in conformance with the 
> style
> described in the Synopsys manual for the VHDL compiler.  (VHDL-2160)
>  1 error(s) 0 warning(s) found
> Can anyone do me a favor to tell me how to fix it?
> Thank you very very much!

Many features of VHDL are designed for simulation, and you are restricted 
in a synthesis context. Synthesis can only use 'event to infer clocks, so 
you need something like,

	signal last_control : std_logic;
	
	if CLK'event and CLK = '1' then		-- infers a +ve clock 
		if REALCONTROL /= last_control then
			CHANGEC <= '1';
		else
			CHANGEC <= '0';
		end if;
		
		last_control <= REALCONTROL;	-- infers a register
	end if;

--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>


Article: 27046
Subject: Re: Spartan2 macros in WebPACK
From: "Karl Olsen" <kro@post3.tele.dk>
Date: Wed, 8 Nov 2000 20:18:30 +0100
Links: << >>  << T >>  << A >>
Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote in message
news:qhbsvrhzm6.fsf@ruckus.brouhaha.com...
> Tim Jaynes <tim.jaynes@xilinx.com> writes:
> > Macros can only be used if you have a schematic flow-
> > If you had a supported schematic tool you could use them in an HDL flow
by
> > creating a netlist w/ hierarchical ports and instantiating that in your
code,
> > but as of now schematic entry in WebPACK only supports CPLDs.
>
> Does this mean that I can't use RAM in my VHDL designs when using
> WebPACK?  That would seem like quite a limitation.


No, I have found two ways of using BlockRAM.

1. Inferring it -- write VHDL code that the compiler recognizes and turns
into a BlockRAM (if you're lucky).  The WebPACK compiler turns this into a
512x8 single-port BlockRAM:

entity ent is
  ...
end ent;

architecture arch of ent is

type regfiletype is array (511 downto 0) of std_logic_vector (7 downto 0);
signal regfile   : regfiletype;
signal file_we   : boolean;
signal file_din  : std_logic_vector (7 downto 0);
signal file_dout : std_logic_vector (7 downto 0);
signal file_addr : std_logic_vector (8 downto 0);
signal ra        : std_logic_vector (8 downto 0);

begin

regfile_reg: process (clk)
begin
  if rising_edge(clk) then
    ra <= file_addr;
    if file_we then
    regfile (conv_integer(file_addr)) <= file_din;
  end if;
  end if;
end process;

file_dout <= regfile (conv_integer(ra));

end arch;



2. Instantiating a primitive.  The compiler will warn about an unknown
macro, but it will turn it into a BlockRAM.  I guess that the reason it
works is that RAMB4_S8 is a primitive and not a macro.  I have only tried
instantiating the RAMB4_S8, but I suppose that you can instantiate all the
library elements mentioned as primitives at
http://toolbox.xilinx.com/docsan/3_1i/data/common/lib/chap02/lib02003.htm .
In this way you can also specify initialization values with INIT_0x
attributes.

entity ent is
  ...
end ent;

architecture arch of ent is

component ramb4_s8
  port (
    we   : in  std_logic;
  en   : in  std_logic;
  rst  : in  std_logic;
  clk  : in  std_logic;
  addr : in  std_logic_vector (8 downto 0);
  di   : in  std_logic_vector (7 downto 0);
  do   : out std_logic_vector (7 downto 0));
end component;

signal ram_we   : std_logic;
signal ram_en   : std_logic;
signal ram_rst  : std_logic;
signal ram_clk  : std_logic;
signal ram_addr : std_logic_vector (8 downto 0);
signal ram_di   : std_logic_vector (7 downto 0);
signal ram_do   : std_logic_vector (7 downto 0);

begin

U1: ramb4_s8 port map (ram_we, ram_en, ram_rst, ram_clk, ram_addr, ram_di,
ram_do);

end arch;


Regards,
Karl Olsen



Article: 27047
Subject: Re: PLL vs DLL
From: Muzaffer Kal <muzaffer@dspia.com>
Date: 08 Nov 2000 19:36:51 GMT
Links: << >>  << T >>  << A >>
Austin Lesea <austin.lesea@xilinx.com> wrote:
>...  DLL's do not filter out the input jitter, they pass it through.

Is this really true ? Depending on how you decide to switch from tap
to tap, you can filter the input jitter to a degree. Effectively it
still depends on your loop filter which makes this decision.

Muzaffer
http://www.dspia.com

Article: 27048
Subject: problem with XC95288 with PC-104
From: "Simon Bilodeau" <simon.bilodeau@htrc.com>
Date: Wed, 08 Nov 2000 20:41:39 GMT
Links: << >>  << T >>  << A >>
Hi, I am developping an prototype board that is interfaced with PC-104 bus.
It works well but after 5 minutes I begin to read 0xFFFF on my board and
bizarre caracters appear on my screen..

Some bizarre caracters display when the PC is booting (without my program
running)

My board use 0x220 to 0x23F in I/O space with no interrupts.

all my VCC and GND are connected with decoupling capacitors and unused pins
(TIE) are connected to GND.

Any hint for me?

Thanks in advance

Simon Bilodeau
HTRC Paper Technologies.





Article: 27049
Subject: Re: Global buffers in xc40000xla
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Wed, 08 Nov 2000 13:51:03 -0700
Links: << >>  << T >>  << A >>
prc wrote:
> 
> I have a problem concerning the global buffers (BUFG) in a xc4062xla
> fpga from xilinx. I have 2 clocks signals using them in a design (the
> second clock is internal). I can see these buffers in the xnf netlist.
> During Place & Route the design manager gives me a warning saying that
> my internal clock is using non-dedicated resources.

Are you using both edges of the clock?

I found a bug with FPGA Express v3.4.  If it sees that you are using
both edges of the clock, it stupidly infers an CLB inverter on the
clock, and runs that through a BUFGLS, whose output drives the flops
clocked on the opposite edge.  Since at that point, the tools think the
clocks are unrelated, they complain about skew problems.  The
non-dedicated resource is the inverter in the CLB.

FPGA Express should use the polarity-select mux that's part of EVERY
flip-flop in the XLA part, but it doesn't.  There's no work-around,
except maybe going back to a previous version, or buying a real
synthesis tool.  V3.3 did not seem to have this problem.

See
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=10127
for Xilinx' lame answer.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u

"It is better to be silent and thought a fool, 
 than to send an e-mail to the entire company
 and remove all doubt."



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