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
Derek, > Unfortunately the timing does not change wether I use the TIMESPEC > constraint or not; I just get a warning that "timing was not met" if I > use the constraint. Is there a constraint that will force the > implementation to meet timing? Signal to signal skew is more important > to me than propogation delay but these signals are asynchronous and I > could not find a constraint that meets that need - all the skew > constraints seem to involve a clock. The way I would implement this in > hardware would be to make all the signal traces the same length; is > there a similar constraint I can use in FPGA design? The short answer is you are not supposed to do an asynchronous design in a FPGA. Nothing good will come out. /MikhailArticle: 130501
On Mar 25, 12:32 pm, wlpstx...@gmail.com wrote: > Hi all, > > I am using Chipscope 9.2i in ubuntu 7.10. Everything works fine except > for Chipscope analyzer GUI not showing up. But the weird thing is > insert.sh and gengui.sh are working, I mean the GUI pops up, but > analyzer's GUI never show up. When I use Tightvnc to remote desktop > to the local machine, the Chipscope analyzer GUI shows up. I recon > it's problem of my X. And I did run export DISPLAY=:0, but it doesn't > help. Why insert.sh and gengui.sh's GUI works, but analyzer's? Please > help, thanks in advance. I found the problem. Refer to this link: http://ph.ubuntuforums.com/showthread.php?t=633142Article: 130502
FPGA <FPGA.unknown@gmail.com> wrote: >I wish to design a FIFO to tansfer data from a high speed clock >domain(320 MHz) to low speed clock domain(40 Mhz). I dont wish to use >the cores available from any of the vendors. > >Inputs => >DataIn // 16 bit data input that is latched in on the posedge of >clkHigh when Wen is high >Wen // Write enable to strobe in the data into the register >Ren // read enable strobe to let the reg know data was read >out of the DataOut register >clkHigh // High speed clock for writing data in >clkLow // low speed clock for reading data out > >Outputs => >DataOut // 16 bit data out that is changed to the next value (or >all low if nothing is yet stored inside) when Ren > goes low after toggling high based on the clkL >Full // signal goes high when all input registers are filled >up. >Empty // Goes high when nothing > >How to decide on the depth of register DataOut to ensure that data is >not overwritten. The issue is that the FIFO has to have some high >speed storage capacity to allow for more data coming in then was >written out. > >Any suggestions would be appreciated. Design the entire FIFO (counters & flags logic) to run at 320MHz and add a clock domain transfer circuit on the low frequency side. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 130503
mvjijuaie@gmail.com wrote: > hai..all > > i am trying to make a particular snr (in dB ) awga (additive > white guassian noise.) in vhdl. > > pls guide me to code it.. i generated the random number using F/F and > exor gate, but not getting how to generate guassian noise. pls help me > Creating good Gaussian noise is a whole science to itself. You can approximate Gaussian noise by summing independent white noise sources (e.g., LFSRs with different numbers of taps) together. The more sources the better the curve, though you have to multiply by some constant to get the standard deviation to work out right, unless you use just the right number of sources. As I recall, using three LFSRs gives you a rough approximation of a Gaussian curve without requiring a constant multiplier. You use N bits from each LFSR and sum them. I forget where the binary point is placed exactly. But you get the idea. -KevinArticle: 130504
On Mar 25, 2:24=A0pm, "BobW" <nimby_NEEDS...@roadrunner.com> wrote: > "Peter Alfke" <pe...@xilinx.com> wrote in message > > news:48ceae85-5695-477e-8ed4-ea446dca38fe@s13g2000prd.googlegroups.com... > On Mar 25, 1:14 pm, Jon Elson <el...@wustl.edu> wrote: > > > > > Peter Alfke wrote: > > > On Mar 24, 11:58 am, Jon Elson <el...@wustl.edu> wrote: > > > >>sky46...@trline4.org wrote: > > > >>>Jon Elson <el...@pico-systems.com> wrote: > > > >>>>I got a batch of "Xilinx" Spartan XCS30 FPGAs from a Chinese > > >>>>seller, and am having problems with random failures at first > > >>>>power up. Sometimes it is a stuck I/O pin, sometimes a failure > > >>>>to configure. I first thought maybe we had an ESD problem, but > > >>>>I'm now thinking these may be counterfeit. They have white ink > > >>>>printed labels on the front, whereas other Xilinx chips have > > >>>>laser-etched labels. Also, these Spartan chips don't have the > > >>>>Spartan logo just below the Xilinx logo, like my other Xilinx > > >>>>chips. Anyone have any comments on this? > > > >>>Photo.. ? > > > >>OK, where should I put the photos? > > > >>Jon > > > > You can send it to me,and I will pass it on. > > > OK, I will do that. I'll have to see how "macro" my camera will go. > > Do you have any comment on some date code 1999 > > Spartans that are printed with white ink (not laser marked) and > > have the Xilinx logo but no Spartan logo under it? These are > > XCS30-3TQ144C parts. I just got them late last year and am having what > > looks like a 50%+ failure rate. In the past, when I got an occasional > > ESD damage event, I usually observed the chip running EXTREMELY hot or > > totally shorting out the power supply. These chips all run cool, but > > many have what seems to be a stuck output pin or they don't configure at= > > all, and the pins that should be doing certain things when the PROG/ > > line is cycled don't do anything. I've used several hundred of this > > particular Xilinx part in previous boards and never ran into any > > problems like this. That combined with the different markings make me > > think they could be counterfeit, maybe poor quality wafers that were > > supposed to be recycled, or something like that. > > > Jon > > Jon, I really have no comments. I do not work in the Spartan group or > even division, let alone building. I just promised to send your > picture and comments to the people in the know. > I hope the parts are fake, for I cannot imagine such a sudden surge in > failure rate from good devices. > Peter Alfke, who works in the Advanced Products (Virtex) division. > > Peter, > > Can you tell us if you've ever seen any counterfeit Xilinx parts? If yes, > were they authentic die that had been repackaged or relabled, or were the > die themselves fakes? > > Thanks, > Bob I have no recollection of fake FPGAs.My educated guess is that the die inside were probably genuine, but either abused or not tested or test escapes.I have never heard that somebody had the money and the audacity to really design and make chips as complicated as ours. But I do not have any proof. And the outside world is getting smarter and has deeper pockets than in the past. Xilinx definitely would like to get their hands on those chips... PeterArticle: 130505
austin wrote: > You are attempting to do asynchronous design in a synchronous design flow, > > By that, I mean, you may bus signals together, and you may register them > by having them arrive at flip flops, clocked from the global clock resource. > > Then timing constraints will be applied, and all bussed signals will be > routed such that they arrive in time to be registered in the flip flops > at the rising lock edge. > > You do not have to worry about how the routing is done (the tools take > care of that for you). > > Having signals leave a register, and arrive at another register (after > passing through logic, or arithmetic operations) is the basis of > synchronous design. > > Without registers and clocks, what you want to do is unsupported > (asynchronous design in a part designed for synchronous implementation). > > http://en.wikipedia.org/wiki/Sequential_logic > > http://en.wikipedia.org/wiki/Synchronous_circuit > > as opposed to: > http://en.wikipedia.org/wiki/Asynchronous_circuit > (which is unsupported by FPGA design flows) > > Austin > Without registers and clocks, what you want to do is unsupported > (asynchronous design in a part designed for synchronous > implementation). I wouldn't say that doing an asynchronous design is unsupported in the part. It's the application of the timing constraints to an asynchronous portion the design which is unsupported. As with all designs, understanding the capabilities of the devices being used along with the performance needs of the final design will lead one to a series of decisions which will insure that all requirements are met. UrbArticle: 130506
On Mar 25, 1:17 pm, John_H <newsgr...@johnhandwork.com> wrote: > water9...@yahoo.com wrote: > > no reply? > > > water9...@yahoo.com wrote: > >> The Linux lspci -xxx command can show my PCIE device header > >> space(0x00~0xFF). However,simultaneity,the Correctable Error and > >> Unsupported Request error from PCIE Capabilities device status > >> register are set. > > >> I run the PCI Express Configuration Testing program from PCISIG to > >> test configure space.The system is halt after click run all test.Reset > >> PC and report NMI error. > > >> why? > > >> My configuration: PCIEx1, 16bit customize GTP wrapper same as Endpoint > >> x1 IP. > > Do you see anything unusual from your PCI Express protocol analyzer? No,i didn't use any protocol analyzer. Only PCISIG Configuration Testing programArticle: 130507
BobW wrote: > Can you tell us if you've ever seen any counterfeit Xilinx parts? If yes, > were they authentic die that had been repackaged or relabled, or were the > die themselves fakes? Think about it. No one is going to set up to create clone die. The costs would be massive, for tiny, short term returns. Xilinx already have a path for defective (test failure/yield fallout) die to be sold, which is the easy-path. Those devices are tested/warranted for ONE or TWO bitstreams only. Depending on their yields/sales mix, Xilinx may have a surplus, or shortfall of 'bad die' - (and as time progresses, you expect the yields to improve). So, it is possible EasyPath devices would work with many more test patterns. The OP could try a series of pgm/verify on suspect devices, to check they can 'remember' a valid bitstream. -jgArticle: 130508
Peter Alfke wrote: > > I have no recollection of fake FPGAs.My educated guess is that the die > inside were probably genuine, but either abused or not tested or test > escapes.I have never heard that somebody had the money and the > audacity to really design and make chips as complicated as ours. But I > do not have any proof. And the outside world is getting smarter and > has deeper pockets than in the past. > Xilinx definitely would like to get their hands on those chips... Oh, well, you can certainly have 6 that I have so far confirmed are bad in some way. If some Spartan expert at Xilinx can tell they are indeed counterfeit from the photo I sent, I guess I am going to have to scrap the lot of them, and so you can have units that have never left the tray. (I don't know if you'd have any interest in electrically experimenting with them.) The removed chips have been pretty heavily abused with our removal tool, the package was visibly flexing as I pried them from the desoldering tool. I've NEVER seen anything like that before either, but I haven't desoldered a TQ144 using this tool before, either. I usually just cut the leads off the body, but this time I wasn't sure if the problem was in the board or the FPGA until I had replaced the FPGA. The last one I did, I had to replace the FPGA twice to get a good one! I know that my procedures at my rework bench are pretty good, so I am really confident I didn't ESD-damage the first replacement. If these units are NOT counterfeit, then they must have been salvaged in some manner that leaves them incredibly "new" looking, but stressed in some way. Absolutely no sign they've been "fiddled with", though. JonArticle: 130509
Jim Granville wrote: > BobW wrote: > >> Can you tell us if you've ever seen any counterfeit Xilinx parts? If >> yes, were they authentic die that had been repackaged or relabled, or >> were the die themselves fakes? > > > Think about it. No one is going to set up to create clone die. > The costs would be massive, for tiny, short term returns. > > Xilinx already have a path for defective (test failure/yield fallout) > die to be sold, which is the easy-path. Those devices are > tested/warranted for ONE or TWO bitstreams only. > > Depending on their yields/sales mix, Xilinx may have a surplus, or > shortfall of 'bad die' - (and as time progresses, you expect the yields > to improve). > So, it is possible EasyPath devices would work with many more test > patterns. > > The OP could try a series of pgm/verify on suspect devices, to > check they can 'remember' a valid bitstream. I only have a couple bitstreams for this particular Spartan size. Several of the chips would not go through the basic steps of the load sequence, such as clearing the addr register of the serial PROM. The others looked like they were mostly working, but had stuck output pins or failed logic internally driving those pins. I really didn't want to go into a great detail diagnosing the problem once I was able to prove it was a bunch of bad chips. Some time ago I got a tape of Analog Devices op-amps that about 60% of them went up in smoke when the board was turned on! On closer inspection, the date codes were all over the place on the same tape, at least an indication that the chips were salvaged off some production run or something. Curiously, these troublesome Spartans have a number after the date code that varies. I wouldn't expect a real counterfeiter to bother with that. All the chips would have the same logo, part number, date code, etc. on them. I'm still stumped. I'm not doing anything different here, and I've only had one or two bad chips in years of making these. I can EASILY attribute that to random ESD problems. (I got 12 V into one when a wire touched, and a couple units were taken out by lightning, too. I expect that.) JonArticle: 130510
DJ Delorie wrote: > David Brown <david@westcontrol.removethisbit.com> writes: >> I would not imagine that bit torrent would be so popular among >> professional users - most companies' networks will (should!) block bit >> torrent traffic. > > Red Hat relies heavily on Bittorrent to distribute copies of the > Fedora stuff. So, don't just assume "bittorrent == bad". No, that's not what I meant - I use bittorrent regularly myself. When I'm downloading something like a Linux distribution, or even larger apps like OpenOffice, it is my first choice of download method when I am at home. But on our office LAN, bittorrent is blocked (to be more precise, incoming bittorrent ports are blocked, so you can't upload - and download speeds will therefore be terrible if anyone tries it). There is no way I'd open up a port forward through our firewall/NAT router to allow p2p networking here, and UPnP (horror!) is of course not used. The difference between usage patterns for businesses and home use (or very small offices) is shown by Red Hat - they rely on Bittorrent for Fedora, but not for RHEL.Article: 130511
ahosyney wrote: [Power estimation using XPower and ModelSim] > To Clarify this I started with an array size of 10 integers, this > array requires 887 clock cycles to be sorted and the total estimated > power consumption was around 488.65 mW. When I increased the array > size to 20 integers (which requires 3069 clock cycles to be sorted) > the estimated power consumption was 492.28mW with increase of about > 3.5 mW. When I increased the number of integers to 40 (11298 clock > cycles are needed to sort that), the power consumption just increased > by around 2mW to be 494.29mW. When I raised the number of integers to > be 80 (43280 clock cycles to be sorted), the power consumption was > reduced to 493mW. So it seems that the activities stored in the VCD > file are not affecting the power estimation as I expected. Why would you expect the power to be higher? Remember that power is energy-per-second. I would expect the 20 integer case to require much the same power as the 10 integer case, but because it takes 3069/887 times longer, it would use 3069/887 times more energy. A MicroBlaze doesn't consume more energy per instruction or energy per second just because the overall problem size is bigger! Note that had you used a different solution than a MicroBlaze or PowerPC, for example a parallel solution with greater parallelism for larger problem size, then it is entirely possible that the power consumption would increase for larger problem sizes, while the time to solve the problem remained constant.Article: 130512
Hi, We have developed a High Speed on FPGA using the MGT/RocketIO to generate high speed signals. Also we receive the high speed signals using the MGT. Due to the nature of the application, we require a pure signal without encoding (We have switched off the 8B/10B encoding in the MGT). The problem is that it effects the clock recovery accuracy in the received signal as there might not be good DC balance in the signal. Which in turn effects the data received. And MGT is a black box to us. Two options- 1. Another encoding mechanism such that we have pure signal and good clock recovery. 2. Or is there a parameter in MGT to improve the clock recovery. We are looking for some solution around this problem. Our setup: FPGA - Xilinx Virtex II Pro Board - Xilinx XUP Virtex(tm)-II Pro Development System Software - ISE 9.1i Best Regards ShakithArticle: 130513
On 2008-03-26, ratztafaz <heinerlitz@googlemail.com> wrote: > BTW a nice Verilog Editor would be a great thing too! Automatic code > completion, automatic wiring through hierarchies, complex refactoring > capabilities, real time syntax compiler, back tracing instantiation > calls, linking between instantiations and module definitions...(I am > dreaming). Still, its pathetic that you still have to invest tons of > time to create toplevel modules and wire modules together. I have found verilog-mode for emacs to be quite nice in regards to the above. It doesn't have all the features I want but it is quite nice nevertheless if you use the /*AUTO*/ features of it. /AndreasArticle: 130514
Partitioning would be nice, if it would work. At least with Xilinx ISE it does not. It could dramatically reduce my compile times, but I got so many random fatal errors with it so I had to abandon it. Maybe in some future version when they fix the issues. Another thing with partitions: The ISE gets so ridiculously slow, its not even funny. Not that I would use the crappy ISE editor but it still is annoying. BTW a nice Verilog Editor would be a great thing too! Automatic code completion, automatic wiring through hierarchies, complex refactoring capabilities, real time syntax compiler, back tracing instantiation calls, linking between instantiations and module definitions...(I am dreaming). Still, its pathetic that you still have to invest tons of time to create toplevel modules and wire modules together.Article: 130515
Jon Elson <elson@pico-systems.com> writes: >I got a batch of "Xilinx" Spartan XCS30 FPGAs from a Chinese >seller, and am having problems with random failures at first >power up. Sometimes it is a stuck I/O pin, sometimes a failure >to configure. I first thought maybe we had an ESD problem, but >I'm now thinking these may be counterfeit. They have white ink >printed labels on the front, whereas other Xilinx chips have >laser-etched labels. Also, these Spartan chips don't have the >Spartan logo just below the Xilinx logo, like my other Xilinx >chips. Anyone have any comments on this? I have XCS10XL in TQFP100 from around 1999/2000 and they also have printed labels. They were obtained from the official German distri at that time (Metronik/Unique). So I guess that white ink labels are no sign of unoffical chips... -- Georg Acher, acher@in.tum.de http://www.lrr.in.tum.de/~acher "Oh no, not again !" The bowl of petuniasArticle: 130516
In article <b2a2d8ca-444d-4508-9f2c-33adb30c8829@p73g2000hsd.googlegroups.com>, Antti <Antti.Lukats@googlemail.com> wrote: >Hi > >I have been think and part time working towards a goal to make useable >and useful serialized processor. The idea is that it should be > >1) VERY small when implemented in any modern FPGA (less 25% of >smallest device, 1 BRAM) >2) be supported by high level compiler (C ?) One of the smallest languages is Forth. There are a couple of cpu engines designed with Forth in mind, and they are really tiny. I.a. Bernd Paysan has published fpga code. The Novix chip (Forth chip design) could be emulated in less that 4k gates (inasfar as I recollect. They were remarkably efficient, I have seen bit-banged video output with the Novix name. (20 Mhz processor). >3) execute code in-place from either serial flash (Winbond quad speed >SPI memory delivers 320 mbit/s!) or from file on sd-card > >serial implementation would be smaller and run at higher speeds, so >128 clock per machine cycle would already mean 2 MIPS, what would be >acceptable for many applications. This you would have to add based on > >Parallax basic stamps I executes 2KIPS only, so ultra lite serial >processor in FPGA with 2 MIPS would be eh, for me its some to dream >off :) > >I have poked around this idea for some years, but never got the "final >kick" to really go and do-complete the design and development of this >processor. > >So I decided to offer some bounty for others to maybe motivate to work >for this goal and dream, current list of items available for the >developers from my own funding is listed here (I hope to add items and >maybe some $ by the time) > >http://code.google.com/p/serial-processor/w/list > >there is also very preliminary spec-goal document as well > >Antti Lukats -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- like all pyramid schemes -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horstArticle: 130517
<shakith.fernando@gmail.com> wrote in message news:a01b5815-57f0-4f38-bade-fae9d7937826@d4g2000prg.googlegroups.com... > Hi, > > We have developed a High Speed on FPGA using the MGT/RocketIO to > generate high speed signals. Also we receive the high speed signals > using the MGT. Due to the nature of the application, we require a pure > signal without encoding (We have switched off the 8B/10B encoding in > the MGT). The problem is that it effects the clock recovery accuracy > in the received signal as there might not be good DC balance in the > signal. Which in turn effects the data received. And MGT is a black > box to us. > > Two options- > 1. Another encoding mechanism such that we have pure signal and good > clock recovery. > 2. Or is there a parameter in MGT to improve the clock recovery. > > We are looking for some solution around this problem. > > Our setup: > FPGA - Xilinx Virtex II Pro > Board - Xilinx XUP Virtex(tm)-II Pro Development System > Software - ISE 9.1i > > Best Regards > Shakith The clock recovery circuitry requires that there be a minimum number of received edges per unit time. Otherwise, the recovered clock edges will drift with respect to the data stream. If you don't use some type of encoding (e.g. 8B/10B), or you don't insure that your raw data ALWAYS provides this minimum edge density requirement, then the clock/data recovery circuitry will not work. BobArticle: 130518
Hi! I have the problem that a core (cordic) can't run with the desired clock (200MHz). As this specific core is totally uncritical for the performance of the system I want to run it with only half of the clock (100MHz). I'm going to use a DCM to divide the clock by 2, and drive the cordic with the halfed clock. I got some problems with hold time violations when going from the lo- speed clock domain to the hi-speed clock domain. Is there any application note / design example availiable that describes how to do this ?Article: 130519
Paul, You can hand place and route an asynchronous design using FPGA_Editor, but I do not recommend this. From Xilinx point of view, we do not support asynchronous design. If you called, and entered a case, and had a problem with an asynchronous design, we would say "don't do that." AustinArticle: 130520
On Mar 26, 7:43=A0am, SaTaN...@googlemail.com wrote: > Hi! > > I have the problem that a core (cordic) can't run with the desired > clock (200MHz). > As this specific core is totally uncritical for the performance of the > system I want to run it with > only half of the clock (100MHz). > > I'm going to use a DCM to divide the clock by 2, and drive the cordic > with the halfed clock. > I got some problems with hold time violations when going from the lo- > speed clock domain to the hi-speed > clock domain. > > Is there any application note / design example availiable that > describes how to do this ? Don't use two clock domains, just drive the cordic with a half- frequency Clock Enable. That keeps everything synchronous, and on the same clock. Peter Alfke, XilinxArticle: 130521
On 25 Mrz., 21:15, Paul Leventis <paul.leven...@gmail.com> wrote: > As for automatic partitioning: Our users tend to push design > performance. If we pre-decide how to break up a design into > completely separable partitions and then separately synthesize and > place-and-route those partitions, yes, you can get a compile time > speed-up. But how much performance is lost? Could you have got an > equal speed-up by just dialing down the effort level in the flat, > serial algorithm? Also, what do you do at the partition boundaries? > Do you need to do some routing and timing analysis at the top level > after synthesis/placement/routing on the sub-sections? If the > partitions do not line up perfectly with clock domains or with > keepers, then you have a slack dependency on signals that cross > partition boundaries -- how do you solve that? That is one of the comon EDA questions: What are the benefits vs. the caveats of high level decisions compare to an algorithm working on a global detailed design description.. Early partitioning costs some optimization potential and requires guestimates at the boundaries, but frees up computational ressources that can used to obtain better results within the partitions in the same tool run time. What is better is not easy to say beforehand. While currently not at the top of the crowd, partitioning based placers still perform pretty well. They were introduced without parallization in mind so partitioning isn't all bad. Another example of this type of tradeoff (albeit no related to parallel algorithms) are all approaches that use clustering. They lose detail to make the overall problem more manageable. I do not know about Altera, but Xilinx has to do partial partitioning anyway to place flip-flops connected to regional clocks. (well, actually this is floorplanning not partitioning, but it has similar effects on the placement) Kolja SulimmaArticle: 130522
> Don't use two clock domains, just drive the cordic with a half- > frequency Clock Enable. That keeps everything synchronous, and on the > same clock. Thank You. I'm currently trying to implement the design using a parallel cordic (which is able to reach 200MHz), but is of course a huge ressource waste. (this cordic will process 1 vector every 3000 clock cycles) I'll try aour suggestion once I'm done with the current run, but a question remains: will ISE be smart enough to notice that the cordic runs at half of the clock speed ? I have the feeling that ISE will still create timing violations in the cordic. Do I need to use timing groups?Article: 130523
On Mar 23, 5:40=A0pm, Jon Elson <el...@pico-systems.com> wrote: > I got a batch of "Xilinx" Spartan XCS30 FPGAs from a Chinese > seller, and am having problems with random failures at first > power up. =A0Sometimes it is a stuck I/O pin, sometimes a failure > to configure. =A0I first thought maybe we had an ESD problem, but > I'm now thinking these may be counterfeit. =A0They have white ink > printed labels on the front, whereas other Xilinx chips have > laser-etched labels. =A0Also, these Spartan chips don't have the > Spartan logo just below the Xilinx logo, like my other Xilinx > chips. =A0Anyone have any comments on this? > > Jon Hi Jon, I am an independent distributor of electronic components. Most of the product I supply comes from fortune 500 OEM's , but occasionally we do have to go to the broker market. Only in very extreme cases would we buy product from China. I would guess that about 95% of the product that is coming out of China brokers/traders is counterfeit. Who is the company you bought them from? Are they in Shenzhen? It is a very bad sign if they did come from that area. We have a very strong quality department and know most of the tricks these companies are using. I would be more than happy to assist in verifying if you have authentic product. From what I have read, I doubt it, but to be fair I typically have a negative attitude towards product coming from China. Please give me a call and I will be more than happy to give you my insight and maybe be able to help you avoid having future problems with buying from China. I mentioned that I supply product from fortune 500 OEM's. I would like you to know that normally the product is in my stock. I am able to do this as we hold inventory for these OEM's on a VMI or SMI agreements that we have with the OEM's. They allow me to borrow some of their material to fill critical needs of other customers. Just about all my inventory is purchased direct from the factory or franchise distribution. Jon E. Hansen Strategic Sales Pyramid Technologies Inc. jon@pyramidemail.com www.pyramidtechnologiesinc.com (949)864-7745 Direct (888)288-8913 Ext. 205 (949)636-1416 Cell (949)864-1869 Fax CERTIFIED ISO 9001:2000Article: 130524
On Mar 26, 10:25 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote: > <shakith.ferna...@gmail.com> wrote in message > > news:a01b5815-57f0-4f38-bade-fae9d7937826@d4g2000prg.googlegroups.com... > > > > > Hi, > > > We have developed a High Speed on FPGA using the MGT/RocketIO to > > generate high speed signals. Also we receive the high speed signals > > using the MGT. Due to the nature of the application, we require a pure > > signal without encoding (We have switched off the 8B/10B encoding in > > the MGT). The problem is that it effects the clock recovery accuracy > > in the received signal as there might not be good DC balance in the > > signal. Which in turn effects the data received. And MGT is a black > > box to us. > > > Two options- > > 1. Another encoding mechanism such that we have pure signal and good > > clock recovery. > > 2. Or is there a parameter in MGT to improve the clock recovery. > > > We are looking for some solution around this problem. > > > Our setup: > > FPGA - Xilinx Virtex II Pro > > Board - Xilinx XUP Virtex(tm)-II Pro Development System > > Software - ISE 9.1i > > > Best Regards > > Shakith > > The clock recovery circuitry requires that there be a minimum number of > received edges per unit time. Otherwise, the recovered clock edges will > drift with respect to the data stream. > > If you don't use some type of encoding (e.g. 8B/10B), or you don't insure > that your raw data ALWAYS provides this minimum edge density requirement, > then the clock/data recovery circuitry will not work. > > Bob Perhaps a scrambler/descrambler using LFSR's would help alleviate any edge density or DC bias problems by randomizing the data a bit? I'm not sure if it would guarantee correct reception, but it may help.
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