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 62375

Article: 62375
Subject: Re: Xilinx JTAG Parallel IV cable and INITIALIZING CHAIN
From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com>
Date: Tue, 28 Oct 2003 12:05:44 +0100
Links: << >>  << T >>  << A >>
Amontec Team, Laurent Gauch wrote:

> Ronald Chung wrote:
> 
>> I have spent three-four days on several XPLA3 CPLD boards that I've
>> designed (same boards) to determine why the JTAG is not working
>> properly.  I cannot initialize the chain to "read" what devices are on
>> the boundary scan chain, nor will TDO change states.  I can set
>> "levels" on TDI, TMS, and TCK using the "Start Debug Chain" portion of
>> the Xilinx IMPACT software.
>>
>> I am using the Parallel IV cable and have read a few places it could
>> be cable length issues?  Does ANYONE have any type of experience with
>> this?  I've been wracking my brains out trying to figure out what's
>> wrong.
>>
>> I am using a "home-made" cable because my PCB is used in embedded
>> application with limited space.
>>
>> Even went to a BLANK PCB and stuffed only CPLD, linear regulator, and
>> caps.
>>
>> Any help is MUCH MUCH appreciated...
>>
>> Thanks!
> 
> 
> Try to add an 1K pull-up on TDO and let me know if that's better.
> 
> Laurent
> www.amontec.com
> 
place the pull-up on 5V (if you have a 5V)

Laurent
www.amontec.com


Article: 62376
Subject: Re: Electronic Dice VHDL Program
From: "Jonathan Bromley" <jonathan.bromley@doulos.com>
Date: Tue, 28 Oct 2003 11:08:05 -0000
Links: << >>  << T >>  << A >>
"Tim" <tim@rockylogic.com.nooospam.com> wrote in
message news:bnli77$j0i$1$8302bc10@news.demon.co.uk...

> Jonathan - do you happen to know how fasible it is to
> generate a random stream by sampling white noise with
> an A->D converter.  By feasible I mean a reasonable cost
> level and a reasonable component count, though I guess
> qualifying the resulting circuit is really the expensive
> part of the job.

hi Tim,

sorry to disappoint but I have no experience of doing this.
I do know that people have used various kinds of active
device (zener diodes are a good candidate) to generate
noise that can be used to control a process randomly.
But I'd be very frightened that the sampling process would
introduce some systematic bias that I didn't know about,
and as you say the verification would be a nightmare.

> Somewhere in "The Art of Computer Programming" Knuth points
> out that you cannot generate random numbers by randomly
> choosing an algorithm ;-)

Grin.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                    mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 62377
Subject: How can I lock design with ISE 5.2?
From: qiu.xiaoyong@zte.com.cn (wosiqiu)
Date: 28 Oct 2003 04:02:16 -0800
Links: << >>  << T >>  << A >>
Hi,
   I am doing a large_scale design with Xilinx Virtex2 and at the end
of it.
Now,the modification of the design seems to be painful,for a bit
modification will take a very long P&R. So I hope that there can be
some suggestions about how to lock the unchanged portion of the
design.
Best rgds.
Wosiqiu.

Article: 62378
Subject: Re: chipscope pro and jtag
From: henk@mediatronix.com (Henk van Kampen)
Date: 28 Oct 2003 05:07:58 -0800
Links: << >>  << T >>  << A >>
> this cant be used with Cable IV, because the API and documentation
> about Cable IV are kept as secret.

I have successfully used a Cable IV assuming it is a Cable III. The
only problem is that iMPACT leaves the cable and your port in an
undefined state, so you have to reset the ECP mode and reset the cable
(reset printer). Of course you will not benefit from the ECP speed
possible with the Cable IV.

Henk van Kampen
www.mediatronix.com

Article: 62379
Subject: Re: Are clock and divided clock synchronous?
From: "louis lin" <louis@zyflex.com.tw>
Date: Tue, 28 Oct 2003 21:18:56 +0800
Links: << >>  << T >>  << A >>

I ever implemented such divided clock design.
The derived clock (A) took data from high-speed clock domain
at A's falling edge. On the other hand, the high-speed clock put
data to derived clock domain at A's rising edge.
Besides, the area constraint was needed to limit the inter-domain
module. So the routing delay was confined.


"John_H" <johnhandwork@mail.com> :6c803f5f.0310231147.7e129cbe@posting.google.com...
: "Valentin Tihomirov" <valentin@abelectron.com> wrote in message news:<3f97eb7a$1_1@news.estpak.ee>...
: > Divided clock seems synchronous to original clk in terms it is stable on clk
: > edage. On the other hand, synchronous signals should switch simultaneusly
: > while divided signal is calculated on the clk egdage; hence, it switches
: > after Thold and the condition is not met. I understand principles of
: > asynchronous communication. Should I treat divided clock as an asynchronous
: > clock domain? Any references are appretiated.
: 
: Are you referring to a divided clock that you're generating or a
: divided clock from a dedicated FPGA clocking resource?
: 
: If you're generating the clock yourself, I'd suggest generating a
: one-pulse-wide enable signal every n cycles rather than a divide-by-n
: clock and use
: the enable for all the reduced-speed logic that would otherwise use
: the divided clock.  The timing tools should be able to easily apply a
: multi-cycle constraint that you assiciate with the enable signal.  The
: only logic that needs to have short propagation delays is the enable
: signal.


Article: 62380
Subject: Re: OPB write actions
From: "Frank" <someone@work.com>
Date: Tue, 28 Oct 2003 14:22:05 +0100
Links: << >>  << T >>  << A >>
I have good results: it's working when I drop the IPIF address decoding
stuff and do the OPB interface manually. But if anybody knows WHY the IPIF
stuff is not working correctly, let me know...

Frank

"Frank" <someone@work.com> wrote in message
news:3f9e2b15$0$9484$edd6591c@news.versatel.net...
> Sorry for the late response...
>
> "John Williams" <jwilliams@itee.uq.edu.au> wrote in message
> news:bn9j1j$c24$1@bunyip.cc.uq.edu.au...
> > Hi Frank,
> >
> > Frank wrote:
> > > I've succesfully build a microblaze system with external interrupt and
> my
> > > own IP core (using the opb slave template in the EDK). The interrupt
is
> > > connected to a dip-switch. In the ISR I'm writing some data to my own
IP
> > > core (which is an OPB slave). My OPB slave is reading some other
> > > dip-switches and put the result to some LEDs (yes I'm using an
> evaluation
> > > board ;). So far everything is ok. Now comes the problem: the expected
> > > behaviour is dependent of the code in the ISR. If I've the following
> ISR:
> > >
> > > void dip_isr(void)
> > > {
> > >  *(opb_mycore_base) = 0x12345678;
> > >
> > >  // Write the value of j to the LED
> > > // XGpio_DiscreteWrite(&gp_out, 0);
> > >
> > > #ifdef USE_INTC
> > >  XIntc_mAckIntr(XPAR_MY_INTC_BASEADDR, XPAR_SYSTEM_MY_INT_MASK);
> > > #endif
> > > }
> > >
> > > it's not working.
> >
> > Can you define what you mean by "not working"?
>
> Well in my own user IP core, I'm reacting if there is a write access to
the
> base address of my IP core. The reaction is reading some dip switches and
> writing a value to some leds. I can not see this behaviour when it's "not
> working".
>
> >
> > > But if I enable the XGpio write, it is working.
> >
> > And similarly, what do you mean by "working"?
>
> If it's working, the value of the dip switches are shown correctly at the
> leds.
>
> >
> > > And at
> > > last, if I do the XGpio write first and than the write to the OPB
slave
> > > (opb_mycore) it's again not working anymore.
> >
> > > In all three situations, the
> > > code is coming in the ISR (I see that, because there is no output at
the
> > > uart anymore, which is done in the main program).
> >
> > I would hesitate to use that fact as proof that the code is entering the
> > ISR...
>
> I'm 100% sure that it's entering the ISR, because I also tested it with
> toggling leds in the ISR.
>
> >
> > Anyway it almost suggests like you have some issues with the OPB address
> > decoding in your slave.  Either that, or some kind of bus timeout issue
> > maybe.  Have you tried simulating your core?
>
> No, I haven't. At this moment, I don't know how to do that.
>
> >
> > Also, are you using the IPIF example that comes with edk3.2?  Someone
> > here in our lab very recently had problems with that, the IPIF address
> > decoding wasn't doing anything like what he expected.  When he dropped
> > IPIF and did the OPB interface manually, it got a lot better.
>
> Yes, I'm using the IPIF example from the EDK3.2 (I used the
> opb_core_ssp0_v1_00_b). I will try it without the IPIF, but I'm still
> inquisitive about the fact why it isn't working...
>
>
>



Article: 62381
Subject: Re: Picoblaze development tool
From: henk@mediatronix.com (Henk van Kampen)
Date: 28 Oct 2003 06:24:12 -0800
Links: << >>  << T >>  << A >>
> In my source, the "input sX, (sY)" instruction were reported as "?Closing".
> Some labels ahead instructions were reported as "?Phasing", but some were OK. Why?
> Besides, what's the difference between "open file" and "import file"?

pBlazIDE uses a somewhat different syntax than KCPSMBLE. You should
leave out the brackets around the second register. The INPUT opcode is
INP. You can find the opcodes and directives for pBLazIDE on the web
at www.mediatronix.com/pBlazIDE.htm.

?Phasing errors occur because of mismatches of labels between the 1st
and 2nd pass. They can occur when some instructions are accepted by
the 1st pass and not by the 2nd. Probably this is because of the
differences in opcodes as explained.

'open file' reads the file as is. 'import' file is meant to convert
the file while reading, from KCPSMBLE to pBlazeIDE syntax.

Regards,
Henk van Kampen
www.mediatronix.com

Article: 62382
Subject: Re: Trenz-electronics (spartan2 development board) help?
From: Thorsten Trenz <t.trenz@trenz-electronic.de>
Date: Tue, 28 Oct 2003 15:39:15 +0100
Links: << >>  << T >>  << A >>
Loi,

> spartan will then load automatically.  Whenever I start the webpack4.1 impact 
> programmer, I keep getting an error telling me to set the JTAG clock 
> setting.  I've done it, but I can't get the stupid thing to properly 

What is the exact error? Is it about Startup clock? If yes, set the 
startup clock to CCLK, and make a proper mcs file. Then read the manual, 
and set the M0-M2 Jumpers to boot from flash.

If you can't fix this, contact me directly at
t.trent at trenz-electronic dot de

best regards
Thorsten Trenz
http://www.trenz-electronic.de






Article: 62383
Subject: Re: Sort of Running Quartus II on SuSE Linux 8.1
From: Charles Braquet <cbraquet@mppmu.mpg.de>
Date: Tue, 28 Oct 2003 15:55:21 +0100
Links: << >>  << T >>  << A >>
Mike Treseler wrote:

> Quartus II on SuSE Linux 8.1
>
> -- Installs fine.
>
> -- quartus -g  comes up fine.
>
> -- Loads an existing project fine.
>
> -- Recompiles a windows precompiled project fine
>
> -- Can't compile a new project itself.
>    Tries for a while then says
>
>   "Error: Current module quartus_map ended unexpectedly".
>
>
>  -- Mike Treseler
>
Quartus II V3.0 SP2 works on Linux 8.2.
I used to get your error before I installed the SP2 of Quartus
charles B.

-- 
               \\¦// 
               (o o) 
 ----------oOO--(_)--OOo------------------------------------------------

Max Planck Institute for Physics   Charles Braquet
Föhringer Ring 6 Dept.             Elektronik Entwicklung
80805 Münich                       tel. : +49-(0)89-92354-249
http://www.mppmu.mpg.de            fax  : +49-(0)89-3226704
                                   email: charles.braquet@mppmu.mpg.de
                  Oooo.
          .oooO  (   )
 ---------(   )---) /---------------------------------------------------
           \ (   (_/
            \_)


Article: 62384
Subject: Re: Picoblaze development tool
From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com>
Date: Tue, 28 Oct 2003 16:01:00 +0100
Links: << >>  << T >>  << A >>
Henk van Kampen wrote:
> Dear Laurent:
> 
> 
>>Could you explain what we can do with your JTAG option ? Can we do 
>>on-chip PicoBlaze debugging or ROM download ?
> 
> 
> That is the idea. You can generate an SVF file by including in your
> source file:
>        SVF "testjtag.svf"
> 
> It will generate an SVF file based on the specifications in the JTAG
> tab of the settings dialog and your source. Since this is still in its
> infance please let me know is this is useful or what to change/add.
> Since your are an probably an expert on JTAG considering your
> Chamelion product I welcome your advice.
> 

We are interested to do something in this way.
I will ask my Team about the idea to do a OCD (On-Chip Debug) solution 
for the PicoBlaze.

We have a relative good knowledge about JTAG on Arm processor.
For the PicoBlaze, we have to add, in the PicoBlaze, a small register 
bank for On-chip debug solution including breakpoint fsm  and to read 
back the PicoBlaze registry. We have naturally to think about the 
possibility to chain multi-PicoBlaze boundary Scan together

Do you know if Xilinx have a support or source for On-chip debug 
machanism on JTAG ... other way we will do that!

Then, we will use our new very low cost pockeTAG POD based USB to play 
the JTAG TAP to accelerate the job.
And we will give you instructions for upgrade your software with our OCD 
solution, to be able to mark the breakpoint and to execute the on-chip 
debugging step.

Our new POD will be about $89.-, and can run JTAG trace at the same 
speed that Cable IV (for download without verify, we are a better 
datarate on the JTAG !) but it works over USB with the big advantage of 
the power from USB, on MS and Linux. JTAG target can be 1V, 1.2V, 1.8V, 
2.5V and 3.3V with 5V IOs tolerant! It can be a good solution for this 
JOB too. A low cost On-chip debug solution for a free Picoblaze Processor!

> 
>>Actually, we are working on reconfigurable high speed automat machine. 
>>We will try to use picoblaze as base. One automat will have about 10 to 
>>100 picoblaze. The goal is to keep the speed and true multi-processing 
>>achitechture of sequencial function.
> 
> 
> Very interesting. You will, however, need a lot of blockrams. And with
> the JTAG option you can not use two PB's with one blockram. By the
> way, how do you want to let the PB's communicate? One of my own wishes
> for pBlazIDE is to be able to simulate several PB's in cooperation.
> This will need some for of inter I/O port, which needs to be simulated
> and therefore some how specified. I also have used more than 1 PB in a
> design and have them communicate but that was by some form of
> dual-ported RAM. So let me know what your ideas are.

Yes you right, and when I saw the SPARTAN-III architecture, I thinking 
this was not a good idea. The RAM is bigger, but too much regrouped for 
this JOB.

But for the first run we will do the job with 10 Picoblazes.

> 
> Henk van Kampen
> www.mediatronix.com
Before, we have to contact Xilinx if they are interested or if that too 
much for this small PicoBlaze.

Laurent Gauch
www.amontec.com




Article: 62385
Subject: Re: Xilinx JTAG Parallel IV cable and INITIALIZING CHAIN
From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com>
Date: Tue, 28 Oct 2003 16:08:20 +0100
Links: << >>  << T >>  << A >>
Amontec Team, Laurent Gauch wrote:

> Amontec Team, Laurent Gauch wrote:
> 
>> Ronald Chung wrote:
>>
>>> I have spent three-four days on several XPLA3 CPLD boards that I've
>>> designed (same boards) to determine why the JTAG is not working
>>> properly.  I cannot initialize the chain to "read" what devices are on
>>> the boundary scan chain, nor will TDO change states.  I can set
>>> "levels" on TDI, TMS, and TCK using the "Start Debug Chain" portion of
>>> the Xilinx IMPACT software.
>>>
>>> I am using the Parallel IV cable and have read a few places it could
>>> be cable length issues?  Does ANYONE have any type of experience with
>>> this?  I've been wracking my brains out trying to figure out what's
>>> wrong.
>>>
>>> I am using a "home-made" cable because my PCB is used in embedded
>>> application with limited space.
>>>
>>> Even went to a BLANK PCB and stuffed only CPLD, linear regulator, and
>>> caps.
>>>
>>> Any help is MUCH MUCH appreciated...
>>>
>>> Thanks!
>>
>>
>>
>> Try to add an 1K pull-up on TDO and let me know if that's better.
>>
>> Laurent
>> www.amontec.com
>>
> place the pull-up on 5V (if you have a 5V)
> 
> Laurent
> www.amontec.com
> 
OOPS, try to download xpla_programmer.exe from our webpage 
http://www.amontec.com/chameleon_xilinxcableiii.shtml

That's the old programmer provided by Philips for Xilinx.
You will find the schematic of the how to connect the PC parallel port 
to the XPLA JTAG PORT.

PS: Are you sure about the PIN PORT_EN of your XPLA, when your are in 
JTAG mode, these pin must be at '1' logic.

Laurent
www.amontec.com


Article: 62386
Subject: Re: How can I lock design with ISE 5.2?
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Tue, 28 Oct 2003 15:59:10 GMT
Links: << >>  << T >>  << A >>
Look into modular or incremental design.  The bad news is that you will have
to take your design apart in order to comply with the constraints imposed by
these approaches.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"


"wosiqiu" <qiu.xiaoyong@zte.com.cn> wrote in message
news:b053419c.0310280402.4c06fe89@posting.google.com...
> Hi,
>    I am doing a large_scale design with Xilinx Virtex2 and at the end
> of it.
> Now,the modification of the design seems to be painful,for a bit
> modification will take a very long P&R. So I hope that there can be
> some suggestions about how to lock the unchanged portion of the
> design.
> Best rgds.
> Wosiqiu.



Article: 62387
Subject: Re: Sort of Running Quartus II on SuSE Linux 8.1
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 28 Oct 2003 08:39:41 -0800
Links: << >>  << T >>  << A >>
Charles Braquet wrote:

> Quartus II V3.0 SP2 works on Linux 8.2.
> I used to get your error before I installed the SP2 of Quartus
> charles B.

Given your good results, I will attempt to duplicate them
and report back. Vielen Dank.

  -- Mike Treseler


Article: 62388
Subject: Re: What's a good book on FPGA CPU design?
From: do_not_reply_to_this_addr@yahoo.com (Sumit Gupta)
Date: 28 Oct 2003 09:13:26 -0800
Links: << >>  << T >>  << A >>
Pratip Mukherjee <pratipm@hotmail.com> wrote in message news:<Xns9421CF58A715Fpratipmhotmailcom@204.127.199.17>...
> Hi,
> Is there a good book on FPGA CPU design which starts with a simple cpu, 
> like Xilinx PicoBlaze, and takes the user through different aspect of cpu 
> design like instruction set design, pipelining, etc., etc, at the same time 
> keeping the focus on actual implementaion in a FPGA and not on theoritical 
> discussions? Am I asking for too much?
> Thanks.
> 
> Pratip Mukherjee.

You can also check out my site

http://www.c-nit.net/

Sumit

Article: 62389
Subject: Re: Are clock and divided clock synchronous?
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 28 Oct 2003 17:45:27 GMT
Links: << >>  << T >>  << A >>
Bob, thanks for putting the question forward so well.

Xilinx Insiders, if there is input-jitter related DCM output skew in the 1x,
2x, or DIV clocks, I'd like "reassurance" that the new JITTER constraints in
6.1i will adjust for the input-jitter induced timing skew.

If the caution we've been designing against can be a non-issue with a proper
INPUT_JITTER number, I'm a happy guy.  Primarily because of this caution, I
was ecstatic to see these new constraints.  If the caution we've been
designing against is a non-issue because it never was a problem (despite
apparent empirical evidence otherwise) I'm still happy though a little
confused.

I never did find out if the multiple clocks were guaranteed to use the same
delay-line tap for the common edge (versus 180 or 360 degrees out of phase).

"Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message
news:uj7rpvcbiklg4k1eg87sv89mmjkkh49rjb@4ax.com...
> Peter -
>
> I don't want to put words in Ray Andraka's mouth, but I distinctly
> remember him posting about the dangers of using the supposedly
> low-skew outputs from the DLLs of Virtex parts.  As I recall, the
> problem he experienced was that jitter on the clock coming into the
> part resulted in jitter on the DCM output clocks, in a way that didn't
> track from clock to clock.  (Such jitter could be caused by the clock
> generator itself, or by SSO noise from nearby FPGA outputs.) So while
> the spec for output-to-output skew is indeed low, the effects of input
> clock jitter could increase these numbers.  (If this is wrong, Ray,
> please jump in and correct me.)
>
> For that reason, I've always treated transfers between f and Nf
> domains carefully, and I assume that rising-edge-to-rising edge
> transfers won't work reliably in all cases.
>
> So, my questions:
>
> 1) To what extent does jitter on the input clock affect DLL/DCM
> output-to-output skew?
>
> 2) Is there some amount of input clock jitter below which the skew
> published in the data sheets dominates?  For example, for a Virtex II
> part, how much jitter can I tolerate on the DCM clock input before the
> DCM output-to-output phase offset exceeds the +/-140ps number in the
> data sheet?  (The Virtex II data sheet says that the input clock
> period jitter can be as high as +/-1ns; is this just the amount of
> jitter we can tolerate before losing lock, or do I get the +/-140ps
> clock-to-clock output skew with this much jitter?)
>
> Thanks,
> Bob Perlman
> Cambrian Design Works
>
> On Mon, 27 Oct 2003 11:53:55 -0700, Peter Alfke <peter@xilinx.com>
> wrote:
>
> >DLLs ain't misbehavin' !
> >
> >The DLL in Spartan-2 does not have all the functionality of the
> >Virtex-II and Spartan-3 DCMs, but all these circuits, even the DLL,
> >offer extremely low ("zero") skew between their output drivers. So I
> >disagree with Jeff's statement.
> >
> >Peter Alfke, Xilinx Applications
> >=================
> >Jeff Cunningham wrote:
> >>
> >> Peter Alfke wrote:
> >> > If you use the Digital Clock Manager in Virtex-II or Spartan3,  you
have
> >> > four outputs with practically zero skew (<100ps?)between them, and
they
> >> > can be fractions or multiples of the incoming clock. When you
distribute
> >> > these signals on global clocks, there will not be any hold-time
caused
> >> > problems. The skew is definitely less than any clock-to-Q.
> >>
> >> Just to make sure I understand, this is NOT the case with the Spartan-2
> >> DLL is it, i.e. the skew is not so well behaved in the DLL.
> >>
> >> Jeff
>



Article: 62390
Subject: Re: Are clock and divided clock synchronous?
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Tue, 28 Oct 2003 11:25:22 -0800
Links: << >>  << T >>  << A >>
John_H,

A few comments...

Austin

John_H wrote:

> Bob, thanks for putting the question forward so well.
>
> Xilinx Insiders, if there is input-jitter related DCM output skew in the 1x,
> 2x, or DIV clocks, I'd like "reassurance" that the new JITTER constraints in
> 6.1i will adjust for the input-jitter induced timing skew.

Skew is a fixed phase offset, or error, from a nominal value.  Think of it aas
DC.

Jitter is variations around the "significant instant" (ie where a perfect clock
would be).  Think of it as AC.  Don't mix AC and DC.  They don't mix well.  AC
adds RMS or peak to peak root mean square.  DC adds linearly (1+1=2).

6.1i has much better software prediction of both skew and jitter (kept separate)
so that you do not have to make an Excel spreadsheet to keep track of
everything.

>
>
> If the caution we've been designing against can be a non-issue with a proper
> INPUT_JITTER number, I'm a happy guy.  Primarily because of this caution, I
> was ecstatic to see these new constraints.  If the caution we've been
> designing against is a non-issue because it never was a problem (despite
> apparent empirical evidence otherwise) I'm still happy though a little
> confused.

If you can state your confusion to me, I will attempt to clarify (can post, or
send to me directly).

>
>
> I never did find out if the multiple clocks were guaranteed to use the same
> delay-line tap for the common edge (versus 180 or 360 degrees out of phase).

Clocks fromt he same DCM are spec'd to arrive at their destinations when using
the global clock buffers +/- 140 ps (for example) when the destinations are all
on the same H clock tree within a few CLBs or IOBs of one another (ie removing
clock skew on the global).

>
>
> "Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message
> news:uj7rpvcbiklg4k1eg87sv89mmjkkh49rjb@4ax.com...
> > Peter -
> >
> > I don't want to put words in Ray Andraka's mouth, but I distinctly
> > remember him posting about the dangers of using the supposedly
> > low-skew outputs from the DLLs of Virtex parts.  As I recall, the
> > problem he experienced was that jitter on the clock coming into the
> > part resulted in jitter on the DCM output clocks, in a way that didn't
> > track from clock to clock.  (Such jitter could be caused by the clock
> > generator itself, or by SSO noise from nearby FPGA outputs.) So while
> > the spec for output-to-output skew is indeed low, the effects of input
> > clock jitter could increase these numbers.  (If this is wrong, Ray,
> > please jump in and correct me.)
> >
> > For that reason, I've always treated transfers between f and Nf
> > domains carefully, and I assume that rising-edge-to-rising edge
> > transfers won't work reliably in all cases.
> >
> > So, my questions:
> >
> > 1) To what extent does jitter on the input clock affect DLL/DCM
> > output-to-output skew?
> >
> > 2) Is there some amount of input clock jitter below which the skew
> > published in the data sheets dominates?  For example, for a Virtex II
> > part, how much jitter can I tolerate on the DCM clock input before the
> > DCM output-to-output phase offset exceeds the +/-140ps number in the
> > data sheet?  (The Virtex II data sheet says that the input clock
> > period jitter can be as high as +/-1ns; is this just the amount of
> > jitter we can tolerate before losing lock, or do I get the +/-140ps
> > clock-to-clock output skew with this much jitter?)
> >
> > Thanks,
> > Bob Perlman
> > Cambrian Design Works
> >
> > On Mon, 27 Oct 2003 11:53:55 -0700, Peter Alfke <peter@xilinx.com>
> > wrote:
> >
> > >DLLs ain't misbehavin' !
> > >
> > >The DLL in Spartan-2 does not have all the functionality of the
> > >Virtex-II and Spartan-3 DCMs, but all these circuits, even the DLL,
> > >offer extremely low ("zero") skew between their output drivers. So I
> > >disagree with Jeff's statement.
> > >
> > >Peter Alfke, Xilinx Applications
> > >=================
> > >Jeff Cunningham wrote:
> > >>
> > >> Peter Alfke wrote:
> > >> > If you use the Digital Clock Manager in Virtex-II or Spartan3,  you
> have
> > >> > four outputs with practically zero skew (<100ps?)between them, and
> they
> > >> > can be fractions or multiples of the incoming clock. When you
> distribute
> > >> > these signals on global clocks, there will not be any hold-time
> caused
> > >> > problems. The skew is definitely less than any clock-to-Q.
> > >>
> > >> Just to make sure I understand, this is NOT the case with the Spartan-2
> > >> DLL is it, i.e. the skew is not so well behaved in the DLL.
> > >>
> > >> Jeff
> >


Article: 62391
Subject: Re: Sort of Running Quartus II on SuSE Linux 8.1-- sp2=fix!
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 28 Oct 2003 11:34:49 -0800
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> Charles Braquet wrote:
> 
>> Quartus II V3.0 SP2 works on Linux 8.2.
>> I used to get your error before I installed the SP2 of Quartus
>> charles B.
> 
> 
> Given your good results, I will attempt to duplicate them
> and report back. Vielen Dank.

Quartus II V3.0 SP2 is running full compilations here on SuSE Linux 8.1.
quartus_map error is gone.

Thanks Charles and someguy@Altera.

I may surplus my win2k box :)

  -- Mike Treseler


Article: 62392
Subject: Re: Searching for 802.11a/g implementations
From: dbeberman@earthlink.net (David)
Date: 28 Oct 2003 11:54:16 -0800
Links: << >>  << T >>  << A >>
Thanks for the response, Robert.  I hadn't found what I was looking
for with a google search, but will take a look at ittiam.

In answer to another response, what I'm looking for is the DSP
baseband processing part of the 802.11 phy.  The RF frontend and the
ADC/DAC are not my main focus right now. Not looking at the MAC
either.
Thanks

"Robert Sefton" <rsefton@abc.net> wrote in message news:<%xfnb.71886$th6.68580@twister.socal.rr.com>...
> I googled on "802.11" phy core and got several hits. Here's one that has
> been targeted to an FPGA.
> 
> http://www.ittiam.com/pages/products/wlan-aphy.htm
> 
> Robert
> 
> "David" <dbeberman@earthlink.net> wrote in message
> news:366a0905.0310250649.7e4883f@posting.google.com...
> > Hi,
> >
> > I've been reading the archives of this list, and the FAQ.  I haven't
> > seen much about 802.11a and g phy implementations.  Does anybody know
> > where I might find 802.11a/g VHDL, Verilog or other implementations.
> > This does not need to be open source, however, I am looking for
> > something that I will be able to add my own modifications to.
> >
> > Thanks,
> >
> > David

Article: 62393
Subject: Re: Electronic Dice VHDL Program
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 29 Oct 2003 09:34:02 +1300
Links: << >>  << T >>  << A >>
Amstel wrote:
> 
> Somehow , I'm required to write this electronic dice game program
> using the
> function " Random Number Generator ".

 What is this function, and how is it called ( params in /out) ?

 In terms of applying RNG to your code, you could use 
a script to generate 'next state' in a (semi) random basis
( it does need to be a monotonic thread )

 You could also additionally 'randomize' the LED Table lookups 
you have, but will again need to ensure a smoothed average 
( all numbers 1-6 need to have equal ROM frequency )

 Q: Will the resulting code create a 'better dice' ?

 It would be more useable at lower clock frequencies.

-jg

Article: 62394
Subject: Re: Are clock and divided clock synchronous?
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 28 Oct 2003 13:29:32 -0800
Links: << >>  << T >>  << A >>
Here is something from the other stereo channel (Austin and I often
complement each other):

Each DLL or DCM takes the rising input edge and feeds it into a very
long chain of cascaded buffers. In the background, we have a complex
calculating engine that figures out which tap should feed which output,
and it gracefully adjusts the tap setting when temperature or voltage
change. (One tap is about 50 picoseconds or less).
That's the basic mechanism, quite simple, although the implementation
takes tens of thousands of transistors.

Obviously, incoming jitter is passed through to the outputs ( delayed by
more than one period), but exactly equally to all outputs. So, there is
no added skew caused by the input jitter. If you trust the global clock
lines to distribute a clock with simultaneous arrival times at all
flip-flops, you should also trust two global lines to distribute two
different (e.g. 2:1) clocks in a similar way. No race condition...

This describes the physical action. What the timing analyzer does, and
why it does it, is not my area of expertise.

Peter Alfke
==========================
Austin Lesea wrote:
> 
> John_H,
> 
> A few comments...
> 
> Austin
> 
> John_H wrote:
> 
> > Bob, thanks for putting the question forward so well.
> >
> > Xilinx Insiders, if there is input-jitter related DCM output skew in the 1x,
> > 2x, or DIV clocks, I'd like "reassurance" that the new JITTER constraints in
> > 6.1i will adjust for the input-jitter induced timing skew.
> 
> Skew is a fixed phase offset, or error, from a nominal value.  Think of it aas
> DC.
> 
> Jitter is variations around the "significant instant" (ie where a perfect clock
> would be).  Think of it as AC.  Don't mix AC and DC.  They don't mix well.  AC
> adds RMS or peak to peak root mean square.  DC adds linearly (1+1=2).
> 
> 6.1i has much better software prediction of both skew and jitter (kept separate)
> so that you do not have to make an Excel spreadsheet to keep track of
> everything.
> 
> >
> >
> > If the caution we've been designing against can be a non-issue with a proper
> > INPUT_JITTER number, I'm a happy guy.  Primarily because of this caution, I
> > was ecstatic to see these new constraints.  If the caution we've been
> > designing against is a non-issue because it never was a problem (despite
> > apparent empirical evidence otherwise) I'm still happy though a little
> > confused.
> 
> If you can state your confusion to me, I will attempt to clarify (can post, or
> send to me directly).
> 
> >
> >
> > I never did find out if the multiple clocks were guaranteed to use the same
> > delay-line tap for the common edge (versus 180 or 360 degrees out of phase).
> 
> Clocks fromt he same DCM are spec'd to arrive at their destinations when using
> the global clock buffers +/- 140 ps (for example) when the destinations are all
> on the same H clock tree within a few CLBs or IOBs of one another (ie removing
> clock skew on the global).
> 
> >
> >
> > "Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message
> > news:uj7rpvcbiklg4k1eg87sv89mmjkkh49rjb@4ax.com...
> > > Peter -
> > >
> > > I don't want to put words in Ray Andraka's mouth, but I distinctly
> > > remember him posting about the dangers of using the supposedly
> > > low-skew outputs from the DLLs of Virtex parts.  As I recall, the
> > > problem he experienced was that jitter on the clock coming into the
> > > part resulted in jitter on the DCM output clocks, in a way that didn't
> > > track from clock to clock.  (Such jitter could be caused by the clock
> > > generator itself, or by SSO noise from nearby FPGA outputs.) So while
> > > the spec for output-to-output skew is indeed low, the effects of input
> > > clock jitter could increase these numbers.  (If this is wrong, Ray,
> > > please jump in and correct me.)
> > >
> > > For that reason, I've always treated transfers between f and Nf
> > > domains carefully, and I assume that rising-edge-to-rising edge
> > > transfers won't work reliably in all cases.
> > >
> > > So, my questions:
> > >
> > > 1) To what extent does jitter on the input clock affect DLL/DCM
> > > output-to-output skew?
> > >
> > > 2) Is there some amount of input clock jitter below which the skew
> > > published in the data sheets dominates?  For example, for a Virtex II
> > > part, how much jitter can I tolerate on the DCM clock input before the
> > > DCM output-to-output phase offset exceeds the +/-140ps number in the
> > > data sheet?  (The Virtex II data sheet says that the input clock
> > > period jitter can be as high as +/-1ns; is this just the amount of
> > > jitter we can tolerate before losing lock, or do I get the +/-140ps
> > > clock-to-clock output skew with this much jitter?)
> > >
> > > Thanks,
> > > Bob Perlman
> > > Cambrian Design Works
> > >
> > > On Mon, 27 Oct 2003 11:53:55 -0700, Peter Alfke <peter@xilinx.com>
> > > wrote:
> > >
> > > >DLLs ain't misbehavin' !
> > > >
> > > >The DLL in Spartan-2 does not have all the functionality of the
> > > >Virtex-II and Spartan-3 DCMs, but all these circuits, even the DLL,
> > > >offer extremely low ("zero") skew between their output drivers. So I
> > > >disagree with Jeff's statement.
> > > >
> > > >Peter Alfke, Xilinx Applications
> > > >=================
> > > >Jeff Cunningham wrote:
> > > >>
> > > >> Peter Alfke wrote:
> > > >> > If you use the Digital Clock Manager in Virtex-II or Spartan3,  you
> > have
> > > >> > four outputs with practically zero skew (<100ps?)between them, and
> > they
> > > >> > can be fractions or multiples of the incoming clock. When you
> > distribute
> > > >> > these signals on global clocks, there will not be any hold-time
> > caused
> > > >> > problems. The skew is definitely less than any clock-to-Q.
> > > >>
> > > >> Just to make sure I understand, this is NOT the case with the Spartan-2
> > > >> DLL is it, i.e. the skew is not so well behaved in the DLL.
> > > >>
> > > >> Jeff
> > >

Article: 62395
Subject: Re: Xilinx JTAG Parallel IV cable and INITIALIZING CHAIN
From: ronchung@massie-labs.com (Ronald Chung)
Date: 28 Oct 2003 14:37:18 -0800
Links: << >>  << T >>  << A >>
Thanks for the help...

I finally figured out there was a pin-mis-wire on my schematics...
hidden in all the hierarchy.  Thought I had checked the wiring, but
must have missed it...

Things are configuring now.

Just a note for those out there.... if you get erratic behaviour
because the JTAG sometimes will and/or will not initialize the chain,
it could be due to swapping TDI and TCK.

RC

Article: 62396
Subject: Virtex-II DCM frequency synthesizer
From: evgenist@yahoo.com (Evgeni)
Date: 28 Oct 2003 18:48:46 -0800
Links: << >>  << T >>  << A >>
I'm using Virtex-II DCM frequency synthesizer to get 52MHz clock from
16MHz. Two questions:
 1) Since my input frequency is outside the minimum operating range in
the low frequency mode(24MHz), I cannot use CLKFB feedback. Is there
any easy way to override this restriction.
 2) I tried doing this freq. conversion without CLKFB using
CLKFX_DIVIDE = 4, CLKFX_MULTIPLY=13 parameters. Output is connected to
CLKFX. Input is connected directly from external source. I'm measuring
64MHz on that output instead of 52MHz. Is there anything wrong with
those particular parameters?

Thanks,
Eugene.

Article: 62397
Subject: Re: BoardScope
From: "Jay" <yuhaiwen@hotmail.com>
Date: Wed, 29 Oct 2003 10:50:27 +0800
Links: << >>  << T >>  << A >>

"Steve Casselman" <sc_nospam@vcc.com> дÈëÏûÏ¢ÐÂÎÅ
:sSbnb.1371$Rh7.1311@newssvr14.news.prodigy.com...
> In the distribution I have it is at - Jbits/con/xilinx/Boardscope..
>
> Steve
> PS there are a lot of great engineers who speak German, French, Spanish,
> Japanese, Chinese, Korean, Polish and many other languages. If you are
> unsure of your English try posting in both English and your native
language.

good idea. but I'm not sure whether the newsgroup can display other
languages' characters.
just try:
´ó¼ÒºÃ!
:)




Article: 62398
Subject: Re: Are clock and divided clock synchronous?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 29 Oct 2003 16:25:33 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Here is something from the other stereo channel (Austin and I often
> complement each other):
> 
> Each DLL or DCM takes the rising input edge and feeds it into a very
> long chain of cascaded buffers. In the background, we have a complex
> calculating engine that figures out which tap should feed which output,
> and it gracefully adjusts the tap setting when temperature or voltage
> change. (One tap is about 50 picoseconds or less).
> That's the basic mechanism, quite simple, although the implementation
> takes tens of thousands of transistors.
<snip>

 So when this 'smart tracking' has to adjust a delay step
( due to Temp, or Vcc changes ) you will get a quantized jump
in the delay ?  (50ps)
 Some may call that jitter, and it depends on the HW design
how often it occurs.
 With Hyst in the decision, the spectrum of the jitter can
be reduced, but note that poor Vcc behaviour can cancell the
Hyst.
 It does not sound like the adjust steps are an issue from
Tsu/Th viewpoint, but they _may_ affect a system with a critical
jitter budget - such as those where jitter == signal to noise 
floor.

-jg

Article: 62399
Subject: Re: Are clock and divided clock synchronous?
From: Jeff Cunningham <jcc@sover.net>
Date: Wed, 29 Oct 2003 03:47:55 GMT
Links: << >>  << T >>  << A >>
Google dug up the following quote from Ray back on 2003-04-21.

/quote

I got nailed on an early Virtex design where the 1x and 2x clocks were 
sourced by the same DLL.  Several factors contributed:
-  the 1x clock was very lightly loaded while the 2x clock was heavily 
loaded,
- There was fair amount of jitter on the clock input (>300ps IIRC),
- There was heavy output switching on pins adjacent to the clock input 
pin (adds
to jitter at DLL clock input)
- the failing nets were on direct flip-flop to flip-flop connections (no 
LUT) on
FF's that were floorplanned to be adjacent.
- static timing indicated no setup or hold violations.

The combination of the jitter (which with input jitter barely in spec 
plus jitter introduced by output current modulation of input thresholds 
was likely out of spec), highly skewed loading (not convinced this is a 
real factor), and the absolute minimum flip-flop to flip-flop delay 
conspired to bite us where it counted.  Since then, we have as a policy 
treated the 1x and 2x clock domains with utmost care to make sure the 
receiver is not sensitive around the transmitter's active edge.  I 
suspect that if you have no direct connects between adjacent slices at 
the clock domain boundary, you won't have a problem.

/unquote

Peter & Austin, I really want to believe you. Do you think Ray's being 
overly careful? Could it be a problem in the "extreme" topology Ray 
describes?

Jeff




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