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
fpgavhdl@gmail.com wrote: > Thanx Again > > The black burst generator is both NTSC and PAL compliant... > > I am locking the Hsync using a PLL (external to the fpga) using a 1715 > x fh = twice 858 x fh ...which u were talking abt.. > > I cant get the Hsnyn without jitter. <snip> All PLLs will have some jitter - do you have some numbers on how much jitter you are seeing ? If this is an external Analog PLL, it probably has a loop filter, so you can scope that to check it is actually in stable lock. PLLs like this are also a trade off of lock-range vs stability. eg Colour burst PLLs use XTALS, very high stability, but quite narrow lock ranges. Horiz PLLs can use RC or LC circuits, RC are cheaper, but have higher jitter values. -jgArticle: 80401
Duane Clark wrote: > junkmail@fastertechnology.com wrote: > > > > We have not measured the speed of the 10/100 EMAC. There are a number > > of reasons to support the slower speeds that Duane Clark mentioned: > > > > The EMAC core is on the OPB bus, and does not use the DMA engine in the > > IPIF. The processor has to copy the data between the core and memory. > > As the reference design is supplied, the PPC is only configured to run > > at 66MHz. > > The memory used in the reference design is on the OPB bus. > > The OPB bus has burst mode turned off. (At first glance, it does not > > look like the OPB memory interface works with burst mode turned on). > > So you chose anonymity, I can only guess that you have some relation to ^^^^^^^??????? The email I post with is real, it just gets more heavily filtered. > the Avnet board/project from your comments. In any case, I will add a > comment that the board and project as provided by Avnet are quite > impressive in my opinion. And at the price, they simply cannot be beat. > I agree, that is why we use them. My list above is just a list of what to upgrade if one wants to speed up the design. > > > > My guess is that the OPB EMAC was used because a real version of the > > core is supplied with the EDK. All of the PLB EMAC cores are evaluation > > versions. You can use them in a design, but they turn themselves off > > after about 12 hours. > > > > Actually, the OPB_EMAC core supplied with EDK is also an evaluation > version, with the same timeout limitation. > > -- > My real email is akamail.com@dclark (or something like that). John McCaskill (Really)Article: 80402
<fpgavhdl@gmail.com> wrote in message news:1109966827.887251.96500@g14g2000cwa.googlegroups.com... > Thanx Again > > The black burst generator is both NTSC and PAL compliant... > > I am locking the Hsync using a PLL (external to the fpga) using a 1715 > x fh = twice 858 x fh ...which u were talking abt.. > > I cant get the Hsnyn without jitter. So we have a problem right from the start. I didn't know if your jitter was in h or in sc. > What do u mean by source? Is it a test generator, a DVD player etc. If it's a non-tbc'd vtr that can cause interesting problems. > > The output from the PLL (which is clock of frequency 1715 x fh = 27 > MHz) is then given to the FPGA. The FPGA does the Black burst > generation...also does the subcarrier locking..where it has two modes > of operation. One when the extrenal is given...where the Black burst > generated locks to the external reference and the second when no > external is given...in this case....it acts as a free running black > burst generator. The PDF document looks really good and will be of > great help. > > Let me know if u need any more details... > How much is the jitter? Presumably you have video coming into an LM1881 or such like. The output of your sync stripper will go to one input of the phase comp, and the divided VCO (from the FPGA) will go to the other. Stick a scope on these and measure the jitter. What PLL chip are you using, or did you make it yourself? The PLL should have a memory style phicomp; not xor. How well filtered is the VCO supply? How clean is the loop filter ground (FPGA noise)? Is the VCO LC, XTAL or relaxation (bad)? What is the resonant frequency and damping factor of the loop? Are you getting pure H out of your sync stripper (i.e., check that there is no weird stuff going on in vertical)?Article: 80403
"Falk Brunner" <Falk.Brunner@gmx.de> writes: > Yeah, but what about tolerances? The 1,25V reference of the good ole LM317 > ist exactly 1,25V. Are the tolerances within the +/-5 % of the 1,2V for the > core? No. The reference voltage specification for the LM317 is min 1.20V, max 1.30V (page 5 of data sheet from National, dated July 2004). So for any given LM317, you *might* be able to adjust to within the rating of an XC3S (1.14V to 1.26V), or you might not. The LM317A has a tighter range, 1.225V to 1.270V, which is still potentially out of spec. The only linear regulators I've found that meet the spec are either 1.2V fixed LDO, or special low voltage LDO.Article: 80404
junkmail@fastertechnology.com wrote: > Duane Clark wrote: > >> So you chose anonymity, I can only guess that you have some >> relation > > to ^^^^^^^??????? The email I post with is real, it just gets more > heavily filtered. My apologies. Rereading things, I see I just didn't read carefully. -- My real email is akamail.com@dclark (or something like that).Article: 80405
Hi,
Is there any specific reason that u want to read back.....U told
that u have a design that writes to BRAM's..does it write data or logic
to BRAM's or else does it write the bit file into the BRAM's...If you
can elaborate ..probably I can help you ..
--
Parag Beeraka
Article: 80406
Hi Everyone,
I wanted to load linux (Montavista ) on a partition in the
Compact Flash ..and wanted to run my program after linux gets
loaded..When I see the Xilinx Linux tutorial for the ML 310..I came to
know that the two important things are -- ml310_base_bootloop.bit
(which has a bootloop in it )and the zImage.initrd.elf (the Linux
kernel as a power pc executable)...So I downloaded the bit file using
iMPACT and then started of XMD and on the command line, then I said
..dow zImage.initrd.elf... After the on the xmd command line I said
run..But nothing changes on the minicom(terminal..because I am running
Linux).....
Has anyone tried this sort of a thing ...If so please help
me out..
Thanks in advance
--
Parag Beeraka
Article: 80407Thanks for the replies. What I meant is the SRAM on the XS40 board, so the vga generator example for XS40 works the same way as the one for XSA board? The img2xes utility works for XS40 too? What if I actually have a bunch of data (put them all together would make an image I suppose), how should I store the data to the SRAM? I would also have to modify the vga generator example since it always sets web = '1'?Article: 80408
My design is microprocessor based, on which 8-bit binary values representing a picture are written to some region in my block rams. I would like to know if it is possible to extract those value by using a program, similar to data2bram, through JTAG out from the FPGA JacquesArticle: 80409
I am designing a DDR controller which runs at 133 MHz. I am trying to synthesize this on Spartan 3. I am using FDDR IO and OBUFT for generation of IO signals. Everything works fine till FFDR block. It gives proper double data rate output. But when this goes to OBUFT, output of OBUFT is distorted. I miss the first hald of data completely and second half is also not stable enough. Can anybody help me on this. How can I make this tristate buuffers work.Article: 80410
why not? infact, no matter wht the cost is, once technology is mass produced, it tends to bring down the cost. qualcomm is thinking of doing the same in india. but before tht they need to build a team. lets hope we get a crack team to handle this. moreover, its not tht we are lookng for indians only. anybody may apply for this. cheers Ranbir big_in_russia@yahoo.com wrote: > Hi Ranbir! > > So, are you looking for Americans to move to India? It's so great that > India is finally going to take care of all the engineers here who lost > their jobs due to outsourcing. > > Will I be able to afford a Qualcomm-chipset based phone with the pay I > get? > > Thanks in advance! > > reachranbir@gmail.com wrote in message news:<1109664726.181045.112170@z14g2000cwz.googlegroups.com>... > > Hi, > > I am Ranbir from eQURA Consulting. > > Guys, my client, which is a San Diego based wireless telecom giant. > > They were the original inventors of CDMA technology. > > > > They have recently set up a next gen design centre here in Bangalore, > > India. > > We are looking at various profiles, starting from frontend, backend to > > verification managers. > > > > If interested do contact me on +91 09845365740 > > ranbir@equra.comArticle: 80411
Hi, this is ranbir here. my client is plannin to build complex SoC for their CDMA based mobile handsets. their design centre will be based in Bangalore, India. they are looking for an entire team for that purpose. we want frontend design engineer, backend, physical design, verification, memory design, rtl architects and everyting else. anybody from any nationlity are welcome to apply. Anybody interested??Article: 80412
its a strange coincidence. belive me in India also we are thikning its not fare to do this outsouring stuff. but wht to do?? business dynamics makes u do strange actions regs, RanbirArticle: 80413
Hi, I'm discovering the wonderful world of FPGA, so please excuse the probably stupid question and use of improper terminology. It seems to be a trivial case of the difficult "state assignment problem" but i must admit i'm to lazy to read the 199 pages of http://alexandria.tue.nl/extra2/200413270.pdf now :-/) There are 2 very simple situations in FSM 1. n-step cycle S1 -> S2 -> Sn -> S1 -> S2 -> .... 2. n-step, last is a sink : S1 -> S2 -> Sn -> Sn -> Sn -> Sn ... that can be easily implemented with counters, binary, gray code, whatever. The question is: what's your favorite representation when you have strong restrictions on the number of gates/FF ? I guess everybody uses a standard binary counter for large values, say N>1000) with initial state = 0 and last = N-1, or the other way, but are there "good practices" for small ones ? Michel Billaud -- Michel BILLAUD billaud@labri.fr LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)Article: 80414
skherich wrote: > I am using v2pro 100 device with core clk speed of 200 mhz and am > running rocket io, aurora and supporting logic at 156.25Mhz. > I am noticing unusually high skews on these clocks. here is an excerpt > from par report. ... > Although this skew might be for two flops which are at farthest in the > chip and probably not in the path it still does seem mighty large. Is > there anything we can do to reduce this skew. We are using DCM and > these clock as well. > > samir Proper way to address these type of issues would be to partition your design by clocks (as much as possible) and constrain each block to a dedicated area with a floor planner. Best Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and SynthesisArticle: 80415
i want to program atf750 from a .tt2 file (generated from another vendor software). I'm trying fitters, i download fit5.0.zip and the fitters for 1500, 1502, 1508... works well, but fit2500 which i must use for atf750 says "NTTAPKP.DLL not found" and fails. I,ve tried to download and use fit2500.zip but when i do fit2500 -i myfile.tt2 -dev p750 it says "error cannot open .dev file p750.dev" i,ve tried also with ablfit2500.zip but when i install it and try to use says "i cant connect to the key". i've also tried to use the p750.dev file from ablfit2500.zip with the fit2500.exe froom fit2500.zip but it says it is a wrong file. ¿is there any way of using the fitter from command line or similar? thanksArticle: 80416
Gabor wrote: > Fernando Peral wrote: > >>I want to use ATMEL ATF750 with ABEL, but i cant find a tool. >>¿is there any way? >> >>thanks > > > If it HAS to be Abel, your only choice is Synario. See: > > http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2755 > > but that is not synario is just a synario update ¿no? i can't find atmel synario anywhere.Article: 80417
Hallo, I have tried to export an edk project to ise, but before exporting, edk make synthesis with xst. Into the project option I have chosen Synthesis tool: none. Why edk make synthesis in any case? I would make synthesis of the edk project with synplify. MarcoArticle: 80418
"Rudolf Usselmann" <russelmann@hotmail.com> schrieb im Newsbeitrag news:d0c1ms$as$1@nobel.pacific.net.sg... > > there anything we can do to reduce this skew. We are using DCM and > > these clock as well. Hmm, are these global clock nets? > Proper way to address these type of issues would be to partition > your design by clocks (as much as possible) and constrain each > block to a dedicated area with a floor planner. Why? Arnt the global clock nets supposed to drive the WHOLE chip with low skew (full buffered etc.) ?? Regards FalkArticle: 80419
"Michel Billaud" <billaud@labri.u-bordeaux.fr> schrieb im Newsbeitrag news:7zekeupgbe.fsf@serveur5.labri.fr... > There are 2 very simple situations in FSM > 1. n-step cycle S1 -> S2 -> Sn -> S1 -> S2 -> .... > 2. n-step, last is a sink : S1 -> S2 -> Sn -> Sn -> Sn -> Sn ... > that can be easily implemented with counters, binary, gray code, > whatever. > > The question is: what's your favorite representation when you > have strong restrictions on the number of gates/FF ? Binary or Gray offer the highest density when it comes to FF count. Using Toggle-FFs instead of "ordinary" D-FFs can sometimes simplify the next state encoding logic. Regards FalkArticle: 80420
"greenplanet" <greenplanet@hotmail.com> wrote in news:1109997031.596085.165410@f14g2000cwb.googlegroups.com: > Thanks for the replies. > > What I meant is the SRAM on the XS40 board, so the vga generator > example for XS40 works the same way as the one for XSA board? No, the XSA VGA generator fetches image data from 16-bit SDRAM so it has to account for the variable arrival time of the data with a FIFO. The XS40 has a static 8-bit RAM with a fixed access time so the FIFO isn't needed and the image path is narrower. The > img2xes utility works for XS40 too? img2xes just translates the format of common image files into the simple XES format. The XES file can be downloaded into the XS40 SRAM using the GXSLOAD utility. You should be able to use the img2xes options to format the image data for the byte-wide SRAM on the XS40. > What if I actually have a bunch of data (put them all together would > make an image I suppose), how should I store the data to the SRAM? I > would also have to modify the vga generator example since it always > sets web = '1'? For writing to the SRAM: 1) Lower the RAM chip-enable and raise the output-enable. 2) Output the address and data. 3) Pulse the write-enable low and then high. You will have to modify the VGA generator to make it release the RAM address, data and control pins while you do the write operations. -- ---------------------------------------------------------------- Dave Van den Bout XESS Corp. PO Box 33091 Raleigh NC 27636 Phn: (919) 363-4695 Fax: (801) 749-6501 devb@xess.com http://www.xess.comArticle: 80421
Austin, > >> Looking at the output waveforms shown in figure 20, my first >> reaction was that it clearly showed that Xilinx hasn't done >> much to improve their I/O cell capacitance [1] since V2. > >Why should we do that? > Because 10 pF and 1 Gbps are a poor match. > >What is it about the Cout that is such a big deal? > Note that I used "I/O cell capacitance" in my post as I attempted to point out the impact on both inputs and outputs. However, as the only parameter given in the V4 datasheets is called Cin, I wasn't consistent in that name usage. Hereafter I shall attempt to use C to refer to the I/O structure capacitance, as applies to both inputs & outputs. > >Driving the pcb trace, and the load at the other end swamps >the intrinsic C of the pin in almost all cases. > Not in my experience, particularly when dealing with connections from 'real' 1 Gbps logic <-> FPGA > >To do what we do (which is more than the competitor), we >need the silicon area. Silicon area = C. > My heretical $0.02: DCI = not worth the penalty of excess C So ditch DCI, keep the DT terminators, and invent a controlled slew driver with low C for the LVCMOS-ish standards. > >> >> Meanwhile, the marketeering data rate has gone from >> "840 Mbps" for V2 to "1 Gbps" for V4. > >Sure has. Works great. Eye diagrams look fantastic (on a real board). > Where in Xilinx's V4 documentation might one find these pictures and eye diagrams, including real world vs. simulated waveforms at the driver, receiver, and points in between ? > >> Perhaps Dr. Johnson could proffer his honest opinion of >> a "1 Gbps" LVDS receiver with a Cin of 10 pF [2]. > >I am sure he wioll answer that if asked in a fair and impartial way. > Those 1 Gbps and 10 pF numbers are straight from Xilinx's own V4 datasheet- I don't see how you can claim any partiality on my part for merely pointing out your own numbers. > >Perhaps he will also point out that there is a lot more to the >IO performance than just C? > When have I ever claimed that it is the only factor? Particularly in a post where my lead-in paragraph ended with the phrase "... which is not the whole story for high speed I/O." > >> While the reduced output slew rate due to capacitive loading >> may be of marginal "benefit" for low speed I/O standards, > >Ho ho ho. That is funny. Take the problem of slew rate out of control, >and try to case our C as BAD because it slows us down SO WE WORK? Ha ha >ha. I am rolling on the floor. Be serious. The C is what it is. It >does not limit performance in any way. > ROTFL right back at ya > >If all the power is in the pin C, perhaps you will see a 30% >improvement. Again, we may be talking less than 6 milliwatts per pin. >Big advantage when the S2 won't work in a system. > >Oh my, my 72 pin bus switching at 200 MHz with 2.5V has ~430 mW more >power than an S2......but it WORKS! > I suggested this test as a quick way of verifying Altera's claims of improved C - given 500 switching outputs, a few points along the power vs switching rate curve should give us something to ponder. I never said anything about what percentage of device power this would represent. BTW, how many of those 500 outputs connect to PCB traces, how many only to a BGA solder pad? > >Excuse me, the waveforms look fine. Excessive rise and fall >times don't buy you anything but misery. HJ just proved that. > Dr. J demonstrated that Xilinx's package is better. He did not address the issue of whether the I/O capacitance of the V4 was amenable to 1 Gbps operation. "Too Fast For the Package" is bad. "Just Fast Enough" is great. "Can't get out of my own way due to high C" is also bad. As these are general purpose I/O, the case of multidrop as well as point-point needs to be considered, along with non-FPGA 1 Gbps drivers. > >> C) Differential output switching would mitigate the SSO package >> effects somewhat as compared to single ended switching at >> the same rate > >Yes, the C is half differentially. > There's more to this one than just output C ( balanced driver ICCO; some degree of agressor cancellation ). If you can repeat Figure 19 with 250 LVDS/LDT type pairs ( or as many as you can fit into both devices ), that would be an interesting comparison. > >> >> D) input reflections would be worse for the Xilinx part >> >Yes. But, since our termination is internal, and the driver is >terminated, it doesn't matter. > >Do the simulation, the eye the receiver sees is just fine. >Reflected signal (small) is absorbed by the transmitter, and >does not cause distortion in the receiver. > ROTFL yet again I'll note here that, unlike the current V2/V4 material, the old Virtex-E LVDS application notes actually addressed the issues of C, reflections, and multidrop configurations, with waveforms plotted at points other than only the receiver of a point-point connection. > >You are not correct in assuming bad SI always results from pin C. > When, and where, have I EVER said that pin C is the ONLY source of SI problems? > > If you terminate externally, I would agree with you. > BTW, thanks to Xilinx for putting those DT terminators back into the S3E parts. > >We'll keep that in mind if we ever get to where we have to do >this to meet all specs and standards. SO far, we do > Long ago and far away, when discussing this for V2, I wrote: Although the original LVDS specification did not directly specify a max Cin value, newer specifications such as HyperTransport do; for example, HyperTransport requires a maximum 2pf (single-ended) Cin for receivers rated > 800 Mbps. and also: See for instance Table 13, footnote 1 of XAPP622, which clearly states that, although tested interoperable, the V2 devices do not meet the rise/fall requirements of the SFI-4 specification > >> [2] I'd be happy to quote a Cdiff instead, if someone could tell >> me where it is documented. >> >> Ideally, the differential input model would include both >> the single ended shunt Cin values as well as a differential >> across-the-pair Cdiff, so I could model both the differential >> and common mode reflections. >> >> If Cdiff is negligible, and the input waveform is purely >> differential, then Cdiff = 1/2 Cin, as Austin has argued before. > >Uh, last I looked at circuit theory, it is still C/2 for the diff pair. > It also agrees with simulations (if you instantiate the V4 receiver, >and compare it to a circuit model of the same thing). > I'm not sure exactly what you're disagreeing with here. I was attempting to point out that real differential input buffers have a mix of both "shunt to plane" and "shunt across the pair" C, the values of each I'd like to see documented separately for modeling purposes. Perhaps I should have said "effective Cdiff = 1/2 Cin" in my last sentence about the special case? BrianArticle: 80422
Hi all, I have write some codes about magnetic card reader and simulation result is good so code is done. But I can't run program on the board well. You think what kind of difference are there between simulation and real world (board)? I use Modelsim and 95XL CPLD. What do you recommended? ThanksArticle: 80423
Also what do you recommend for debugging?Article: 80424
<usrdr@yahoo.co.uk> schrieb im Newsbeitrag news:1110030980.829013.17840@f14g2000cwb.googlegroups.com... > Hi all, > I have write some codes about magnetic card reader and simulation > result is good so code is done. But I can't run program on the board > well. You think what kind of difference are there between simulation > and real world (board)? I use Modelsim and 95XL CPLD. What do you > recommended? Debugging?? Have a look at the IO signals form the 95 XL using a scope. Are the signals as expected? Have a look to internal registers, route them to unused pins (testpins) Regards Falk
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