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 May 18, 5:32=A0am, wzab <wza...@gmail.com> wrote: > to myhttp://www.ise.pw.edu.pl/~wzab/fpgadbgtool) Maybe you've looked at the CPU-less option before. Python has an interactive console, so it's almost like "C done right". In that respect, since you seem to know more Python than Forth, Python on the host end would make sense. Usually a built-in CPU is used primarily to control things. The debugger is an added feature. If all you need is the debugger and you define the hardware, a CPU may not be necessary. -BradArticle: 151801
On Wed, 18 May 2011 11:57:09 -0500, "maxascent" wrote: >>>> Does anyone know if its possible to change the waveform signals so >that >>>> they are in hex instead of binary. I dont want to do it manually but >>>> just have it come up in hex when the design is loaded. Manually tweak the waves so at least some of them look the way you want. Then, in the wave window, pick menu File/SaveFormat. This will save you a "wave.do" file, which is just a big messy Tcl script. You can replay that into the wave viewer any time, or you can pick individual lines from it and modify them to taste to create your custom setup script, and then execute that on the command line using vsim -do my_script.tcl It's a good idea to save the wave format first, because that file contains a lot of unusual but straightforward commands to adjust wave view that would take you ages to find by reading the docs. -- Jonathan BromleyArticle: 151802
On May 18, 11:14=A0am, Pratap <pratap.i...@gmail.com> wrote: > On May 18, 11:06=A0pm, Pratap <pratap.i...@gmail.com> wrote: > > > > > > > Hi, > > I need to take out two square wave signals from the Virtex II Pro FPGA > > board(XC2VP30, package ff896) with good signal shape and less jitter > > value. The frequency of the two square wave signals are around 40MHz > > and one is the delayed version of the other. I am trying to evaluate > > the performance of a delay generator block inside the FPGA. Hence, the > > shape and precision of the delays is of greater importance to me. I > > have tried to take the signals through various pins on the board > > including the high speed expansion connector. But I found that only > > when the signals are routed out through the EXT_CLK_P(G15) and > > EXT_CLK_N(F15) pins, the jitter performance is the best. But there is > > a funny thing happening when I observe the two waveforms on a scope. > > Below are the two cases. Looks like, when the signal levels of the two > > signals are different, the signal with ZERO logic goes up to around > > 0.2*Vsupply and at the same time the signal with logic '1' goes down > > by around 0.2Vsupply. Can anybody suggest how can I avoid such a > > situation? I feel there is some sort of resistor coupling between > > these two signals. But, can I =A0disable this coupling by changing some > > setting in the ucf file? This is the entry in the ucf file > > corresponding to the two pins mentioned above. > > > NET "clk_in_copy" =A0LOC =3D "G15" | IOSTANDARD =3D LVTTL =A0| SLEW =3D= FAST | > > DRIVE =3D 12 ; > > #EXTERNAL_CLOCK_P=3DG15 > > > NET "op_from_delay_chip_copy" =A0LOC =3D "F15" | IOSTANDARD =3D LVTTL |= SLEW > > =3D FAST | DRIVE =3D 12 ; > > #EXTERNAL_CLOCK_N=3DF15 > > > Please suggest a way to set these signals such that the coupling > > between these two signals is nullified and I can use them as two true > > single ended outputs. > > > Here is an illustration of the case.https://picasaweb.google.com/lh/web= Upload?uname=3Dpratap.iisc&aid=3D56081... > > > Waiting for some helpful answers. > > Thanks and regards, > > Pratap > > Sorry...The link for the picture was wrogly pasted...Here is the > correct link.https://picasaweb.google.com/pratap.iisc/May182011?authkey= =3DGv1sRgCMjQ...- Hide quoted text - > > - Show quoted text - Based on the names these are intended to be a differential pair. This means that they have been routed close together on the board and will have intentional coupling/crosstalk between the two routed nets. In addition there is likely a 100 ohm termination resistor between the two nets that is generating the bump that you are seeing. The resistor could be removed, you will need to check the schematics for you board to determine which one it is. The crosstalk however cannot be removed. Ed McGettigan -- Xilinx Inc.Article: 151803
On May 18, 8:32=A0am, wzab <wza...@gmail.com> wrote: > > At this point I can't say I understand what you are asking. =A0Do you > > have something specific you are asking about or have you figured it > > out at this point? > > The idea was to have a small but efficient CPU inside of FPGA which > could be used to collect some debugging data (e.g. connected > to myhttp://www.ise.pw.edu.pl/~wzab/fpgadbgtool) > and also to control behavior of user IP core. > Forth seems to be the best solution due to it's extendibility > and possibility to work using simple link (serial or other). > > I've exchanged some e-mails with the developer who ported J1 to > MyHDL and after this discussion I think, that the approach used > in Riscy Pygness may be really the best solution. Sounds like you will be doing what I would like to be doing. I have my own dual stack CPU design intended to run Forth. I have only used Forth as a sort of macro assembler for it and with no more work that needs such a CPU it has sat for a number of years with no further development. I have considered a couple of alternatives for adding proper software development support for an embedded processor. One is using open source software such as Riscy Pygness. The other is working from a commercial package such as MPE Forth. From my perspective a commercial package has lot of benefits which include a wide software base that conceivably could be available to support complex projects. The down side is that the use of the processor would be limited to owners of the commercial tool. The advantage of an open source tool is that it is available for anyone to work with and to work on. But you start with a lot less capability. How do you plan to proceed? I assume you are looking for some initial capability that will let you compile code to machine instructions, download those instructions to the target and then interact with the target for debugging. Do you look for anything more? RickArticle: 151804
Nial Stewart wrote: >>> What's the signal path to the FPGA? >>> The ISO is on a 6-layer PCB IO buffering panel with BNC connectors to >> connect to a research lab. The output of the ISO (input to FPGA) at >> 3.3V passes via a 2" ground return wire and 2" signal wire to an FPGA >> header pin on the Digilent NEXYS2 board. > > Then it's probably not a ground problem, especially if this is the only > input to the FPGA. > >> That is a horizontally magnified view of the input to the FPGA (ch1 >> "A0") measured at the Digilent board pin, with 1.5cm probe ground to the >> Digilent pin. > > Does that go straight to the FPGA? > > Is this what it's seeing? Yes, the FPGA input is at the other end of about 2" of trace after the pin where the signal was scoped. >>> If that falling edge is an input than at ~30ns it's shouldn't be what's causing >>> the problem unless you've got _terrible_ ground problems. >> Well if there are ground problems, they are out of my control, as this >> is the signal at the pin on the Digilent board. I would expect them to >> have done a competent job. >> I'm not sure, is there a history of people complaining about Digilent >> board signal integrity problems? > > No, as above this almost definitely isn't a problem. > >>> This shows your design is still susceptible to asynchronous inputs toggling. >> The important other fact is that if the drive impedance is made stiffer >> (180->50ohms) and speed to the FPGA input increased (30->10ns) then the >> glitches are no longer observed, even after an all night wait. > > There could be a race condition internally which stops being a factor when > you speed up the inputs. > > Depending on your build, choice of pins etc this could be re-introduced at > any point. I find this less plausible than simply ground bounce. Although at the same time, I find it very new to have a problem with a 30ns rise/fall. Can you explain a mechanism for such a race condition so I can think about it better? Regarding other things going on, there are the QEP outputs switching a few ns after the clock switches. There were several other asynchronous IOs going in and out, such as a 1MHz and 250kHz divided clock, coming from the 50MHz board clock (which is async vs. the 288kHz qep_sim() clock causing the trouble. > :-) Indeed. >>> Synchronise both(all) the inputs at the IO to the system clock then use those >>> to look for falling or rising edges for your counter >> Yeah, tried that. Works. I think I have things under control, with two >> possible choices of path forward. > > No, there's _only_ one path forward, synchronise your inputs. Well that's what I've changed it to and it worked fine the first time. > The input you're looking at is _reasonably_ fast, how fast is the internal clock > you're using to synchronise it? Ideally it'll be a good multiple (> 5) of this > clock. Well, the board clock is 50MHz. That works fine. Later I will experiment with sending that into the on chip DCM/PLL/DLL thingy and see what happens when I resync stuff at 100MHz, and 200MHz. Of course, now the outputs of my qep_sim() have 20ns of re-synchronization jitter relative to the 288kHz QEP "clock" input. This is Ok in this situation because there are no other data flows synchronous with the 288kHz that must interact with the output from the FPGA. But I can envision cases where this just can't be tolerated, and the FPGA must be configured to count, divide, etc. external clocks and produce outputs that are synchronous with the external clock. It seems the FPGA designers are focussed on a world of data interfaces where the one rule always applies. But what if sub-ns jitter pulse genration of frequency division relative to an external timebase is required? How to do that? Can't be done unless you allow an isolated clock domain. This is a common need in scientific experiments, pulse generators, laser control logic, etc. What am I to do with those problems, design discrete logic again? The whole point of an FPGA to me is that in a research environment, the requirements change constantly, so flexible logic on an inflexible PCB is necessary. I take the expected needs today and say "oh they need a few counters and gates, so multiply that by 100-1000 and in a few years they will have chewed through half of the over-designed resources." That much time I don't have to re-spin the hardware PCBs. I love PLDs! Coupled with a decent CPU and one little platform can fill a thousand roles. That said, certainly what I've gathered at this point is that for whatever clock is brought into the FPGA, that certainly shouldn't be gated or muxed, unless perhaps it's done with resources designed for that purpose, and there is comprehension on how to analyze the timing. >> Thanks for the feedback. Once again! -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 151805
Pete Fraser wrote: > Brian Drummond wrote: >> On Tue, 17 May 2011 06:40:07 -0700, rickman wrote: >> >>> this is working well for my kayaking schedule. :^) >>> >> Heh, you too, huh? > > Is there some requirement that FPGA coders > are also kayakers? > > Pete Fraser > Looksha IV HV No, only that you can only ever use one clock. ;-) -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 151806
On May 18, 11:15=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net> wrote: > Nial Stewart wrote: > > Depending on your build, choice of pins etc this could be re-introduced= at > > any point. > > I find this less plausible than simply ground bounce. =A0Although at the > same time, I find it very new to have a problem with a 30ns rise/fall. > > Can you explain a mechanism for such a race condition so I can think > about it better? > FPGA logic is implemented with memory lookup tables. Since your mux logic has two clock inputs that are presumably running at different frequencies there will be times when both of those inputs are changing *close* to the same time and from the viewpoint of the memory device that is encoding the mux logic might temporarily be outputting the 'wrong' value. FPGA vendors can make the so that a single input change to the memory will not cause a spurious output glitch but they typically don't guarantee no glitches when two or more inputs change simultaneously. This may or may not be the failure mechanism in your particular case here, but it is a mechanism that needs to be avoided. This is also why one would want to sync the clocks first and then mux them. It's easy to think of the logic you write as being implemented by gates, but that is not what is happening. FPGA logic gets implemented in lookup table memories. Changing the address inputs can cause a glitch on the output in certain cases. Another situation would be if the two inputs are not asynchronous but changing the relative timing of one with respect to the other changes the behavior slightly (for better or worse). As an example, any case where you have a clock path that clocks some device and the clock then goes through some delay and then gets used to clock some other device that receives data input (directly or through logic) from the first clocked device would be this type of situation. If the delay through the clock path is *long* and the delay through the data path is *short* then the data can beat the clock to the downstream device. This is a race condition. In this case you can find that an apparent 'fix' (really a band-aid) can be any of the following: - Re-routing until you get a long enough delay on the data path so that the clock wins the race - Put a big capacitor on the data line to attempt to slow the edge down - Re-route the clock on the board with wires so that the clock gets to the downstream device sooner - Spray the part with cold spray or heat up the device with hot air to change the transistor characteristics just enough so that things work...for a few seconds or minutes at best. > > Of course, now the outputs of my qep_sim() have 20ns of > re-synchronization jitter relative to the 288kHz QEP "clock" input. > > This is Ok in this situation because there are no other data flows > synchronous with the 288kHz that must interact with the output from the > FPGA. > > But I can envision cases where this just can't be tolerated, and the > FPGA must be configured to count, divide, etc. external clocks and > produce outputs that are synchronous with the external clock. > In that situation you might use one of the other techniques that I mentioned in your other posting: - Replicate the logic, use the two clock inputs as real clocks and put the mux on the back end outputs. - Use a PLL that can switch over between multiple clock inputs Which approach to use depends on what the actual conditions and constraints you have to deal with in that situation. > It seems the FPGA designers are focussed on a world of data interfaces > where the one rule always applies. =A0 This isn't really limited to FPGAs. Hark back to Digital Logic 101 class and recall that there are lots of ways to implement any logic function: memory devices, nand gates, nor gates, multiplexers. Not all approaches guarantee 'no glitch' performance. What they guarantee is that when the dust settles, the black box function appears to be identical. I'm not sure just what 'one rule' you're referring to, but the important thing is that one must be somewhat aware of the actual implementation and what pitfalls there can be with that type of implementation so that one can avoid the pitfalls as best as possible. > But what if sub-ns jitter pulse > genration of frequency division relative to an external timebase is > required? =A0 How to do that? =A0Can't be done unless you allow an isolat= ed > clock domain. =A0This is a common need in scientific experiments, pulse > generators, laser control logic, etc. > > What am I to do with those problems, design discrete logic again? > Whether you need discrete logic would depend on the particular problem, but the two approaches I mentioned earlier would likely suffice for at least some of the problems. > > That said, certainly what I've gathered at this point is that for > whatever clock is brought into the FPGA, that certainly shouldn't be > gated or muxed, unless perhaps it's done with resources designed for > that purpose, and there is comprehension on how to analyze the timing. > Then you've taken away the right lesson. Kevin JenningsArticle: 151807
On May 18, 11:21=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net> wrote: > Pete Fraser wrote: > > Is there some requirement that FPGA coders > > are also kayakers? > > > Pete Fraser > > Looksha IV HV > > No, only that you can only ever use one clock. ;-) > Not true. FPGAs implement dual clock FIFOs and memories just fine. Kevin JenningsArticle: 151808
On May 19, 5:24=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On May 18, 11:14=A0am, Pratap <pratap.i...@gmail.com> wrote: > > > > > On May 18, 11:06=A0pm, Pratap <pratap.i...@gmail.com> wrote: > > > > Hi, > > > I need to take out two square wave signals from the Virtex II Pro FPG= A > > > board(XC2VP30, package ff896) with good signal shape and less jitter > > > value. The frequency of the two square wave signals are around 40MHz > > > and one is the delayed version of the other. I am trying to evaluate > > > the performance of a delay generator block inside the FPGA. Hence, th= e > > > shape and precision of the delays is of greater importance to me. I > > > have tried to take the signals through various pins on the board > > > including the high speed expansion connector. But I found that only > > > when the signals are routed out through the EXT_CLK_P(G15) and > > > EXT_CLK_N(F15) pins, the jitter performance is the best. But there is > > > a funny thing happening when I observe the two waveforms on a scope. > > > Below are the two cases. Looks like, when the signal levels of the tw= o > > > signals are different, the signal with ZERO logic goes up to around > > > 0.2*Vsupply and at the same time the signal with logic '1' goes down > > > by around 0.2Vsupply. Can anybody suggest how can I avoid such a > > > situation? I feel there is some sort of resistor coupling between > > > these two signals. But, can I =A0disable this coupling by changing so= me > > > setting in the ucf file? This is the entry in the ucf file > > > corresponding to the two pins mentioned above. > > > > NET "clk_in_copy" =A0LOC =3D "G15" | IOSTANDARD =3D LVTTL =A0| SLEW = =3D FAST | > > > DRIVE =3D 12 ; > > > #EXTERNAL_CLOCK_P=3DG15 > > > > NET "op_from_delay_chip_copy" =A0LOC =3D "F15" | IOSTANDARD =3D LVTTL= | SLEW > > > =3D FAST | DRIVE =3D 12 ; > > > #EXTERNAL_CLOCK_N=3DF15 > > > > Please suggest a way to set these signals such that the coupling > > > between these two signals is nullified and I can use them as two true > > > single ended outputs. > > > > Here is an illustration of the case.https://picasaweb.google.com/lh/w= ebUpload?uname=3Dpratap.iisc&aid=3D56081... > > > > Waiting for some helpful answers. > > > Thanks and regards, > > > Pratap > > > Sorry...The link for the picture was wrogly pasted...Here is the > > correct link.https://picasaweb.google.com/pratap.iisc/May182011?authkey= =3DGv1sRgCMjQ...Hide quoted text - > > > - Show quoted text - > > Based on the names these are intended to be a differential pair. =A0This > means that they have been routed close together on the board and will > have intentional coupling/crosstalk between the two routed nets. =A0In > addition there is likely a 100 ohm termination resistor between the > two nets that is generating the bump that you are seeing. > > The resistor could be removed, you will need to check the schematics > for you board to determine which one it is. > > The crosstalk however cannot be removed. > > Ed McGettigan > -- > Xilinx Inc. Thanks a lot McGettigan for the quick answer. I checked the board again and found out that there was indeed an SMD resistor soldered from the bottom side creating this impact. After removing that resistor it looks nice. The crosstalk is not that much as I am operating at around 40MHz. But one thing I am wandering is, how only these two outputs are behaving so well where as none of the other pins (even some pins taken from high speed expansion connector J37) produce such clean and less jittery waveforms. -PratapArticle: 151809
On May 19, 9:26=A0am, Pratap <pratap.i...@gmail.com> wrote: > On May 19, 5:24=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > > > On May 18, 11:14=A0am, Pratap <pratap.i...@gmail.com> wrote: > > > > On May 18, 11:06=A0pm, Pratap <pratap.i...@gmail.com> wrote: > > > > > Hi, > > > > I need to take out two square wave signals from the Virtex II Pro F= PGA > > > > board(XC2VP30, package ff896) with good signal shape and less jitte= r > > > > value. The frequency of the two square wave signals are around 40MH= z > > > > and one is the delayed version of the other. I am trying to evaluat= e > > > > the performance of a delay generator block inside the FPGA. Hence, = the > > > > shape and precision of the delays is of greater importance to me. I > > > > have tried to take the signals through various pins on the board > > > > including the high speed expansion connector. But I found that only > > > > when the signals are routed out through the EXT_CLK_P(G15) and > > > > EXT_CLK_N(F15) pins, the jitter performance is the best. But there = is > > > > a funny thing happening when I observe the two waveforms on a scope= . > > > > Below are the two cases. Looks like, when the signal levels of the = two > > > > signals are different, the signal with ZERO logic goes up to around > > > > 0.2*Vsupply and at the same time the signal with logic '1' goes dow= n > > > > by around 0.2Vsupply. Can anybody suggest how can I avoid such a > > > > situation? I feel there is some sort of resistor coupling between > > > > these two signals. But, can I =A0disable this coupling by changing = some > > > > setting in the ucf file? This is the entry in the ucf file > > > > corresponding to the two pins mentioned above. > > > > > NET "clk_in_copy" =A0LOC =3D "G15" | IOSTANDARD =3D LVTTL =A0| SLEW= =3D FAST | > > > > DRIVE =3D 12 ; > > > > #EXTERNAL_CLOCK_P=3DG15 > > > > > NET "op_from_delay_chip_copy" =A0LOC =3D "F15" | IOSTANDARD =3D LVT= TL | SLEW > > > > =3D FAST | DRIVE =3D 12 ; > > > > #EXTERNAL_CLOCK_N=3DF15 > > > > > Please suggest a way to set these signals such that the coupling > > > > between these two signals is nullified and I can use them as two tr= ue > > > > single ended outputs. > > > > > Here is an illustration of the case.https://picasaweb.google.com/lh= /webUpload?uname=3Dpratap.iisc&aid=3D56081... > > > > > Waiting for some helpful answers. > > > > Thanks and regards, > > > > Pratap > > > > Sorry...The link for the picture was wrogly pasted...Here is the > > > correct link.https://picasaweb.google.com/pratap.iisc/May182011?authk= ey=3DGv1sRgCMjQ...quoted text - > > > > - Show quoted text - > > > Based on the names these are intended to be a differential pair. =A0Thi= s > > means that they have been routed close together on the board and will > > have intentional coupling/crosstalk between the two routed nets. =A0In > > addition there is likely a 100 ohm termination resistor between the > > two nets that is generating the bump that you are seeing. > > > The resistor could be removed, you will need to check the schematics > > for you board to determine which one it is. > > > The crosstalk however cannot be removed. > > > Ed McGettigan > > -- > > Xilinx Inc. > > Thanks a lot McGettigan for the quick answer. > I checked the board again and found out that there was indeed an SMD > resistor soldered from the bottom side creating this impact. After > removing that resistor it looks nice. The crosstalk is not that much > as I am operating at around 40MHz. But one thing I am wandering is, > how only these two outputs are behaving so well where as none of the > other pins (even some pins taken from high speed expansion connector > J37) produce such clean and less jittery waveforms. > > -Pratap- Hide quoted text - > > - Show quoted text - The most likely answer is that you are getting a good connection for the scope probe and a bad one trying to connect to the other connector. Ed McGettigan -- Xilinx Inc.Article: 151810
>"KJ" <kkjennings@sbcglobal.net> wrote in message >On May 18, 11:15 pm, "Mr.CRC" >wrote: >> Nial Stewart wrote: >> > Depending on your build, choice of pins etc this could be re-introduced >> > at >> > any point. >> >> I find this less plausible than simply ground bounce. Although at the >> same time, I find it very new to have a problem with a 30ns rise/fall. >> >> Can you explain a mechanism for such a race condition so I can think >> about it better? > >FPGA logic is implemented with memory lookup tables. Since your mux >logic has two clock inputs that are presumably running at different >frequencies there will be times when both of those inputs are changing >*close* to the same time I think KJ has spotted the problem. Try using a BUFGMUX primitive instead of a LUT to MUX the clocks.Article: 151811
Andrew Holme wrote: >> "KJ" <kkjennings@sbcglobal.net> wrote in message >> On May 18, 11:15 pm, "Mr.CRC" >wrote: >>> Nial Stewart wrote: >>>> Depending on your build, choice of pins etc this could be re-introduced >>>> at >>>> any point. >>> I find this less plausible than simply ground bounce. Although at the >>> same time, I find it very new to have a problem with a 30ns rise/fall. >>> >>> Can you explain a mechanism for such a race condition so I can think >>> about it better? >> FPGA logic is implemented with memory lookup tables. Since your mux >> logic has two clock inputs that are presumably running at different >> frequencies there will be times when both of those inputs are changing >> *close* to the same time > > I think KJ has spotted the problem. > > Try using a BUFGMUX primitive instead of a LUT to MUX the clocks. No, I don't think it's the mux glitching since it does it even with one of the inputs constant. I think I even removed the mux altogether and it still had problems, until stiffening the source impedance. I'm remaining convinced that it's ground bounce. I tried a BUFGMUX and had a hell of a time with inability to implement the design due to not being able to get the IO pins chosen to connect to it. I was using right side GCLKn inputs on a Spartan 3E 500k. I'm happy with the independent edge detectors providing clock enables, which are muxed prior to sending to the qep_sim() which now clocks of the board clock at 50MHz. Now I have to go rework some amateurish resettable clock dividers... -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 151812
Hello, I've been attempting to basically run through the mem_test template and tutorial,on Cyclone® III EP3C120 chip board. I am able to compile the custom SOPC design, the encompassing Quartus file, download the SRAM Object File .sof to the board correctly, create the Application from BSP and Template, and even build the file in NIOS II with no errors. The problem comes about when I attempt to run the system; the .elf downloads in its entirety , but then fails during verification. Verifying 08000000 ( 0%) Verify failed between address 0x80000 and 0x08FFFF Leaving target processor paused. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151813
hi all! I'm working on the Spartan 3E started with mapping MJPEG decoder. I had the source code of the JPEG deccoding, now I use AVI container to display MJPEG via VGA port. I wanna find the first image inside of AVI container but I don't understand the AVI's structure. it has some index such as super index, old index, ect. And I don't know how to display video into monitor via VGA port. any body has idea for my problems? Please, help me! thanks alot! --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151814
Hello, Do you have system ID included in your SOPC design ? Adam > Hello, > > I've been attempting to basically run through the mem_test template and > tutorial,on Cyclone® III EP3C120 chip board. > > I am able to compile the custom SOPC design, the encompassing Quartus file, > download the SRAM Object File .sof to the board correctly, create the > Application from BSP and Template, and even build the file in NIOS II with > no errors. The problem comes about when I attempt to run the system; the > elf downloads in its entirety , but then fails during verification. > > > Verifying 08000000 ( 0%) > Verify failed between address 0x80000 and 0x08FFFF > Leaving target processor paused. > > > > > --------------------------------------- > Posted through http://www.FPGARelated.comArticle: 151815
Hi, I am using xilinx 12.3 for my synthesis and implementation. I am having issues running timing analyzer, the problem is that when i run timing analyzer from the ISE Design Tools menu as a stand alone application and open my design with .ncd file, a message pops up and says "Design is missin for open design. Please make sure design (.ncd) is opened". I have no idea what it means as i am openeing the design according to the procedure i read on some site. Secondly, if i run it from within xilinx Project navigator-> Tools-> Timing Analyzer->Post Place and Route, a message comes in console window at the bottom saying "Process "Analyze Post-Place & Route Static Timing" completed successfully". But i don't see timing analyzer running or anything. Can anyone tell me how to make it work. thanks regards --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151816
On May 18, 11:15=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net> wrote: > Nial Stewart wrote: > >>> The ISO is on a 6-layer PCB IO buffering panel with BNC connectors to > >> connect to a research lab. =A0The output of the ISO (input to FPGA) at > >> 3.3V passes via a 2" ground return wire and 2" signal wire to an FPGA > >> header pin on the Digilent NEXYS2 board. > > > Then it's probably not a ground problem, especially if this is the only > > input to the FPGA. Nial, I'm curious as to why you think this indicates it is not a ground bounce problem? > >>> If that falling edge is an input than at ~30ns it's shouldn't be what= 's causing > >>> the problem unless you've got _terrible_ ground problems. > >> Well if there are ground problems, they are out of my control, as this > >> is the signal at the pin on the Digilent board. =A0I would expect them= to > >> have done a competent job. > >> I'm not sure, is there a history of people complaining about Digilent > >> board signal integrity problems? > > > No, as above this almost definitely isn't a problem. I don't follow. A 30 ns rise time is slow compared to the pulse widths the FFs will clock at. The slow edge looks like a ramp and with only a few tens of milivolts of ground noise imposed by the pins and bond wires the voltage the internal input sees can glitch through the threshold giving an unexpected clock edge. > >>> This shows your design is still susceptible to asynchronous inputs to= ggling. > >> The important other fact is that if the drive impedance is made stiffe= r > >> (180->50ohms) and speed to the FPGA input increased (30->10ns) then th= e > >> glitches are no longer observed, even after an all night wait. > > > There could be a race condition internally which stops being a factor w= hen > > you speed up the inputs. > > > Depending on your build, choice of pins etc this could be re-introduced= at > > any point. > > I find this less plausible than simply ground bounce. =A0Although at the > same time, I find it very new to have a problem with a 30ns rise/fall. > > Can you explain a mechanism for such a race condition so I can think > about it better? > > Regarding other things going on, there are the QEP outputs switching a > few ns after the clock switches. CRC, So this is while the external clock is still slewing? If they are high current or a lot of them, it can cause a problem with a slow clock input. I would also like to hear the details of the race condition. > There were several other asynchronous IOs going in and out, such as a > 1MHz and 250kHz divided clock, coming from the 50MHz board clock (which > is async vs. the 288kHz qep_sim() clock causing the trouble. > > > :-) > > Indeed. > > >>> Synchronise both(all) the inputs at the IO to the system clock then u= se those > >>> to look for falling or rising edges for your counter > >> Yeah, tried that. =A0Works. =A0I think I have things under control, wi= th two > >> possible choices of path forward. > > > No, there's _only_ one path forward, synchronise your inputs. > > Well that's what I've changed it to and it worked fine the first time. > > > The input you're looking at is _reasonably_ fast, how fast is the inter= nal clock > > you're using to synchronise it? Ideally it'll be a good multiple (> 5) = of this > > clock. > > Well, the board clock is 50MHz. =A0That works fine. =A0Later I will > experiment with sending that into the on chip DCM/PLL/DLL thingy and see > what happens when I resync stuff at 100MHz, and 200MHz. > > Of course, now the outputs of my qep_sim() have 20ns of > re-synchronization jitter relative to the 288kHz QEP "clock" input. > > This is Ok in this situation because there are no other data flows > synchronous with the 288kHz that must interact with the output from the > FPGA. > > But I can envision cases where this just can't be tolerated, and the > FPGA must be configured to count, divide, etc. external clocks and > produce outputs that are synchronous with the external clock. The more I think about this the less I agree. Logic always has delays. The only issue if if the delay is too much. Then you need to find a way to mitigate that delay or reduce it. I can't remember a design where I couldn't just clock signals at the interface if that was what I wanted to do. > It seems the FPGA designers are focussed on a world of data interfaces > where the one rule always applies. =A0But what if sub-ns jitter pulse > genration of frequency division relative to an external timebase is > required? =A0 How to do that? =A0Can't be done unless you allow an isolat= ed > clock domain. =A0This is a common need in scientific experiments, pulse > generators, laser control logic, etc. I have to say I'm not sure what "sub-ns jitter pulse genration of frequency division relative to an external timebase" is exactly. So I can't say what it requires in an FPGA. But no one has said you can't use multiple clock domains. Your problem comes from a clock input with an excessively slow rise/fall time. One easy fix is to not use it as a clock, but as a clock enable by detecting the edge with another clock. That effectively provides a low pass filter so the fast glitches are removed. > What am I to do with those problems, design discrete logic again? How would discrete logic be any different than an FPGA? > The whole point of an FPGA to me is that in a research environment, the > requirements change constantly, so flexible logic on an inflexible PCB > is necessary. =A0I take the expected needs today and say "oh they need a > few counters and gates, so multiply that by 100-1000 and in a few years > they will have chewed through half of the over-designed resources." > That much time I don't have to re-spin the hardware PCBs. =A0I love PLDs! > =A0Coupled with a decent CPU and one little platform can fill a thousand > roles. How is a PLD any different from an FPGA??? I'm very confused at this point. > That said, certainly what I've gathered at this point is that for > whatever clock is brought into the FPGA, that certainly shouldn't be > gated or muxed, unless perhaps it's done with resources designed for > that purpose, and there is comprehension on how to analyze the timing. Just to be clear running a clock through logic is not really an issue for the clock. The only reason it is a bad thing is if you are using the multiplexed clock for data on an IO pin. Then the internal delay between the clock pin and the IO pin can be hard for the tools to account for, mostly the variability in the delay. The LookUp Table (LUT) structure in FPGAs is not the same as a semiconductor memory and is designed to not glitch from a single input changing state. In the case of a multiplexer, the clock input that is not selected never has an impact on the output regardless of what the other clock is doing. As long as that clock is being used in a way such that the delay is not important, then it will not cause problems... providing the select line is not changing when your downstream logic is enabled. You don't want to have splinter pulses on the clock mucking with your state machines and counters. If you think your problems here have anything to do with the fact that you are using an FPGA, then you misunderstand what I have been telling you. I hope I haven't given you any wrong information. RickArticle: 151817
On May 19, 5:06=A0pm, "Andrew Holme" <a...@nospam.com> wrote: > >"KJ" <kkjenni...@sbcglobal.net> wrote in message > >On May 18, 11:15 pm, "Mr.CRC" >wrote: > >> Nial Stewart wrote: > >> > Depending on your build, choice of pins etc this could be re-introdu= ced > >> > at > >> > any point. > > >> I find this less plausible than simply ground bounce. Although at the > >> same time, I find it very new to have a problem with a 30ns rise/fall. > > >> Can you explain a mechanism for such a race condition so I can think > >> about it better? > > >FPGA logic is implemented with memory lookup tables. =A0Since your mux > >logic has two clock inputs that are presumably running at different > >frequencies there will be times when both of those inputs are changing > >*close* to the same time > > I think KJ has spotted the problem. > > Try using a BUFGMUX primitive instead of a LUT to MUX the clocks. That would be a band aid, if it even works. What makes you think this is not noise in the ground connection imposing a spike on the slow rise/fall time of the clock? RickArticle: 151818
On May 20, 4:29=A0pm, rickman <gnu...@gmail.com> wrote: > On May 18, 11:15=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net> > > Just to be clear running a clock through logic is not really an issue > for the clock. This is not true. If the memory implementing the logic has a couple of inputs changing together a glitch can occur. Based on what CRC says this may not be his failure mode, but it is a failure caused by "running a clock through logic". > The only reason it is a bad thing is if you are using > the multiplexed clock for data on an IO pin. CRC's code does not clock in any data on an I/O pin...it simply clocks a counter, all internal. So saying 'The *only* reason...' is not correct. > The LookUp Table > (LUT) structure in FPGAs is not the same as a semiconductor memory and > is designed to not glitch from a single input changing state. A plausible explanation though for the rogue clock edge that advanced CRC's counter at the falling edge is that the LUT structure did glitch as a result of a single input changing. There are other plausible explanations, my point is that I wouldn't rule out this as a possiblity. > In the > case of a multiplexer, the clock input that is not selected never has > an impact on the output regardless of what the other clock is doing. Not true. What about when both clocks happen to switch simultaneously (or nearly so). Now you'll have two of the three inputs to the LUT switching. Even if you were guaranteed no glitches with one input changing, you're not guaranteed the same result with two. Kevin JenningsArticle: 151819
rickman wrote: > On May 18, 11:15 pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net> > wrote: > CRC, > > So this is while the external clock is still slewing? If they are > high current or a lot of them, it can cause a problem with a slow > clock input. > > I would also like to hear the details of the race condition. > > >> There were several other asynchronous IOs going in and out, such as a >> 1MHz and 250kHz divided clock, coming from the 50MHz board clock (which >> is async vs. the 288kHz qep_sim() clock causing the trouble. Well considering: http://web.newsguy.com/crobcng/spartan3e/scope_12.png The answer is "no" since the QEP output is switching *because* of the erroneous count on the falling edge. Ie., QEP output switching here is effect, not cause. So chalk this one up to my engaging mouth before brain again. What is going on is the asynchronous outputs from a pair of clock dividers running off the board clock (which is async. to the QEP mechanism) with outputs switching nearby to the troublemaker. So a good experiment would be to scope those along with an incidence of this glitch, and see if something else is actually observable switching during the sensitive portion of the QEP clock edge. But seriously, at this point this is all academic, because I have solved the problem by following the good and applicable advice of everyone here, by resynchronizing the QEP clock input and using the edge detects as CEs. >> Of course, now the outputs of my qep_sim() have 20ns of >> re-synchronization jitter relative to the 288kHz QEP "clock" input. >> >> This is Ok in this situation because there are no other data flows >> synchronous with the 288kHz that must interact with the output from the >> FPGA. >> >> But I can envision cases where this just can't be tolerated, and the >> FPGA must be configured to count, divide, etc. external clocks and >> produce outputs that are synchronous with the external clock. > > The more I think about this the less I agree. Logic always has > delays. The only issue if if the delay is too much. Then you need to > find a way to mitigate that delay or reduce it. I can't remember a > design where I couldn't just clock signals at the interface if that > was what I wanted to do. Ok, but you do agree at this point that my QEP outputs now have 20ns of jitter relative to the 288kHz signal which serves as their timebase, due to the fact that the 288kHz has been re-synced to the board's 50MHz clock. My point is simply that in the case where that 20ns of jitter is not acceptable, then there would be two choices: 1. resynchronize the external clock with a higher frequency FPGA clock such that the synchronization jitter is within tolerable limits, or 2. use the externally supplied clock directly, assuming that signal integrity requirements were satisfied and that it was understood that the logic driven by this clock constitutes a unique clock domain. >> It seems the FPGA designers are focussed on a world of data interfaces >> where the one rule always applies. But what if sub-ns jitter pulse >> genration of frequency division relative to an external timebase is >> required? How to do that? Can't be done unless you allow an isolated >> clock domain. This is a common need in scientific experiments, pulse >> generators, laser control logic, etc. > > I have to say I'm not sure what "sub-ns jitter pulse genration of > frequency division relative to an external timebase" is exactly. So I > can't say what it requires in an FPGA. Simply taking in a clock, dividing it by N and spitting out the result. Or using an external clock as the timebase to generate pulses of N counts of that clock. These are cases where synchronization jitter might not be tolerable, precisely because it is necessary that the result signals must remain *in* the clock domain of the external clock. Yes there will be delay, but delay is delay, and jitter is jitter. The delay in this case would be understood. > But no one has said you can't > use multiple clock domains. Yes. And so there is no disagreement. > Your problem comes from a clock input > with an excessively slow rise/fall time. One easy fix is to not use > it as a clock, but as a clock enable by detecting the edge with > another clock. That effectively provides a low pass filter so the > fast glitches are removed. Yes. Please recognize that sometimes I speak generally. Most of the past few iterations of this discussion have been about generality, not the original problem, which is solved and understood pretty well I think. >> What am I to do with those problems, design discrete logic again? > > How would discrete logic be any different than an FPGA? Well for one thing, it is composed of actual gates rather than LUTs, so one can actually prove correctness of asynchronous designs if one desires. Where, that seems to be impossible with LUTs. >> The whole point of an FPGA to me is that in a research environment, the >> requirements change constantly, so flexible logic on an inflexible PCB >> is necessary. I take the expected needs today and say "oh they need a >> few counters and gates, so multiply that by 100-1000 and in a few years >> they will have chewed through half of the over-designed resources." >> That much time I don't have to re-spin the hardware PCBs. I love PLDs! >> Coupled with a decent CPU and one little platform can fill a thousand >> roles. > > How is a PLD any different from an FPGA??? I'm very confused at this > point. Just speaking generally again. I use the term "PLD" to mean the overall category of programmable logic devices that includes PALs, GALs (both mostly obsolete for my purposes) and more importantly CPLDs and FPGAs. >> That said, certainly what I've gathered at this point is that for >> whatever clock is brought into the FPGA, that certainly shouldn't be >> gated or muxed, unless perhaps it's done with resources designed for >> that purpose, and there is comprehension on how to analyze the timing. > > Just to be clear running a clock through logic is not really an issue > for the clock. The only reason it is a bad thing is if you are using > the multiplexed clock for data on an IO pin. Then the internal delay > between the clock pin and the IO pin can be hard for the tools to > account for, mostly the variability in the delay. Key point. Got it many times over! > The LookUp Table > (LUT) structure in FPGAs is not the same as a semiconductor memory and > is designed to not glitch from a single input changing state. Key point, of a more subtle variety. I've got it, but am still working on a full understanding of this. I think another post is in order. > In the > case of a multiplexer, the clock input that is not selected never has > an impact on the output regardless of what the other clock is doing. That would be in the case of a "glitch-free mux." I will make a new post about this. > As long as that clock is being used in a way such that the delay is > not important, then it will not cause problems... providing the select > line is not changing when your downstream logic is enabled. You don't > want to have splinter pulses on the clock mucking with your state > machines and counters. Yes! > If you think your problems here have anything to do with the fact that > you are using an FPGA, then you misunderstand what I have been telling > you. I hope I haven't given you any wrong information. > > Rick The only thing different about my FPGA is the fact that it is capable of operating at frequencies several times higher than what I've dealt with before. Don't worry so much. Your input has been especially helpful, and I think you are the one who's on target re: the real cause of my glitch--ground bounce rather than the mux glitching. I'm pretty sure this is proved at this point by the various observations that have been made so far. One nice thing about this group is that people have a much more professional demeanor than at certain other less civil neighborhoods (cough, cough, SED, cough cough). I really appreciate this. I want to be able to have my kid peek over my shoulder and not feel shame at the behavior of otherwise highly intelligent folks. Thanks to all! I'll be back with more fun logic silliness in the future... -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 151820
Hi:
The simplest incarnation of a 2-to-1 multiplexer can be described by the
equation:
y = ~s & a | s & b
where 'y' is the output, 's' is the select input, with 'a' and 'b' the
data inputs.
Of course, this multiplexer is broken because a practical implementation
glitches in a if 'a' and 'b' are true, and the select line toggles.
Such as this example from the book (1):
-----------------------------------------
module mux21g (
input wire a,
input wire b,
input wire s,
output wire y
);
wire _s;
wire c, d;
assign #10 _s = ~s;
assign #10 c = _s & a;
assign #10 d = s & b;
assign #10 y = c | d;
------------------------------------
The fix for the glitching is of course to implement an extra term
(Verilog not shown, but I think we can all handle it):
y = ~s & a | s & b | a & b
So the big questions are:
1. What happens (ie., synthesizes) when you implement these equations
in an FPGA?
1a. What synthesizes if you do:
assign y = ~s & a | s & b; // ???
1b. What synthesizes if you code the corrected mux equation:
assign y = ~s & a | s & b | a & b; // ???
1c. Is there any difference in the synthesis if you code it one bitwise
operation at a time, like the module above, vs. all in one equation?
1d. If you "infer" a mux using the code shown in the vendor's device
library, then do you get a good mux, or a glitchy mux?
In the case of a CPLD, I would expect that I could implement the fixed
mux if I selected suitable synthesis properties, such as "mux
extraction" (which I think recognizes my intent to create a mux, perhaps
whether I code it glitch free or not, and implements a correct mux--can
any tool experts clarify?) and/or "wysiwyg" which will probably even
implement the bad mux if I so choose.
But the FPGA with its LUTs is a different ball of wax.
I will be extremely interested to hear what the experts make of these
questions.
I think that it is possible, though I don't yet know how, to see the
"RTL" output by the synth? Are the answers to my questions to be found
there?
Then there are pre-synthesis and post-synthesis (or is it pre and post
fitting?) simulation models, etc., and whew! There are quite a few
things I haven't delved into yet.
Have a nice weekend!
(1) "Learning by Example using Verilog ..." Richard Haskell, et.al. pg. 78.
Disclaimer -- none of the above is intended to imply that one should
ever route a clock through logic such as a mux!
--
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17
Article: 151821Mr.CRC <crobcBOGUS@removethissbcglobal.net> wrote: > The simplest incarnation of a 2-to-1 multiplexer can be > described by the equation: > y = ~s & a | s & b > where 'y' is the output, 's' is the select input, with 'a' and 'b' the > data inputs. > Of course, this multiplexer is broken because a practical implementation > glitches in a if 'a' and 'b' are true, and the select line toggles. (snip) > The fix for the glitching is of course to implement an extra term > (Verilog not shown, but I think we can all handle it): > y = ~s & a | s & b | a & b As I understand it, the FPGA LUTs are designed not to glitch in just this condition. The exact implementation I don't know, but they should not glitch in the cases where a combination of gates that the LUT represents would not glitch. -- glenArticle: 151822
"Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> wrote in message news:ir7ee102lrc@news6.newsguy.com... > 1a. What synthesizes if you do: > assign y = ~s & a | s & b; // ??? > 1b. What synthesizes if you code the corrected mux equation: > assign y = ~s & a | s & b | a & b; // ??? They both synthesize to the same thing: a function of 3 inputs, which is implemented as a single LUT. According to Peter Alfke, Xilinx LUTs do not glitch if only a single input changes at a time. > I think that it is possible, though I don't yet know how, to see the > "RTL" output by the synth? Are the answers to my questions to be found > there? You can view a post-synthesis schematic and you can examine the final output using FPGA Editor.Article: 151823
On May 21, 12:18=A0am, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net> wrote: > > The fix for the glitching is of course to implement an extra term > (Verilog not shown, but I think we can all handle it): > > y =3D ~s & a | s & b | a & b > > So the big questions are: > > 1. =A0What happens (ie., synthesizes) when you implement these equations > in an FPGA? > Redundant logic terms do not get synthesized. If you add them to the source, they will get stripped out of the result. Kevin JenningsArticle: 151824
On May 19, 4:46=A0am, rickman <gnu...@gmail.com> wrote: > Sounds like you will be doing what I would like to be doing. =A0I have > my own dual stack CPU design intended to run Forth. =A0I have only used > Forth as a sort of macro assembler for it and with no more work that > needs such a CPU it has sat for a number of years with no further > development. > > I have considered a couple of alternatives for adding proper software > development support for an embedded processor. =A0One is using open > source software such as Riscy Pygness. =A0The other is working from a > commercial package such as MPE Forth. =A0From my perspective a > commercial package has lot of benefits which include a wide software > base that conceivably could be available to support complex projects. > The down side is that the use of the processor would be limited to > owners of the commercial tool. > > The advantage of an open source tool is that it is available for > anyone to work with and to work on. =A0But you start with a lot less > capability. > I definitely prefer to use the open source approach (if I'm only allowed to ;-) - sometimes I'm bound by conditions set for the whole design, which do not allow me to publish it). > How do you plan to proceed? =A0I assume you are looking for some initial > capability that will let you compile code to machine instructions, > download those instructions to the target and then interact with the > target for debugging. =A0Do you look for anything more? > Well, unfortunately this a rather low priority project for me, which I'm doing only in my spare time. In fact all I need at the moment is a possibility to define new words for J1. It could be done in a "Riscy Pygness" way, but then the tool running on the host (corresponding to riscy.tcl in RP) should record all the interactive session to allow further analysis, and extraction of best performing words defined during the session. Wojtek
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