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 57850

Article: 57850
Subject: Re: Rant mode ON
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Tue, 8 Jul 2003 16:39:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3F0AE7CC.68F9D9D0@yahoo.com>,
rickman  <spamgoeshere4@yahoo.com> wrote:
>I need to vent a little steam.  So at risk of making myself look stupid
>(or more stupid) I will do it here.  

Silly question, why not drive over to Frys or whatever and stick a $10
ethernet card in your system?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 57851
Subject: Re: std_logic_vector type port doesn't work after synthesis.
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 08 Jul 2003 09:40:23 -0700
Links: << >>  << T >>  << A >>
Mike wrote:

> I declared a std_logic_vector(7 downto 0) (inout type) entity port
> in my VHDL program. In the testbench, I will try
> to assign some value to this port. But after synthesis
> using Synopsys Design Compiler, I found this port wouldn't
> accept the value from signal assignment in the test bench
> and the value of this port becomes "XX".


Post your code. Your output enable logic is likely the problem.

  -- Mike Treseler


Article: 57852
Subject: Re: About BRAM in VirtexII
From: "Avrum" <avrum@REMOVEsympatico.ca>
Date: Tue, 8 Jul 2003 13:30:19 -0400
Links: << >>  << T >>  << A >>
You haven't really given us enough information - you should post a little
more about the problem; are you getting an error or warning from the
simulation, and if so, what exactly is happening around the time of the
error. Also we need to know a little more about your application.

Are you using the same clock for both ports of the ram (i.e. are CLKA and
CLKB driven from the same BUFG). If so, there is one condition where reading
and writing to the same address is legal - if the port doing the write is
set to "READ_FIRST" (an attribute set on the RAM), then the data returned
from the read port is the previous contents of the RAM. You also don't
specify if the two ports of the RAM are the same widths.

That being said, you say that you have "logic to avoid hits over the same
address", meaning you are (trying to) guarantee that you never attempt a
simultaneous read and write to the same address. In the past, we have had
some problems with the simulation models of the CoreGen RAMs; we definately
had situations where the model would erroneously declare a read/write
conflict (i.e. there have been bugs in the simulation models in the past).
So, the question is, are you sure there is no conflict. It should be easy to
verify by looking at the waveforms (capuring all the inputs and outputs of
the Dual Port RAM in question). If you are getting an error, look at the
waveforms around this error to determine if you are indeed writing and
reading to the same address (or similar addresses) at the same time.
Remember, if the port wirths of the two ports are not the same, then the
"same address" from the point of view of the RAM is not simply ADDRA ==
ADDRB; if portA is 16 bits wide and portB is 4 bits wide then a contention
exists when ADDRB/4==ADDRA

Avrum

"Nap" <nap@4plus.com> wrote in message
news:4ca417fe.0307040701.52e71a46@posting.google.com...
> Hi guys.
>
> I'm working on a project using a HW platform with an XC2V300FG676-5.
> In my design I used Dual Ports BRAM produced by Coregen 4.2i (in Fndtn
> 4.2i). In simulation of the logic I faced the following problem:
> I wrote data on Port#A but when tried to read them back using port#B I
> realized that have been altered. Xilinx claims in Answer Record 10462
> that this condition
> has to do with conflict resolution over the BRAM (same Read address on
> Port#B with write address on port#A). The answer they provide does not
> help me at all because I have alot and complicated logic in order to
> avoid hits over same address. Does anybody knows if this condition
> affects only simulation?
>
> Thanks in advanced
> Nap



Article: 57853
Subject: Re: phase noise in NCO
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Wed, 09 Jul 2003 03:49:46 +1000
Links: << >>  << T >>  << A >>
On Tue, 8 Jul 2003 14:33:20 +0200, "Marc Battyani"
<Marc.Battyani@fractalconcept.com> wrote:

>Hello,
>
>I want to make a phase measurement at 100MHz with a NCO at 200+ MHz
>This NCO will have a 32 bit phase accumulator and a 32 bits phase offset. The
>output will be only one bit.
>I will use a phase comparator followed by an integrator (digital or analogic
>if needed).
>At 100MHz the NCO output will be very very noisy but if I integrate it for a
>rather long time (10ms) will it have a 0 mean ?
>Can I implement this in an FPGA or should I use a DDS chip (AD9854) ?
>Where can I find some maths on this subject ?

Do you need to know the spectrum of the noise, or just the peak to
peak value?

I sometimes find myself in the situation of having to work out the
spectral characteristics of the phase noise (jitter) of the msb of a
phase accumulator.  E.g. if I am using a post-NCO PLL (as Peter A.
suggested) then I only care about the phase noise components at offset
frequencies less than the loop bandwidth of the PLL.

I don't know of a closed form expression for spectrum of the noise,
but it's trivial to work out the spectrum with a spreadsheet (once you
know how).  This is much easier that trying to measure the spectrum in
the lab.
(Reply if you are interested in the method.)


BTW, Peter's trick of reducing the jitter by a factor of 4 (I assume)
relies on using a 4 phase clock.  This is almost certainly worth the
effort if you are trying to reduce the jitter.
I have a worked example that uses a 2 phase clock (actually it uses
both edges of a single clock) in my free fractional N divider
generator, at this web site:
http://fractional_divider.tripod.com/
(Note: some web proxies don't like domain names with underscores.)

Allan.

Article: 57854
Subject: Re: [DLL usage Virtex/Spartan-II] HowTo drive CLKDV Div 2 off Chip
From: "Avrum" <avrum@REMOVEsympatico.ca>
Date: Tue, 8 Jul 2003 14:19:48 -0400
Links: << >>  << T >>  << A >>
The terminology here is a bit tricky - there are three different things
here - IBUF, IBUFG and BUFG.

An IBUF is a "regular" IOB configured as an input.

An IBUFG is one of (depending on the size of your device) 16 IOBs on the
device that can be configured as a "global clock input" These IOBs have
special dedicated connections to some of the clocking resources in the FPGA.
The output of an IBUFG has a dedicated route to
   - the CLKIN of all/some of the DLLs/DCMs on the same side of the chip
(depends on version and family)
   - the CLKFB of all/some of the DLLs/DCMs on the same side of the chp
   - the input of the BUFG directly in line with the IBUFG
These dedicated routes are provided so that timing to these resources is
guaranteed by design.

A BUFG is the global buffer that drives the low skew global clock nets of
the FPGA. There are a lot of rules about the use of these clocks (refer to
the handbook), but the global clock nets (and hence, effectively the BUFGs)
can be used to clock all the clockable devices (slice FFs, IOB FFs, BRAM
clocks) with a guaranteed clock skew. The BUFG can be configured to be a
BUFGMUX or BUFGCE (which both effectively use two BUFGs).

That being said, you can use a DCM without a BUFG, and still have access to
the phase shift and deskew mechanisms of the DCM. You MUST drive the CLKFB
with something combinationally related to CLK0 or CLK2X - you cannot feed a
divided clock back into CLKFB. For example, you can connect your input clock
via an IBUFG to CLKIN of the DCM, connect CLK0 to an OBUF, connect (on the
board) the OBUF to a second IBUFG, and connect the output of the second
IBUFG back to the CLKFB of the DCM. This will effectively keep the output
clock (the output of the OBUF) in phase with the input clock (or phase
shifted according to the fine phase shift of the DCM). Unfortunately, this
doesn't help you with a divided clock; the net from the CLK0 to the OBUF
will use general routing, and hence will have different timing from P&R run
to run. So for example, if you run the CLKDIV of the DCM to a second OBUF,
there is no guaranteed phase relationship between the two OBUFs (the routing
of the two nets can be quite different).

If you have even one BUFG available, then there are other options (using the
DDR flops in the IOBs). I presume you are using Virtex II or II-pro (since
you talk about phase shift). Remember, that the clocks in Virtex-II are
quadrant based, so if you can free up a BUFG for use in even one quadrant,
you have some options. What part are you using, and how many global clocks
do you need?

Avrum



"John" <jfornews@rogers.com> wrote in message
news:3F0A04F8.6080107@rogers.com...
> Be carefull. Usually when you instantiate a ibufg, you are actually
> instantiating a IOB configured as an input, and a bufg. You only want to
use an
> IOB as the input and make sure it is loc'd to a clk input pin location.
>
> As for your div/2, you can divide the input to the dll by 2 using the
> CLKIN_DIVIDE_BY_2 parameter. Don't know if this helps because the clk0
will be
> div/2 since the dll is dividing the input to the dll.
>
>
>
>
>
> Markus Meng wrote:
>  > Hi All,
>  >
>  > some notes I could not figure out directly from one of the XAPP132, 174
>  > from Xilinx. If I want to drive an Off-Chip device with half of the
clkin
>  > frequency
>  > without using a GBUF driver, can I feedback the devided signal from the
obuf
>  > driving the pin through an IBUFG and still having the DLL functionality
of
>  > phase
>  > shift an duty cycle correction. I read that the feedback signam MUST be
>  > clkout
>  > or 2xclkout. The problem is that I am running out of GBUF's in my
design ...
>  >
>  > markus
>  >
>
>



Article: 57855
Subject: Multiple Files to Synthesis in Make File ?
From: vhdl_uk@yahoo.co.uk (MACEI'S)
Date: 8 Jul 2003 11:30:38 -0700
Links: << >>  << T >>  << A >>
Hi Fellows,

How can I synthesize multiple file one by one using xilinx compiler in
MAKEFILE script. I have done using only one file but when I enter
multiple files in "VHDL= ....." field thenI get the following error.

make: *** No rule to make target `VIR3.vhd,VIR3_1.vhd,VIR3_2.vhd

Rgds

MACEI

Article: 57856
Subject: clock management on SPARTAN2
From: udayan@jhu.edu (Udayan)
Date: 8 Jul 2003 11:37:23 -0700
Links: << >>  << T >>  << A >>
Hi,

I am having trouble with the GCLK feature in my design.

Basically my code is a 4 way handshaking protocol between my PC and
the FPGA on one hand and another 4 way handshaking with an
asynchronous chip on the other.

I am providing a clock to the system through the GCLK0 pin using an
oscilltor.

I further require edge tests on three lines that I receive from the
computer and the chip - which means they are inferred as clock
signals.

A total of 4 clocks.

However when I try to implement the design the engine complains that
my design is too large

Number of GCLKs:                   6 out of      4   150%
Number of GCLKIOBs:                1 out of      4   25%

I cannot understand why this is so. I take the input from my CLKIOB
and pass it through a clock divide routine that I wrote and use that
signal as my global clock. The rest of the three lines go through
BUFGs befor entering the design.
I would loke to pass my divided clock through a BUFG so that it does
not suffer from skew.

To see what the problem might be I implemented another design which
has only one clock - the global clock that I divide and pass through a
BUFG but still the engine reports

Number of GCLKs:                   3 out of      4   75%
Number of GCLKIOBs:                1 out of      4   25%

I was not clear on how this inference is taking place - possibly
because of IOB placements that are hardwired and result from clock
test or bad clock management.

Could someone advice on how to remedy the situation. Would a Clkdll
help? I am not very clear on how it will solve the problem with the
multiple clock lines or even how it broadly works.

Thanks

Udayan

Article: 57857
Subject: Re: Copy Altera Config EPC2 via JTAG?
From: Rene Tschaggelar <tschaggelar@dplanet.ch>
Date: Tue, 08 Jul 2003 18:37:24 GMT
Links: << >>  << T >>  << A >>

Tim Hogard wrote:
> I have the need to duplicate the code that is in one Altera EPC2
> to another one on an identical bit of hardware.  The device has a
> 10 pin JTAG connector.
> 
> Is there a low cost, easy way to suck the bits out and put them
> into the other EPC2?  I also have a .jbc file as well if that makes
> it easier.
> 
> I was doing a flash upgrade but the device reset before it finished
> resulting it a dead bit of hardware.  To get it fixed, it has to
> be sent 1/2 world away and tech support hasn't ever done that and
> don't know if they can even fix it so I'm looking for a better
> option if one exists.


It's been a while I last used MaxPlus2 or Quartus2.
Don't they allow reading the EPC2, assumed the protection bit
is not set ?

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Article: 57858
Subject: Books
From: vhdl_uk@yahoo.co.uk (MACEI'S)
Date: 8 Jul 2003 11:38:23 -0700
Links: << >>  << T >>  << A >>
Can anyone tell me good books or web sites related to following.
1. MAKE file for VHDL ( XILINX)
2. Implementation of Coding using FPGA 

Rgds 

MACIE

Article: 57859
Subject: Re: clock management on SPARTAN2
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Tue, 8 Jul 2003 19:25:10 +0000 (UTC)
Links: << >>  << T >>  << A >>
Udayan <udayan@jhu.edu> wrote:
: Hi,

: I am having trouble with the GCLK feature in my design.

: Basically my code is a 4 way handshaking protocol between my PC and
: the FPGA on one hand and another 4 way handshaking with an
: asynchronous chip on the other.

: I am providing a clock to the system through the GCLK0 pin using an
: oscilltor.

: I further require edge tests on three lines that I receive from the
: computer and the chip - which means they are inferred as clock
: signals.

: A total of 4 clocks.

: However when I try to implement the design the engine complains that
: my design is too large

: Number of GCLKs:                   6 out of      4   150%
: Number of GCLKIOBs:                1 out of      4   25%

: I cannot understand why this is so. I take the input from my CLKIOB

Look at the synthesis report (*.syr) and at the graphical representation of
your circuit ("View RTL Schematics").  It will give you a glimpse of what is
going on. Then rethink the way you wrote your HDL implementation. In the
synthesis report, the "Clock information" might be the most important
thingto look at.

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 57860
Subject: Re: SPARTAN-3 vs. VIRTEX-II
From: "BRANE-NEWS" <brankob@avtomatika.com>
Date: Tue, 8 Jul 2003 21:43:56 +0200
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message

<SNIP>
> I am not looking for champagne on a beer budget, but I would sure like
> to be able to pour them both into the same glass.

Isn't that a bit of redneck perspective -champagne in Budweiser glass ? ;o)






Article: 57861
Subject: Re: Rant mode ON
From: charleybrant@hotmail.com (CB)
Date: Tue, 08 Jul 2003 19:54:52 GMT
Links: << >>  << T >>  << A >>

Geeze .... I'm glad altera doesn't waste valuable time on your problem
, they have real work to do.  They have standardized on the ethernet
interface, if you have a desktop spend $15 and buy one, if you have a
laptop without one you may have to spend twice that on a USB version
or something.  You must have lots of time and little work.




On Tue, 08 Jul 2003 11:48:28 -0400, rickman <spamgoeshere4@yahoo.com>
wrote:

>I need to vent a little steam.  So at risk of making myself look stupid
>(or more stupid) I will do it here.  
>
>I have been trying to get the Quartus 3.0 software and a license since
>last Thursday.  I tried three times over the weekend to download it, but
>the slow modem link I have to use would not complete the entire transfer
>without a problem.  I think I have that licked as my brother tells me he
>has downloaded it for me.  
>
>But I have been trying to get a license file that does not require an
>Ethernet interface and am getting nowhere.  I have received several
>emails from Altera people who say that they support this and I need to
>contact my local FAE or the main office.  I have tried to do both.  All
>of the FAEs I know are either on vacation or in California at training. 
>Calling both 800 numbers has gotten me nowhere since I reach people who
>are the "first line" and always have to refer it to someone else.  I
>have left about half a dozen voice mails, sent easily a dozen emails,
>spoken with two types of support and still I have not heard back from
>anyone at Altera about this.  
>
>Right now I have been holding for about 15 minutes waiting for a third
>number to connect me with a person.  I know that if I was this hard to
>get ahold of no one would *ever* buy any of my products!  
>
>-- 
>
>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: 57862
Subject: Re: Xilinx ISE drops support for more parts
From: lecroy7200@chek.com (lecroy)
Date: 8 Jul 2003 12:55:42 -0700
Links: << >>  << T >>  << A >>
> I made this statement because one of my clients is in a marketplace
> (military and medical) where they ship systems for years and years because
> the customers don't care about the costs they just don't want to rewrite
> or requalify software. 

That's your client, not us.  

> You don't seem to understand that Xilinx isn't removing support for the
> old devices, they aren't adding support for those devices to new tools.

ISE is not a new tool, just a new release with no support for Spartan.

> Periodically Xilinx completely rewrites some component. They do this
> because the requirements change for each new generation. 

Are you talking for Xilinx now?  Are they also a client of yours?

> part. If you were to add support for old parts into the new tools you
> would expect that the new tools to be riddled with bugs for that part for
> the simple reason that nobody is using that tool set on that part, and
> therefore nobody is finding the bugs. 

I expect Xilinx to maintain a certain level of quality in their
software, and I would not expect the tools to be riddled with bugs,
ever!

> Anyone who uses a brand new part
> knows how buggy the tools can be for the first six months or so. Now
> imagine that you are the only person in the world that was using that
> part, the bugs would never get fixed. 

And the part would never be made.  

> That's exactly the situation that an
> obsolete part would be in if it were supported by the newest tools. It
> would be like the part was perpetually in beta release.

The fact they are unable to isolate the sections of code that are
unique to a given part tells me the code is poorly structured.  So the
code may grow. It's not like a modern PC is resource limited.  ISE
currently ships with 6 CDs.  Do you think I really care if it ships
with seven?

Again, I have not seen the case you are describing with Altera's
router.  Try to be more data driven with your comments.

Article: 57863
Subject: Re: Rant mode ON
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Tue, 8 Jul 2003 22:15:53 +0200
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag
news:3F0AE7CC.68F9D9D0@yahoo.com...

> I have been trying to get the Quartus 3.0 software and a license since
> last Thursday.  I tried three times over the weekend to download it, but
> the slow modem link I have to use would not complete the entire transfer
> without a problem.  I think I have that licked as my brother tells me he
> has downloaded it for me.

Get a download manager like Gozilla or something. The can resume a aboarded
download.

--
Regards
Falk






Article: 57864
Subject: Re: scaling fixed point fft
From: Ray Andraka <ray@andraka.com>
Date: Tue, 08 Jul 2003 16:15:59 -0400
Links: << >>  << T >>  << A >>
You didn't mention the radix of each stage.  Divide by 4 is too much if
it is a radix2 butterfly.  If it is radix 2, the gain is at most 2, not
4.  The max output from an FFT occurs when all the input energy falls
into one output bin, which implies the input is a pure sinusoid with a
frequency that is an integer multiple of the sample time.  If the input
is white noise, the output signal energy is going to be spread evenly
among all the output bins, in effect dividing the input signal by N.  As
you can see, this results in a fairly wide dynamic range.  If you know
the nature of your input, you can scale accordingly.  If not, you need
to either carry extra bits or you can use dynamic scaling such as a
block floating point scheme.

Bob wrote:

> Hello,
>
> I have constructed a 256 pt complex fft. My scaling is causing
> problems as the outputs from each stage are divided by 4 to avoid
> overflow. The input data and the twiddle factor coeffs are 16 bits
> wide (Q15). My problem is that when the data arrives at the last two
> butterfly stages of the FFT, it is non-existant, due to all the
> scaling beforehand. All inputs to these stages are zero. Thus I get
> nothing at the output.
>
> How can I work around this?
>
> Many thanks
>
> Bob

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 57865
Subject: Re: Xilinx ISE drops support for more parts
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Tue, 08 Jul 2003 17:13:12 -0400
Links: << >>  << T >>  << A >>
On Tue, 08 Jul 2003 12:55:42 -0700, lecroy wrote:

>> I made this statement because one of my clients is in a marketplace
>> (military and medical) where they ship systems for years and years
>> because the customers don't care about the costs they just don't want
>> to rewrite or requalify software.
> 
> That's your client, not us.
> 
>> You don't seem to understand that Xilinx isn't removing support for the
>> old devices, they aren't adding support for those devices to new tools.
> 
> ISE is not a new tool, just a new release with no support for Spartan.

ISE is just the GUI front end for the tools, it's not the important part
of the Xilinx tool suite. The key elements are the mapper (map), the place
and router (par), and the timing analyzer (trce). Xilinx is also now doing
a synthesis tool of their own (XST) which is one more piece of the puzzle
that has to be supported for each device. I was told by Xilinx that map
was rewritten for the 5.x release. The 6.x release is going to be 64 bit
as well as supporting native Linux, so that means that every important
piece of the tool chain is subject to major changes. Which means in turn
that the tool set has to be QAed on every part that it supports. The more
parts that they have to support the harder the QA job is.

>> Periodically Xilinx completely rewrites some component. They do this
>> because the requirements change for each new generation.
> 
> Are you talking for Xilinx now?  Are they also a client of yours?

I'm not talking for Xilinx, but I do talk to them all the time. With any
complex piece of software, not just Xilinx's, you have to make choices
when you go forward that requires you to lose some features that you had
in the past in order to improve support for the things that you need to do
in the future. To give you an example from a field completely unrelated to
this one, last week Adobe announced a new version of their video editing
software, Premiere. As of this release they are no longer supporting Macs,
just XP. Premiere was originally written for the Mac and for years was a
Mac only product but now the number of Mac users is to small for Adobe to
bother doing a Mac port. When they did a radical rewrite they choose that
moment to drop Mac support. The same thing goes for Xilinx and Spartans.
No one is doing new designs with the original Spartan family, so it's not
worth Xilinx spending any money putting in support for Spartans in their
new tool sets. The old tools are completely adequate for doing anything
that you need to do with a Spartan. Just because there is a new better
faster tool set available doesn't mean that the old stuff has suddenly
vanished from the face of the earth. Disk space is cheap, you can have as
many versions of the tools as you want on a system, all you have to do to
switch between one rev and another is change an environment variable.



>> part. If you were to add support for old parts into the new tools you
>> would expect that the new tools to be riddled with bugs for that part
>> for the simple reason that nobody is using that tool set on that part,
>> and therefore nobody is finding the bugs.
> 
> I expect Xilinx to maintain a certain level of quality in their
> software, and I would not expect the tools to be riddled with bugs,
> ever!

All software has bugs and x.0 software has lots of bugs. Xilinx is
actually better than most but whenever they add a new family or do a major
rewrite there are bugs. I did an Altera Stratix design last year and every
piece of software in their design chain was broken, starting with the
Verilog models which wouldn't even compile. I've never had that level of
problems with Xilinx but I've certainly encountered my share of bugs in
their stuff over the years.

> 
>> Anyone who uses a brand new part
>> knows how buggy the tools can be for the first six months or so. Now
>> imagine that you are the only person in the world that was using that
>> part, the bugs would never get fixed.
> 
> And the part would never be made.

My point is that the support for an old part in a new tool wouldn't be any
better than the initial beta release of a new part. The difference being
is that with a new part lots of people are using it so that the software
bugs get found and fixed. With the obsolete part there will be hardly
anyone using it so the bugs aren't going to get found, the fixes aren't
going to get made, and the software quality will be beta forever. With the
tool set that existed at the end of the parts mainstream life the software
was mature. You benefit from the years of cumulative bug fixes that had been
applied, that's the stuff you want to be using if you have to make a
change to an old part.
 
> Again, I have not seen the case you are describing with Altera's router.
> Try to be more data driven with your comments.

As I said before my experience with Altera has been much worse then with
Xilinx. The kind of bugs that I encountered with the Altera tool set
indicated that they hadn't done any QA at all. In all fairness I was doing
a Stratix design which was a beta part at the time so you would expect all
sorts of problems. 


Article: 57866
Subject: Re: constraints, etc
From: Spam Hater <spam_hater_7@email.com>
Date: Tue, 08 Jul 2003 22:51:36 GMT
Links: << >>  << T >>  << A >>

This is an FPGA question; I removed comp.lang.vhdl from this followup.

If you put your clock signal on a GCK pin, and ISE recognizes it as a
clock signal, the GBUF gets added automatically.  (ISE adds a GBUF to
almost everything it recognizes as a clock)

At 30 MHz, the only constraints you will (probably) need is to lock
down the pin numbers.

Typically, the 2nd constrain you add is the clock speed (the 1st being
the pinout).  Other constraints are added to help the software meet
the speed constraint.  (pre-assigning locations, that kind of stuff)

Hope that helps,
SH7


On Thu, 3 Jul 2003 22:13:22 -0400, "Jason Berringer"
<look_at_bottom_of@email.com> wrote:

>Hello all,
>
>I would like to know a couple of things if anyone could help or point me to
>a file etc. I'm using Webpack from Xilinx, and a Spartan XC2S100 and I've
>been messing around with writing simple project to get familiar with VHDL
>and programming the board. I'm curious to know if I have to instantiate a
>global clock buffer each time I sythesis my design, or if I simply make sure
>that my clock goes to a GCK pin is that enough? Also I'm a little confused
>as to what constraints are and how they might help my designs. For example
>if I have a 30 MHz clock going to a GCK pin do I have to put constraints on
>it or are constraints primarily used for very complex designs?
>
>Sorry if this seems like small question, but it is somewhat confusing from
>the documents that I have read, and since I haven't had any problems with
>any of my projects (without using any constraints) I was not all that
>worried. Now that I'm getting into bigger designs I figured that it was time
>to start figuring this out.
>
>Any and all help is greatly appreciated.
>
>Thanks
>
>Jason
>


Article: 57867
Subject: Re: phase noise in NCO
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Wed, 9 Jul 2003 01:08:36 +0200
Links: << >>  << T >>  << A >>

"Allan Herriman" <allan_herriman.hates.spam@agilent.com>
> On Tue, 8 Jul 2003 14:33:20 +0200, "Marc Battyani"
> <Marc.Battyani@fractalconcept.com> wrote:
> >I want to make a phase measurement at 100MHz with a NCO at 200+ MHz
> >This NCO will have a 32 bit phase accumulator and a 32 bits phase offset.
The
> >output will be only one bit.
> >I will use a phase comparator followed by an integrator (digital or
analogic
> >if needed).
> >At 100MHz the NCO output will be very very noisy but if I integrate it for
a
> >rather long time (10ms) will it have a 0 mean ?
> >Can I implement this in an FPGA or should I use a DDS chip (AD9854) ?
> >Where can I find some maths on this subject ?
>
> Do you need to know the spectrum of the noise, or just the peak to
> peak value?

The spectrum I think. In fact I need to have a very precise phase lock
(0.1%). The frequency lock is already ok as I have the reference clock.

> I sometimes find myself in the situation of having to work out the
> spectral characteristics of the phase noise (jitter) of the msb of a
> phase accumulator.  E.g. if I am using a post-NCO PLL (as Peter A.
> suggested) then I only care about the phase noise components at offset
> frequencies less than the loop bandwidth of the PLL.

I thought about filtering and integrating the phase error after the phase
comparator. I don't think I need a PLL as I'm not synthesising a frequency.

> I don't know of a closed form expression for spectrum of the noise,
> but it's trivial to work out the spectrum with a spreadsheet (once you
> know how).  This is much easier that trying to measure the spectrum in
> the lab.
> (Reply if you are interested in the method.)

Sure, please explain how to do it, I'm really interested.

> BTW, Peter's trick of reducing the jitter by a factor of 4 (I assume)
> relies on using a 4 phase clock.  This is almost certainly worth the
> effort if you are trying to reduce the jitter.
> I have a worked example that uses a 2 phase clock (actually it uses
> both edges of a single clock) in my free fractional N divider
> generator, at this web site:
> http://fractional_divider.tripod.com/
> (Note: some web proxies don't like domain names with underscores.)

Thanks, I will look at it.

Marc





Article: 57868
Subject: Re: phase noise in NCO
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Wed, 9 Jul 2003 01:09:02 +0200
Links: << >>  << T >>  << A >>

"John_H" <johnhandwork@mail.com> wrote
> "Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote
> >
> > I want to make a phase measurement at 100MHz with a NCO at 200+ MHz
> > This NCO will have a 32 bit phase accumulator and a 32 bits phase offset.
> The output will be only one bit.
>
> A 1-bit output will give you NCO phase noise that has a range of 5nS
> peak-to-peak based only on the single bit output.  The only exception to
> this value is when you run at a fractional value such as 100 MHz from the
> 200MHz clock where the accumulator acts as a divide-by 2.  [I guess all
> frequencies will be a fractional relation - 1329046/2^32 is still a
> fraction.  The arguement applies to small whole number fractions such as
> 3/16.]  The way to get good performance from the system is to use the full
> DDS - an NCO with a D/A such as those very nifty Analog Devices parts.
>
> > I will use a phase comparator followed by an integrator (digital or
> analogic
> > if needed).
> > At 100MHz the NCO output will be very very noisy but if I integrate it
for
> a
> > rather long time (10ms) will it have a 0 mean ?
>
> If you compare the phase to a noise-free reference that is precisely the
> desired frequency, the low-passed output of the phase comparator will
> conceptually be the phase offset between your NCO and the noise-free
> reference.  I say conceptually because this is not a practical test.  If
> you're trying to figure out of the phase noise is "lopsided," you should
> find the phase comparator output is some form of sawtooth.  If the
frequency
> is very close to a fraction of the 200MHz clocking frequency, your phase
> comparator output will appear to recover from a step function while the
> reality is that it's a very long sawtooth.  Your frequency give you results
> with phase variations that are much closer in time where it's hard to see
> the longer term sawtooth characteristics beyond the very large, high
> frequency variations you see without the lowpassing.

Yes I don't want to have a 23mHz noise (100MHz / 2^32)

> > Can I implement this in an FPGA or should I use a DDS chip (AD9854) ?
>
> The NCO can be implemented in the FPGA.  You could drive a D/A with the
FPGA
> though it's recommended that the D/A's clock be sourced direclty from your
> low phase-noise source rather than passing the clock through the FPGA.  The
> DDS chips with integrated D/As are the best for this kind of thing.

If I need to have more than 1 bit of resolution for the output I will use a
stand alone DDS.

> > Where can I find some maths on this subject ?
>
> Unfortunately, the maths are a little loose on the phase noise results.
> I've only seen textbook treatment of simple jitter: a sinusoidal phase
> variation.  The Bessel function is a result of the Fourier of the
>
>   sin(wt+Psin(at))
>
> kind of form (ah, my kingdom for an ohmega, phi, or alpha on this
keyboard).
> The Bessels give you only a slight idea of what happens in the NCO realm.
> The investigations I did went through a theoretical setup I described
above.
> Determine the time domain of the phase comparator output from your NCO
> compared to the "ideal" noise-free reference mathematically.  The pattern
> will repeat when the NCO accumulator values repeat which will happen at
> least every 2^32 cycles.  This time-domain result might be what you seek.
> The frequency domain interested me, so I took the FFT of the time domain.
>
> If you're only interested in close-in phase noise and higher frequencies
are
> a non-issue, there are ways to increase the peak-to-peak phase noise while
> decreasing the close-in phase noise.  A google on "MASH" and "frequency
> synthesis" might bring up results on that advanced subject.

Ok I will look at this

Marc



Article: 57869
Subject: Re: phase noise in NCO
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Wed, 9 Jul 2003 01:12:39 +0200
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> wrote in
> I have been playing around with the idea of a 32-bit DDS circuit at 200
> MHz ( as a digitally controlled VCO) and I know some tricks to reduce
> the timing uncertainty from the obvious 5 ns by a factor of 4. Then I
> was going to use an external PLL to reduce it further.
> These are just ideas...

I'm trying to have an almost all digital solution. I would rather use a DDS
rather than a PLL as I'm not generatin a frequency.
I just want to lock on the phase. (I have the reference frequency) I'ts a
kind of DLL...

Marc



Article: 57870
Subject: Re: Books
From: jon8spam@yahoo.com (Jon)
Date: 8 Jul 2003 16:20:41 -0700
Links: << >>  << T >>  << A >>
MACIE,
  Check out the xilinx website I remember seeing a document for vhdl
coding for xilinx FPGA.  Also check out the answers database for using
the automated tool functionality to script up your synthesis run.

Jon


vhdl_uk@yahoo.co.uk (MACEI'S) wrote in message news:<fdfcada5.0307081038.6f1c5d22@posting.google.com>...
> Can anyone tell me good books or web sites related to following.
> 1. MAKE file for VHDL ( XILINX)
> 2. Implementation of Coding using FPGA 
> 
> Rgds 
> 
> MACIE

Article: 57871
Subject: Benchmark designs for partial dynamic reconfiguration
From: aman_78in@yahoo.com (Aman Gayasen)
Date: 8 Jul 2003 16:28:32 -0700
Links: << >>  << T >>  << A >>
I am doing my Ph.D research related to partial dynamic reconfiguration
of FPGAs. I need a few real designs to test my work. Can someone tell
me where I can get them from? The more frequently the design
reconfigures a part of the FPGA, the better it will work for me. I
expect the design to be in Verilog, VHDL, EDIF or NGD format.
Any help in this regard will be deeply appreciated.

Thanks,
Aman

Article: 57872
Subject: Re: phase noise in NCO
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 09 Jul 2003 11:45:41 +1200
Links: << >>  << T >>  << A >>
Marc Battyani wrote:
> 
> "Peter Alfke" <peter@xilinx.com> wrote in
> > I have been playing around with the idea of a 32-bit DDS circuit at 200
> > MHz ( as a digitally controlled VCO) and I know some tricks to reduce
> > the timing uncertainty from the obvious 5 ns by a factor of 4. Then I
> > was going to use an external PLL to reduce it further.
> > These are just ideas...
> 
> I'm trying to have an almost all digital solution. I would rather use a DDS
> rather than a PLL as I'm not generatin a frequency.
> I just want to lock on the phase. (I have the reference frequency) I'ts a
> kind of DLL...


Sounds challenging : If I have this right
 You have 100MHz 'incomming' (hopefully very clean and phase stable :)
 You want to lock to 0.1%, (or 10ps), nominally 200MHz local Osc
 You can tolerate longer lock acquire times

Analog Phase locked loops work because they integrate 
the phase-magnitude errors,
- In a digital system, edge resolution of 10ps may be just possible, but
I'm not sure you can get any error-proportional siganl.
 Go-right/Go-Left control is likely to be swamped by the phase-noise of
the DDS signal.....
-jg

Article: 57873
Subject: Re: phase noise in NCO
From: "John_H" <johnhandwork@mail.com>
Date: Wed, 09 Jul 2003 00:19:05 GMT
Links: << >>  << T >>  << A >>
"Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message
news:befj4b$94c@library2.airnews.net...
<snip>
> I just want to lock on the phase. (I have the reference frequency) I'ts a
> kind of DLL...
</snip>

You could use the dynamic phase shift capabilities of the Xilinx DCMs.  The
slight caveat there is that the phase isn't a 360 degree "wraparound" phase,
but a +/- 180 (or +/- 360?) degree shift.  If you need to nudge your phase
too far one direction, you'd need to have two DCMs and a real good
understanding on how to get one to pick up where the other is leaving off.
The update rate isn't good for matching frequencies beyond several 10s of
ppm frequency error, but if your frequency is *ded* on and all you want is
to get your phase to match, the DCMs let you nudge the phase forward and
backward.

The DCMs are absolutely superb for some things.

If you're trying to "nudge" an NCO to match your phase (or perhaps a
frequency offset >100ppm), you will get those system-clock-period sized
phase jumps.  Peter's technique would cut that system clock into quarters to
cut the error by a factor of 4 but you still get the phase hit when you have
to "adjust" your divide by 2.



Article: 57874
Subject: Re: QuartusII software licencing
From: Sander Vesik <sander@haldjas.folklore.ee>
Date: Wed, 9 Jul 2003 00:23:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
H. Peter Anvin <hpa@zytor.com> wrote:
> 
> For Ethernet cards, too; for most it's trivial to flash a new MAC
> address permanently.  You need hardware-specific tools to do it, but
> virtually all modern Ethernet cards have the MAC address in a serial
> EEPROM of some sort.

all 3com cards used to come with a floppy that let you set it. so did
most ne2000 clones. for same macs you could use smoething similar to nat
for translation, or just a vlan switch ... but ... what would be the
point?  you could just write a driver that returned the mac you wanted 
without any hardware changes.

overzealous software licencing check schemes are fundametaly the wrong way.

> 
> You can still, obviously, not have two Ethernet cards with the same
> MAC address on the same network.
> 
>        -hpa

-- 
	Sander

+++ Out of cheese error +++



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