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
On Sep 6, 2:11 pm, "MM" <mb...@yahoo.com> wrote: > "John McCaskill" <jhmccask...@gmail.com> wrote in message > > news:1189105528.073561.184050@d55g2000hsg.googlegroups.com... > > > > > The FX output jitter spec of the DCMs does not meet the input jitter > > requirements of the DCMs. What you are trying to do will not work > > reliably. > > Yes, I remember reading it... So, no hope here? Anyone from Xilinx? I don't > care much about the output jitter on the two DCMs, I just need them to > produce the clocks at right frequencies.... If I can't do it, I am in real > trouble... > > Thanks, > /Mikhail Skip the first DCM, and use the other two in FX mode. If they do not lock in the phase relationship that you need, reset one of them. Regards, John McCaskill www.fastertechnology.comArticle: 123901
> > How is it not working? Not compiling, or not getting the data you > expect? What are you compiling with, and do you have the MMU of the > PowerPC turned on? > > Regards, > > John McCaskillwww.fastertechnology.com No this is the only code i am using to initialize the Brams and following to make the project active. I dont have MMU IP. It is crucial to have mmu? no i do not have the expected data, when i am simulationing it, it is uses more GPR than the ones mentioned above. Actually i am using the iocm controller for the instrution and the Docm for the data when i make a linker file. i dont know if there is the problem. Also some data getting into the GPRs but after some simulation time the registers becomes as XXXXX. i am using a testbench which is connected to the Port B's signals and declared as external. so i am feeding with specific data and specific addresses for the data. Probably the problem might located there. Because in the system assembly view windows the PORT B of the BRAM is shown as "unconnected" even when these signals are made from be as "external" . Do you think that the netlist might not been produced by the EDK? thank you all. you are very help full with a newbi in FPGA. regardsArticle: 123902
"John McCaskill" <jhmccaskill@gmail.com> wrote in message news:1189106556.202143.39700@o80g2000hse.googlegroups.com... > > Skip the first DCM, and use the other two in FX mode. If they do not > lock in the phase relationship that you need, reset one of them. The problem is not so much in the phase, but in the CLKFX_DIVIDE and CLKFX_MULTIPLY values I need to get the required frequencies. The maximim CLKFX_DIVIDE is not big enough to allow for what you are suggesting... I've actually spent a lot of time trying to avoid the first DCM, but couldn't find a solution. /MikhailArticle: 123903
"MM" <mbmsv@yahoo.com> wrote in message news:5kb1oeF2ut3mU1@mid.individual.net... > "John McCaskill" <jhmccaskill@gmail.com> wrote in message > news:1189105528.073561.184050@d55g2000hsg.googlegroups.com... >> >> The FX output jitter spec of the DCMs does not meet the input jitter >> requirements of the DCMs. What you are trying to do will not work >> reliably. > > Yes, I remember reading it... So, no hope here? Anyone from Xilinx? I > don't care much about the output jitter on the two DCMs, I just need them > to produce the clocks at right frequencies.... If I can't do it, I am in > real trouble... > > > Thanks, > /Mikhail I agree with John McCaskill. If you can't generate your later clocks in FX mode from the initial clock, you can't get there from here. What is the system input and DCM output frequencies you need? Must they be phase aligned? If the design can still be altered, a different clock might be used to feed the DCMs in the first place (such as 70 MHz to generate all the clocks, even what was the system clock) or go through an external jitter clean-up clock chip to then feed the DCMs. With the architecture fixed as it is now, it won't work. - John_HArticle: 123904
On Sep 6, 2:40 pm, "MM" <mb...@yahoo.com> wrote: > "John McCaskill" <jhmccask...@gmail.com> wrote in message > > news:1189106556.202143.39700@o80g2000hse.googlegroups.com... > > > > > Skip the first DCM, and use the other two in FX mode. If they do not > > lock in the phase relationship that you need, reset one of them. > > The problem is not so much in the phase, but in the CLKFX_DIVIDE and > CLKFX_MULTIPLY values I need to get the required frequencies. The maximim > CLKFX_DIVIDE is not big enough to allow for what you are suggesting... I've > actually spent a lot of time trying to avoid the first DCM, but couldn't > find a solution. > > /Mikhail 2/3 and 2/6 should get you there. I think that those are valid combinations for M and D. 2/3 * 210 = 140 2/6 * 210 = 70 Regards, John McCaskill www.fastertechnology.comArticle: 123905
"PeteS" <axkz70@dsl.pipex.com> wrote in message news:dcSdnX9fMOKXz33bRVnyjQA@pipex.net... <snip> > > The vast majority of 'differential signals' on PCBs are *not* true > differential (balanced) signals. They need the reference plane (sometimes > called ground which is really a little confusing) for return currents. > > A balanced signal does not need a reference except it's inverse - that is > NOT true of PCB differential signals in 99% of cases. > > Break the return path and you break the impedance control - it really is > that simple. > > Cheers > > PeteS Just because a differential signal has some reference current in the cround plane doesn't mean the impedance control goes out the window if the ground return path is broken. Consider the lumped LC transmission line model recently referenced. There are Cs between the diff pair wires and from the wires to ground. Since the ground is common (unless your split runs underneath between the wires) these three Cs which were a delta configuration can be rearranged to a Y configuration. The single capacitor to ground should be at the common mode voltage level. You actually would like to get rid of steps in common mode, so any discontinuity in the common reference path is actually a *good* thing. If one wanted to design two ground sections with an inch gap between the ground planes, the differential design could still work if the trace width and separation is changed over the gap. Referenced to a ground plane, the LC model has capacitors that include ground. For the ungrounded differential pair, the LC is entirely in the adjacent wires. The differential pair would make the transition from ground referenced to ground-free and back if the geometries are properly controlled for a proper transition. Any arguement that return currents *are* necessary are harmed when the differential case is deemed as *requiring* the unbroken ground return current path. Keep in mind that the return current "pair" is complementary if the common mode is balanced. - John_HArticle: 123906
"John McCaskill" <jhmccaskill@gmail.com> wrote in message news:1189108426.459585.116970@w3g2000hsg.googlegroups.com... > > 2/3 and 2/6 should get you there. I think that those are valid > combinations for M and D. > > 2/3 * 210 = 140 > 2/6 * 210 = 70 > Not sure what you are trying to say here... This is pretty much what my first DCM with PMCD is doing. The final clocks are (70/29)*16 and (140/29)*20. /MikhailArticle: 123907
"John_H" <newsgroup@johnhandwork.com> wrote in message news:13e0m5eprs3aje6@corp.supernews.com... > > If the design can still be altered, a different clock might be used to > feed the DCMs in the first place (such as 70 MHz to generate all the > clocks, even what was the system clock) or go through an external jitter > clean-up clock chip to then feed the DCMs. > > With the architecture fixed as it is now, it won't work. The design can be altered but at a high cost, as I will need to redesign many other pieces... /MikhailArticle: 123908
On Sep 6, 3:05 pm, "MM" <mb...@yahoo.com> wrote: > "John McCaskill" <jhmccask...@gmail.com> wrote in message > > news:1189108426.459585.116970@w3g2000hsg.googlegroups.com... > > > > > 2/3 and 2/6 should get you there. I think that those are valid > > combinations for M and D. > > > 2/3 * 210 = 140 > > 2/6 * 210 = 70 > > Not sure what you are trying to say here... This is pretty much what my > first DCM with PMCD is doing. The final clocks are (70/29)*16 and > (140/29)*20. > > /Mikhail My mistake, what are the two freqencies you are tring to generate? Regards, John McCaskill www.fastertechnology.comArticle: 123909
Dear All, Please have a look at Scanseer (http://www.scanseer.com), a new software for 'manual' boundary-scan testing. Scanseer does not generate SVF tests, but it allows to: * monitor pins with no interference to normal device operation, * manipulate with pins signals in EXTEST or INTEST mode to test PCB interconnections or internal chip logic, * display pins waveforms, * display graphical package outline with color coded pins values. And last but not least, it's a nice to use and user friendly software. http://www.scanseer.comArticle: 123910
"MM" <mbmsv@yahoo.com> wrote in message news:5kb4tjF2u4qpU1@mid.individual.net... > "John McCaskill" <jhmccaskill@gmail.com> wrote in message > news:1189108426.459585.116970@w3g2000hsg.googlegroups.com... >> >> 2/3 and 2/6 should get you there. I think that those are valid >> combinations for M and D. >> >> 2/3 * 210 = 140 >> 2/6 * 210 = 70 >> > > Not sure what you are trying to say here... This is pretty much what my > first DCM with PMCD is doing. The final clocks are (70/29)*16 and > (140/29)*20. > > /Mikhail Do you need those exact frequencies or values within a range? If the latter, what range? Also... V4 speedgrade which? And are you an FPGA power user or still a bit green with the more detailed stuff? - John_HArticle: 123911
"John_H" <newsgroup@johnhandwork.com> wrote in message news:13e0pj9mt7vep3a@corp.supernews.com... > > Do you need those exact frequencies or values within a range? If the > latter, what range? > Exact. > Also... V4 speedgrade which? -10 > And are you an FPGA power user or still a bit green with the more detailed > stuff? I don't know everything, but I am not a novice :) While we were having this conversation I changed my design to have separate resets for all 3 DCMs. So far, it seems to have worked and they all now lock happily... /MikhailArticle: 123912
skswrus@gmail.com wrote: > Dear All, > Please have a look at Scanseer (http://www.scanseer.com), a new > software for 'manual' boundary-scan testing. > Scanseer does not generate SVF tests, but it allows to: > * monitor pins with no interference to normal device operation, > * manipulate with pins signals in EXTEST or INTEST mode to test PCB > interconnections or internal chip logic, > * display pins waveforms, > * display graphical package outline with color coded pins values. > And last but not least, it's a nice to use and user friendly software. > http://www.scanseer.com Does it run on Unix/Linux? -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 123913
On Sep 6, 11:46 am, axr0284 <axr0...@yahoo.com> wrote: > What are the different ways of crossing clock boundaries. Is there any > website with good information on that. Thanks > Amish You might look at an article I published years ago... Peter Alfke http://www.eetimes.com/editorial/2000/design0003.htmlArticle: 123914
Using linear adjustable regulators for VCCINT (1.25v), VCCIO (3.3v), and VCCAUX (2.5v). VCCINT and VCCIO are dead on, but VCCAUX is 2.72v, 2.88v, and 2.92v on the 3 boards I grabbed and measured. All boards seem to work just fine. The regulator output voltage is controlled by just 2 resistors. When I changed one of the resistors to lover the voltage a bit, VCCAUX did not change. This leads me to believe that VCCAUX is somehow being "back" powered from the Xilinx chip. These voltages are present like this before the Xilinx chip has been programmed. I have not removed the regulator to measure current yet. Another thought was to put a shotkey diode between the regulator output and the load to see if the Xilinx really is powering VCCAUX, but I thought I'd post and see if anyone else has come across this issue. Half the I/O banks are 2.5v and half are 3.3v if that makes any difference. Thanks - DanArticle: 123915
I am looking into a MIG-generated DDR SDRAM interface and am having trouble with the simulation. I can see the interface go through the intialization sequence, but when it gets to the first dummy read to cal the IDELAY's on the data lines, the data that comes back from the RAM is all 'x' except for the least significant 16 bits. Unfortunately the comparison checks look at everything except those bits and the first check never finishes. I have generated these files based on a known RAM DIMM...not a user RAM. And I just used all default values. I am just trying to get educated on DDR. Is there something I am missing? I followed the steps in the sim readme file..... Thanks!Article: 123916
"Dan K" <danielgkNOSPAM@visi.com> wrote in message news:K5%Di.100073$Iu.95108@fe182.usenetserver.com... > Using linear adjustable regulators for VCCINT (1.25v), VCCIO (3.3v), and > VCCAUX (2.5v). VCCINT and VCCIO are dead on, but VCCAUX is 2.72v, 2.88v, > and 2.92v on the 3 boards I grabbed and measured. All boards seem to work > just fine. > > The regulator output voltage is controlled by just 2 resistors. When I > changed one of the resistors to lover the voltage a bit, VCCAUX did not > change. This leads me to believe that VCCAUX is somehow being "back" > powered from the Xilinx chip. These voltages are present like this before > the Xilinx chip has been programmed. I have not removed the regulator to > measure current yet. Another thought was to put a shotkey diode between > the regulator output and the load to see if the Xilinx really is powering > VCCAUX, but I thought I'd post and see if anyone else has come across this > issue. Half the I/O banks are 2.5v and half are 3.3v if that makes any > difference. > > Thanks - Dan > > It sounds like you're driving one of the dedicated configuration pins with a 3V3 signal. They should all be 2V5. There's a Xilinx app note about 3V3 configration which suggests series resistors to limit current through the ESD diodes, and provision of current-sink capability on the 2V5 supply!Article: 123917
> Does it tun on Unix/Linux? No, currently only Windows. But it's written using cross-platform GUI library with the idea to be easily ported to Linux if there will be a market for it.Article: 123918
John Larkin wrote: > On Wed, 05 Sep 2007 18:10:59 -0400, PeteS <axkz70@dsl.pipex.com> > wrote: > >> John Larkin wrote: >>> On Sun, 2 Sep 2007 13:15:25 +0100, "Symon" <symon_brewer@hotmail.com> >>> wrote: >>> >>>> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >>>> news:oduid31vs6ln11b62visqug6ql7rostl1f@4ax.com... >>>>>> Hi Jon, >>>>>> Yes. But with a caveat. When your signals switch reference layers, make >>>>>> sure >>>>>> there is a path for the reference current. >>>>>> >>>>>> E.g. Take a 6 layer board, layer 2 ground, layer 5 power. If the signal >>>>>> goes >>>>> >from layer 1 to 6 through a via, you should have a bypass cap bewteen >>>>>> power >>>>>> and ground near this via. >>>>> That's not necessary. There's already so much plane-plane capacitance >>>>> that the planes are already equipotential as far as the tiny charge >>>>> injected by the signal trace can affect them. >>>>> >>>>> Really, on a board with, say, 3000 vias, are you going to put a bypass >>>>> via near every signal via? I've heard of people asking for two! >>>>> >>>>> John >>>>> >>>> Hi John, >>>> I wish that was always the case! There are problems relying solely on the >>>> interplane capacitance. There will be an impedance discontinuity at the via >>>> no matter what, but using solely the interplane capacitance increases this >>>> discontinuity. Clearly the inductance of the signal in this case is higher. >>>> Also, if a bus does the transistion, all the even mode effects add up. >>>> Finally, the high Q of the planes means you are vulnerable to plane >>>> resonances. >>>> >>>> http://www.sigrity.com/papers/epep2000/QC-JZ-EPEP2000-Final.pdf >>> Wow, that's about as incoherent as papers get! >>> >>> >>>> http://www.hottconsultants.com/techtips/pcb-stack-up-6.html >>> >>> Incredible, dangerous nonsense. Absolutely moronic. Quote: >>> >>> "Referencing the Top and Bottom of the Same Plane. Whenever a signal >>> switches layers and references first the top and then the bottom of >>> the same plane we must still ask the question, how does the return >>> current get from the top to the bottom of the plane. Do to the "skin >>> effect" the current cannot flow through the plane, it can only flow on >>> the surface of the plane. >>> >>> This is some sort of joke, right? >> I would call it glossing over certain issues. The current can obviously >> pass through the plane copper [because skin effect doesn't cause >> infinite impedance obviously], but it won't necessarily be a >> particularly low impedance path (depends on copper weight and signal >> speed, obviously) although it will be a short path ;) > > What's the dielectric constant of copper? > > John > > The dielectric constant is not nearly as important as the relative permeability (which is so close to a vacuum as to be indistinguishable) For 0.5 oz copper (0.685 thou or about 17 micron) the vast majority of the current at really high speeds will be in the outer 6 micron or less. (The definition of skin effect - 1/e). At really high speeds, the skin area [where >50% of current flows] will be < 3 micron. The inner area will have exponentially increasing impedance with a maxima at the centre. (I am not going to apologise for appearing to teach grandmothers to suck eggs). The impedance through the plane will be of the order of 10s to 100s of milliohms at high speeds (where we are speaking of multigigabit/s signals) which can hit signal budgets if not accounted for. Of course, a tactically placed via solves the problem (although it adds the stub problem which is easier to deal with). Cheers PeteSArticle: 123919
Symon wrote: > "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message > news:lZqdnS0_y5YKvULbnZ2dnUVZ_s7inZ2d@comcast.com... >> vasile wrote: >> >> (snip) >> >>> If you're routing a long 3Gbps differential signal, then definitely >>> you must have ground vias near every signal pair vias. Bypassing with >>> a capacitor near an inductive vias has no effect. But using at least >>> one ZBC plane in the stack it helps. >> If it is a differential signal, then you should not need to >> worry about ground bypassing. There should be no net >> ground current, that is the whole point of differential >> signaling. >> >> -- glen >> > Hi Glen, > I think it does matter in this case. I think we're agreed that the two > signals that make up the pair are mainly coupled to the plane, not to each > other. This means that current is flowing in the ground. As you say in > another reply in this thread to me, that doesn't matter, UNTIL the signals > come to a discontinuity in the 'signal to ground' coupling. Such a situation > arises at the transition between layers, which is why the use of adjacent > ground vias can mitigate the situation. > HTH, Symon. > > The vast majority of 'differential signals' on PCBs are *not* true differential (balanced) signals. They need the reference plane (sometimes called ground which is really a little confusing) for return currents. A balanced signal does not need a reference except it's inverse - that is NOT true of PCB differential signals in 99% of cases. Break the return path and you break the impedance control - it really is that simple. Cheers PeteSArticle: 123920
Hi there, I'm not very pleased reading the virtex 5 datasheet dealing with Rocket IO transcievers. In fact the Xilinx datasheets are not comprehensive and dificult to read. Every transciever bank has two lanes and a differential clock. It seems the transciever can work with the regional clock too. See page 66 of the http://direct.xilinx.com/bvdocs/userguides/ug196.pdf: "There are three ways to drive the CLKIN port (see Figure 5-3): =B7 Using an external oscillator to drive GTP dedicated clock routing =B7 Using a clock from a neighboring GTP_DUAL tile through GTP dedicated clock routing =B7 Using a clock from inside the FPGA (GREFCLK)" However the jitter requirements for the rocket IO clk is restrictive. "GREFCLK clocking is not recommended for most designs because of the increased jitter introduced by the FPGA clock nets." Why the hell they keep it ? Which will be your recommandation: using a suplementary low jitter LVDS clock for every Rocket IO transciever or one clock to 3+1+3 transcievers? If using a LVDS clock, one differential clock can be shared succesfully between multiple transcievers ? (see page 69 of the same datasheet). There is no information about the max jitter of such configuration for the longest clk (the third transciever away from the clk supply). thank you very much, VasileArticle: 123921
Hi Paulo, Thank you for your help. I will try to read the report as you suggested. I have tried in some other way and can build the project without this map error. But now I have 2 very wired cases. In one case, I have a failed project and then create new a new porject with the same mhs and mss configuration, the latter one succeed. In another case, I change the a successful case's configuration, which repaces an opb uart and an opb intc with an opb_gpio, this project fail with the same map error. At this time, I am really not sure what's the casue of error. Do you have any suggestion ? Many thanks, On Sep 5, 6:07 pm, Paulo Dutra <paulo.du...@NOSPAM.NOSPAM> wrote: > The typical source of the error is leaving the clock unconnected on the > bus (opb, lmb, or plb) which is then forward propagated to all periphals > on the bus. if this is the problem, then read no further. > > However, your situation may not be typical. First, you'll need to > discover your source of the error in the trimming section of the MAP > report. This is the .MRP file. To get a verbose description of the > trimming report. You'll need to run xflow/projnav without the .BMM file. > Without the BMM file in the flow, map/par will run to completion without > the "all memory mapped blockram" error. Open the MRP and follow the > trimming report. > Good luck. >Article: 123922
On Sep 6, 4:03 pm, "Andrew Holme" <and...@nospam.com> wrote: > "Dan K" <danielgkNOS...@visi.com> wrote in message > > news:K5%Di.100073$Iu.95108@fe182.usenetserver.com... > > > > > Using linear adjustable regulators for VCCINT (1.25v), VCCIO (3.3v), and > > VCCAUX (2.5v). VCCINT and VCCIO are dead on, but VCCAUX is 2.72v, 2.88v, > > and 2.92v on the 3 boards I grabbed and measured. All boards seem to work > > just fine. > > > The regulator output voltage is controlled by just 2 resistors. When I > > changed one of the resistors to lover the voltage a bit, VCCAUX did not > > change. This leads me to believe that VCCAUX is somehow being "back" > > powered from the Xilinx chip. These voltages are present like this before > > the Xilinx chip has been programmed. I have not removed the regulator to > > measure current yet. Another thought was to put a shotkey diode between I would load the Vccaux pin with a 100 Ohm resistor to ground. That adds 25 mA to the regulated current. Normall, this should hardly change the voltage, but if the regulator is back-fed, there will be a big voltage drop. Parallel resistors to ground are nice and easy, and do not cuase any irrepairable tdamage. Peter Alfke > > the regulator output and the load to see if the Xilinx really is powering > > VCCAUX, but I thought I'd post and see if anyone else has come across this > > issue. Half the I/O banks are 2.5v and half are 3.3v if that makes any > > difference. > > > Thanks - Dan > > It sounds like you're driving one of the dedicated configuration pins with a > 3V3 signal. They should all be 2V5. > > There's a Xilinx app note about 3V3 configration which suggests series > resistors to limit current through the ESD diodes, and provision of > current-sink capability on the 2V5 supply!Article: 123923
On Sep 6, 2:46 pm, axr0284 <axr0...@yahoo.com> wrote: > What are the different ways of crossing clock boundaries. Is there any > website with good information on that. Thanks > Amish Although a little dated, I've found this 10 Commandments of Excellent Design article useful. http://www.bawankule.com/verilogcenter/files/10_1.pdfArticle: 123924
Peter Alfke wrote: >> >>>The regulator output voltage is controlled by just 2 resistors. When I >>>changed one of the resistors to lover the voltage a bit, VCCAUX did not >>>change. This leads me to believe that VCCAUX is somehow being "back" >>>powered from the Xilinx chip. These voltages are present like this before >>>the Xilinx chip has been programmed. I have not removed the regulator to >>>measure current yet. Another thought was to put a shotkey diode between > > I would load the Vccaux pin with a 100 Ohm resistor to ground. That > adds 25 mA to the regulated current. > Normall, this should hardly change the voltage, but if the regulator > is back-fed, there will be a big voltage drop. > Parallel resistors to ground are nice and easy, and do not cuase any > irrepairable tdamage. You can also drop the values of the two SET resistors, then you do not need to change the PCB design. -jg
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