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
J o h n _ E a t o n (at) hp . com (no spaces) wrote: >> Why not? This would be a great teaching tool for fpga design and/or >> computer system design courses at college level. > > Only if it can fit into an FPGA. Anybody have a gatecount? Even if it didn't - having source to a modern commercial processor would still be useful - I recall someone was asking about this on the group a little while ago. JeremyArticle: 99651
bijoy wrote: > Hi > > I have a board with Spartan-3-e mounted on it. > > I am using HSWAP pin as an User I/O. > > I forgot to put an external pull-down resitor on HSAWP pin, will it have any problem in configuring the FPGA ? > > please help me. > > rgs bijoy The latest Spartan-3E data sheet provides a bit more detail on HSWAP. See pages 68-69. http://www.xilinx.com/bvdocs/publications/ds312.pdf HSWAP has a dedicated pull-up resistor to VCCO_0 during configuration. If HSWAP floats, then all the other pins not actively used during configuration will be high impedance (i.e., floating), which may or may not be what you want. Some of the other FPGA pins have dedicate pull-up resistors to their associated power rail that are active during configuration, including PROG_B, DONE, HSWAP, INIT_B, and the JTAG pins (TDI, TMS, TCK, TDO). --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 99652
On 27 Mar 2006 13:29:02 -0800, "Peter Alfke" <peter@xilinx.com> wrote: > >John Larkin wrote: >>> >> And the crystal oscillator turns out to be both fast and weak. On its >> rise, it puts a step into the line of about 1.2 volts in well under 1 >> ns, and doesn't drive to the Vcc rail until many ns later. > >Why would the signal round-trip delay be several ns, at 6" or 15 cm >per ns one-way propagation on a pc-board ? >The flat spot at 1.2 V is usually the result of a matched (weak) driver >achieving half-amplitude driving the transmission line, and waiting for >the reflection coming back from the far end. But "many nanoseconds ??? >Peter Alfke Well, two maybe. Is two "many"? What with trace routing and capacitive pin loading and vias and the pcb dielectric itself, we're talking velocities well under half of c. The plateau is real as sin, viewed on a 500 MHz scope with a fet probe. JohnArticle: 99653
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:eukg22d156r3lq8ke0l63nt7mdvv6fh818@4ax.com... >> >>Since the issue is 'local', I'd fix it locally, and 2. sounds >>preferable. You know the CLK freq, so can choose the delay banding. > > That's looking promising; we're testing that one now. Gotta figure how > many cells it takes to delay 5 ns. (We'll just xor the ends and bring > that out to a test point.) > John, I've done option 2 before on a sine wave oscillator fed to an FPGA. I used the delay element within some unbonded IOBs to get the delay. (Drive signal out on O/P, get it back through I/P delay. NB. turn off DRC check in bitgen.) I figured it would be more likely to carry on working with newer versions of software. Each new version comes up with more fiendish ways to remove delay chains! Good luck, Syms.Article: 99654
javaguy11111@gmail.com wrote: > I have been playing around with opensparc some using xst. I did manage > to get a build without errors, but since I did not have a clock defined > everything got optimized away. So no gate counts. One thing I did > learn is to not import the files using Project Navigator. It just locks > it up. > > A build using an xst script worked. There was one file that had a > function defined that was causing xst to fail. However when I removed > it I got no more complaints. > > It may not be possible to synthesize with 8 cores, but I thought I saw > something in the docs about being to specify fewer cores. > > I will probably play around with it some more as free time allows and > see how far I can get with it. > OK, Thanks very much for the information. I also tried to synthesize using Altera's Quartus II but gave up when I got many errors. Thought I would try it out with DC first and see what I get. -ShyamArticle: 99655
John, here is an idea that eliminates the impact of fast clockglitches: It uses one LUT plus some routing delay outside the LUT. Inside the LUT implement a latch plus an AND condition which drives set, and an other AND to drive reset. Drive one input of the set AND gate with the inverted clock, the other input with the delayed Q. Drive one input of the reset AND gate with the clock and the other with the inversion of the delayed Q. The inverters all get folded into the LUT. Q is your cleaned-up clock signal. Thus you can only set the latch if it had been reset for awhile, and you can only reset it if it had been set for awhile. All in one LUT with 3 inputs: incoming clock, Q output direct, Q output delayed (somehow...) (The synthesizer may not like this feedback arangement.) This (untried) circuit does of course not solve the time uncertainty due to the flat spot, but it avoids double-triggering. Peter Alfke Peter AlfkeArticle: 99656
John Larkin wrote: > We have a perfect-storm clock problem. A stock 16 MHz crystal > oscillator drives a CPU and two Spartan3 FPGAs. The chips are arranged > linearly in that order (xo, cpu, Fpga1, Fpga2), spaced about 1.5" > apart. The clock trace is 8 mils wide, mostly on layer 6 of the board, > the bottom layer. We did put footprints for a series RC at the end (at > Fpga2) as terminators, just in case. > > Now it gets nasty: for other reasons, the ground plane was moved to > layer 5, so we have about 7 mils of dielectric under the clock > microstrip, which calcs to roughly 60 ohms. Add the chips, a couple of > tiny stubs, and a couple of vias, and we're at 50 ohms, or likely > less. > > And the crystal oscillator turns out to be both fast and weak. On its > rise, it puts a step into the line of about 1.2 volts in well under 1 > ns, and doesn't drive to the Vcc rail until many ns later. At Fpga1, > the clock has a nasty flat spot on its rising edge, just about halfway > up. And it screws up, of course. The last FPGA, at the termination, is > fine, and the CPU is ancient 99-micron technology or something and > couldn't care less. I'm with Peter Alfke. Fpga1 is seeing the half-heght pulse on its way to the end of the line to be reflected back to give you the full height pulse. I'd be looking at minor surgery on the board to give Fpga1 its own private track (or length of VMTX55 1.17mm OD 50R coax cable). I don't think that the crystal-oscillator output is necessarily weak - it sounds more as if some clown has embedded a source terminating resistor inside the package. You might find it worthwhile to extend the minor surgery to the point of adding a few SOT-23 wideband transistors (BFR93, BFT93?) to buffer the clock signal. Don't forget the 33R base-stoppers on the wideband transistors if you do go down this route. We got forced into this sort of cut and link work to get a prototype GaAs board working when the PC department mispositioned the -2V plane that should have been directly under the tracks distributing an 800MHz ECL-level clock - the clock ended up being distributed on VMTX55 links, which looked a bit strange, but worked remarkably well. -- Bill Sloman, NijmegenArticle: 99657
On 27 Mar 2006 15:00:52 -0800, bill.sloman@ieee.org wrote: > >John Larkin wrote: >> We have a perfect-storm clock problem. A stock 16 MHz crystal >> oscillator drives a CPU and two Spartan3 FPGAs. The chips are arranged >> linearly in that order (xo, cpu, Fpga1, Fpga2), spaced about 1.5" >> apart. The clock trace is 8 mils wide, mostly on layer 6 of the board, >> the bottom layer. We did put footprints for a series RC at the end (at >> Fpga2) as terminators, just in case. >> >> Now it gets nasty: for other reasons, the ground plane was moved to >> layer 5, so we have about 7 mils of dielectric under the clock >> microstrip, which calcs to roughly 60 ohms. Add the chips, a couple of >> tiny stubs, and a couple of vias, and we're at 50 ohms, or likely >> less. >> >> And the crystal oscillator turns out to be both fast and weak. On its >> rise, it puts a step into the line of about 1.2 volts in well under 1 >> ns, and doesn't drive to the Vcc rail until many ns later. At Fpga1, >> the clock has a nasty flat spot on its rising edge, just about halfway >> up. And it screws up, of course. The last FPGA, at the termination, is >> fine, and the CPU is ancient 99-micron technology or something and >> couldn't care less. > >I'm with Peter Alfke. Fpga1 is seeing the half-heght pulse on its way >to the end of the line to be reflected back to give you the full height >pulse. > >I'd be looking at minor surgery on the board to give Fpga1 its own >private track (or length of VMTX55 1.17mm OD 50R coax cable). I don't >think that the crystal-oscillator output is necessarily weak - it >sounds more as if some clown has embedded a source terminating resistor >inside the package. You might find it worthwhile to extend the minor >surgery to the point of adding a few SOT-23 wideband transistors >(BFR93, BFT93?) to buffer the clock signal. Don't forget the 33R >base-stoppers on the wideband transistors if you do go down this route. > >We got forced into this sort of cut and link work to get a prototype >GaAs board working when the PC department mispositioned the -2V plane >that should have been directly under the tracks distributing an 800MHz >ECL-level clock - the clock ended up being distributed on VMTX55 links, >which looked a bit strange, but worked remarkably well. If we wanted to spin the board layout, we could just put in the risetime-limiting inductor, or add a meaty clock buffer, or better yet add a series resistor, with maybe an optional cap to ground, to slow down the sig on the clock line, and then add a Tiny Logic schmitt buffer at each chip. But as I noted, the challenge here is to find a software-only fix. JohnArticle: 99658
On Mon, 27 Mar 2006 14:31:13 -0800, "Symon" <symon_brewer@hotmail.com> wrote: >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:eukg22d156r3lq8ke0l63nt7mdvv6fh818@4ax.com... >>> >>>Since the issue is 'local', I'd fix it locally, and 2. sounds >>>preferable. You know the CLK freq, so can choose the delay banding. >> >> That's looking promising; we're testing that one now. Gotta figure how >> many cells it takes to delay 5 ns. (We'll just xor the ends and bring >> that out to a test point.) >> >John, >I've done option 2 before on a sine wave oscillator fed to an FPGA. I used >the delay element within some unbonded IOBs to get the delay. (Drive signal >out on O/P, get it back through I/P delay. NB. turn off DRC check in >bitgen.) I figured it would be more likely to carry on working with newer >versions of software. Each new version comes up with more fiendish ways to >remove delay chains! >Good luck, Syms. > The unbonded pad thing sounds slick. I argued to use a real pin in-and-out as the delay element, but certain stingy engineers around here are unwilling to give up one of their two available test points. JohnArticle: 99659
John Larkin wrote: > On Tue, 28 Mar 2006 08:55:50 +1200, Jim Granville >>Enable the schmitt option on the pin :) > > > Don't I wish! There is a programmable delay element in the IO block, > but it's probably a string of inverters, not an honest R-C delay, so > it likely can't be used to lowpass the edge. We're not sure. > > I wish they'd tell us a little more about the actual electrical > behavior of the i/o bits. I mean, Altera and Actel and everybody else > has snooped all this out already. > >> >>Since the issue is 'local', I'd fix it locally, and 2. sounds >>preferable. You know the CLK freq, so can choose the delay banding. > > > That's looking promising; we're testing that one now. Gotta figure how > many cells it takes to delay 5 ns. (We'll just xor the ends and bring > that out to a test point.) Yes, your main challenge will then be to persuade the tools to keep your delay elements... What is the pin-delay on the part - you could use that feature, enable it on your pin, drive another nearby pin(s) (non bonded?) and then use those as the S/R time-shutters. -jgArticle: 99660
Thank you! That actually makes sense - there's no need to keep multiple clock signals and then your sensitivity list shrinks down to two signals: process(reset, clk) mk wrote: > On 27 Mar 2006 13:21:20 -0800, "bobrics" <bobrics@gmail.com> wrote: > > ... > >MY_PROCESS: process(reset, clk, state) > > begin > ... > > elsif (rising_edge(clk) and state = 0) then > > > Remove the state from the dependency list and the elsif expression. > You don't need the state dependency. Move the state = 0 expression to > the statement which elsif evaluates. > > HTH.Article: 99661
Hi, I am getting the following warning: WARNING:Xst:1778 - Inout <AddrBus> is assigned but never used. My AddrBus is bi-directional and I am following example suggested here: http://groups.google.ca/group/comp.arch.fpga/msg/a2a5b1ec480bcbe1?dmode=source&hl=en I am writing to the bus outside of process. Why would I get this message? It looks like the signal is used. here is the code: architecture Behavioral of controller is begin ... ... AddrBus <= AddrOut1 when module_sel(0) = '1' else -- one-hot vector to select a module AddrOut2 when module_sel(1) = '1' else AddrOut3 when module_sel(2) = '1' else (others => 'Z'); ... ... end Behavioral;Article: 99662
bobrics wrote: > Hi, > > I am getting the following warning: WARNING:Xst:1778 - Inout <AddrBus> > is assigned but never used. My AddrBus is bi-directional and I am > following example suggested here: > http://groups.google.ca/group/comp.arch.fpga/msg/a2a5b1ec480bcbe1?dmode=source&hl=en > > I am writing to the bus outside of process. Why would I get this > message? It looks like the signal is used. > here is the code: > > architecture Behavioral of controller is > begin > ... > ... > AddrBus <= > AddrOut1 when module_sel(0) = '1' else -- one-hot vector to select a > module > AddrOut2 when module_sel(1) = '1' else > AddrOut3 when module_sel(2) = '1' else > (others => 'Z'); > ... > ... > end Behavioral; Is this portion in your top level entity? Or is a sub entity? -IsaacArticle: 99663
For now, this is my top entity, but there'll be something else higher in the hierarchy later on. Another entity will be using AddrBus for reading from it as well. For now, there's only writing implemented as I am accessing memory at specific location. Isaac Bosompem wrote: > bobrics wrote: > > Hi, > > > > I am getting the following warning: WARNING:Xst:1778 - Inout <AddrBus> > > is assigned but never used. My AddrBus is bi-directional and I am > > following example suggested here: > > http://groups.google.ca/group/comp.arch.fpga/msg/a2a5b1ec480bcbe1?dmode=source&hl=en > > > > I am writing to the bus outside of process. Why would I get this > > message? It looks like the signal is used. > > here is the code: > > > > architecture Behavioral of controller is > > begin > > ... > > ... > > AddrBus <= > > AddrOut1 when module_sel(0) = '1' else -- one-hot vector to select a > > module > > AddrOut2 when module_sel(1) = '1' else > > AddrOut3 when module_sel(2) = '1' else > > (others => 'Z'); > > ... > > ... > > end Behavioral; > > Is this portion in your top level entity? Or is a sub entity? > > -IsaacArticle: 99664
On Mon, 27 Mar 2006 14:21:16 -0800, John Larkin wrote: > On 27 Mar 2006 13:29:02 -0800, "Peter Alfke" <peter@xilinx.com> wrote: >>John Larkin wrote: >>>> >>> And the crystal oscillator turns out to be both fast and weak. On its >>> rise, it puts a step into the line of about 1.2 volts in well under 1 >>> ns, and doesn't drive to the Vcc rail until many ns later. >> >>Why would the signal round-trip delay be several ns, at 6" or 15 cm per >>ns one-way propagation on a pc-board ? The flat spot at 1.2 V is usually >>the result of a matched (weak) driver achieving half-amplitude driving >>the transmission line, and waiting for the reflection coming back from >>the far end. But "many nanoseconds ??? Peter Alfke > > Well, two maybe. Is two "many"? What with trace routing and capacitive pin > loading and vias and the pcb dielectric itself, we're talking velocities > well under half of c. The plateau is real as sin, viewed on a 500 MHz > scope with a fet probe. > I fear there may be no quick fix. The waveform you've described sounds almost exactly like what I've seen on a TDR (except, of course, at 6" rather than 8 feet :-) ) so I'm surmising that there's some transmission line mismatch that's giving you that nasty reflection. But impedance matching a clock line on an 8-layer board is way out of my league. )-; Good Luck! RichArticle: 99665
Jan Panteltje wrote: > On a sunny day (Mon, 27 Mar 2006 22:04:29 +0200) it happened Ben > Twijnstra > <btwijnstra@gmail.com> wrote in > <3bb06$442826db$d52e23a9$24513@news.chello.nl>: > >>Jan Panteltje wrote: >> >>> Altera (HELLO!!!!) still does not work from the Netherlands today >>> (monday), it did not work sunday either. >>> Neither does the IP 66.35.227.20 directly >> >>Strange. I in The Netherlands too and I haven had a single problem. What >>provider are you on? My trace goes from Chello to Level3 to savvis.net. >>Could be that your provider goes through a different route. >> >>Best regards, >> >> >>Ben > It is working now, from 1600h or so? > Not a provider, I have a direct line (direct-adsl KPN), webserver, ftp > server, mail server, all here too. > I *am* the ISP. Hmmmm... Chello first routes to Level3, then the traces converge in New York (your hop 7, my hop 13). It all seems to have depended on router configuration. I guess Savvis will have had a fewrather angry phone calls from Altera ;-) Best regards, Ben BTW: what are you paying for that direct ADSL line?Article: 99666
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >> > > The unbonded pad thing sounds slick. I argued to use a real pin > in-and-out as the delay element, but certain stingy engineers around > here are unwilling to give up one of their two available test points. > > John > I sent you some stuff from my Hotmail account. If your spam filter blocks it, let me know. Best, Syms.Article: 99667
On 2006-03-27, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > We have a perfect-storm clock problem. A stock 16 MHz crystal > oscillator drives a CPU and two Spartan3 FPGAs. > ... At Fpga1, > the clock has a nasty flat spot on its rising edge, just about halfway > up. And it screws up, of course. The last FPGA, at the termination, is > fine Got any spare interconnects between FPGA2 and FPGA1? A new bitstream could ignore the clock at FPGA1 and get it from FPGA2. -- Ben Jackson <ben@ben.com> http://www.ben.com/Article: 99668
"Ben Jackson" <ben@ben.com> wrote in message news:slrne2h2ga.2ulk.ben@saturn.home.ben.com... > On 2006-03-27, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> > wrote: >> We have a perfect-storm clock problem. A stock 16 MHz crystal >> oscillator drives a CPU and two Spartan3 FPGAs. >> ... At Fpga1, >> the clock has a nasty flat spot on its rising edge, just about halfway >> up. And it screws up, of course. The last FPGA, at the termination, is >> fine > > Got any spare interconnects between FPGA2 and FPGA1? A new bitstream > could ignore the clock at FPGA1 and get it from FPGA2. > > -- > Ben Jackson > <ben@ben.com> > http://www.ben.com/ Oooooohhhh, nice possibility here ! Great idea, Ben.Article: 99669
Thanks to all those providing these ideas. It occurs to me that I only need the optical bitstream to run at 2x rate - I don't need the whole FPGA design to run at the doubled rate. So any of these "clever/tricky" schemes could be isolated to just a small part of the design which makes them more palletable. I already need to implement a DPLL at the far end of the optical link so it may not require much more design time to use this technique also(although it will use up more FPGA logic resources than the other techniques). To answer Ralphs questions: The 22M clock is the xDSL chipsets local clock generated from a crystal so its fixed. The 8M clock generated by the xDSL PLL is its max. The PLL can generate nx64kHz but 8.192M is the upper limit. Thansks again. Regards Andrew Ralf Hildebrandt wrote: > Andrew FPGA wrote: > > Hi, > > We are developing a product that passes data between an xDSL interface > > and a proprietory optical interface. We are using a Spartan 3 FPGA. The > > xDSL chipset generates an 8.192MHz clock that is recovered from the DSL > > line. (The xDSL chipset uses a digital phase locked loop for this). The > > current FPGA design uses this clock internally, and uses it to clock > > the optical interface also. Single clock domain, nice. > ... > > A doubling of the clock frequency would be enough. Just > > the name of a technique would be enough to get me googling... > > If you don't need the doubled clock as an output, but want to operate at > the doubled frequency, you could use both clock edges. A way to get > fully synthesizable dual-edge behavior I've described in > <http://www.ralf-hildebrandt.de/publication/pdf_dff/pde_dff.pdf>. This > idea is not limited to just flipflops. You may also extend it easily to > dual-edge state machines. > > > > The xdsl chipset also has a local oscillator at 22MHz - but it just > > free runs of course...I could invisage a plesiosynchronous scheme where > > the optical link runs at 22MHz and I bit stuff to get the required data > > rate. But it feels too complex, overkill. And then I have to think more > > carefully about the optical link clock recovery at the far end. > > Does this oscillator run fixed at 22MHz or is it it's maximum and it is > modified by the PLL? If it is modified by the PLL, would it be an option > to let the PLL generate the doubled clock, divide it by two, feed it > back and synchronize this divided clock? > > > RalfArticle: 99670
On Mon, 27 Mar 2006 18:57:46 -0600, Ben Jackson <ben@ben.com> wrote: >On 2006-03-27, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >> We have a perfect-storm clock problem. A stock 16 MHz crystal >> oscillator drives a CPU and two Spartan3 FPGAs. >> ... At Fpga1, >> the clock has a nasty flat spot on its rising edge, just about halfway >> up. And it screws up, of course. The last FPGA, at the termination, is >> fine > >Got any spare interconnects between FPGA2 and FPGA1? A new bitstream >could ignore the clock at FPGA1 and get it from FPGA2. Yeah, that would work. I think we do have a few crossover lines, with 0 ohm jumper/resistor pads along the way! JohnArticle: 99671
Andrew FPGA wrote: > Thanks to all those providing these ideas. It occurs to me that I only > need the optical bitstream to run at 2x rate - I don't need the whole > FPGA design to run at the doubled rate. Do you need to provide both clock and data, or just a data stream, to the TX optical interface? If you need to provide the clock, can that portion of the optical interface be modified to accept an 8.192 MHz clock with 16.384 Mbps DDR data? Is the jitter performance of the 8.192 MHz clock sufficient for your system link budget at a 2x data rate? > To answer Ralphs questions: > The 22M clock is the xDSL chipsets local clock generated from a crystal > so its fixed. The 8M clock generated by the xDSL PLL is its max. The > PLL can generate nx64kHz but 8.192M is the upper limit. > Is the 8.192 Mhz clock close to 50% duty cycle? Is the chipset datsheet available online? BrianArticle: 99672
i want to design the prototype board for spartan series FPGA which is least costly,for master serial mode of configuration i want to use PROM.I am looking for some through hole component like PLCC84 pin & PLCC 20 pin package.can u suggest me some.Article: 99673
PLCC stands for Plastic Leadless Chip Carrier, so it is NOT through-hole. But there are sockets that can convert PLCC to through-hole. Don't expect any modern devices in this package. Too big and too few pins for today's designs. The world changes, not always in the direction one likes... Peter AlfkeArticle: 99674
I got a little further into poking around with the opensparc code. I realized that I did not have any defines enabled for any of the cores to synthesize. I enabled 1 core and the xst sucked up all the memory my system had and then failed for lack of memory. So I guess if I am going to play with this anymore I need to up my system memory from 1G to 4G memory at least. For now I will just have to stick to openrisc experimenting. Shyam wrote: > javaguy11111@gmail.com wrote: > > I have been playing around with opensparc some using xst. I did manage > > to get a build without errors, but since I did not have a clock defined > > everything got optimized away. So no gate counts. One thing I did > > learn is to not import the files using Project Navigator. It just locks > > it up. > > > > A build using an xst script worked. There was one file that had a > > function defined that was causing xst to fail. However when I removed > > it I got no more complaints. > > > > It may not be possible to synthesize with 8 cores, but I thought I saw > > something in the docs about being to specify fewer cores. > > > > I will probably play around with it some more as free time allows and > > see how far I can get with it. > > > > OK, Thanks very much for the information. I also tried to synthesize > using Altera's Quartus II but gave up when I got many errors. Thought I > would try it out with DC first and see what I get. > > -Shyam
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