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 112500

Article: 112500
Subject: Re: Problems connecting MicroBlaze to custom IP
From: Zara <me_zara@dea.spamcon.org>
Date: Thu, 23 Nov 2006 15:43:23 +0100
Links: << >>  << T >>  << A >>
On 23 Nov 2006 04:41:41 -0800, "Antti" <Antti.Lukats@xilant.com>
wrote:

>Christian Schleiffer schrieb:
>
>> Hi,
>>
>> I'm trying to connect a MicroBlaze system build in EDK to a custom
>> periphal core. I am using Atmark's Suzaku board [1]. It is shipped with
>> an example project which I would like to extend via FSL. Here is what I did:
>>
>> - Added two FSL cores and connected them to the MB
>> - Changed the ports for my periphal to "make external"
<...>
>>
>one solution is to make the MB FSL ports external, in that case you
>have no FSL bus in EDK, this works for sure, but you have to implement
>the FSL bus and-or fifos in ISE toplevel then
>

Another solution is making FSL BUS ports external, leaving the other
side connected to MB. Thus you don't need to implement FSL FIFOS.

Zara

Article: 112501
Subject: Re: Xilinx EDK Problem
From: "Antti" <Antti.Lukats@xilant.com>
Date: 23 Nov 2006 06:46:47 -0800
Links: << >>  << T >>  << A >>
maxascent schrieb:

> Hi
>
> I have a design with a Power PC that I am trying to put through ISE. The
> problem I have is that I get the following error.
>
> Failed to process BMM file
>
> Not sure why or how to fix this as there is a bmm file in the
> implementation dir. Any help would be appreciated
>
> Jon
the instance path in BMM is possible wrong.

make sure you have added the XMP file as submodule in ISE then it
should work ok
the XPS export-import feature should not be used!

Antti


Article: 112502
Subject: Re: Cypress 68013 - Xilinx FPGA
From: "Will Dean" <will@nospam.demon.co.uk>
Date: Thu, 23 Nov 2006 15:49:47 -0000
Links: << >>  << T >>  << A >>
"al99999" <alastairlynch@gmail.com> wrote in message 
news:1164284398.352919.41170@l12g2000cwl.googlegroups.com...

> I have now written a program to initialise the 68013 to slave fifo
> mode, but I am struggling to find any tutorials on how to program this
> onto the 68013 and test it.  If for example I wished to write to a
> memory location on the 8051 and then read it back how could I do this.

This is off-topic for this group, but you're clearly struggling.

The 68013 doesn't have non-volatile storage internally, you either store the 
code in an external EEPROM or you send it down the USB cable at USB 
enumeration time.   The chip will actually run the code from RAM.

You need to get the (free) development tools from Cypress, which contain 
lots of samples (of variable quality) and utilities/drivers to help you send 
the code down into the chip or into an external EEPROM.

You would probably find comp.arch.embedded a better group for support - I 
suspect you're going to need lots of it.

Will



Article: 112503
Subject: Re: Altera configuration with microcontroller
From: "Will Dean" <will@nospam.demon.co.uk>
Date: Thu, 23 Nov 2006 15:56:38 -0000
Links: << >>  << T >>  << A >>
"Nevo" <nevo_n@hotmail.com> wrote in message 
news:va89h.8052$oP6.1833@trnddc03...
>
> Before I go off and reinvent the wheel, does anyone know of a prepackaged 
> solution for programming an Altera device (I'm using a Cyclone) with a 
> microcontroller that I can just drop into my project?  I'm sure I can't be 
> the first person to do this. If anyone has a website describing a similar 
> setup, I'd love to see it.

I always configure FPGAs from micros rather than expensive configuration 
chips, sometimes from local flash, but often from a PC over USB or similar.

The Altera Cyclone handbook describes exactly how to do what you want with a 
micro - look at 'Passive Serial' in the configuration chapter.  It's 
trivial.

I suspect it will be quicker to get it working from scratch yourself than to 
try and munge someone else's design into your own specific platform.

Will



Article: 112504
Subject: Re: DCM Jitter
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 23 Nov 2006 08:03:00 -0800
Links: << >>  << T >>  << A >>
Andrew,

You can not (meet timing).

http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&category=&sGlobalNavPick=&sSecondaryNavPick=&multPartNum=1&sTechX_ID=al_slack
and
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&category=&sGlobalNavPick=&sSecondaryNavPick=&multPartNum=1&sTechX_ID=rw_tim_closure

Austin

Andrew Holme wrote:

> Tool = ISE 8.2i
> Target = Spartan 3 xc3s400-4tq144
> 
> I'm using an external 50 MHz oscillator and a single DCM to generate
> clocks of 50, 100 and 200 MHz.  The static timing reports says the
> minimum period for my 200 MHz clock is 4.999ns i.e. 1ps to spare.
> 
> I saw this comment in the Verilog file auto-generated by the DCM
> wizard:
> 
>    // Period Jitter (unit interval) for block DCM_INST = 0.14 UI
>    // Period Jitter (Peak-to-Peak) for block DCM_INST = 0.70 ns
> 
> What does this mean?  How can I meet timing by 1ps when the jitter is
> 700ps?
> 

Article: 112505
Subject: Re: board - T562.jpg
From: "Homer J Simpson" <nobody@nowhere.com>
Date: Thu, 23 Nov 2006 17:25:36 GMT
Links: << >>  << T >>  << A >>

"John Fields" <jfields@austininstruments.com> wrote in message 
news:dlvam25q5c9n959lsspek87p0v8bkgie21@4ax.com...

>>> How high did it go?  to 9?
>>
>>You still count on your fingers?

> Sure. For lots of things.

Try taking off your shoes if you can stand the smell. That will almost 
double your counting ability.





Article: 112506
Subject: Re: C++ on uBlaze : C++ Problems...Possible Xilinx bugs ?
From: Tim Wescott <tim@seemywebsite.com>
Date: Thu, 23 Nov 2006 09:53:48 -0800
Links: << >>  << T >>  << A >>
Alfmyk wrote:

> Hi all.
> 
> I'm using EDK 8.2.02i. ISE: 8.2.03i. Board: Spartan 3E Xilinx Starter Kit Rev.D
> 
> I'd like use C++ for my SW project but I have found problems...
> 
> 1) Using namespace --------------- In my code application.h I have written:
> 
> namespace prova1{ int a=5; };
> 
> namespace prova2{ int a=10; int b=8; };
> 
> Then to make a test in my application.cc :
> 
> printf("prova1::a = %d \n", prova1::a); printf("prova2::a = %d \n", prova2::a); printf("prova2::b = %d \n", prova2::b);
> 
> So I expect to see in my terminal right values, but what really happen is:
> 
> prova1::a = 5 prova2::a = 5 prova2::b = 8
> 
> So system show and see only the first "a".
> 
> Moreover, and this is incredible, if in my makefile I compile using -0s optimization (size) then no error happen in linking. But if i DON'T USE ANY OPTIMIZATION this error occurs:
> * *********************************************************************************** Creating target elf file... mb-g++ -Wl,-defsym -Wl,_TEXT_START_ADDR=0x22000C00 -o ./application.elf -Wall -g application.cc \ -I../microblaze_0/include/ -I../Libs/ \ -L../microblaze_0/lib/ -L../Libs/ -LD:\EDK/gnu/microblaze/nt/mi croblaze/lib -LD:\EDK/gnu/microblaze/nt/include/C++/3.4.1/ -lcommon -lstdc++ /cygdrive/c/DOCUME~1/alettoal/LOCALS~1/Temp/cc31lsQU.s: Assembler messages: /cygdrive/c/DOCUME~1/alettoal/LOCALS~1/Temp/cc31lsQU.s:102: Fatal error: Symbol a already defined. make: *** [application.elf] Error 1
> * ***********************************************************************************
> 
> 2) Using simple class ------------------
> 
> In my application.h :
> 
> class Cliente { public: char name[20]; char surname[20]; void p() { printf("Client::p\n"); } virtual void insert_name( void ) = 0; };
> 
> class ClienteD : public Cliente { public: void insert_name() { printf("insert_name ClientD\n"); } void p() { printf("ClientD::p\n"); } };
> 
> In my application.cc :
> 
> ...
> 
> ClienteD pippo; ...
> 
> ClienteD* cliente = new ClienteD(); cliente->insert_name(); cliente->p();
> 
> Cliente* base = new ClienteD(); base->insert_name(); base->p();
> 
> pippo.p();
> 
> But when I see my terminal window NOTHING, NO any printf() Appear !
> 
> KEEP IN MIND that the SAME application (Example 2) only) I used for testing C++ with EDK 8.1.01i and all was fine ! Why now I have all these problem ?
> 
> Thanks in advance for any answers !
> 
> Cheers,
> 
> Al.

This sounds more like a problem with the compiler than with the chip or 
processor implementation.

I suggest that if you don't already have a native PC gnu toolchain that 
you get one (use Cygwin if you're running windows), try your code out on 
that, and see what happens.  If you get the same results then you'll 
know that it's an issue either with Gnu or you.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 112507
Subject: Re: Protecting netlist for Xilinx
From: fpga_toys@yahoo.com
Date: 23 Nov 2006 11:52:05 -0800
Links: << >>  << T >>  << A >>

Austin Lesea wrote:
> In Virtex 5, we have provided for decrypting AND reconfiguration, so
> that you may load multiple encrypted bitstreams (all using the same
> key), but again, this does not provide a model for IP 'per use'
> payments.  It does allow for secure crypto solutions for applications
> like SDR.
>
> It is a tough problem, and one we would like to solve (obviously).

If you can get the bits into the fpga securely, and the fpga has
network access, then you can easily do per use.

This is where failing to think in terms of systems level solutions
generally gets the hardware only guys only part way to a viable
solution. At a systems level, simply providing access to a license
server can easily lock valuable IP on a per use basis. Again, it's
possible to defeat a license server, but it does raise the bar
considerably, especially if the license server is not hosted at the
customers site.


Article: 112508
Subject: Re: board - T562.jpg
From: John Fields <jfields@austininstruments.com>
Date: Thu, 23 Nov 2006 14:35:31 -0600
Links: << >>  << T >>  << A >>
On Thu, 23 Nov 2006 17:25:36 GMT, "Homer J Simpson"
<nobody@nowhere.com> wrote:

>
>"John Fields" <jfields@austininstruments.com> wrote in message 
>news:dlvam25q5c9n959lsspek87p0v8bkgie21@4ax.com...
>
>>>> How high did it go?  to 9?
>>>
>>>You still count on your fingers?
>
>> Sure. For lots of things.
>
>Try taking off your shoes if you can stand the smell. That will almost 
>double your counting ability.

---
Almost?

Hmmm... I take it back.  Did your sieve go as high as 7?


-- 
JF

Article: 112509
Subject: Re: Constraining timing analyser when using two DCMs
From: "Andrew Holme" <andrew@nospam.com>
Date: Thu, 23 Nov 2006 20:51:36 -0000
Links: << >>  << T >>  << A >>

"Symon" <symon_brewer@hotmail.com> wrote in message 
news:4565b22b$1_1@x-privat.org...
> "Andrew Holme" <ajholme@hotmail.com> wrote in message 
> news:1164289962.815338.179200@j44g2000cwa.googlegroups.com...
>> Tool = ISE 8.2i
>> Target = Spartan 3 xc3s400-4tq144
>>
>> I have routing delays which cannot be cancelled by the DLL.  How do I
>> stop the tools from checking paths between different clock domains?
>>
> Google UCF TIG
> HTH, Syms.
>

I tried putting this in my UCF:

NET clk_50  TNM_NET = clk_grp1;
NET clk_90  TNM_NET = clk_grp2;
NET clk_180 TNM_NET = clk_grp3;
TIMESPEC tig1 = FROM clk_grp1 TO clk_grp2 TIG;
TIMESPEC tig2 = FROM clk_grp1 TO clk_grp3 TIG;
TIMESPEC tig3 = FROM clk_grp2 TO clk_grp1 TIG;
TIMESPEC tig4 = FROM clk_grp2 TO clk_grp3 TIG;
TIMESPEC tig5 = FROM clk_grp3 TO clk_grp1 TIG;
TIMESPEC tig6 = FROM clk_grp3 TO clk_grp2 TIG;

But I get errors:
ERROR:NgdBuild:765 - Line 46 in 'foo.ucf': A parsing error has occurred 
while
   reading the constraint file. The value 'tig' at column 10 is invalid.




Article: 112510
Subject: Re: DCM Jitter
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 23 Nov 2006 20:52:29 GMT
Links: << >>  << T >>  << A >>
Andrew Holme wrote:
> Tool = ISE 8.2i
> Target = Spartan 3 xc3s400-4tq144
> 
> I'm using an external 50 MHz oscillator and a single DCM to generate
> clocks of 50, 100 and 200 MHz.  The static timing reports says the
> minimum period for my 200 MHz clock is 4.999ns i.e. 1ps to spare.
> 
> I saw this comment in the Verilog file auto-generated by the DCM
> wizard:
> 
>    // Period Jitter (unit interval) for block DCM_INST = 0.14 UI
>    // Period Jitter (Peak-to-Peak) for block DCM_INST = 0.70 ns
> 
> What does this mean?  How can I meet timing by 1ps when the jitter is
> 700ps?

Austin didn't directly address the DCM-generated jitter.

There has been information on the Xilinx tools that suggest that jitter 
from the DCMs - assuming the input jitter is clean (within datasheet 
spec) to those devices - is included in the timing analysis.  The caveat 
I saw was something like "for thoroughly characterized Xilinx devices 
such as the Virtex-4 family" or similar qualification targeting the DCM 
jitter.

I do not know if the tools do, indeed, add the jitter into the timing 
uncertainty.  I haven't looked hard for it but perhaps I should look 
harder.  The caveat left me with a poor feeling about the tools' ability 
to deal with my Spartan3(E) designs because I don't know if those 
families were "thoroughly characterized" or not.

I'd suggest looking at the full timing report for a 200 MHz path and for 
a 50 MHz path.  Do both have identical Tco and Tsu times?  Is there a 
"clock uncertainty" value used in the slack calculation?

The assumption here is that you have a low jitter clock presented to 
your system for the DCMs to work from.  If your input jitter isn't 
clean, that value needs to be added to your UCF.  If it is clean, it was 
my understanding that the tools were supposed to automatically propagate 
the DCM jitter values to the registers in that clock domain.

Are we there?  With all recent families?  With some?

Article: 112511
Subject: Re: board - T562.jpg
From: "Homer J Simpson" <nobody@nowhere.com>
Date: Thu, 23 Nov 2006 20:55:54 GMT
Links: << >>  << T >>  << A >>

"John Fields" <jfields@austininstruments.com> wrote in message 
news:4e1cm2ph7tkl0pm0ek7hin684pquochl58@4ax.com...

> Hmmm... I take it back.  Did your sieve go as high as 7?

If it did it would exceed your IQ by a comfortable margin.




Article: 112512
Subject: Re: Voltage prorating for Spartan 3
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 23 Nov 2006 20:58:52 GMT
Links: << >>  << T >>  << A >>
Andrew Holme wrote:
> Tool = ISE 8.2i
> Target = Spartan 3 xc3s400-4tq144
> 
> I created a prorated VOLTAGE constraint using the GUI constraints
> editor; but it seems to be ignored when I implement my design.  The PAR
> report quotes the default of 1.140V.  When I launch Timing Analyzer, it
> says prorating is not available for my device and speed grade.  Is
> there any way around this?  My design achieves timing closure, but only
> by 1ps, which is cutting it a bit fine!  Should I be worried?

The delays are for worst case process/voltage/temperature values unless 
the timing models support prorating and you've specified a prorated 
value.  Since you got the "not available" message, your timing is based 
on worst-case.  If the DCM jitter *is* included in your timing, your 
input clock is clean, and you don't have SSO issues that would make that 
input clock dirty, my understanding is that 4.999 ns value *is* worst 
case.  I haven't had problems in my designs (which are not subject to 
temperature extremes) that stop trying to improve timing the moment it 
achieves 1 ps of margin.  I have over-specified my frequency or added 
INPUT_JITTER to my constraints in the past but haven't had "flaky 
operation" to deal with as a result of marginal timing.

The tools stop trying at 1 ps margin.  You should be able to rely on 
this OR expect the tools to keep trying.

Article: 112513
Subject: Re: Constraining timing analyser when using two DCMs
From: "Andrew Holme" <andrew@nospam.com>
Date: Thu, 23 Nov 2006 21:15:13 -0000
Links: << >>  << T >>  << A >>

"Andrew Holme" <andrew@nospam.com> wrote in message 
news:ek51ko$11p$1$8300dec7@news.demon.co.uk...
>
> "Symon" <symon_brewer@hotmail.com> wrote in message 
> news:4565b22b$1_1@x-privat.org...
>> "Andrew Holme" <ajholme@hotmail.com> wrote in message 
>> news:1164289962.815338.179200@j44g2000cwa.googlegroups.com...
>>> Tool = ISE 8.2i
>>> Target = Spartan 3 xc3s400-4tq144
>>>
>>> I have routing delays which cannot be cancelled by the DLL.  How do I
>>> stop the tools from checking paths between different clock domains?
>>>
>> Google UCF TIG
>> HTH, Syms.
>>
>
> I tried putting this in my UCF:
>
> NET clk_50  TNM_NET = clk_grp1;
> NET clk_90  TNM_NET = clk_grp2;
> NET clk_180 TNM_NET = clk_grp3;
> TIMESPEC tig1 = FROM clk_grp1 TO clk_grp2 TIG;
> TIMESPEC tig2 = FROM clk_grp1 TO clk_grp3 TIG;
> TIMESPEC tig3 = FROM clk_grp2 TO clk_grp1 TIG;
> TIMESPEC tig4 = FROM clk_grp2 TO clk_grp3 TIG;
> TIMESPEC tig5 = FROM clk_grp3 TO clk_grp1 TIG;
> TIMESPEC tig6 = FROM clk_grp3 TO clk_grp2 TIG;
>
> But I get errors:
> ERROR:NgdBuild:765 - Line 46 in 'foo.ucf': A parsing error has occurred 
> while
>   reading the constraint file. The value 'tig' at column 10 is invalid.
>
>

This seems to work:

TIMESPEC TS_tig1 = FROM clk_grp1 TO clk_grp2 TIG;
TIMESPEC TS_tig2 = FROM clk_grp1 TO clk_grp3 TIG;
TIMESPEC TS_tig3 = FROM clk_grp2 TO clk_grp1 TIG;
TIMESPEC TS_tig4 = FROM clk_grp2 TO clk_grp3 TIG;
TIMESPEC TS_tig5 = FROM clk_grp3 TO clk_grp1 TIG;
TIMESPEC TS_tig6 = FROM clk_grp3 TO clk_grp2 TIG;

It seems to need the TS.



Article: 112514
Subject: Re: Problems connecting MicroBlaze to custom IP
From: Christian Schleiffer <cschleiffer@crypto.rub.de>
Date: Thu, 23 Nov 2006 22:15:32 +0100
Links: << >>  << T >>  << A >>
Zara schrieb:
> On 23 Nov 2006 04:41:41 -0800, "Antti" <Antti.Lukats@xilant.com>
> wrote:
> 
>> Christian Schleiffer schrieb:
>>
>>> Hi,
>>>
>>> I'm trying to connect a MicroBlaze system build in EDK to a custom
>>> periphal core. I am using Atmark's Suzaku board [1]. It is shipped with
>>> an example project which I would like to extend via FSL. Here is what I did:
>>>
>>> - Added two FSL cores and connected them to the MB
>>> - Changed the ports for my periphal to "make external"
> <...>
>> one solution is to make the MB FSL ports external, in that case you
>> have no FSL bus in EDK, this works for sure, but you have to implement
>> the FSL bus and-or fifos in ISE toplevel then
>>
> 
> Another solution is making FSL BUS ports external, leaving the other
> side connected to MB. Thus you don't need to implement FSL FIFOS.
> 
> Zara

Hi Zara,

this is exactly what I tried to do.

>>> - Changed the ports for my periphal to "make external"
                  ^^^^^^^^^^^^
Maybe that should have been "...ports _to_ my..." ;)
My fault. Thanks anyway.

/Chris

Article: 112515
Subject: Re: Problems connecting MicroBlaze to custom IP
From: Christian Schleiffer <cschleiffer@crypto.rub.de>
Date: Thu, 23 Nov 2006 22:17:38 +0100
Links: << >>  << T >>  << A >>
Christian Schleiffer schrieb:
> Antti wrote:
> 
>> one solution is to make the MB FSL ports external, in that case you
>> have no FSL bus in EDK, this works for sure, but you have to implement
>> the FSL bus and-or fifos in ISE toplevel then
> 
> Good point. It should be quite simple to implement FSL myself, but I
> think I even saw some source files somewhere in the EDK directory...

Antti,

I found the instantiation template for the FSL bus and it took me about
5 minutes to make it working your way.

Thanks very much
/Chris

Article: 112516
Subject: Re: Spartan 3E-Kit
From: spartanius@arcor.de
Date: 23 Nov 2006 13:48:08 -0800
Links: << >>  << T >>  << A >>

I only find "C:\Dokumente und Einstellungen\MyName" but there is no
"Lokale Einstellungen", however, neiter with the user "administrator"
nor with "all users". ????


Article: 112517
Subject: Re: board - T562.jpg
From: John Fields <jfields@austininstruments.com>
Date: Thu, 23 Nov 2006 15:54:46 -0600
Links: << >>  << T >>  << A >>
On Thu, 23 Nov 2006 20:55:54 GMT, "Homer J Simpson"
<nobody@nowhere.com> wrote:

>
>"John Fields" <jfields@austininstruments.com> wrote in message 
>news:4e1cm2ph7tkl0pm0ek7hin684pquochl58@4ax.com...
>
>> Hmmm... I take it back.  Did your sieve go as high as 7?
>
>If it did it would exceed your IQ by a comfortable margin.

---
Well, there ya go!  That's not too bad, actually, considering that
before I took on the job of teaching you how not to walk on your
knuckles you were mostly interested in where your next banana was
coming from.


-- 
JF

Article: 112518
Subject: Re: DCM Jitter
From: "Andrew Holme" <andrew@nospam.com>
Date: Thu, 23 Nov 2006 22:08:00 -0000
Links: << >>  << T >>  << A >>

"John_H" <newsgroup@johnhandwork.com> wrote in message 
news:hSn9h.6231$J5.2710@trnddc04...
> Andrew Holme wrote:
>> Tool = ISE 8.2i
>> Target = Spartan 3 xc3s400-4tq144
>>
>> I'm using an external 50 MHz oscillator and a single DCM to generate
>> clocks of 50, 100 and 200 MHz.  The static timing reports says the
>> minimum period for my 200 MHz clock is 4.999ns i.e. 1ps to spare.
>>
>> I saw this comment in the Verilog file auto-generated by the DCM
>> wizard:
>>
>>    // Period Jitter (unit interval) for block DCM_INST = 0.14 UI
>>    // Period Jitter (Peak-to-Peak) for block DCM_INST = 0.70 ns
>>
>> What does this mean?  How can I meet timing by 1ps when the jitter is
>> 700ps?
>
> Austin didn't directly address the DCM-generated jitter.
>
> There has been information on the Xilinx tools that suggest that jitter 
> from the DCMs - assuming the input jitter is clean (within datasheet spec) 
> to those devices - is included in the timing analysis.  The caveat I saw 
> was something like "for thoroughly characterized Xilinx devices such as 
> the Virtex-4 family" or similar qualification targeting the DCM jitter.
>
> I do not know if the tools do, indeed, add the jitter into the timing 
> uncertainty.  I haven't looked hard for it but perhaps I should look 
> harder.  The caveat left me with a poor feeling about the tools' ability 
> to deal with my Spartan3(E) designs because I don't know if those families 
> were "thoroughly characterized" or not.
>
> I'd suggest looking at the full timing report for a 200 MHz path and for a 
> 50 MHz path.  Do both have identical Tco and Tsu times?  Is there a "clock 
> uncertainty" value used in the slack calculation?
>
> The assumption here is that you have a low jitter clock presented to your 
> system for the DCMs to work from.  If your input jitter isn't clean, that 
> value needs to be added to your UCF.  If it is clean, it was my 
> understanding that the tools were supposed to automatically propagate the 
> DCM jitter values to the registers in that clock domain.
>
> Are we there?  With all recent families?  With some?

I generated a verbose timing report, as you suggested, and every single path 
included the line:

  Clock Uncertainty:    0.000ns

So I don't think the DCM jitter is automatically propogated.

If the tools stop trying as soon as they get 1ps of slack, how is it 
supposed to work?  Am I supposed to manually create a jitter constraint for 
the DCM?




Article: 112519
Subject: Re: Spartan 3E-Kit
From: Frank Buss <fb@frank-buss.de>
Date: Thu, 23 Nov 2006 23:12:36 +0100
Links: << >>  << T >>  << A >>
spartanius@arcor.de wrote:

> I only find "C:\Dokumente und Einstellungen\MyName" but there is no
> "Lokale Einstellungen", however, neiter with the user "administrator"
> nor with "all users". ????

You have to enable hidden files. In German Windows just enable the well
hidden option "Extras->Ordernoptionen->Ansicht->Versteckte Dateien und
Ordner->Alle Dateien und Ordner anzeigen" (and while you are in this mask,
make sure to disable the option "Erweiterungen bei bekannten Dateitypen
ausblenden" for a better life :-)

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 112520
Subject: Re: board - T562.jpg
From: "Homer J Simpson" <nobody@nowhere.com>
Date: Thu, 23 Nov 2006 22:58:47 GMT
Links: << >>  << T >>  << A >>

"John Fields" <jfields@austininstruments.com> wrote in message 
news:ph5cm2lv6pguo2rlnnqnc1q0pievcv5cgk@4ax.com...

> Well, there ya go!  That's not too bad, actually, considering that
> before I took on the job of teaching you how not to walk on your
> knuckles you were mostly interested in where your next banana was
> coming from.

You seem to have a fixation about where YOUR next banana will be inserted.




Article: 112521
Subject: Re: DCM Jitter
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 24 Nov 2006 01:19:00 GMT
Links: << >>  << T >>  << A >>
Andrew Holme wrote:
> "John_H" <newsgroup@johnhandwork.com> wrote in message 
> news:hSn9h.6231$J5.2710@trnddc04...
>> Andrew Holme wrote:
>>> Tool = ISE 8.2i
>>> Target = Spartan 3 xc3s400-4tq144
>>>
>>> I'm using an external 50 MHz oscillator and a single DCM to generate
>>> clocks of 50, 100 and 200 MHz.  The static timing reports says the
>>> minimum period for my 200 MHz clock is 4.999ns i.e. 1ps to spare.
>>>
>>> I saw this comment in the Verilog file auto-generated by the DCM
>>> wizard:
>>>
>>>    // Period Jitter (unit interval) for block DCM_INST = 0.14 UI
>>>    // Period Jitter (Peak-to-Peak) for block DCM_INST = 0.70 ns
>>>
>>> What does this mean?  How can I meet timing by 1ps when the jitter is
>>> 700ps?
>> Austin didn't directly address the DCM-generated jitter.
>>
>> There has been information on the Xilinx tools that suggest that jitter 
>> from the DCMs - assuming the input jitter is clean (within datasheet spec) 
>> to those devices - is included in the timing analysis.  The caveat I saw 
>> was something like "for thoroughly characterized Xilinx devices such as 
>> the Virtex-4 family" or similar qualification targeting the DCM jitter.
>>
>> I do not know if the tools do, indeed, add the jitter into the timing 
>> uncertainty.  I haven't looked hard for it but perhaps I should look 
>> harder.  The caveat left me with a poor feeling about the tools' ability 
>> to deal with my Spartan3(E) designs because I don't know if those families 
>> were "thoroughly characterized" or not.
>>
>> I'd suggest looking at the full timing report for a 200 MHz path and for a 
>> 50 MHz path.  Do both have identical Tco and Tsu times?  Is there a "clock 
>> uncertainty" value used in the slack calculation?
>>
>> The assumption here is that you have a low jitter clock presented to your 
>> system for the DCMs to work from.  If your input jitter isn't clean, that 
>> value needs to be added to your UCF.  If it is clean, it was my 
>> understanding that the tools were supposed to automatically propagate the 
>> DCM jitter values to the registers in that clock domain.
>>
>> Are we there?  With all recent families?  With some?
> 
> I generated a verbose timing report, as you suggested, and every single path 
> included the line:
> 
>   Clock Uncertainty:    0.000ns
> 
> So I don't think the DCM jitter is automatically propogated.
> 
> If the tools stop trying as soon as they get 1ps of slack, how is it 
> supposed to work?  Am I supposed to manually create a jitter constraint for 
> the DCM?

You can specify JITTER and/or INPUT_JITTER in the constraints file; 
check your constraints guide for details.

If the "Clock Uncertainty" is where the jitter shows up, then yes - you 
would need to add the jitter values manually.  I had thought, however, 
that the adjustments for DCM generated jitter showed up in a different 
form for those families where DCM jitter *is* included such as for the 
Tco or Tsu times.  If those values match picosecond for picosecond, then 
you have no DCM jitter included through those values

Article: 112522
Subject: What's Nonpipelined bus mean?
From: "Davy" <zhushenli@gmail.com>
Date: 23 Nov 2006 18:08:27 -0800
Links: << >>  << T >>  << A >>
Hi all,

I always heard Nonpipelined bus. Is any bus Nonpipelined? Or is there
Pipelined bus or other types of bus. Thanks in advance!

Best regards,
Davy


Article: 112523
Subject: Re: What's Nonpipelined bus mean?
From: "rickman" <gnuarm@gmail.com>
Date: 23 Nov 2006 20:32:55 -0800
Links: << >>  << T >>  << A >>
Davy wrote:
> Hi all,
>
> I always heard Nonpipelined bus. Is any bus Nonpipelined? Or is there
> Pipelined bus or other types of bus. Thanks in advance!

Sure, a bus can be pipelined.  In many FPGAs busses are actually a
collection of point to point connections with multiplexers.  The
multiplexers can be pipelined in sections which will allow faster clock
speeds.


Article: 112524
Subject: Re: What's Nonpipelined bus mean?
From: "Davy" <zhushenli@gmail.com>
Date: 23 Nov 2006 20:36:18 -0800
Links: << >>  << T >>  << A >>
Hi, rickman,

Thanks!

Can you tell me what's Nonpipelined bus mean?

Best regards,
Davy

rickman wrote:
> Davy wrote:
> > Hi all,
> >
> > I always heard Nonpipelined bus. Is any bus Nonpipelined? Or is there
> > Pipelined bus or other types of bus. Thanks in advance!
>
> Sure, a bus can be pipelined.  In many FPGAs busses are actually a
> collection of point to point connections with multiplexers.  The
> multiplexers can be pipelined in sections which will allow faster clock
> speeds.




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