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 Jul 3, 9:34 am, austin <aus...@xilinx.com> wrote: > Use the Locked signal from the first DCM to release resetting the second > DCM. > > Locked ---> invert -----> Reset That is what we were doing. However, the input clock, clk, and the associated DCM may lock before GTS is released. As such, the second DCM may try to aquire before the feedback clock is present. I guess the real question is: "How long after GSR is GTS released?" This really determines how long to wait until the reset on the second DCM should released.Article: 121401
I invite you to use free code of a USB full speed project as final work for diploma. The site includes some description of the functionality and main state machines. The code is based on some free cores 8051 and USB function. The PHY is my own code. Pinhas bknpk@hotmail.com http://bknpk.no-ip.bizArticle: 121402
On Jul 3, 2:28 pm, "MM" <m...@yahoo.com> wrote: > <john.m.oy...@gmail.com> wrote in message > > news:1183486887.598253.267900@w5g2000hsg.googlegroups.com... > > > > > How does one interface to TTL logic? Which devices can be used for > > that, and what does it take to safely hook them up to something that > > is 5v? > > What do you need TTL logic for if you have an FPGA? What is it you are > trying to build? I'll start out with tutorial stuff, but my real goal is some type of accelerator for an old home computer. The fpga board would plug into the cpu socket, sitting between it and the cpu. Maybe implement some of the unused opcodes, have hardware fpu stuff. Still undecided on the specifics yet. > If you really need to interface to 5V logic you could use some of the level > translation techniques/devices... Just google on level translation and > you'll find a bunch of ideas.... Thank you. The first few hits are all relevant. I have some learning to do now.Article: 121403
On 19 juin, 09:23, "Jeremie" <nos...@here.com> wrote: > Hi everyone, > > Could someone with experience or simulation tools provide information on the > hardware requirements to interconnect Virtex2pro and Virtex4 with rocketio > at 2.5Gb/s. > The simpler the better, DC if possible and if not AC. I'd like to know the > termination voltages and anything needed on the lines. > v2pro<=>v2pro and V4<=>V4 works. > I can't get the proper setup to run aberttest V4 to v2pro (v2pro to V4 is > easier) so if you have a working setup I'd be glad if you could describe it. > > Thanks, > > Best regards, > > Jeremie > > PS: If someone feels like describing his V5 setup I'm sure that will be > useful for many people. A little late response but I'd be interested to know if you have made progress on this issue. I unfortunately cannot provide help yet but we will soon (in 2 weeks) have to connect a V4 to a V2Pro through RocketIO (Aurora) in the lab. Regarding the BERT core from the Chipscope serial IO toolkit, I read the manual but I don't see how I could use this to test a V4-V2Pro connection unfortunately. Actually, it seems limited to a single FPGA. I don't see how to control two FPGAs from one Chipscope interface... PatrickArticle: 121404
On Jul 3, 11:56 am, austin <aus...@xilinx.com> wrote: > Antti, > > I even hate to bring this up, but how do we know it really is the part > it is supposed to be? We have seen counterfeit parts (some odd die, > packaged, and marked as Xilinx) sold to unsuspecting people by "gray > market" resellers... > > If it doesn't wake up, and say "I am the Xilinx FPGA you expect me to > be" perhaps it isn't? > > I certainly hope this is a simple case of a mis-wired pcb, and not a > case of bogus components sold to an unsuspecting buyer. > > Austin I bought them from Avnet, so hopefully they are not counterfeit. Xilinx thinks it is a software problem, but I am pretty sure it is a hardware problem. Again, it seems JTAG works, but the internals don't. How is this possible? But I have run out of ideas to try. Alan NishiokaArticle: 121405
On Jul 3, 11:59 am, austin <aus...@xilinx.com> wrote: > Antti, > > Further, we have seen where old board test continuity systems apply > voltages (and currents) that my damage the newer 90nm and smaller devices. > > I certainly hope no one exceeded the absolute maximum voltage stress > limits, and has damaged the parts. > > Austin No testing was done (this is a new board bring up) The same micrel mic2204 power supplies were used successfully with a virtex2p design (spartan-3e swapped in to lower cost; slightly different vint used). Is there a reason spartan-3e would behave differently than virtex2p? Could this be caused by the ramp up of vint? Alan NishiokaArticle: 121406
Alan Nishioka wrote: > Again, it seems JTAG works, but the internals don't. How is this > possible? > > But I have run out of ideas to try. Can you restrap the mode pins and try slave serial mode? That might give you a clue.Article: 121407
On Jul 3, 12:57 pm, "Tim (one of many)" <t...@nooospam.roockyloogic.com> wrote: > Alan Nishioka wrote: > > Again, it seems JTAG works, but the internals don't. How is this > > possible? > > > But I have run out of ideas to try. > > Can you restrap the mode pins and try slave serial mode? That might give > you a clue. I have tried changing the mode pins (difficult because they are connected directly to V33 and gnd) to no effect. But JTAG should work regardless of the mode pin settings, right? Thanks, Alan NishiokaArticle: 121408
PlayDough, I don't see the issue: If the DCM locks, that implies that everything is present in order for it to lock. AustinArticle: 121409
Alan, No, this is not an issue of the ramp of any supplies.... I would look for something very simple, and basic, like an open, or a short. AustinArticle: 121410
Alan, Mode pins have no effect on JTAG. AustinArticle: 121411
Alan, http://direct.xilinx.com/bvdocs/userguides/ug332.pdf On page 184, it details the settings for Vccaux 2.5 volt powering of the JTAG. Perhaps, this being the only difference with V2 Pro, this may need to be looked into? Also, the INIT should go low, and then once the device has cleaned out, and is ready to be configured, INIT will return high (requires a pull-up resistor). Holding INIT low, continues the cleanout, and prevents any further operation (until it is released). I am not sure, but it may be that as long as INIT is low, the JTAG state machine may not be operating (..?..). AustinArticle: 121412
On Jun 29, 4:50 am, Allen <lphp...@gmail.com> wrote: > Hi guys, > > Thanks for your replies first. > I forget to say that function of this design is correct by using > Design Vision and the testbench for that and this are the same. > > I check description of testbench. > Timescale directive was includeded on the top of testbench and the > custom design ( `timescale 1ns/10ps). > > The clock speed is 5 MHz ( #100 clock = ~ clock) and the design still > doesn't work properly. > > The input singals are as what I described in the testbench. > > I still have no idea about how to debug or modify the design? > > Thanks again. > > Regards, > > Allen Have you added the clock net to a waveform and actually looked at it? You may have forgotten to initialize the net. In verilog, ~X === X. G.Article: 121413
The bank voltage is 2.5. I am using LVDS_25. I instantiate the buffer by hand and pass the attribute in there. The ISE has instantiation templates for most things. It doesn't have one for the IBUFDS_DIFF_OUT, but you can easily figure things out. I'm just saying the tools give a warning and that is why I removed the attribute.Article: 121414
Alan Nishioka wrote: > I have tried changing the mode pins (difficult because they are > connected directly to V33 and gnd) to no effect. But JTAG should work > regardless of the mode pin settings, right? Yes, JTAG works in all modes. And maybe you have the mode pins set to salve serial. Or even floating, which means that the default pullups pull them to slave serial, depending on the HSWAP pin. What I was suggesting is that you try programming the part in slave serial mode. That could show up any one of a host of problems. If slave serial works and JTAG doesn't... Good luck.Article: 121415
3.3V I/O can drive TTL, no questions asked, for 5-V TTL's Vih min is 2.4 V The difficult issue is 5-V TTL driving the 3.3 V CMOS input. Most 5-V TTL only drives up to two diode drops below the rail, which nominally means 3.6 V. (But 5-V CMOS devices drive all the way to the rail, which poses a problem for you). There are worst-case assumption of the 5 V supply being high, while the 3.3 V supply is low, where things get less benign (5.5 - 1.4 = 4.1, which is 1.1 V above 3.0 V.) Just to give you some facts. Peter Alfke On Jul 3, 12:28 pm, john.m.oy...@gmail.com wrote: > On Jul 3, 2:28 pm, "MM" <m...@yahoo.com> wrote: > > > <john.m.oy...@gmail.com> wrote in message > > >news:1183486887.598253.267900@w5g2000hsg.googlegroups.com... > > > > How does one interface to TTL logic? Which devices can be used for > > > that, and what does it take to safely hook them up to something that > > > is 5v? > > > What do you need TTL logic for if you have an FPGA? What is it you are > > trying to build? > > I'll start out with tutorial stuff, but my real goal is some type of > accelerator for an old home computer. The fpga board would plug into > the cpu socket, sitting between it and the cpu. Maybe implement some > of the unused opcodes, have hardware fpu stuff. Still undecided on the > specifics yet. > > > If you really need to interface to 5V logic you could use some of the level > > translation techniques/devices... Just google on level translation and > > you'll find a bunch of ideas.... > > Thank you. The first few hits are all relevant. I have some learning > to do now.Article: 121416
On Jul 3, 1:12 pm, austin <aus...@xilinx.com> wrote: > I don't see the issue: If the DCM locks, that implies that everything > is present in order for it to lock. That's precisely the problem: everything is not necessarily there for it lock, i.e. the feedback clock. I am using external feedback. That is, the sdram clock is output to the SDRAM, then fed back into the FPGA and finally to the DCM. Since the sdram clock is an output, it is not driven until GTS is released. If GTS is released during the DCM aquisition, then it can lock incorrectly. >From UG331, p.102: "Why is this extra reset pulse required? For an optimum locking process, a DCM configured with external feedback requires both the CLKIN and either the CLK0 or CLK2X signals to be present and stable when the DCM begins to lock. During the configuration process, the external feedback, CLKFB, is not available because the FPGA's I/O buffers are not yet active. At the end of configuration, the DCM begins the capture process once the device enters the startup sequence. Because the FPGA's global 3- state signal (GTS) still is asserted at this time, any output pins remain in a 3-state (high-impedance, floating) condition. Consequently, the CLKFB signal is in an unknown logic state. When CLKFB eventually appears after the GTS is deasserted, the DCM proceeds to capture. However, without the reset pulse, the DCM might not lock at the optimal point, which potentially introduces slightly more jitter and greater clock cycle latency through the DCM. Without the reset, another possible issue might occur if the CLKFB signal, while in the 3-state condition, cross-couples with another signal on the board due to a printed-circuit board signal integrity problem. The DCM might sense this invalid cross-coupled signal as CLKFB and use it to proceed with a lock. This possibly prevents the DCM from properly locking once the GTS signal deasserts and the true CLKFB signal appears."Article: 121417
Alan, INIT is not the signal that holds the JTAG block in reset, it is the PROG signal, or the power ON reset. So, if the core voltage AND the Vccaux AND the IO bank which has the config pins on it are all powered ON, AND if the PROG_b is not being intentionally held low, THEN the JTAG state machine should be released, and should operate. Basically, when INIT goes high, the mode pins are sampled, and then based on the mode pins, the configuration state machine goes to whatever mode is specified, and proceeds with configuration. If JTAG is specified by the mode pins, then the part waits to be configured through the JTAG port. JTAG device ID can be read out prior to configuring (by any mode). Amazing what digging through the schematics reveals. AustinArticle: 121418
PlayDough, Yes, external source of CLKFB requires that you tell the (first) DCM when to LOCK. You need to provide a reset signal, that informs the DCM when the CLKFB signal is present, and valid. If you do this with a counter, or SRL, you need to be sure your counter is long enough, or SRL's are long enough, or clocks are slow enough to account for the time required. The configuration is not smart enough to know when an external signal is 'good'. AustinArticle: 121419
On Jun 29, 1:24 am, "MM" <m...@yahoo.com> wrote:
> "Perry" <lipeng....@gmail.com> wrote in message
>
> news:1182928882.882676.134330@e9g2000prf.googlegroups.com...
>
>
>
> > DeleteInterpProc called with active evals
>
> Apparently this problem is a known issue:http://tinyurl.com/yof2hf
>
> /Mikhail
Mikhail,
I have/had the same problem with multiple designs. Here are the
problems/solutions that I have received from Xilinx about it:
1) Problem: The V4FX60 is a large part, therefore it requires more
memory usage. Under Windows, it can run out of memory and crash.
Solution: If you have a Linux development environment, you can try
running the linux version of the tools and it should get past the
problem. It did for me, but my design failed timing horribly (>
1,000,000 timing score).
>From my experience:
1) Problem: If the system design has flaws (I was using EDK), i.e. un-
connected necessary signals, missing constraints, etc. it can crash
during PAR.
Solution: Ensure the design is setup correctly.
BTW, the windows memory problem was supposedly fixed with ISE 9.2, but
I don't have that in-house for testing yet.
HTH,
-- Mike
Article: 121420On Jul 3, 2:42 pm, austin <aus...@xilinx.com> wrote: > If you do this with a counter, or SRL, you need to be sure your counter > is long enough, or SRL's are long enough, or clocks are slow enough to > account for the time required. And how long is that (ignoring any issues external to the FPGA)? How long is it from when configuration is complete until GTS is released? Given my clock frequency I can derive how long to hold the DCMs in reset after configuration. I just can't find a spec anywhere on the Xilinx website that says how long after configuration that GTS is released. The problem is that the documentation seems to think that 16 clock cycles is enough. But without reference to frequency, I don't know how long that actually is. In fact, I found reference to this in Xilinx Answer Record #14425 (see http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=14425), and this hints at 4 clocks. But when running at, say, 200 MHz, this is only 20ns! What clock frequency are they assuming when the say that 4 clocks is enough? > The configuration is not smart enough to know when an external signal is > 'good'. Absolutely. However, Xilinx should be able to specify how long after configuration the GTS is released. Take this number, add some pad to account for the delay before the feedback clock has a chance to stablize, and keep the DCMs reset until this occurs.Article: 121421
AugustoEinsfeldt wrote: > Thanks for all responses. Because the time zone I was unable to reply > earlier. > The device will do a lot of slow timings (1 second to 10 minutes), > read 6 serial interface ADC converters (with 2.5MHz SCLK) and talk to > a CPLD (used as port expander and watchdog) at 10Mbps data rate. It is > a 3S200 and may have up to 70% of resources used. > > I may stick to the pull-down resistor idea because the system MTBF. > Resistors cause less impact here. > System has a XPLA3 CPLD and other circuits at 3V3 (that is supplied > by a TDK's DC-DC converter) and I think the excess of current will > sink easily. But I will calculate it again. TDK's never answered about > sink capability of their DC-DC modules and I'd like to avoid using a > 3V6 zener to do not waste energy in some temperature conditions. > The signal's rise/fall time are around 50us (worst case). I know it is > very slow for this device and I will have some extra current in the > pin's input circuitry but the cycle time of each signal is in the > range of several minutes. So the impact of slow signal transition may > not be important for the system. Only 2 to 5 signals of 56 may change > at same time and since they came from mechanical feedback it is very > unlikely they will really change precisely together. If you are chasing high operational MTBF, I would be wary of feeding slow edges into a device running a lot of other logic. I have seen very strange effects, caused by input theshold oscillations on Digital devices without hysteresis. High series R makes this effect worse. [I think Xilinx fpga's may have small Hyst, you'll need to check ] > The design did use schmitt-trigger devices for the inputs in the past > but the MTBF did fall because other added circuits and I thought I > could work out the bounce and slow edges with some sample/timing logic > in the FPGA. > > Each of these input signals has a transient suppressor and another > 100ohm resistor to the input connector. Those are to protect against > huge ESD strikes and EMC/EMI. > > Exercising a bit longer in this subject, in case I can sink externally > (to the FPGA) the excess of current (56mA) and since each clamp diode > for this device can handle 100mA (according DS099), which leads a good > current injection handling, the single input resistor (no pull-down) > could work. I am in the limit of system MTBF and it is why I still > thinking to avoid any other component... The main question remains: > would the FPGA's MTBF be reduced because this current flowing in the > clamp diodes? > > System cost is not a big issue but I'd like to avoid high reliability > resistors because availability and lead times. While writing this text > I am having second thoughts about avoiding these resistors... but your > opinion would help in the FPGA's MTBF. What about 4-Pack resistors ?. That slashes the component count, so should improve your MTBF. Another design approach, would be to hold the IP pins low, most of the time, and tristate for narrow window, and read the Pin status at the end of that time. Result is no significant clamp energy, and faster slews - as you now effectively sense a CURRENT level, not a voltage level. [ eg at 1mA and 10pF I get 20ns for 0-2V slew] -jgArticle: 121422
PlayDough , page 234, http://www.xilinx.com/bvdocs/userguides/ug332.pdf details the start up sequence. If you use the default, and you must not wait for DCM to LOCK (as they won't), then you need to know the CCLK rate, and you will see the delay from GTS. Table 12-7. The state machine for the start up progresses as shown. Using bitgen options, you may re-arrange the start up sequence, if for some reason you wish one even to happen before another (should have a really good reason, however, as the default sequence is the easiest to debug and understand because it is the default). Inputs are active before GTS is released (GTS affects outputs). If the feedback is from an output of the device, back to an input, then you also need to know how long it takes from GTS is released, and the output is toggling, until the feedback comes back into the input. Is there an external buffer, PLL, or other component in series with the feedback path? Essentially, once GTS is released, one may assume that the output is immediately active. Page 235 details the source of the startup clock (CCLK is the default). AustinArticle: 121423
As you may see, Even delaying a few clocks after GTS is released should be completely adequate for the feedback signal to get back into the device, unless an external PLL or other component is in series. Speed of light on pcb wires is pretty fast... Hence the reason why the SRL16 solution is considered "bulletproof" for just about every design requiring any delay at all. AustinArticle: 121424
First of all, you're coming at this from a software point of view. If you looked at the situation from a hardware based prospective, the FPGA would be far easier to program because the structures used are more familiar. Secondly, many designs don't have to worry about the implementation details of the mapping of HDL to FPGA, least of all timing closure. All they do is let the tools do their thing and make sure the clock frequency is less than the reported Fmax. Xilinx is smart not to sink all of its resources into a market it coule NEVER hold a decent share of. Video cards will always be much faster than FPGAs. Look at it now, ohhh The fastest DSP blocks can go 500MHz while video cards push 1GHz. It's not going to change. Tools can only do so much, they aren't magic. Xilinx is much better served at using resources in making there existing toolset better as they still need to mature, lest they lose market share in areas that they dominate. ---Matthew Hicks > On Jul 2, 7:47 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: > >> By the way, the programming model for the cell is by far worse >> than anything I've seen on an FPGA, and the programming model for >> video cards >> in the user domain isn't much better, but it's getting there as >> Nvidia prioritizes >> it higher. > As a programming model, having to design circuits around an array of > DSP and bRAM slices is BY FAR MUCH MORE OF A HORRIBLE PROGRAMMING > MODEL ... and a LOT more effort when you also have to fight timing > closure, placement, layout, etc. > > That array of DSP slices exists exactly to exploit this same > market ... and lacking competitive system level solutions (packaged > hardware and software) the volumes for these parts will ultimately be > lacking, and with it a self fulfilling promise that the tools will > never mature behind them either. > Nvidia is simply doing with GPUs, what Xilinx should have done (or > allowed to be done) to get their chips out front as a easy to use > gigaflop/teraflop systems level product to drive embedded comodity > volume sales. > > I personally still believe FPGAs offer greater promise, but only if > there is a systems level vision behind the product to allow it to > mature before becoming obsolete. >
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