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
I think, you just send auto refresh command to sdram, and set a count, let it count down from the cycles it needs. When count equals 0, then auto refresh is finished. SDRAM does the job automatically. Steven sudharr@myw.ltindia.com (RANGA REDDY) wrote in message news:<37ba429a.0405252227.77dfb1f2@posting.google.com>... > Hi all, > > can anybody tell how autorefresh in SDRAM exactly works? suppose in > SDRAM specifications it is mentioned that 64 ms, 4096 cycle > refresh(15.6 us/row) what exactly it means and how we need to generate > the autorefresh cycles. > > actually i am trying to upgrade the 512k*4*32 SDRAM(Fujitsu Make) to > Micron Make 1M*4*32 SDRAM. > > FUJITSU specifies that 4K refresh cycles every 16ms, auto refresh (3.9 > us) and micron specifies that 64 ms, 4096 cycle refresh(15.6 us/row). > > Did any body tried to do this kind of upgradation. we have the code > for Fujitsu SDRAM specifications. > > Anybody can help in this regard please reply to > sudharr@myw.ltindia.com .i can send u the data sheets of both the > SDRAMs,if you want. > > thanks and regards, > > S.RANGA REDDYArticle: 70001
If the simulation says that you are within a few percent of desired performance, then I am sure that it will run under "normal" condition. Simulation parameters assume worst-case temperature (hot), voltage (low) and processing (slow). It is very unlikely that all this comes together in one particular board. For production, you should absolutely always obey the simulation results, but in the lab you can "cheat". Peter Alfke Student wrote: > > Thanks. > > The frequency is fixed and RTL is documented to operate at 40MHz. > I will tamper with the tools for a while instead of havocing with the codes. > Codes change will be my last resort... > > Kelvin > > "ALuPin" <ALuPin@web.de> wrote in message > news:b8a9a7b0.0405250502.385b73b0@posting.google.com... > > "Student" <student@nowhere.com> wrote in message > news:<40b2f02e@news.starhub.net.sg>... > > > Hi, there: > > > > > > My clock is 40MHz, but I have complicated FFT operations and other DSP > > > stuff. > > > The longest path is 25.8ns, though after I set the constraints at > > > 23ns...Previously it > > > was 27.5ns at constraints of 25ns... > > > > > > What may I do now? How far can over constraining go? The source codes > are > > > from > > > other people so I can't change a lot of it. > > > > > > Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1? > > > > > > Does Synplify optimize for speed? How does it compare with XST? > > > > > > Kelvin > > > > Hi Kelvin, > > > > if the source codes are from other people and you cannot change it > > you should assume that is has been optimized for 40MHz, isn't it? ;o) > > > > You have to clarify for which clock frequency the original design has > > been developed. > > > > So basically the best possibility is to think about pipelining your > design. > > By doing so you will not have to worry about constraining. > > > > RgdsArticle: 70002
Do you know where I can find the LP6 documentation? If I'm interested in purchasing the LP6, what is the current price and who can I contact? Thanks again, Derek Simmons "Subroto Datta" <sdatta@altera.com> wrote in message news:<CF1tc.903$n65.588@newssvr33.news.prodigy.com>... > Hi Derek, > > One of my colleagues said that this should work and the LP6 documentation > should be helpful. > > - Subroto Datta > Altera Corp. >Article: 70003
Chuck McManis wrote: > "Rene Tschaggelar" <none@none.net> wrote in message > news:40b323b8$0$700$5402220f@news.sunrise.ch... > >>Chuck McManis wrote: >> >>>Bringing it back on topic... >>> >>>Have you played with the FPSLIC stuff? AVR core plus FPGA? I've got the >>>development board as I was looking at some sort of custome baseboard >>>controller (SMBus, i2c, etc) and it looks great but Atmel doesn't seem >>>particularly committed to it ... >> >>As said, I had no gain in putting any core into an FPGA yet. While using >>a standalone cpu let you select between a bunch of compilers, they >>somehow vanish when you put a core into an FPGA. >>BTW, what does an I2C or SMB, that cannot be done with some port pins ? > > > You mis-read what I typed. The FPSLIC system embeds a "real" ATMEL AVR core > inside an FPGA fabric. All the ATMEL compilers work as you'd expect, all the > peripherals are on the expected pins, except that the pins go into the FPGA > fabric where you can either route them to an "off chip" I/O (using them then > like you would normally) or to some device you've cons'd up inside the FPGA. > > Imagine a multichip module where the FPGA and the microprocessor are on the > same subtrate. No, no, I didn't misread. The more modern compilers come with an IDE, including programmer that download the code and the data and even allow to debug the code on target. This likely won't work anymore, as the integration likely does not go this far. And the ADC is missing of course too. I doubt the AVR core is from Atmel itself, rather from some guys who took the pain of assembling an AVR act-alike. Atmel is of course interested in selling their own chips. ReneArticle: 70004
>Can you explain how it "blows away" custom instructions? I don't know what >the FSL interface is, so I can't compare them myself. > > > You should take a look at xilinx app.note529 http://direct.xilinx.com/bvdocs/appnotes/xapp529.pdf It will explain FSL a little more and also why FSL interfaces are better for HW acceleration that custom instructions. GöranArticle: 70005
"E.S." <emu@ecubics.com> wrote in message news:v33tc.124$UP5.25@fe39.usenetserver.com... > Kenneth Land wrote: > > "E.S." <emu@ecubics.com> wrote in message > > news:GsOsc.20467$zs2.931@fe39.usenetserver.com... Microblaze (no grapes) - so you say "They are probably sour anyway") > > OK, I got it. Thanks ;-) > > But I wasn't even thinking about the NIOS <--> MicroBlaze > competition (?) > > More along the lines, how I like to expand my processors. And > my software guys are trying to kill me each time we invent a new > instruction ;-) > > Cheers > You'd be treated better here! I'm more of a software guy, but I'd be very happy if my hardware guy took the initiative to add instructions to my NiosI/II! Take careArticle: 70006
Peter Alfke wrote: > If the simulation says that you are within a few percent of desired > performance, then I am sure that it will run under "normal" condition. > Simulation parameters assume worst-case temperature (hot), voltage (low) > and processing (slow). It is very unlikely that all this comes together > in one particular board. > For production, you should absolutely always obey the simulation > results, but in the lab you can "cheat". You can also test for actual margin in the lab, by control of two of those corners (Temp,Voltage), and if you can vary the clock, you can get close to the third. > Student wrote: >>Thanks. >> >>The frequency is fixed and RTL is documented to operate at 40MHz. You might want to get a full copy of 'documented to operate at 40MHz' for details of the tool chains, and test interfaces, as well as timing results. -jgArticle: 70007
When you say the design is set to run at 40 Mhz, does that mean 40 Mhz on a specific xilinx fpga or on some generic fab process or what? On Thu, 27 May 2004, Jim Granville wrote: > Peter Alfke wrote: > > If the simulation says that you are within a few percent of desired > > performance, then I am sure that it will run under "normal" condition. > > Simulation parameters assume worst-case temperature (hot), voltage (low) > > and processing (slow). It is very unlikely that all this comes together > > in one particular board. > > For production, you should absolutely always obey the simulation > > results, but in the lab you can "cheat". > > You can also test for actual margin in the lab, by control of two of > those corners (Temp,Voltage), and if you can vary the clock, you can > get close to the third. > > > Student wrote: > >>Thanks. > >> > >>The frequency is fixed and RTL is documented to operate at 40MHz. > > You might want to get a full copy of 'documented to operate at 40MHz' > for details of the tool chains, and test interfaces, as well as timing > results. > -jg > >Article: 70008
The original author tested the RTL on a Virtex2...Now I am still V2 but I need to split the chip into RX & TX and compile them in partial reconfigurable mode...In full V2 chip compilation, it satisfied timing at 24.5ns...in partial compilation, timing is 25~26ns... I am aware partial reconfigurable compilation introduces long wire delays...Since the interface signals between RX/TX are registered, so I don't have effictive control over the offset delays... TX/RX(with FFT) shares FFT & trigonormetric functions, which contain critical paths... Kelvin "Matthew E Rosenthal" <mer2@andrew.cmu.edu> wrote in message news:Pine.GSO.4.58-035.0405262118560.3574@unix3.andrew.cmu.edu... > When you say the design is set to run at 40 Mhz, does that mean 40 Mhz on > a specific xilinx fpga or on some generic fab process or what? > > On Thu, 27 May 2004, Jim Granville wrote: > > > Peter Alfke wrote: > > > If the simulation says that you are within a few percent of desired > > > performance, then I am sure that it will run under "normal" condition. > > > Simulation parameters assume worst-case temperature (hot), voltage (low) > > > and processing (slow). It is very unlikely that all this comes together > > > in one particular board. > > > For production, you should absolutely always obey the simulation > > > results, but in the lab you can "cheat". > > > > You can also test for actual margin in the lab, by control of two of > > those corners (Temp,Voltage), and if you can vary the clock, you can > > get close to the third. > > > > > Student wrote: > > >>Thanks. > > >> > > >>The frequency is fixed and RTL is documented to operate at 40MHz. > > > > You might want to get a full copy of 'documented to operate at 40MHz' > > for details of the tool chains, and test interfaces, as well as timing > > results. > > -jg > > > >Article: 70009
> You can also test for actual margin in the lab, by control of two of >those corners (Temp,Voltage), and if you can vary the clock, you can >get close to the third. Only if you have an environment setup in your lab that generates test cases for all of paths through your design. It's generally easy to get most of them. But that doesn't mean your whole design will run at that frequency. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 70010
"Chuck McManis" <devnull@mcmanis.com> writes: > You mis-read what I typed. The FPSLIC system embeds a "real" ATMEL AVR core > inside an FPGA fabric. Looks nice, except for the price. For that kind of money, I can buy a Spartan II, IIE, or III that is big enough to hold my FPGA design along with a small processor soft core and block RAMs for the memory.Article: 70011
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:40B4A67A.FBE59F51@yahoo.com... > Kenneth Land wrote: > > > > "Jon Beniston" <jon@beniston.com> wrote in message > > news:e87b9ce8.0405251505.5b6713a8@posting.google.com... > > <snip> > > > > > > You say it like it doesn't matter. Maybe it doesn't with FPGA CPUs as > > > you're obviously not concerned about price anyway ;) > > > > > > Cheers, > > > JonB > > > > Hard to imagine an embedded project without an fpga. Might as well have > > only one chip (fpga + softcore cpu) and save the board space since you're > > most likely going to require an fpga anyway. (board space == $$$, parts > > count == $$$) > > > > The reason you would want to use a softcore over hard is because it can be > > *exactly* customized to any application. Need 27 serial ports and timers? > > no problem. Need none? don't waste the pins or money. Need more > > processing power? add custom instructions/external parrallel logic or > > another softcore cpu (or 8!). > > > > I've seen hard core projects fail, but a soft core project can only fail > > from early abandonment. More/harder work can always find a solution, > > because the hardware can become anything you're willing to realize. > > Ok, how about an 8 bit CPU with an 8 input, 10 bit ADC and a brown out > detector? I think this costs less than $3 and comes in a 28 pin TSSOP > or a 5 x 5 mm QFN. MCUs often have advantages since they are typically > mixed signal chips, not just digital. It can be pretty hard to beat an > MCU with an FPGA when you need even just a little bit of analog. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com If you didn't know you needed an ADC before you started then yes you are out of luck. Not so much because there's no ADC on your board, but because you can't produce an initial design that's in the ballpark. But yes you are literally correct. There are many things that an FPGA can't do. I was thinking more in the realm of what processing you might want to do on those 8 input channels - especially after the customer or salesmen started with the post production design ideas :) You sound like one of my kids "What if Godzilla shows up and steps on your board?" enough :) KenArticle: 70012
"E.S." <emu@ecubics.com> wrote in message news:ui3tc.160$UP5.83@fe39.usenetserver.com... > > Sitting long nights to get the tools working ? > priceless ;-) > > cheers > Yeah, but once you figure out all the quirks you're Super Man! Able to drive any nail with your new hammer! (at least that's what I keep telling myself , but then comes along version 2,3,4... plus XP updates :) Some of my favorite efforts in delving into this world of fpga's and soft cores has been separating the truly usefull feature/tools from the marketing checkoffs. Altera support told me that to bring out internal signals using Signal Probe would require placing the signal into a register. But wasn't the whole point of SP to avoid full rebuilds? :) (I'm sure SP is extremely usefull once mastered, just don't have "priceless" hours right now and no one here is letting loose with the secrets) :) KenArticle: 70013
I'm looking into some development boards to play around with, to learn how fpga's work and possibly scale up the complexity later on (real-time audio processing, complex algorithms, etc.) What kind of chip and board would best meet my needs for around 200 dollars?Article: 70014
General Schvantzkoph <schvantzkoph@yahoo.com> writes: > Synplify usually does a 10% better job then any other synthesis tool Synplify is an excellent synthesis tool, but have you benchmarked against all available synthesis tools, including DC-FPGA? It's been I while since I used Synplify, but it appears that some users are less than happy with the later developments of the product: http://www.deepchip.com/items/0427-01.html Other users (including myself) are very excited about DC-FPGA: http://www.deepchip.com/items/0427-02.html Petter // Synopsys DC-FPGA user -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 70015
Hello, it looks like ISE 6.2 doesn't accept LVDCI_33 buffer for Virtex 2 Pro devices. I have only 3,3V banks with an XC2VP7. What happens if I instantiate LVDCI_25 buffer, which are accepted by ISE 6.2? Greetings, MatthiasArticle: 70016
On a sunny day (27 May 2004 00:54:49 -0700) it happened uglya82@yahoo.com (Inquiring Guy) wrote in <310fc2af.0405262354.4961bb47@posting.google.com>: >I'm looking into some development boards to play around with, to learn >how fpga's work and possibly scale up the complexity later on >(real-time audio processing, complex algorithms, etc.) What kind of >chip and board would best meet my needs for around 200 dollars? > https://digilent.us/Sales/boards.cfm I have the D2 and it works fine. JPArticle: 70017
Hi, I have a number of address lines feeding into a combinatorial address decoder, the output of which is clocked twice before being used in my state machine. It could happen that, due to different propagation delays on the address bus, the first flop clocks an incorrect 'valid' address selected. In the next clock period the address lines will have settled and the correct address will be decoded and either selected or not. Apart from checking for two (or more?) consecutive 'valid' pulses, what else can I do to avoid or mitigate this problem? Regards, LourensArticle: 70018
LC Geldenhuys wrote: > Hi, > > I have a number of address lines feeding into a combinatorial address > decoder, the output of which is clocked twice before being used in my > state machine. It could happen that, due to different propagation > delays on the address bus, the first flop clocks an incorrect 'valid' > address selected. In the next clock period the address lines will have > settled and the correct address will be decoded and either selected or > not. > > Apart from checking for two (or more?) consecutive 'valid' pulses, > what else can I do to avoid or mitigate this problem? I think what you are doing is a little bit strange. You should advise your synthesis tool that the allowable asynchronous path length from the register of your address to the flip flop that stores the comparator result is two clock cycles. And, of course, you would only use one flip flop. Regards, MarioArticle: 70019
Thanks for your help, John. Unfortunately, generating synchronous data and clock isn't really an option, as this data is going to be sent out optically. Therefore it has to be within spec and the frequency must meet jitter very stringently. Unfortunately our current hardware platform cannot be modified- I only have power to modify the FPGA. However, new hardware is in the design stages. Most likely support for the asynchronous case will have to be included in the next platform. It will be using an architecture such as that which you described. Thanks for your help! "John_H" <johnhandwork@mail.com> wrote in message news:<JM8qc.5$zR5.133@news-west.eli.net>... > If you're using the recovered clock in an ITU compliant system requiring > very small jitter, take a look at the icst.com clock recovery products to > see about filtering a telecomm clock. They have SAW-based products that can > keep jitter within spec. > > A Numerically Controlled Oscillator can produce your desired STM-16 payload > frequency when you supply frequency adjustments based on your FIFO depth. > That NCO can either generate a digital sinusoid and use a D/A to generate a > sine wave at your desired output frequency or the MSbit of the NCO can be > used to produce a jittered clock that is cleaned up by a PLL like the ones I > mentioned from icst.com; less stringent jitter requirements need less > expensive chips. > > If you only need to generate synchronous data and clock, don't bother > recovering the clock but send out a gated clock with your gated data. > > So - what do you *need*? > > > "Daniel Gowans" <chlump@yahoo.com> wrote in message > news:Xns94EC73A2829D9chlumpyahoocom@198.60.22.31... > > Hello all... > > > > I am using a Xilinx Vitex II FPGA to unwrap a G.709 signal (OTU1) and > > output the underlying STM-16 (or other CBR2G5 signal). > > > > The synchronous payload case is easy- I can use a DCM to generate a clock > > from the incoming data's recovered clock, and use that to clock out the > > data from an asynchronous FIFO filled by the unwrapping logic. > > > > However, the asynchronous payload case seems undoable to me within the > > FPGA. Since the asynchronous payload could vary by +/- 65 ppm from the > > equivalent synchronous payload, I need to use the asynchronous data to > > generate a new clock, or use FIFO level measurement to fine tune the > > frequency of the outgoing clock. If I try to use the clock derived from > > the input clock, the FIFO could at worst start to over/underflow after > > about 1/10th second. > > > > Lastly, if it really can't be done in an FPGA, what type of part could be > > used in tandem that would allow clock generation from a data stream that > is > > accompanied by a valid signal? > > > > Thanks!Article: 70020
Lattice Semiconductor Corporation is currently conducting a seasch for a Product Planning Manager for their Bethlehem, PA facility. RESPONSIBILITIES: - Coordinate and manage activities to define programmable system-on-chip solutions for communication and storage markets. - Work with Strategic Marketing to identify sockets within a system that require programmable logic. Lead the architecting of differentiated programmable solutions as a combination of ASSP and programmable logic based on a thorough understanding of system throughput, bandwidth, data/control interface requirements, higher-level services and customer requirements. - Lead a team to perform system modeling at a behavioral level using C,C++, System C or any HDL; and documentation of specifications of the proposed products. - Must work with and drive cross functional teams (Applications Engineers, Strategic Marketing, R&D) to translate these models to HDL for implementation in programmable logic and standard cell logic - Work with application engineers and marketing to understand customer requirements to develop best-in-class customer solutions and then train application engineers on new products. EDUCATION / SKILLS: - BS with 5+ years or MS with 3+ years - 3+ years management experience - Product development experience in one or more of the following areas:Optical Access systems (Digital crossconnects, ADMs), Storage networks (IP, Fibrechannel switches), Voice or Media Gateways, ATM/IP Edge routers, Multiservice fabric switch - Thorough knowledge of communication network from user interface to the core. - Proficient in network protocols including MPLS/GMPLS, TCP/IP, ATM, SONET, Fibre Channel, IPSec, Ethernet etc. - Experience in designing with FPGAs and high speed digital design- Knowledge of a high-level design language such as Verilog or VHDL, - Knowledge of C,C++ , Perl is a plus - Knowledge of processor (Motorola powerquicc) design and processor interfaces is a plus - Ability to supervise and mentor other group members as well as contribute on an individual basis. - Self-motivated, team player with excellent written and verbal communication skills. IF INTERESTED IN BEING CONSIDERED FOR THIS POSITION, PLEASE CONTACT: KEVIN KELLEY LATTICE SEMICONDUCTOR CORPORATION 610-332-5567 (PHONE) 610-332-5534 (FAX) KEVIN.KELLEY@LATTICESEMI.COMArticle: 70021
Lattice Semiconductor Corporation is conducting a search for Serdes and Flash designers for their San Jose, CA Design Facility. Here are the job descriptions: DESIGN ENGINEER SR (FLASH) Requisition #: 820-299 RESPONSIBILITIES: -Develop and design non-volatile FPGA family architecture and circuit with the focus on Flash technology. -Development includes working closely with Process Technology, Programmability, and Layout on advanced Flash development for use in FPGA architecture as low cost. -Some interface with Product Planning and Software groups might be required. -Design includes working with design engineers and leading design effort in developing Flash programming algorithm and circuits, spice and Verilog simulation, supervising layout activities, test pattern development (as applicable), bench characterization, test and qualification support through production release. EDUCATION / EXPERIENCE: -BSEE with minimum of 5 years of Flash circuit design experience in embedded and/or commodity Flash technology. -Proficient in SPICE, logic verification, bench evaluation, CAD tools. -Knowledge in FPGA is a plus. -------------------------------------------------------------------------------- DESIGN ENGINEER SR (SERDES) Requisition #: 820-297 RESPONSIBILITIES: -Full Custom CMOS IC Digital Circuit Design: GHz Range Clock/Data Recovery (SERDES) and PLL Circuit Design, Circuit/Layout Integration, High Speed IO Design (LVDS, CML). Starting from architecture, circuit design, SPICE DC/AC simulation, layout DRC/LVS verification, layout electrical check, tape out. Work with Product/Test groups on DC/AC characterization plan, test, debug, to final product release. EDUCATION / EXPERIENCE: -MS EE with over 5 years experience, in High Speed SERDES/PLL Circuit Design and Signal Integrity. - Familiar with SPICE, Signal integrity Simulation Tool, CMOS IC Layout, and SERDES/PLL Bench Testing. IF INTERESTED IN BEING CONSIDERED FOR THESE POSITIONS, PLEASE CONTACT: KEVIN KELLEY LATTICE SEMICONDUCTOR CORPORATION 610-332-5567 (PHONE) 610-332-5534 (FAX) KEVIN.KELLEY@LATTICESEMI.COM YOU CAN ALSO ACCESS THESE AND OTHER LATTICE JOB OPENINGS AT: www.latticesemi.comArticle: 70022
Peter Alfke <peter@xilinx.com> wrote in message news:<40B38A28.FDBF2E3F@xilinx.com>... > Here is another suggestion: > Normally transmit a clock that is 30% High, 70% Low, but at the > synchronization moment, change one time to 70% High, 30%Low. > In the receiver, use the DLL to generate 50% duty cycle (the DLL is > always triggered on the rising clock edge). Then use the falling output > edge from the DLL to clock the incoming clock level into a flip-flop. > This flip-flop will be High for just one clock cycle. > This idea is similar to the "missing clock pulse synchronization" > mentioned before, but avoids its problems... > BTW: You must dc-couple the clock for this suggestion ! > Peter Alfke, Xilinx Applications. Great solution, Peter. Some years ago I used this scheme to communicate two systems ... until I change to Manchester ;-). Anyway, has someone thought that the signal needs about 250 ns (25 clock cycles at 100 MHz) to fly from one board to the others. 50m are 50m, and light speed is light speed.Article: 70023
To go one step further with Peter's idea, you can AC couple if instead of sending an occasional "pulse" (one cycle of 70% high) you send a "square wave" of say 50 cycles of 30% high followed by 50 cycles of 70% high. This gives you synchronizing events at each edge of the wave and keeps the DC balance over the period of 1uS. Peter Alfke <peter@xilinx.com> wrote in message news:<40B38A28.FDBF2E3F@xilinx.com>... > Here is another suggestion: > Normally transmit a clock that is 30% High, 70% Low, but at the > synchronization moment, change one time to 70% High, 30%Low. > In the receiver, use the DLL to generate 50% duty cycle (the DLL is > always triggered on the rising clock edge). Then use the falling output > edge from the DLL to clock the incoming clock level into a flip-flop. > This flip-flop will be High for just one clock cycle. > This idea is similar to the "missing clock pulse synchronization" > mentioned before, but avoids its problems... > BTW: You must dc-couple the clock for this suggestion ! > Peter Alfke, Xilinx Applications. > ===================================== > John_H wrote: > > > > How about this weird idea: Don't send a pulse, send an edge. Your > > attenuation might provide a little phase shift but it would be pretty easy > > to alter the phase to match the clocks. Rather than a smeared pulse with > > low high-level amplitudes, you get a full transition with a consistent 50% > > point. > > > > "Tom Derham" <uceeted@ucl.ac.uk> wrote in message > > news:xtvsc.1724$hu1.16883825@news-text.cableinet.net... > > > I am using 3 Xilinx SpartanIIE boards, each loaded with a similar design > > > running with a 100MHz master clock. This clock is derived from a single > > > source and distributed to each board so they are synchronised. The boards > > > are postioned about 50m apart. > > > > > > I need to synchronise events on the boards, but occasionally sending a > > > single pulse (say 10ns long) from the output pin of one of the FPGAs to > the > > > other boards, to allow them to synchronise internal timers. I need to > make > > > sure that the pulse arrives at the other two boards at the same time so > that > > > it is 'recognised' on the same rising edge of the reference clock in each > > > case, so that the boards synchronise together. > > > > > > Clearly the attenuation of any 50m length of cable is such that I cannot > > > connect them directly, but nor do I want the complexity of converting the > > > pulse to optical fibre and back again. > > > For the distribution of the reference clock I am using National CLC005/012 > > > driver and equaliser chipset over UTP, using equal length wires so as to > not > > > introduce propagation skew. For practical reasons I can't use the same > > > cable for sending this event pulse, and ideally would like a simple, > elegant > > > solution. > > > I was just wondering if anyone had done anything similar before... if not, > I > > > have a back-up plan using more of the National drivers, but I thought they > > > might be a sledgehammer to crack a nut - and am unsure what levels of skew > > > they may introduce themselves... jitter is not so important because the > > > event is resynced at the receiving fpga, as long as the total difference > in > > > edge is less than half of the reference clock cycle (so 5ns). > > > > > > Thank you in advance for any ideas.... > > > > > >Article: 70024
sanpab@eis.uva.es wrote: > Peter Alfke <peter@xilinx.com> wrote in message news:<40B38A28.FDBF2E3F@xilinx.com>... > >>Here is another suggestion: >>Normally transmit a clock that is 30% High, 70% Low, but at the >>synchronization moment, change one time to 70% High, 30%Low. >>In the receiver, use the DLL to generate 50% duty cycle (the DLL is >>always triggered on the rising clock edge). Then use the falling output >>edge from the DLL to clock the incoming clock level into a flip-flop. >>This flip-flop will be High for just one clock cycle. >>This idea is similar to the "missing clock pulse synchronization" >>mentioned before, but avoids its problems... >>BTW: You must dc-couple the clock for this suggestion ! >>Peter Alfke, Xilinx Applications. > > > Great solution, Peter. Some years ago I used this scheme to > communicate two systems ... until I change to Manchester ;-). > > Anyway, has someone thought that the signal needs about 250 ns (25 > clock cycles at 100 MHz) to fly from one board to the others. 50m are > 50m, and light speed is light speed. And you want us to give you a link to a cheap, or better to a free time machine ? Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
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