Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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.comArticle: 62376
"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
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
> 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.comArticle: 62379
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
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> 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.comArticle: 62382
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.deArticle: 62383
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: 62384Henk 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.comArticle: 62385
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.comArticle: 62386
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
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 TreselerArticle: 62388
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/ SumitArticle: 62389
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
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: 62391Mike 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 TreselerArticle: 62392
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, > > > > DavidArticle: 62393
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. -jgArticle: 62394
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: 62395Thanks 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. RCArticle: 62396
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
"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
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. -jgArticle: 62399
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:
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