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 27 Mar 2006 08:24:57 -0800, "Dominic" <dominicwalkes@yahoo.com> wrote: >Has anyone ever written a variable width fifo? I would like to have a >fifo that accepts a 32-bit input and reads out a 16 bit output. Do it all the time. This is particularly easy with Xilinx block rams as they can have different widths on each port. As always, you have to keep your wits about you when designing the pointers & flag logic. Regards, AllanArticle: 99626
Tommy At the moment it is penciled in for the 500E part as it is most available and for the target market that we going for but it might be made available in a footprint that could accomodate the 1600E. However we are still playing with some concepts on this board that even for us are different. We do have some targets in mind but even for us it is a bit early to talk about these publically. Multiple devices are also in the envelope of what we are considering but that might be Tarfessock2. It's on the roadmap too but I have not put a date on it yet before anyone asks. As always if you have a serious commercial application it is worth talking to us offline as to what we can do. We do a lot spin-off designs of the boards from our development board products ranging from simple connector changes to radical changes that are barely recognisable as the origonal board. Sometimes it goes the other way like MINI-CAN and it spins out from a customer requirement into a development board. Anyway enough my commercial spin, Philip will be telling me off in his best Aussie voice, so offline if you want more data. Any of the Enterpoint's public email address can be used to contact me if marked for my attention. John Adair Enterpoint Ltd. - Home of UAP. Enterpoint's University Access Program. http://www.enterpoint.co.uk "Tommy Thorn" <foobar@nowhere.void> wrote in message news:44281847$0$58042$742ec2ed@news.sonic.net... > John Adair wrote: >> Well we might beat them out with Tarfessock1 after all then. >> >> John Adair >> Enterpoint Ltd. - Soon to be Home of Tarfessock1. The PCMCIA Spartan-3E >> Development Board. > > Can you share a bit of the specs? If it has an XC3S1600E and megabytes of > external storage then I'm interested. > > TommyArticle: 99627
Allan Herriman wrote: > It appears openSparc Verilog is written to target an ASIC, not an > FPGA. Whilst it might be possible to get it to compile and even fit > into an FPGA, the performance would probably not be stunning. > > In that sense, a different soft-cpu designed to be used on an FPGA > would probably be better. ---It's interesting to see "SoftCores for Multicore FPGA implementations" listed as an example research area that can be explored with OpenSPARC technology, at http://opensparc.sunsource.net/nonav/research.html. Not sure what area/delay/power one would end up with if this core is implemented on an FPGA as is. Perhaps certain enhancements/simplifications may be carried out to the present core in order to make it useful within an FPGA. Since they have released a variety of hardware/software tools (and their sources) I guess it becomes possible to study the performance impact of any architectural modifications. Has anybody already started working on implementing this on an FPGA? I would be very interested to know the results.I want to try to do this but am presently hampered because I don't have Synopsys DC (which is the recommended synthesis environment) appropriately set up. Thanks, ShyamArticle: 99628
Now it works fine Thanks for the help Greets MichielArticle: 99629
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. KPN has wxs.nl doing the work: traceroute to altera.com (66.35.227.20), 30 hops max, 40 byte packets 1 10.0.0.138 (10.0.0.138) 0.493 ms 0.523 ms 0.384 ms 2 195.190.249.104 (195.190.249.104) 6.125 ms 6.094 ms 6.244 ms 3 iawxsrt-dc2-bb21b.wxs.nl (213.75.1.213) 9.540 ms 9.362 ms 9.636 ms 4 acr2-so-6-0-0.Amsterdamamx.savvis.net (208.174.49.177) 9.431 ms 10.412 ms 9.483 ms 5 acr1-ae0.Amsterdamamx.savvis.net (208.174.48.89) 10.888 ms 10.869 ms 10.649 ms 6 bcs1-so-1-2-0.Londonlnx.savvis.net (204.70.193.146) 18.299 ms 18.848 ms 18.332 ms 7 bcs2-so-0-0-0.NewYork.savvis.net (204.70.192.121) 96.990 ms 96.735 ms 96.956 ms 8 bcs2-so-4-0-0.Washington.savvis.net (204.70.192.1) 93.815 ms 93.142 ms 92.341 ms 9 bcs1-so-7-0-0.Washington.savvis.net (204.70.192.33) 96.560 ms 96.722 ms 97.368 ms 10 dcr1-so-3-0-0.Atlanta.savvis.net (204.70.192.53) 106.457 ms 107.380 ms 107.569 ms 11 dcr1-so-3-2-0.dallas.savvis.net (204.70.192.82) 130.313 ms 132.094 ms 131.095 ms 12 dcr2-so-2-0-0.LosAngeles.savvis.net (204.70.192.86) 158.809 ms 185.870 ms 158.541 ms 13 dcr1-as0-0.LosAngeles.savvis.net (204.70.192.117) 161.903 ms 162.221 ms 162.413 ms 14 dcr2-so-2-0-0.SanFranciscosfo.savvis.net (204.70.192.90) 166.046 ms 166.140 ms 166.398 ms 15 bhr1-pos-0-0.SantaClarasc8.savvis.net (208.172.156.198) 168.992 ms 168.039 ms 168.155 ms 16 csr11-ve240.santaclarasc8.savvis.net (66.35.194.82) 442.153 ms 168.002 ms 168.160 ms 17 66.35.226.219 (66.35.226.219) 170.399 ms 172.133 ms 169.886 ms etc... Groeten JanArticle: 99630
Hi everyone, I am building a OPB peripheral. I used Create - Import Peripheral wizard from EDK 7.1 (using opb_ipif_v2_00_h). I selected Master Support, no DMA, no FIFO, 8x32 bit registers and 4 interrupts. Most of the things works fine, just Master Support gives me a lot of trouble. I have selected only one local slave register for data (on which Asyncronous FIFO will be connected) - as a source address for Master data transfer. The destination address is DDR address. I want to use burst transfer with incrementing ONLY destination address, while source address must remain constant (similar to DMA's SINC and DINC flags). Every time I use burst transfer BOTH addresses are incremented, while single beat (4 bytes) transfer works OK, but with much lower transfer speed. I modified the wizard generated "Master model functionality" in user_logic.vhd template to correct this issue, but unsucessfull. I commented the lines where addresses are incremented, but the IPIF seems to overrides my settings - addresses are incremented anyway. Does anyone knows the solution for my problem? Thnx, GuruArticle: 99631
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, BenArticle: 99632
> I don't think it's a block. It sounds like a messed up BGP announcement. No problem from the UK academic network either. Sounds indeed more like a problem with the Internet, rather than with Altera's web server.Article: 99633
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. Adding termination at Fpga2 helps a little, but Fpga1 still glitches now and then. If it's not truly double-clocking then the noise margin must be zilch during the plateau, and the termination can't help that. One fix is to replace the xo with something slower, or kluge a series inductor, 150 nH works, just at the xo output pin, to slow the rise. Unappealing, as some boards are in the field, tested fine but we're concerned they may be marginal. So we want to deglitch the clock edges *in* the FPGAs, so we can just send the customers an upgrade rom chip, and not have to kluge any boards. Some ideas: 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz maybe, and use the second flop's output as the new clock source. A Xilinx fae claims this won't work. As far as we can interpret his English, the DCM is not a true PLL (ok, then what is it?) and will propagate the glitches, too. He claims there *is* no solution inside the chip. 2. Run the clock in as a regular logic pin. That drives a delay chain, a string of buffers, maybe 4 or 5 ns worth; call the input and output of the string A and B. Next, set up an RS flipflop; set it if A and B are both high, and clear it if both are low. Drive the new clock net from that flop. Maybe include a midpoint tap or two in the logic, just for fun. 3. Program the clock logic threshold to be lower. It's not clear to us if this is possible without changing Vccio on the FPGAs. Marginal at best. Any other thoughts/ideas? Has anybody else fixed clock glitches inside an FPGA? JohnArticle: 99634
Hello, I'm not sure synthesis tools exist for SpecC, since it was originaly dedicated to system specification. SystemC can be a good choice if you intend to write new modules. It is an IEEE standard and is widely supported in HW simulation tools and progressively by some HW synthesis tools too. Actually, the "synthesis" tools I've tested so far (Synopsys -discontinued- and Prosilog compiler) translate SystemC to synthesisable VHDL or Verilog. Celoxica also support it but I've not tested their compiler yet. Generaly, the results are very good if your SystemC code is written in an "hardware-oriented" style. Concerning simulation, common commercial products (Modelsim, NC-Sim and probably VCS-MX too) support designs with modules written in the 3 langages mixed toguether thanks to component wrappers. Well, it's true that SystemC is easier to use from the syntax point of view when you're used to C++ langage. But you have to keep in mind that if you code your modules in a software-like style, you take the risk of obtaining inefficient and buggy hardware. Knowledge of hardware-oriented coding style is still required to obtain good results. In particular, some basic concepts must be mastered like the difference between signals and variables, usage of for loops, etc.. Last bu not least, you'll probably have to debug the VHDL code anyway, so it should be usefull to have some langage knowledge. Best regards Manu The Other Guy a écrit : > Hi, > > I apologize if I sound like I don't know what I'm talking about. I am > primarily a C programmer, but I am involved in a hardware design project > at the moment, and would like some advice. > > The 'proof of concept' phase of the development is being done in VHDL, > with a processor core implementing some of the features. As the features > will be incomplete when the project is handed over to me (due to time > constraints), I will need to make modifications to the hardware design. > > My preference is to develop in C for now as the functionality required > is easily implemented in C, while learning VHDL is going to take quite > some time. > > I've been investigating C-based languages, in particular SystemC, SpecC, > and FpgaC. SystemC is based on C++ classes, and FpgaC is still rather > incomplete. SpecC looks like a good option, but I can't find any details > about how the output can be used to programme a FPGA. Knowing not all > vendor software is compatible, is SpecC suitable for this purpose? > > My second question surrounded the mixing of languages. Is it possible > for me to use SpecC or another language, while still making use of the > VHDL code that has already been written and tested? > > Thanks, > > The Other GuyArticle: 99635
You also aren't going to get an accurate FPGA gate count after ASIC synthesis. If I synthesized this OpenSparc processor with DC, targetted a certain ASIC cell library and got a count of 1 million gates for instance, that might be resynthesized for a Virtex2 part and be 2 million gates. Just as an example, I have no clue about these numbers except FPGA gates will be more.Article: 99636
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> schrieb im Newsbeitrag news:6jgg221p6iuffrbbb6dtml39fn3u9sdu4k@4ax.com... > 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. > > Adding termination at Fpga2 helps a little, but Fpga1 still glitches > now and then. If it's not truly double-clocking then the noise margin > must be zilch during the plateau, and the termination can't help that. > > One fix is to replace the xo with something slower, or kluge a series > inductor, 150 nH works, just at the xo output pin, to slow the rise. > Unappealing, as some boards are in the field, tested fine but we're > concerned they may be marginal. > > So we want to deglitch the clock edges *in* the FPGAs, so we can just > send the customers an upgrade rom chip, and not have to kluge any > boards. > > Some ideas: > > 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock > as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz > maybe, and use the second flop's output as the new clock source. A > Xilinx fae claims this won't work. As far as we can interpret his > English, the DCM is not a true PLL (ok, then what is it?) and will > propagate the glitches, too. He claims there *is* no solution inside > the chip. > > 2. Run the clock in as a regular logic pin. That drives a delay chain, > a string of buffers, maybe 4 or 5 ns worth; call the input and output > of the string A and B. Next, set up an RS flipflop; set it if A and B > are both high, and clear it if both are low. Drive the new clock net > from that flop. Maybe include a midpoint tap or two in the logic, just > for fun. > > 3. Program the clock logic threshold to be lower. It's not clear to us > if this is possible without changing Vccio on the FPGAs. Marginal at > best. > > > Any other thoughts/ideas? Has anybody else fixed clock glitches inside > an FPGA? > > John > you can run a genlocked NCO clocked from in-fabric onchip oscillator. your internal recovered clock will have jitter +-1 clock period of the ring oscillator (what could be as high as about 370MHz in S3), you might need a some sync logic that will ensure the 16mhz clock edges are only used to adjust the NCO. using DLL/DDM possible want work as the FAE said, DCMs require decent clock to operate. AnttiArticle: 99637
Seems to be up again , from NZ... >Article: 99638
John Larkin wrote: > Some ideas: > > 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock > as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz > maybe, and use the second flop's output as the new clock source. A > Xilinx fae claims this won't work. As far as we can interpret his > English, the DCM is not a true PLL (ok, then what is it?) and will > propagate the glitches, too. He claims there *is* no solution inside > the chip. > > 2. Run the clock in as a regular logic pin. That drives a delay chain, > a string of buffers, maybe 4 or 5 ns worth; call the input and output > of the string A and B. Next, set up an RS flipflop; set it if A and B > are both high, and clear it if both are low. Drive the new clock net > from that flop. Maybe include a midpoint tap or two in the logic, just > for fun. > > 3. Program the clock logic threshold to be lower. It's not clear to us > if this is possible without changing Vccio on the FPGAs. Marginal at > best. > > > Any other thoughts/ideas? Has anybody else fixed clock glitches inside > an FPGA? Enable the schmitt option on the pin :) Sorry... 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. -jgArticle: 99639
Is it not possible to use DC and target an FPGA library, say Altera's Stratix family? I was thinking that's possible. Or does one need to use DC FPGA? Thanks, ShyamArticle: 99640
On Mon, 27 Mar 2006 22:35:31 +0200, "Antti Lukats" <antti@openchip.org> wrote: >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> schrieb im >Newsbeitrag news:6jgg221p6iuffrbbb6dtml39fn3u9sdu4k@4ax.com... >> 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. >> >> Adding termination at Fpga2 helps a little, but Fpga1 still glitches >> now and then. If it's not truly double-clocking then the noise margin >> must be zilch during the plateau, and the termination can't help that. >> >> One fix is to replace the xo with something slower, or kluge a series >> inductor, 150 nH works, just at the xo output pin, to slow the rise. >> Unappealing, as some boards are in the field, tested fine but we're >> concerned they may be marginal. >> >> So we want to deglitch the clock edges *in* the FPGAs, so we can just >> send the customers an upgrade rom chip, and not have to kluge any >> boards. >> >> Some ideas: >> >> 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock >> as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz >> maybe, and use the second flop's output as the new clock source. A >> Xilinx fae claims this won't work. As far as we can interpret his >> English, the DCM is not a true PLL (ok, then what is it?) and will >> propagate the glitches, too. He claims there *is* no solution inside >> the chip. >> >> 2. Run the clock in as a regular logic pin. That drives a delay chain, >> a string of buffers, maybe 4 or 5 ns worth; call the input and output >> of the string A and B. Next, set up an RS flipflop; set it if A and B >> are both high, and clear it if both are low. Drive the new clock net >> from that flop. Maybe include a midpoint tap or two in the logic, just >> for fun. >> >> 3. Program the clock logic threshold to be lower. It's not clear to us >> if this is possible without changing Vccio on the FPGAs. Marginal at >> best. >> >> >> Any other thoughts/ideas? Has anybody else fixed clock glitches inside >> an FPGA? >> >> John >> > >you can run a genlocked NCO clocked from in-fabric onchip oscillator. your >internal recovered clock will have jitter +-1 clock period of the ring >oscillator (what could be as high as about 370MHz in S3), you might need a >some sync logic that will ensure the 16mhz clock edges are only used to >adjust the NCO. Nice idea. But I do need the 16 MHz to be long-term correct, although duty cycle and edges could jitter a bit and not cause problems. So I could build an internal ring oscillator and use that to resync the incoming 16 MHz clock (dual-rank d-flops again) on the theory that the input glitches will never last anything like the 300-ish MHz resync clock period. And that's even easier. Thanks for the input, JohnArticle: 99641
Jan Decaluwe wrote: > > As for the SPARC code, it seems like an extreme example. I wouldn't > call this RTL code. It's more like a manually generated technology- > independent netlist. For example, they don't even use flip-flop > inference. And they do have excessive hierarchy. > > I suspect that it should be possible to gain at least an order > of magnitude in terms of lines of code by using a proper RTL > style. And the synthesis results might be better. (Excessive > hierarchy tends to yield suboptimal synthesis results). > That's what I was afraid of. Structural netlists are useful for transmitting an intact design without revealling the "real source" code. That code is what you need if you really want to understand or modify the design. This is like compiling a C file into a linked assembler file and releasing that as "open source". You can create an executable but that's about it. Thanks but no thanks. John EatonArticle: 99642
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> schrieb im Newsbeitrag news:0gkg22t80t0838e2odqlfet8h3pror7np4@4ax.com... > On Mon, 27 Mar 2006 22:35:31 +0200, "Antti Lukats" > <antti@openchip.org> wrote: > >>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> schrieb im >>Newsbeitrag news:6jgg221p6iuffrbbb6dtml39fn3u9sdu4k@4ax.com... >>> 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. >>> >>> Adding termination at Fpga2 helps a little, but Fpga1 still glitches >>> now and then. If it's not truly double-clocking then the noise margin >>> must be zilch during the plateau, and the termination can't help that. >>> >>> One fix is to replace the xo with something slower, or kluge a series >>> inductor, 150 nH works, just at the xo output pin, to slow the rise. >>> Unappealing, as some boards are in the field, tested fine but we're >>> concerned they may be marginal. >>> >>> So we want to deglitch the clock edges *in* the FPGAs, so we can just >>> send the customers an upgrade rom chip, and not have to kluge any >>> boards. >>> >>> Some ideas: >>> >>> 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock >>> as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz >>> maybe, and use the second flop's output as the new clock source. A >>> Xilinx fae claims this won't work. As far as we can interpret his >>> English, the DCM is not a true PLL (ok, then what is it?) and will >>> propagate the glitches, too. He claims there *is* no solution inside >>> the chip. >>> >>> 2. Run the clock in as a regular logic pin. That drives a delay chain, >>> a string of buffers, maybe 4 or 5 ns worth; call the input and output >>> of the string A and B. Next, set up an RS flipflop; set it if A and B >>> are both high, and clear it if both are low. Drive the new clock net >>> from that flop. Maybe include a midpoint tap or two in the logic, just >>> for fun. >>> >>> 3. Program the clock logic threshold to be lower. It's not clear to us >>> if this is possible without changing Vccio on the FPGAs. Marginal at >>> best. >>> >>> >>> Any other thoughts/ideas? Has anybody else fixed clock glitches inside >>> an FPGA? >>> >>> John >>> >> >>you can run a genlocked NCO clocked from in-fabric onchip oscillator. your >>internal recovered clock will have jitter +-1 clock period of the ring >>oscillator (what could be as high as about 370MHz in S3), you might need a >>some sync logic that will ensure the 16mhz clock edges are only used to >>adjust the NCO. > > Nice idea. But I do need the 16 MHz to be long-term correct, although > duty cycle and edges could jitter a bit and not cause problems. So I > could build an internal ring oscillator and use that to resync the > incoming 16 MHz clock (dual-rank d-flops again) on the theory that the > input glitches will never last anything like the 300-ish MHz resync > clock period. And that's even easier. > > Thanks for the input, > > John > the gen locked NCO would be cycle accurate too, ok I meant you would fine adjust the NCO to track the 16mhz but given and higher clock you can build different deglitch circuitries without the need of an full digital PLL technique anttiArticle: 99643
On Tue, 28 Mar 2006 08:55:50 +1200, Jim Granville <no.spam@designtools.co.nz> wrote: >John Larkin wrote: > >> Some ideas: >> >> 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock >> as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz >> maybe, and use the second flop's output as the new clock source. A >> Xilinx fae claims this won't work. As far as we can interpret his >> English, the DCM is not a true PLL (ok, then what is it?) and will >> propagate the glitches, too. He claims there *is* no solution inside >> the chip. >> >> 2. Run the clock in as a regular logic pin. That drives a delay chain, >> a string of buffers, maybe 4 or 5 ns worth; call the input and output >> of the string A and B. Next, set up an RS flipflop; set it if A and B >> are both high, and clear it if both are low. Drive the new clock net >> from that flop. Maybe include a midpoint tap or two in the logic, just >> for fun. >> >> 3. Program the clock logic threshold to be lower. It's not clear to us >> if this is possible without changing Vccio on the FPGAs. Marginal at >> best. >> >> >> Any other thoughts/ideas? Has anybody else fixed clock glitches inside >> an FPGA? > >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. >Sorry... > >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.) JohnArticle: 99644
My understanding is that when you purchase the development tools you are entering into an agreement with Altera to use their software with only their devices. When you generate a NIOS II design from SOPC Builder the files are suppose to be encrypted. They have a device called HardCopy that is suppose to be a compromise for an ASIC device. The rep I was talking to said that there were exceptions but they were negoiated on a contract to contract basis.Article: 99645
Hi,
I have a problem synthesizing a VHDL code. The error is the following:
ERROR:Xst:827 - "C:/Xilinx/work/MYPROJECT/projectfile.vhd" line 134:
Signal codeLen<25> cannot be synthesized, bad synchronous description.
The answer record # 14047: XST - "ERROR:Xst:827 suggests using clock
events in the topmost IF statement, which I am doing (The synchronous
element description is based on the 'event VHDL attribute. In order for
XST to infer a synchronous element, the 'event VHDL attribute must be
present in the topmost "IF" statement of your process. Furthermore,
there should be no embedded 'event statements within a process.)
Here is the suggested example:
synchronous_description : process (clk, reset) is begin
if reset = '1' then -- asynchronous reset
q <= '0'; -- you can have embedded if statements if you need to
elsif clk'event and clk = '1' then -- still the topmost if statement
q <= d; -- you can put your case statements here or
end if; -- embed more if statements but not
end process; -- any more 'event statements
Here is my code. Please let me know if you see any problems.
here DataIn is 31 downto 0
CODELEN_WIDTH is 32, so codeLen is 31 downto 0 as well.
MY_PROCESS: process(reset, clk, state)
begin
if (reset = '1') then
codeLen <= (others => '0');
ReadDone <= '0';
elsif (rising_edge(clk) and state = 0) then
if (attr_byte_counter < ATTR_HEADER_LEN_BYTES) then
-- some other signal assignments
if (attr_byte_counter = 0) then
ReadDone <= '0';
elsif (attr_byte_counter = 1) then
maxLocals <= DataIn(DATAIN_WIDTH-1 downto DATAIN_WIDTH/2);
codeLen(CODELEN_WIDTH-1 downto CODELEN_WIDTH/2) <=
DataIn(DATAIN_WIDTH/2-1 downto 0);
ReadDone <= '0';
elsif (attr_byte_counter = 2) then
codeLen(CODELEN_WIDTH/2-1 downto 0) <= DataIn(DATAIN_WIDTH-1
downto DATAIN_WIDTH/2);
-- the rest of DataIn bits are
ignored
ReadDone <= '1';
else -- do nothing
end if;
else
end if;
end process;
Article: 99646"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:6jgg221p6iuffrbbb6dtml39fn3u9sdu4k@4ax.com... > 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. > > Adding termination at Fpga2 helps a little, but Fpga1 still glitches > now and then. If it's not truly double-clocking then the noise margin > must be zilch during the plateau, and the termination can't help that. > > One fix is to replace the xo with something slower, or kluge a series > inductor, 150 nH works, just at the xo output pin, to slow the rise. > Unappealing, as some boards are in the field, tested fine but we're > concerned they may be marginal. > > So we want to deglitch the clock edges *in* the FPGAs, so we can just > send the customers an upgrade rom chip, and not have to kluge any > boards. > > Some ideas: > > 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock > as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz > maybe, and use the second flop's output as the new clock source. A > Xilinx fae claims this won't work. As far as we can interpret his > English, the DCM is not a true PLL (ok, then what is it?) and will > propagate the glitches, too. He claims there *is* no solution inside > the chip. > > 2. Run the clock in as a regular logic pin. That drives a delay chain, > a string of buffers, maybe 4 or 5 ns worth; call the input and output > of the string A and B. Next, set up an RS flipflop; set it if A and B > are both high, and clear it if both are low. Drive the new clock net > from that flop. Maybe include a midpoint tap or two in the logic, just > for fun. > > 3. Program the clock logic threshold to be lower. It's not clear to us > if this is possible without changing Vccio on the FPGAs. Marginal at > best. > > > Any other thoughts/ideas? Has anybody else fixed clock glitches inside > an FPGA? > > John Kludge the boards. The DCM is based on tapped delay lines - the old "Delay Locked Loop" with added functionality. If you have a glitch go in, a glitch will come out. A bad clock is a bad clock. You *might* be able to seriously mess with the signal by using the KEEPER attribute to push the Spartan3 I/O into a schmidt-like behavior but it isn't a good fix, just a punt. You might also try backdriving the pin with a 2mA setting (*not* 2mA at opposite rail - check the IBIS model) to push the threshold up or down, but again - this is a mess. It's much better to change the board; my own recommendation is to change the oscillator to something with some strength.Article: 99647
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 AlfkeArticle: 99648
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. Shyam wrote: > Allan Herriman wrote: > > > It appears openSparc Verilog is written to target an ASIC, not an > > FPGA. Whilst it might be possible to get it to compile and even fit > > into an FPGA, the performance would probably not be stunning. > > > > In that sense, a different soft-cpu designed to be used on an FPGA > > would probably be better. > > ---It's interesting to see "SoftCores for Multicore FPGA > implementations" listed as an example research area that can be > explored with OpenSPARC technology, at > http://opensparc.sunsource.net/nonav/research.html. Not sure what > area/delay/power one would end up with if this core is implemented on > an FPGA as is. Perhaps certain enhancements/simplifications may be > carried out to the present core in order to make it useful within an > FPGA. Since they have released a variety of hardware/software tools > (and their sources) I guess it becomes possible to study the > performance impact of any architectural modifications. > > Has anybody already started working on implementing this on an FPGA? I > would be very interested to know the results.I want to try to do this > but am presently hampered because I don't have Synopsys DC (which is > the recommended synthesis environment) appropriately set up. > > Thanks, > ShyamArticle: 99649
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.
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