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
2019JanFebMar2019

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 66100

Article: 66100
Subject: timing constraints and enables
From: "Ken" <aeu96186_MENOWANTSPAM@yahoo.co.uk>
Date: Thu, 12 Feb 2004 16:24:26 -0000
Links: << >>  << T >>  << A >>

Hello again,

CLK = 280MHz

A state machine clocked by CLK and enabled by NSI generates a CLKEN signal
that enables "other" logic clocked by CLK.

CLK and NSI are on the entity, CLKEN is internal.

The "other" logic contains long carry chains that will run at 140MHz (just).

The FSM should be able to run at ~280MHz on a virtex-ii -5.

I am assuming NSI always = 1 for the time being.

How do I describe this situation to Xilinx ISE 5.2.03i in ucf constraints
please?

I tried this:

NET "CLK*" TNM_NET = "CLK";
NET "CLKEN" TNM_NET = "CLKEN";
NET "NSI*" TNM_NET = "NSI";

TIMESPEC "TS_CLK" = PERIOD "CLK" 3.57 ns HIGH 50 %;
TIMESPEC "TS_CLK_NSI" = FROM "CLK" TO "NSI" "TS_CLK" * 1;
TIMESPEC "TS_CLK_CLKEN" = FROM "CLK" TO "CLKEN" "TS_CLK" * 2;


but ISE tries to constrain the "other" logic with the carry chains to the
280MHz clock instead of the 140MHz CLKEN domain - and timing fails.

Also tried various other combinations some of which are listed at the end
with no success.

Am I on the right lines here or am I missing something obvious?  Surely I
can tell ISE about this situation...?

Also, is there any way to use say "CLKEN*" when specifying the grouping for
CLKEN - do I need to dig in to the hierarchy somehow?  Tried the Xilinx
manuals but couldn't find something that relates to this scenario without
specifying every signal manully - I need to group by enable/clk signal!

Thanks for your time,

Ken


#TIMESPEC "TS_CLKEN" = FROM "CLKEN" TO "CLKEN" "TS_CLK" * 2;
#TIMESPEC "TS_CLKEN_CLK" = FROM "CLKEN" TO "CLK" "TS_CLK" * 2;
#TIMESPEC "TS_NSI" = FROM "NSI" TO "NSI" "TS_CLK" * 2;
#TIMESPEC "TS_NSI_CLK" = FROM "NSI" TO "CLK" "TS_CLK" * 2;


-- 
To reply by email, please remove the _MENOWANTSPAM from my email address.



Article: 66101
Subject: Re: getting back Xilinx ISE commands
From: Sean Durkin <23@iis.42.de>
Date: Thu, 12 Feb 2004 17:25:04 +0100
Links: << >>  << T >>  << A >>
Amontec Team, Laurent Gauch wrote:

> Hi,
> I need to know where I have to include my .ucf file in XFLOW!
As long as it has the same name as the rest of the design XFLOW should 
find it automatically. E.g., if you have a "top.vhd", or a "top.ngc", 
then XFLOW should find a "top.ucf" on it's own, if it resides in the 
current directory. Otherwise you can change it in the *.opt-file for the 
"implement" stage (fast_runtime.opt, for example, or whatever you use).

-- 
Sean Durkin
Fraunhofer Institute for Integrated Circuits (IIS)
Am Wolfsmantel 33, 91058 Erlangen, Germany
http://www.iis.fraunhofer.de

mailto:23@iis.42.de
([23 , 42] <=> [durkinsn , fraunhofer])

Article: 66102
Subject: Re: How many PCB layers ?
From: "Kenneth Land" <kland1@neuralog1.com1>
Date: Thu, 12 Feb 2004 10:25:36 -0600
Links: << >>  << T >>  << A >>
If you can sqeak by with 240 pins I've got a custom 4 layer board running
Nios with SDRAM and USB 2.0 incredibly stable at 110-120 MHz.

Stack is Signal-GND-PWR-Signal.  Made 10 with ground pours, 10 without.
Both sets function the same. I have not compared the external signals on an
analog scope, but the clocks look good, the logic analyzer looks good, and
they all work without glitch.

If you go to CompUSA and buy a few highspeed PCI cards you'll see they're
doing their magic with only 2 layers with ground pours.

I was originally told by the board expert the same 8-layer requirement on
our design.  I talked him down to 6 and then went with 4 based on a lot of
reading, looking at examples, and applying common sense.

I say listen to experts, but beware the advice of people who make more money
if your design is more complex.

IMO
Ken

"Andre" <armcc@lycos.com> wrote in message
news:ae5c06e9.0402120029.4ea5405d@posting.google.com...
> How many layers are normally needed for PCBs using low cost FPGAs ??
>
> I've just been told by a supposed board layout expert that the 256 pin
> BGA version of a Cyclone EP1C6 would require an 8 layer board
> (apparently having the entire underside of the device covered by balls
> with no free space at the centre makes signal routing a big problem).
>
> Is this really true ??



Article: 66103
Subject: Re: getting back Xilinx ISE commands
From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com>
Date: Thu, 12 Feb 2004 17:47:57 +0100
Links: << >>  << T >>  << A >>
I found. There are '-uc' parameter for the

Amontec Team, Laurent Gauch wrote:

> Hi,
> 
> I need to know where I have to include my .ucf file in XFLOW!
> 
> Laurent
> 
> Sean Durkin wrote:
> 
>> Amontec Team, Laurent Gauch wrote:
>>
>>> Hi all,
>>> I am using Webpack ISE to do PAR for Coolrunner.
>>> How to get back all command line from VHDL and UCF parser to JEDEC 
>>> generation (parser, synthesis and par works)
>>> The goal is to do a generic project (using webpack IDE interface) and 
>>> to get back all ISE command line, and to re-run the ISE command line 
>>> for an other VHDL file with minor changes. All the work would be via 
>>> script for generating about 50 news configs of our Chameleon POD.
>>
>>
>> Have a look at the chapter about "xflow" in the ISE Documentation. 
>> That's the command-line-tool to do the complete flow from synthesis to 
>> bitfile generation (I assume you can generate JEDEC-files as well). 
>> The options for each of the steps are set in *.opt-files, that reside 
>> in $XILINX/epld/data. You can copy those and modify the local copies, 
>> and run "xflow" with these instead of the globally available ones.
>>
>> "xflow" is really not that complicated, and is great for using inside 
>> scripts, so that should be what you need.
>>
> 
> ------------ And now a word from our sponsor ------------------
> For a quality usenet news server, try DNEWS, easy to install,
> fast, efficient and reliable. For home servers or carrier class
> installations with millions of users it will allow you to grow!
> ----  See http://netwinsite.com/sponsor/sponsor_dnews.htm  ----

------------ And now a word from our sponsor ------------------
For a quality usenet news server, try DNEWS, easy to install,
fast, efficient and reliable. For home servers or carrier class
installations with millions of users it will allow you to grow!
----  See http://netwinsite.com/sponsor/sponsor_dnews.htm  ----

Article: 66104
Subject: Re: Programmable clock, FPGA PLLs, and Actel PLL Core
From: Jay <invalid@127.0.0.1>
Date: Thu, 12 Feb 2004 10:49:36 -0600
Links: << >>  << T >>  << A >>
Peter,

In article <402BBFA1.49FA2DB5@xilinx.com>
> You need to be more specific about granularity, jitter, and your budget.
> Here is one extreme:
> I am just finishing a project where we combine a small Spartan3 plus an
> ICS8735 PLL to generate 1 Hz to 640 MHz with a granularity of 1 Hz  (all
> the way to 640 MHz ! ) and very low jitter (hopefully below 50 ps). This
> uses some unconventional tricks...

Any plans to make an application note describing your setup? It sounds 
like a very cool design.

Are you doing something like frequency division in the FPGA with 
counters and multiplication with the PLL? Perhaps using different clocks 
& divider combos to cover the range??

Thanks,
Jay.


Article: 66105
Subject: clock
From: charlesg77@yahoo.com (chuk)
Date: 12 Feb 2004 08:49:51 -0800
Links: << >>  << T >>  << A >>
When configuring a virtex fpga with a prom in master serial mode, how
is the clock generated by the fpga.  I presume I don&#8217;t need to
input any other clock other than my normal fast clock of 100MHz.

Article: 66106
Subject: Re: negative hold time
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 12 Feb 2004 09:40:07 -0800
Links: << >>  << T >>  << A >>
Glen, I have no problem with names, but I have a problem giving one
single parameter two different names. There is no inherent difference
between set-up and hold, they are just the two extreme ends of the same
parameter, the input timing window where D must be held constant, in
order to guarantee specified operation and performance.
At any one time, voltage, and temperature on a given part, the "two
parameters" collapse into a single value. I have measured the actual
width of the window (in Virtex-II Pro) as 0.03  femtoseconds. (see
TechXclusives on metastability measurement).

I am a stickler for clarity and simplicity, but this is a battle lost
long time ago...
Peter Alfke
=========================
glen herrmannsfeldt wrote:
> 
> Peter Alfke wrote:
> 
> > Let me blame T.I. for inventing (in the late 'sixties) the stupid name
> > "Hold Time", when we are really talking about the latest possible
> > instant of Set-Up Time.
> 
> (snip)
> 
> > The earliest possible position is specified as Set-up-time. The latest
> > possible position is (unfortunarely) specified as Positive Hold Time if
> > it is later than the clock edge, and as Negative Hold Time if it is
> > before the clock edge.
> 
> > It would be so much nicer if we used only one parameter name, and called
> > the two extremes the max and the min value of the set-up time. I lost
> > that battle 30 years ago. It still smarts every time I hear "Hold Time"
> 
> By having two parameters you can have a typical for both, and also
> a max/min (whichever is applicable).
> 
> Now, I suppose the names could be more symmetric.  What is the opposite
> of setup?  Maybe takedown, or something like that?   Maybe release is
> the opposite of hold.  I don't think setup/takedown or release/hold make
> very good pairs.   It might be that I am too used to setup/hold by now.
> 
> -- glen

Article: 66107
Subject: Re: getting back Xilinx ISE commands
From: Lasse Langwadt Christensen <langwadt@ieee.org>
Date: Thu, 12 Feb 2004 18:51:59 +0100
Links: << >>  << T >>  << A >>
Amontec Team, Laurent Gauch wrote:
> Sean Durkin wrote:
> 
>> Amontec Team, Laurent Gauch wrote:
>>
>>> Hi all,
>>> I am using Webpack ISE to do PAR for Coolrunner.
>>> How to get back all command line from VHDL and UCF parser to JEDEC 
>>> generation (parser, synthesis and par works)
>>> The goal is to do a generic project (using webpack IDE interface) and 
>>> to get back all ISE command line, and to re-run the ISE command line 
>>> for an other VHDL file with minor changes. All the work would be via 
>>> script for generating about 50 news configs of our Chameleon POD.
>>
>>
>> Have a look at the chapter about "xflow" in the ISE Documentation. 
>> That's the command-line-tool to do the complete flow from synthesis to 
>> bitfile generation (I assume you can generate JEDEC-files as well). 
>> The options for each of the steps are set in *.opt-files, that reside 
>> in $XILINX/epld/data. You can copy those and modify the local copies, 
>> and run "xflow" with these instead of the globally available ones.
>>
>> "xflow" is really not that complicated, and is great for using inside 
>> scripts, so that should be what you need.
>>
> Sean,
> 
> I will try the xflow way.
> many thanks
> Laurent
> 

For verilog and FPGA the log file is <top_level_name>.cmd_log just run 
the flow once and copy it to a *.bat file

from the command line  it pretty easy to guess what files you need to
look at to set options etc. and they are quite easy to read and modify

-Lasse


Article: 66108
Subject: Re: getting back Xilinx ISE commands
From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com>
Date: Thu, 12 Feb 2004 18:55:21 +0100
Links: << >>  << T >>  << A >>
All are working fine.
I am now able to pass from VHDL source files to SVF output files only 
using script ! We have now a Chameleon POD self programmable from VHDL 
source. (Just need to intall the Free webpack) :-)

A very nice solution.

Laurent
www.amontec.com

Sean Durkin wrote:
> Amontec Team, Laurent Gauch wrote:
> 
>> Hi,
>> I need to know where I have to include my .ucf file in XFLOW!
> 
> As long as it has the same name as the rest of the design XFLOW should 
> find it automatically. E.g., if you have a "top.vhd", or a "top.ngc", 
> then XFLOW should find a "top.ucf" on it's own, if it resides in the 
> current directory. Otherwise you can change it in the *.opt-file for the 
> "implement" stage (fast_runtime.opt, for example, or whatever you use).
> 


Article: 66109
Subject: Re: Programmable clock, FPGA PLLs, and Actel PLL Core
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 12 Feb 2004 10:02:09 -0800
Links: << >>  << T >>  << A >>
You need to be more specific about granularity, jitter, and your budget.
Here is one extreme:
I am just finishing a project where we combine a small Spartan3 plus an
ICS8735 PLL to generate 1 Hz to 640 MHz with a granularity of 1 Hz  (all
the way to 640 MHz ! ) and very low jitter (hopefully below 50 ps). This
uses some unconventional tricks...

DDS is the traditional method to achieve finest granularity, but it
creates lots of jitter, and is non-trivial at 150 MHz.

Peter Alfke
===================================
dave wrote:
> 
> Escenario : Need a clock system with range from ~50Mhz to 150Mhz with
> as much granularity as possible to drive an FPGA.
> 
> Could anyone please suggest options on how to better implement this
> clock system.? I've looked at programmable clocks from Cypress,
> Maxim-ic, but these require some I2C or 2-wire interface, and I don't
> have a microcontroller on board, just the FPGA so I'd need to put a
> I2C core...  . I've looked at using the PLL core in the FPGA (Actel in
> this case), but I find the documentation about it to be extremely poor
> as to how to really implement it.
> 
> By the way, if anybody has had experience using the PLL core in Actel,
> could you please give a simple example on how to use the core
> generated by "Actgen." I've read the document on "PLL dynamic
> reconfiguration using JTAG," and I still don't understand
> completely....
> 
> Thanks in advance,
> 
> David

Article: 66110
Subject: Re: clock
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 12 Feb 2004 10:07:36 -0800
Links: << >>  << T >>  << A >>
In master mode the configuration clock is generated by an FPGE-internal
RC oscillator. The frequency is not very accurate or stable, but good
enough for the purpose.

Peter Alfke
===============
chuk wrote:
> 
> When configuring a virtex fpga with a prom in master serial mode, how
> is the clock generated by the fpga.  I presume I don&#8217;t need to
> input any other clock other than my normal fast clock of 100MHz.

Article: 66111
Subject: EDA tool for testing HDL designs (new update) - www.hightech-td.com
From: vboykov@yandex.ru (vladimir)
Date: 12 Feb 2004 10:43:55 -0800
Links: << >>  << T >>  << A >>
TBGenerator - program for testing and diagnosting HDL designs (Verilog
or VHDL).
This program reads source files (VHDL or Verilog) and automatically
generates test bench file (Verilog or VHDL format) for the selected
module and macro file (Tcl/Tk, Sh) for particular simulator (ModelSim,
Active-HDL/Riviera, NC-sim, VCSi and others). You don't have to waste
your time for writing test benches!
    You can define input stimulus for in/inout ports either by the
formula, by the clock pulse, by random variable or you can define an
input file with stimulus data (text file with input vectors and time).
You can change only the stimulus in the input file without changing
the test bench file. The values of all the ports will be written to
the file during the simulation if you chose to do so.
Program has some additional tools: 
- generator of components declaration for chosen module; 
- frequency to time converter and vice versa; 
- input file editor. 
User-friendly interface and advanced help.
This program is shareware with a trial period 30 days

Article: 66112
Subject: Re: debug application in sdram (microblaze system)
From: Ryan Laity <ryan_dot_laity@x-i-l-i-n-x_pleasenospam_dot_com>
Date: Thu, 12 Feb 2004 11:54:10 -0700
Links: << >>  << T >>  << A >>
Frank,

I was not aware that you were using cache with your SDRAM in this 
system.  To debug with cache support, you must use the MDM.

Ryan Laity
Xilinx



Frank van Eijkelenburg wrote:
> It looks like there are some troubles with debugging an application in sdram
> while caching is enabled (both instruction cache and data cache are
> enabled). If I remove the cache, I am able to debug my application from
> sdram. Could anyone confirm this (I saw a few postings at the xilinx
> microblaze forum, but I couldn't find an confirmation from xilinx about this
> behaviour)?!
> 
> Frank
> 
> 
> "Ryan Laity" <ryan_dot_laity@x-i-l-i-n-x_pleasenospam_dot_com> wrote in
> message news:c0dod1$5kk1@cliff.xsj.xilinx.com...
> 
>>Frank,
>>
>>Yes, you can do exactly what you have described.  When you use the "dow"
>>command from the XMD command prompt (after an mbconnect), XMD will use
>>the available memory interface core to place the .elf at whatever
>>location has been specified in your linker script.  Therefore, you want
>>to "dow" the final application, not the bootloader.  You are essentially
>>letting MDM/XMD act as your bootloader in this case.
>>
>>Once the .elf is downloaded, you can then "con" to run or "stp" (step)
>>from the command line and see what instruction is causing the problem
>>you described in your previous post.  If the system hangs on one of your
>>first steps then you probably have a problem with your hardware (likely
>>logical or timing issue with your memory interface and/or board).  If
>>this is the case, try using the "mwr" and "mrd" commands from XMD to see
>>if you can get data in and out of your memory correctly.
>>
>>You can also try to "dow" your .elf file, do an object dump (mb-objdump)
>>of the .elf, then use "mrd" on a large block of the instruction memory,
>>and do a comparison between the dumped .elf and what's in the memory.
>>If there are any mismatches then there's likely a problem with the
>>memory interface hardware/timing.
>>
>>If it's many instructions into the run, and that instruction memory
>>location looks correct, then the software is likely at fault.  Use that
>>dumped .elf file to figure out which instruction is causing the problem
>>and debug accordingly.
>>
>>Hopefully you are able to resolve the problem using this information.
>>If not then please contact our support hotline for more help.
>>
>>
>>Best regards,
>>Ryan Laity
>>Xilinx Applications
>>
>>Frank van Eijkelenburg wrote:
>>
>>>Hi,
>>>
>>>Is it possible to debug an application which is in sdram by use of
> 
> xmdstub?
> 
>>>I have a small bootloader program which programs a final application
> 
> into
> 
>>>sdram (by use of xmodem). Now I want to debug this application, is that
>>>possible or should I use the opb mdm device?! If it's possible, I guess
> 
> I
> 
>>>have to build a bootloader with the xmdstub and make a connection. But
> 
> how
> 
>>>to get my application into the sdram? Can I use the "dow" command at the
> 
> xmd
> 
>>>command line or an option inside gdb to download the application into
> 
> sdram
> 
>>>(I'm asking this, because in the normal way the user has to give some
> 
> input
> 
>>>via the serial port, but that's the same port for debugging thus I can't
>>>give any input). And how to step through the code when the application
> 
> is in
> 
>>>the sdram?!
>>>
>>>TIA,
>>>Frank
>>>
>>>
>>
> 
> 


Article: 66113
Subject: Re: is this enable structure ok for synthesis/high speed?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 12 Feb 2004 14:00:41 -0500
Links: << >>  << T >>  << A >>
ANDing is fine here, although in a high speed design the and gate may cause you
some heartburn when trying to meet timing.  The place and route (PAR) tools
don't do a very good job placing second level combinatorial stuff, particularly
gates with multiple loads like you have with a clock enable.  Unless you are
really pushing the clock, it should be fine.


>

--
--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: 66114
Subject: Re: Programmable clock, FPGA PLLs, and Actel PLL Core
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 12 Feb 2004 11:41:30 -0800
Links: << >>  << T >>  << A >>
Jay, give me a few weeks to publish.
In a nutshell:  10 MHz xtal osc gets multiplied to 80 MHz, drives Direct
Digital Synthesis accumulator, a "magic circuit" then multiplies the
frequency and reduces the jitter. The Spartan-3 output drives the ICS
PLL for further jitter reduction and multiplication by up to 8.
Nice GUI and display control by PicoBlaze.
Read about it in XCell, and I will also brag about characterization
results in this ng, once we are finished.  Fun project  :-)

Peter Alfke  
================================
Jay wrote:
> 
> Peter,
> 
> In article <402BBFA1.49FA2DB5@xilinx.com>
> > You need to be more specific about granularity, jitter, and your budget.
> > Here is one extreme:
> > I am just finishing a project where we combine a small Spartan3 plus an
> > ICS8735 PLL to generate 1 Hz to 640 MHz with a granularity of 1 Hz  (all
> > the way to 640 MHz ! ) and very low jitter (hopefully below 50 ps). This
> > uses some unconventional tricks...
> 
> Any plans to make an application note describing your setup? It sounds
> like a very cool design.
> 
> Are you doing something like frequency division in the FPGA with
> counters and multiplication with the PLL? Perhaps using different clocks
> & divider combos to cover the range??
> 
> Thanks,
> Jay.

Article: 66115
Subject: Re: negative hold time
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 13 Feb 2004 10:05:34 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Glen, I have no problem with names, but I have a problem giving one
> single parameter two different names. There is no inherent difference
> between set-up and hold, they are just the two extreme ends of the same
> parameter, the input timing window where D must be held constant, in
> order to guarantee specified operation and performance.
> At any one time, voltage, and temperature on a given part, the "two
> parameters" collapse into a single value. I have measured the actual
> width of the window (in Virtex-II Pro) as 0.03  femtoseconds. (see
> TechXclusives on metastability measurement).

  My preference is for the term Time Aperture. That makes it clear it
is narrow, and requires either leading and trailing numbers, or
a centre point, and a width would also be valid.
  The concept of Aperture then also naturally leads onto adding Jitter
on the clock, or data to any design margins.
  A centre point and width spec would more naturally align
with Jitter values.

  It also leads to Aperture skew, which is the miss-match in these
windows across multiple flip flops in a device. Not good if you
are crossing clock domains.
  These can be much wider than the metastable aperture.

  Then there is the metastable aperture (modeled) you mention above.

  I'm not sure I'd agree that the 0.03fs is the actual width of the 
aperture. The 0.03 is derived by extrapolate from a log eqn fit,
and has units of fs.

  Any attempt to measure the aperture would be swamped in jitter,
as best in class jitter is 'some picoseconds', rather than 
'sub-picoseconds'.
  A one volt signal with 1ns risetime, has 1mv/ps, so system
noise (gnd/vcc/crosstalk) in the order of 1mv will create in
the region of 1ps of jitter. 100ps rise, with 1% system noise
also gives 1ps jitter.

  I can think of a method where you might get close to getting a
physical aperture width value, but it would need a test chip, rather 
than std devices.

-jg


Article: 66116
Subject: Re: Peter's 1Hz-640MHz Synth project
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 13 Feb 2004 10:13:29 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Jay, give me a few weeks to publish.
> In a nutshell:  10 MHz xtal osc gets multiplied to 80 MHz, drives Direct
> Digital Synthesis accumulator, a "magic circuit" then multiplies the
> frequency and reduces the jitter. The Spartan-3 output drives the ICS
> PLL for further jitter reduction and multiplication by up to 8.
> Nice GUI and display control by PicoBlaze.
> Read about it in XCell, and I will also brag about characterization
> results in this ng, once we are finished.  Fun project  :-)

  Yes, sounds a great 'dynamic range' demonstration.
I've changed the topic heading if you want to keep us posted :)

  Any plans to add a 640MHz reciprocal Frequency counter - or
do you have this included already, just to prove the Synth is
on the right frequency :)

-jg



Article: 66117
Subject: Re: Sine Wave Generation
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 12 Feb 2004 21:38:54 GMT
Links: << >>  << T >>  << A >>
Ray Andraka wrote:

> The OP did not mention the sample rate relative to clock rate, the phase
> relationship of the sine to the sample interval if any, or the required
> precision.  Without these, it is not possible to offer a 'best' solution.  ROM
> is fine as long as the number of phase angles supported is small enough to fit
> in the address space of the ROM.  

(big snip)

I seem to remember ones that had two ROMs, where the second was
a linear interpolation.  Adders were then used to combine the
results from the ROMs.   There may be some FPGA cases where
that method could still be used.

-- glen


Article: 66118
Subject: Re: Sine Wave Generation
From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com>
Date: Thu, 12 Feb 2004 22:43:31 +0100
Links: << >>  << T >>  << A >>
SneakerNet wrote:

> Hi all
> 
> I need some help with regards to generating a sine wave. I thought abt this
> problem and some thoughts that came to mind are as follows:
> 1. Generate sine values using spreadsheet
> 2. Store these values either in ROM or make a table withing VHDL
> 3. Write VHDL code and output these values.
> 
> My question is:
> Is it better to store these values in ROM (eg. LUT) or directly hardcode the
> values.
> Is there a website that will explain or give more explanation in this area.
> 
> Cheers
> 
> 

1) write a sample counter. when the msb of the counter is '0', take all 
lsb. when the msb of the counter is '1', invert all lsb.
The result is a triangular wawe.

2) Cut the top and bottom of your triangular wawe using comparators

3) used a filter to remove harmonics

Laurent Gauch
www.amontec.com


Article: 66119
Subject: Re: Help: Configure PCI Device in Windows 2k
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Thu, 12 Feb 2004 13:57:24 -0800
Links: << >>  << T >>  << A >>

Hello,

> I figured that either BIOS or Windows configures the PCI board
> at bootup, and assigns the BAR0 etc. I am using an FPGA with the
> Xilinx PCI32 LogiCore. Hence, the Command and Status Register bit 2
> is '0' at startup. How can I set it to '1' after startup?

This is the responsibility of the device driver for your device.
If you don't have one, you will need to write one.  You can get
the Windows 2000 DDK from Microsoft for examples of how to do it.
Alternately you can purchase a device driver development kit.  I
can think of at least three vendors of such kits.

Basically, when your driver loads, it needs to locate the hardware
and then read what's in the BARs to know what addresses it should
use to access the hardware.  Also, at that time, you would want to
clear all the bits in the status regisiter, and then set whatever
bits you want in the command register.  After that, your hardware
is ready to go...

> For those of you familiar with the Xilinx PCI32 LogiCore, I've
> thought about hard setting the CFG_SELF bit to '1', which will
> fool the core to initiate master transactions.  But in simulation,
> I see that the ADIO bus does not get the date from the AD bus!

Don't do that; this signal is intended to be used only to enable
the core to perform CONFIG reads and writes to its own SELF.  And
you would only want to do that if you were in some kind of an
embedded system with no host.

> A more tedious way is to self configure the PCI core to master,
> but I am seeking an easier way.

You still shouldn't do that, unless you are in an embedded system
with no host (or you are the host) but that isn't the case if you
are in a Windows 2000 system.

I'm not a device driver writer (or even a programmer) and I was
able to leverage stuff in the DDK and a commercial device driver
development kit to get a driver working in Windows 2000.  I took
one of the examples that was closest to what I wanted to do and
then modified it.

Eric

Article: 66120
Subject: Re : fpga +cpu + wireless
From: benn686@hotmail.com (Ben Nguyen)
Date: 12 Feb 2004 14:01:47 -0800
Links: << >>  << T >>  << A >>
Andras,

Couldnt a simple RS-232 to USB chip (ex. www.ftdichip.com/FT2232C.htm )
be used instead of the Cypress SL811HS?  Then go wireless from there
like you mentioned.

Most PICs, AVR, etc have the RS232 built in, and you dont need an
external bus or any additional I/Os.

Im not sure about the "host" thing.

Ben




> The reason I went for fpga was to have wireless networking (802.11)
> Actually, the sensors are 3-4 miles apart, I need the data until a
> base station from where I will transfer the data to the internet.
> the base station is located in the filed and will be 1-2 miles distant
> from each sensor. So how do I transfer (in realtime) the data until the
> base station from the sensor. Is it possible with PCI micro.
> Please suggest me if there is a better solution other than fpga cpu
> for doing this (wireless networking).

Doing wireless with FPGA is not easier (nor harder) than with CPUs or MCUs.
You probably will end up using some kind of off-the-selves wireless card and
connect it to your custom application. Of what I understand of your
application probably a wireless USB card would be the best for your
application. Processing power is not an issue in your case. In that case you
need to choose (or implement) a USB host controller but for control even an
8-bit CPU (PIC or AVR or whatever) should be adequate. I don't know of any
8-bit micro that has an USB host (not function!) controller, but there's a
USB interface IC from Cypress, the SL811HS, that can be used as both a host
and a slave controller. So, my suggestion would be:

- Use an 8-bit microcontroller with an external bus (68HC11 from Motorola)
or one with enough of I/O pins (ATmega from Atmel) and probably a with
built-in A/D for the pressure sensors.
- Use the SL811HS from Cypress to implement the USB host controller
- Stick a wireless USB adapter to the unit to implement wireless
- For 1-2 miles you probably need high-gain, directed antennas so choose an
adapter that has external antenna connectivity.

Regards,
Andras Tantos

Article: 66121
Subject: Re: negative hold time
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 12 Feb 2004 14:06:44 -0800
Links: << >>  << T >>  << A >>
Jim, I agree 100% with your posting. Aperture would be a very good name.
But it looks like we are 40 years too late. It might be politicaly
incorrect to say nasty things about Texans...
Cheers
Peter
==========
Jim Granville wrote:
> 
> Peter Alfke wrote:
> > Glen, I have no problem with names, but I have a problem giving one
> > single parameter two different names. There is no inherent difference
> > between set-up and hold, they are just the two extreme ends of the same
> > parameter, the input timing window where D must be held constant, in
> > order to guarantee specified operation and performance.
> > At any one time, voltage, and temperature on a given part, the "two
> > parameters" collapse into a single value. I have measured the actual
> > width of the window (in Virtex-II Pro) as 0.03  femtoseconds. (see
> > TechXclusives on metastability measurement).
> 
>   My preference is for the term Time Aperture. That makes it clear it
> is narrow, and requires either leading and trailing numbers, or
> a centre point, and a width would also be valid.
>   The concept of Aperture then also naturally leads onto adding Jitter
> on the clock, or data to any design margins.
>   A centre point and width spec would more naturally align
> with Jitter values.
> 
>   It also leads to Aperture skew, which is the miss-match in these
> windows across multiple flip flops in a device. Not good if you
> are crossing clock domains.
>   These can be much wider than the metastable aperture.
> 
>   Then there is the metastable aperture (modeled) you mention above.
> 
>   I'm not sure I'd agree that the 0.03fs is the actual width of the
> aperture. The 0.03 is derived by extrapolate from a log eqn fit,
> and has units of fs.
> 
>   Any attempt to measure the aperture would be swamped in jitter,
> as best in class jitter is 'some picoseconds', rather than
> 'sub-picoseconds'.
>   A one volt signal with 1ns risetime, has 1mv/ps, so system
> noise (gnd/vcc/crosstalk) in the order of 1mv will create in
> the region of 1ps of jitter. 100ps rise, with 1% system noise
> also gives 1ps jitter.
> 
>   I can think of a method where you might get close to getting a
> physical aperture width value, but it would need a test chip, rather
> than std devices.
> 
> -jg

Article: 66122
Subject: Re: Peter's 1Hz-640MHz Synth project
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 12 Feb 2004 14:35:07 -0800
Links: << >>  << T >>  << A >>
Frequency counter is the next project. Since we have case, power supply,
display and all the mechanical trivia established, it is easy to build a
separate frequency counter, 1 Hz to 1.5 GHz with 9 digits of display.
Time base oscillator promises < 3 ppm (Maxim).
The "reciprocal" concept made it into a Xilinx "UltraController"
presentation and demo.
I will use the MultiGigabit Transceiver for the input. 3 Gbps = 1.5 MHz.
 I could use the newest Virtex-II ProX which is 3 times faster, but I do
not see so much demand for a 5 GHz input resolution (LVDS).  Gettinga
bit esoteric, but the chip can do it...
Keep you posted.

Peter Alfke
==========================
Jim Granville wrote:
> 
> 
>   Yes, sounds a great 'dynamic range' demonstration.
> I've changed the topic heading if you want to keep us posted :)
> 
>   Any plans to add a 640MHz reciprocal Frequency counter - or
> do you have this included already, just to prove the Synth is
> on the right frequency :)
> 
> -jg

Article: 66123
Subject: Re: Peter's 1Hz-640MHz Synth project
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 13 Feb 2004 11:58:28 +1300
Links: << >>  << T >>  << A >>


Peter Alfke wrote:
> Frequency counter is the next project. Since we have case, power supply,
> display and all the mechanical trivia established, it is easy to build a
> separate frequency counter, 1 Hz to 1.5 GHz with 9 digits of display.
> Time base oscillator promises < 3 ppm (Maxim).
> The "reciprocal" concept made it into a Xilinx "UltraController"
> presentation and demo.
> I will use the MultiGigabit Transceiver for the input. 3 Gbps = 1.5 MHz.
>  I could use the newest Virtex-II ProX which is 3 times faster, but I do
> not see so much demand for a 5 GHz input resolution (LVDS).  Gettinga
> bit esoteric, but the chip can do it...
> Keep you posted.

Thanks,
  Will this fit into your 'small spartan 3', alongside the Synth ?
  Can you feed the 1.5GHz into a flip flop / ring counter reliably ?
  What about Fmax of a variable modulus divider 1st stage ?
  (was it the 11C90 (?) from fairchild ?)

-jg


Article: 66124
Subject: Re: Configuration Altera Decives using EPC16 in PPS mode
From: gregs@altera.com (Greg Steinke)
Date: 12 Feb 2004 14:58:39 -0800
Links: << >>  << T >>  << A >>
tal_h@elbit.co.il (tal_h) wrote in message news:<7fc7c85.0402110004.797bdc7f@posting.google.com>...
> Hi,
> I have a problem in configurating altera devices in my board.
> my configuration scheme is as follows:
> 1 EPC16 device connected in PPS mode to:
> A stratix device connected to Data0 (EP1S20) & 2 cyclone devices
> (EP1C12) connected to Data1 & Data2 of the EPC16&#8230;
> When I power-up the board => the Configuration isn't done.
> I've looked on the nSTATUS & CONF_DONE signals and they look fine!
> the CONF_DONE stays LOW all the time. the nSTATUS goes HIGH ~85mSec
> after power is stable.
> the DCLK signals stays LOW all the time! (there isn't DCLK)
> I've tried an external OSC to the EPC16 => still the same phenomenon.
> Please Advice!
> Tal

Hi Tal,
The EPC16 should be driving out the DCLK signal, so figuring out why
this does not happen is key. However it's hard to say exactly what is
the problem based on this description. Here's a few things to try:

1. Make sure that the MSEL pins are set correctly on the FPGAs. PPS is
the acronym for Passive Parallel Synchronous - but the setup where one
EPC16 drives multiple FPGAs in parallel like this is called Concurrent
Configuration, and each FPGA should be set to Passive Serial as each
is receiving a serial stream.

2. Make sure the PGM pins are set correctly on the EPC16 to show which
page of data you want to access. If you are not doing anything special
like storing multiple configurations, they should be set to 0.

3. There are some external connections that must be made on the EPC16.
The F-RP# pin must be connected to the C-RP# pin. And the F-WE# pin
must be connected to the C-WE# pin. This connection is because the
EPC16 actually has two dice in it - a Flash and a controller. During
the production test, the Flash pins are driven to 12 V, but the
controller cannot handle this, therefore the connection cannot be made
in the package.

4. The FPGA VCCINT must be powered before the POR on the EPC16
expires. The POR can be set to 2 ms or 100 ms by using the PORSEL pin
- if you drive PORSEL low, then the POR is 100 ms. If this is not
done, then the EPC16 will never start configuration and you will not
see DCLK toggle.

Hopefully one of these solves the problem. If not, please check out
the FPGA Configuration Troubleshooter found on this web site:
http://www.altera.com/cgi-bin/ts.pl?fn=configuration

And if that doesn't work, then you may need to call the distributor,
FAE, or AE for some more assistance as the problem debug starts to get
very specific.

Sincerely,
Greg Steinke
Altera Corporation
gregs@altera.com



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
2019JanFebMar2019

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