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
"Adrian" <g9731642@campus.ru.ac.za> wrote in message news:ee734b3.-1@WebX.sUN8CHnE... > Hi, > > I'm using a programmable clock which has an accuracy of 1 part per million. i.e. I can set f = 1.000000 MHz. However, I need a clock with a resolution of 1 part per billion ie. f can be set to 1.000000000 MHz and does not vary over a period of at least 5 minutes. > > Is there anything I can add to my FPGA design to achieve this? Clock will be running at approximately 32MHz. > maybe a better clock 8-) > thanks > adrianArticle: 36901
Petter Gustad <newsmailcomp1@gustad.com> writes: > In case somebody is struggling with a not-internet-exporer-for-windows > web browser (like myself, using Opera under Linux) to download WebPack > - Here is how you can download it using wget: > > wget --http-user USER --http-passwd PASS http://www.xilinx.com/webpack/41wp2/WebPACK_41wp20_full_installer.exe > > Where USER is your Xilinx registered username and PASS is your > selected password. or even wget http://USER:PASS@www.xilinx.com/webpack/41wp2/WebPACK_41wp20_full_installer.exe I wonder how much money they spent developing that horrible navigation system? It's almost as if their intent was to prevent people from downloading the software.Article: 36902
Ray Andraka <ray@andraka.com> wrote: > For Virtex/VIrtexE, you can use a BEL constraint to place an element > within the F or G LUTs, the X or Y flip-flops or the F or G xorcy gate. > attribute BEL:string; > attribute BEL of U1: label is "F"; > attribute BEL of U2: label is "G"; > attribute BEL of U3: label is "FFX"; > attribute BEL of U4: label is "FFY"; > attribute BEL of U5: label is "XORF"; > attribute BEL of U6: label is "XORG"; I got it work. Thanks very much! ---- BrittleArticle: 36903
Hi everyone
I use synplicity 6.2 synthesis my design, after synthesis, in the
report, I found an strange line that report two clock, one is a
explict specified "clock",the other is "system", what this means?an
wrong with my deign?
as following
##### START TIMING REPORT #####
Performance Summary
*********************
Requested Estimated Requested Estimated
Clock Frequency Frequency Period Period
Slack
------------------------------------------------------------------------
System 85.0 MHz 173.5 MHz 11.8 5.8 6.0
clock 85.0 MHz 47.6 MHz 11.8 21.0
-9.3
========================================================================
Article: 36904That is what I was looking for. Thank you very much. "Wolfgang Loewer" <wolfgang.loewer@elca.de> wrote in message news:<9tlqq5$fuu$07$1@news.t-online.com>... > Naming the busses should work. > You can download a simple example from: > > http://www.elca.de/downloads/bus_test.zip > > - Wolfgang > http://www.elca.de > > "Crni Gorac" <cgorac@yahoo.com> schrieb im Newsbeitrag > news:cb2002fc.0111220955.1033a5cb@posting.google.com... > > Am using Altera Quartus II Web edition for some simple designs for my > > students. My question is: how to fork bus in BDF file using this tool? > > For example, I'm trying to use 2 4-bit adders to create 8-bit adder > > and I would like to separate op0[7..0] input to op0[3..0] input of > > low-nibbles 4-bit adder and op0[3..0] input of high-nibbles 4-bit > > adder. > > > > Thanks.Article: 36905
Jas <spammeanddie_coach.ent@xtra.co.nz> ÐÉÛÅÔ × ÓÏÏÂÝÅÎÉÉ:DcfK7.33$u46.42511@news.xtra.co.nz... > Does anyone know of software to convert AHDL to VHDL ? > Xilinx xport.exe AlexeyArticle: 36906
Well, OK ... Let's try this. We have a data stream that has to be sampled at 120 MHz, assembled into words and shoved into an external DRAM. The DRAM is small (256Kx16) and the data will be assembled and then registered as words before being pipelined off into the RAM. States of the fast end of the counter have to be decoded in order to synchronize the operation with the RAM, and the MSB of the counter is a "DONE" bit. When the counter is reset, it runs until the msb, used as the count enable, goes true. That's a 22-bit counter ... Not terribly long, but long enough. I suppose this could be done as 3-bit counter and a 19-bit counter, but, either way, it's painful. The DRAM access has to be done in short (page-mode) bursts, which is why the synchronization of the decoding of the lower 3-bit section of the counter is critical. How close to the required 120 MHz can this counter be made to go in an FPGA with 5-volt-tolerant I/O? It's got to be synchronous and the sequence has to be monotonic, so the same counter will be useable to accomplish refresh as required. LFSR's don't produce that sort of sequence. What other alternatives are there? Dick On Sun, 28 Oct 2001 03:27:33 GMT, Peter Alfke <palfke@earthlink.net> wrote: >I think this discussion has gone too abstract. >What is a reasonable max counter length? >64 bits, 80 bits, 100 bits, 140 bits? > >Who wants to count 100 MHz until the universe has frozen over a thousand >times? >There has to be some reason for all this. LFSRs are great as random >number generators. Detecting zero is reasonably easy, but adds junk. So >does arbitrary presetting... >The conventional binary ripple-carry structure supported in good FPGAs >is sufficiently compact and fast for all but the most exotic purposes. > >Peter Alfke > > >glen herrmannsfeldt wrote: > >> Ray Andraka <ray@andraka.com> writes: >> >> >How long is *really long* ? As I pointed out, 1 CLB worth of LFSRs >> >gets you a period of over 2000 years with a 100 MHz clock. >> >The single LFSR actually gets more efficient as you increase its >> >length, since the termnal count only grows at log2(N) and the LFSR >> >grows at a little less than 1/17 that rate. Cascading 2 identical >> >LFSRs gets you the same effect as doubling the length of a single >> >LFSR, so it is more expensive. Cascading different lenght LFSRs, >> >however may give you better granularity in your selection of period. >> >> Well, I said really really long. >> >> I don't know Virtex so well, so I don't know which mode you use >> to do this. Does it include the feedback taps in that one CLB? >> Can you select any feedback taps that you want? >> >> So you have a 64 bit LFSR to count your 2000 years, and need >> a 6 bit counter to count the 64 successive zeroes. The suggestion >> was to use a LFSR counter to count those zeroes, though, yes, >> there might be better ways to count to 64. >> >> As you mention, two LFSR's with different periods could be run >> in parallel and then detect the simultaneous zero of the two. >> With only one more CLB you could get a 128 bit counter, and count >> for 3e22 years. >> >> How many CLB's does it take to make a complete LFSR counter? >> (Inlcuding the preset ROM and load logic for arbitrary counts?) >> >> -- glen >Article: 36907
> That's a 22-bit counter ... Not terribly long, but long >enough. I suppose this could be done as 3-bit counter and a 19-bit >counter, but, ... > >How close to the required 120 MHz can this counter be made to go in an >FPGA with 5-volt-tolerant I/O? You can make a counter as big as you want if you can tolerate some pipeline delays. I think carry-save is the magic word. The idea is to drop a FF into the carry chain every N steps, where N is small enough to meet your timing. Of course, that means the top of the counter is X cycles behind the bottom where X is the number of FFs you added. But that doesn't matter if you just need a pulse every x cycles. (If you are loading the counter you may have to adjust the constant.) I don't really understand your problem, but it sounds like you can live with (dance around) the pipeline complications. Your 3-19 split may be the easier way to do things. If you use the (registered) carry out of the bottom 3 bits as a clock enable for the top 19, you have 8 cycles for the carry to ripple through the 19 bit section. This has the same sort of complication - the bottom 3 bits are one step ahead of the top 19. But you can fix that by generating the clock enable a cycle early - when the bottom bits are 110 rather than 111. Look for some app notes. Maybe older ones. This was a more interesting problem when chips were slower. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 36908
Richard, Try a SpartanXL. In the highest speed grade it should reach to beyond 200MHz. I currently have a 16 bit synchronous counter running at 200MHz in a design. Theron Hicks Richard Erlacher wrote: > Well, OK ... Let's try this. > > We have a data stream that has to be sampled at 120 MHz, assembled > into words and shoved into an external DRAM. The DRAM is small > (256Kx16) and the data will be assembled and then registered as words > before being pipelined off into the RAM. States of the fast end of > the counter have to be decoded in order to synchronize the operation > with the RAM, and the MSB of the counter is a "DONE" bit. When the > counter is reset, it runs until the msb, used as the count enable, > goes true. That's a 22-bit counter ... Not terribly long, but long > enough. I suppose this could be done as 3-bit counter and a 19-bit > counter, but, either way, it's painful. The DRAM access has to be > done in short (page-mode) bursts, which is why the synchronization of > the decoding of the lower 3-bit section of the counter is critical. > > How close to the required 120 MHz can this counter be made to go in an > FPGA with 5-volt-tolerant I/O? It's got to be synchronous and the > sequence has to be monotonic, so the same counter will be useable to > accomplish refresh as required. LFSR's don't produce that sort of > sequence. What other alternatives are there? > > Dick > > On Sun, 28 Oct 2001 03:27:33 GMT, Peter Alfke <palfke@earthlink.net> > wrote: > > >I think this discussion has gone too abstract. > >What is a reasonable max counter length? > >64 bits, 80 bits, 100 bits, 140 bits? > > > >Who wants to count 100 MHz until the universe has frozen over a thousand > >times? > >There has to be some reason for all this. LFSRs are great as random > >number generators. Detecting zero is reasonably easy, but adds junk. So > >does arbitrary presetting... > >The conventional binary ripple-carry structure supported in good FPGAs > >is sufficiently compact and fast for all but the most exotic purposes. > > > >Peter Alfke > > > > > >glen herrmannsfeldt wrote: > > > >> Ray Andraka <ray@andraka.com> writes: > >> > >> >How long is *really long* ? As I pointed out, 1 CLB worth of LFSRs > >> >gets you a period of over 2000 years with a 100 MHz clock. > >> >The single LFSR actually gets more efficient as you increase its > >> >length, since the termnal count only grows at log2(N) and the LFSR > >> >grows at a little less than 1/17 that rate. Cascading 2 identical > >> >LFSRs gets you the same effect as doubling the length of a single > >> >LFSR, so it is more expensive. Cascading different lenght LFSRs, > >> >however may give you better granularity in your selection of period. > >> > >> Well, I said really really long. > >> > >> I don't know Virtex so well, so I don't know which mode you use > >> to do this. Does it include the feedback taps in that one CLB? > >> Can you select any feedback taps that you want? > >> > >> So you have a 64 bit LFSR to count your 2000 years, and need > >> a 6 bit counter to count the 64 successive zeroes. The suggestion > >> was to use a LFSR counter to count those zeroes, though, yes, > >> there might be better ways to count to 64. > >> > >> As you mention, two LFSR's with different periods could be run > >> in parallel and then detect the simultaneous zero of the two. > >> With only one more CLB you could get a 128 bit counter, and count > >> for 3e22 years. > >> > >> How many CLB's does it take to make a complete LFSR counter? > >> (Inlcuding the preset ROM and load logic for arbitrary counts?) > >> > >> -- glen > >Article: 36909
Hi everyone APEX20k400E SOPC board has three EPC2 for programing. QuartusII generates three corresponding .pof(as LED.pof,LED1.pof and LED2.pof) when compliling. Their correct order is LED,LED1 and LED2 when programing,but I use wrong order LED1,LED,LED2. And then QuartusII cannot find the EPC2 chain any longer . How to do with it?Thanks. I set jumpers to bypass EPC2 and program the APEX directly , and it works well. So I think that the .pof files with the wrong order configure the EPC2s false. Maybe I should erase the three EPC2. When I cannot scan the EPC2 chains with Quartus,how to erase them?Article: 36910
Dick, the way I understand this, you have a continuously running counter that sampels incoming data. Every 16 clock ticks you dump the assembled data wod into a DRAM ( why not SRAM, which would save you the fancy control and the refresh ? And in Virtex-II you could easily store it in the BlockRAMs inside...) Absolutely under all circumstances use a modern FPGA with dedicated carry, like e.g. Xilinx Spartan, Spartan XL, Spartan-II, Virtex, or Virtex-II. Depending on the family, the carry delay is between 50 and 100 ps per bit, so you should not have any difficulty with your 22 bits. But if you are very conservative, you can break the counter into a 4-bit front-end, decode its all-ones state (F), and use it as a count enable for the remaining 18 bits.This is all very easy, and is totally synchronous. It does not create any pipeline delay or other funnies. Your code is all binary, like you want it to be. Have fun! Peter Alfke, Xilinx Applications ============================ Richard Erlacher wrote: > Well, OK ... Let's try this. > > We have a data stream that has to be sampled at 120 MHz, assembled > into words and shoved into an external DRAM. The DRAM is small > (256Kx16) and the data will be assembled and then registered as words > before being pipelined off into the RAM. States of the fast end of > the counter have to be decoded in order to synchronize the operation > with the RAM, and the MSB of the counter is a "DONE" bit. When the > counter is reset, it runs until the msb, used as the count enable, > goes true. That's a 22-bit counter ... Not terribly long, but long > enough. I suppose this could be done as 3-bit counter and a 19-bit > counter, but, either way, it's painful. The DRAM access has to be > done in short (page-mode) bursts, which is why the synchronization of > the decoding of the lower 3-bit section of the counter is critical. > > How close to the required 120 MHz can this counter be made to go in an > FPGA with 5-volt-tolerant I/O? It's got to be synchronous and the > sequence has to be monotonic, so the same counter will be useable to > accomplish refresh as required. LFSR's don't produce that sort of > sequence. What other alternatives are there? > > Dick >Article: 36911
I am designing DDS using Core Generator When doing implementation for Spartan2, Virtex, there are net delay that cause it to have max freq of 47 Mhz, however I am planning to apply 100 MHz clock or more so that the DDS can output higher frequency --> Question: will DLL or frequency multiplier feature of Virtex 2 helps ? when I generate DDS with the same parameters, it keep gives me different # of LUTs, regs, primitives --- how come, and is it matter? Thanks a lot in advance ennyArticle: 36912
I would be much obliged to learn for your experience with the ALTERA's
Mercury CDR using the M1GXCVR core. we intend to use it in a new project for
800 Mbps links.
thank you in advance.
--
yours -
Arie Z.
============================================
Arie Zychlinski
R&D Consulting & Development
P.O.Box 536
Kfar-Saba 44104
ISRAEL
Mobile: 972-58-320230
Phone: W: 972-9-7673074 H: 972-9-7658268
E-Mail: ariez@attglobal.net
===========================================
Article: 36913Here are some observations from my not-so-impartial viewpoint: 1. The Altera clock recovery requires a specialized training sequence. 2. The claim that it eliminates the need for balanced pc-bord trace length is somewhat strange, since the granularity of the clocking scheme is 300 ps at best. That is equivalent to about 2 inches or 5 cm trace length. For any of the more realistic smaller differences in trace length, this adaptive per-bit clocking scheme offers no advantage. 3. And finally, Altera makes bogus claims about LVDS power consumption, where they quote not the consumed power (Vcc x Icc ) in the driver, but rather the power dissipated in the 100 Ohm termination resistor. Nobody cares about this nice low number, which makes it a candidate for the "Misleading Marketing" award of the year. Parallel busses with 800 Mbps per channel are challenging today. Altera goes for coarse-granularity ( 300 ps ) individual per-bit clocking. Xilinx goes for fine-granularity ( 50 ps ) common clocking. Guess which one I like better. And next year, self-clocking bit-serial 2.5 Gbps, with 4-channel bonding for 10 Gbps data traffic will become the standard. Peter Alfke, Xilinx Applications Engineering. ======================================== Arie Zychlinski wrote: > I would be much obliged to learn for your experience with the ALTERA's > Mercury CDR using the M1GXCVR core. we intend to use it in a new project for > 800 Mbps links. > thank you in advance. > > -- > > yours - > Arie Z. > > ============================================ > Arie Zychlinski > R&D Consulting & Development > P.O.Box 536 > Kfar-Saba 44104 > ISRAEL > > Mobile: 972-58-320230 > Phone: W: 972-9-7673074 H: 972-9-7658268 > > E-Mail: ariez@attglobal.net > ===========================================Article: 36914
Peter, Can you elaborate (or give a pointer) on how Xilinx calculates its LVDS buffers power consumption ? Do Xilinx LVDS buffers support the full LVDS specification, or just the "reduced range" ?. Thanks, Rotem Gazit MystiCom LTD mailto:rotemg@mysticom.com http://www.mysticom.com/ Peter Alfke <palfke@earthlink.net> wrote in message news:<3C015E9A.B98CA518@earthlink.net>... > Here are some observations from my not-so-impartial viewpoint: > > 1. The Altera clock recovery requires a specialized training sequence. > > 2. The claim that it eliminates the need for balanced pc-bord trace length is > somewhat strange, since the granularity of the clocking scheme is 300 ps at > best. That is equivalent to about 2 inches or 5 cm trace length. For any of the > more realistic smaller differences in trace length, this adaptive per-bit > clocking scheme offers no advantage. > > 3. And finally, Altera makes bogus claims about LVDS power consumption, where > they quote not the consumed power (Vcc x Icc ) in the driver, but rather the > power dissipated in the 100 Ohm termination resistor. Nobody cares about this > nice low number, which makes it a candidate for the "Misleading Marketing" > award of the year. > > Parallel busses with 800 Mbps per channel are challenging today. > Altera goes for coarse-granularity ( 300 ps ) individual per-bit clocking. > Xilinx goes for fine-granularity ( 50 ps ) common clocking. > Guess which one I like better. > > And next year, self-clocking bit-serial 2.5 Gbps, > with 4-channel bonding for 10 Gbps data traffic will become the standard. > > Peter Alfke, Xilinx Applications Engineering. > ======================================== > Arie Zychlinski wrote: > > > I would be much obliged to learn for your experience with the ALTERA's > > Mercury CDR using the M1GXCVR core. we intend to use it in a new project for > > 800 Mbps links. > > thank you in advance. > > > > -- > > > > yours - > > Arie Z. > > > > ============================================ > > Arie Zychlinski > > R&D Consulting & Development > > P.O.Box 536 > > Kfar-Saba 44104 > > ISRAEL > > > > Mobile: 972-58-320230 > > Phone: W: 972-9-7673074 H: 972-9-7658268 > > > > E-Mail: ariez@attglobal.net > > ===========================================Article: 36915
I am using synplify to syn my design, after that , I perform post syn
smulation with vcs, vcs report an error in "ALTERA_MF.V" distribut
with Quartus 1.0, I found it actually an error,
in line 8296 of altera_mf.v, it is as follow:
assign rx_locklost = (deserialization_factor > 1) ?
i_rx_locked[number_of_channels-1:0] : {(number_of_channels-1){1'b1}};
notice that in this mux, the first way's width is number_of_channels,
but the second's width is number_of_channels-1
any idea about this error?
Article: 36916
Hello folks,
Im trying to implement large FFTs on Xilinx vertex II FPGAs. I have a couple of questions.
1. There are multipliers on chip with 5ns delays. There is a paper by lez mintzer "large ffts on fpgas" which describes how to code one fft butterfly with DA tables. The pipeline delay in this case is less than the multiplier delay and there are more multiplies per stage delay.
Can some one tell me which is better?
2. Im writing synthesizeable structural VHDL code for the butterfly processor. Im having to write code for controlling this for say, 8192 point FFT. Is this the way people do it. Like say guys writing xilinx cores. Or is there a better way you can suggest.
Thanks a lot,
Hananiel
Article: 369171) In my project I've a master clock at 165MHz and three clocks derived by it , in Synplyfy Pro I could see and apply contrains only at the first, why and how I could resolve this ?? 2) What is the meaning of the following estensions in HDL analist schematics : _cry , _abx , _s and the meaning of FDR , FDS , IBUF , INV , BUF 3) why some LUT on the HDL Analist are showed with a gray background ?? What's the meaning ?? ThanksArticle: 36918
Workshop on Cryptographic Hardware and Embedded Systems 2002
(CHES 2002)
www.chesworkshop.org
Hotel Sofitel, San Francisco Bay (Redwood City), USA
August 13 - 15, 2002
First Call for Papers
General Information
The focus of this workshop is on all aspects of cryptographic hardware
and security in embedded systems. The workshop will be a forum of new
results from the research community as well as from the industry. Of
special interest are contributions that describe new methods for
efficient hardware implementations and high-speed software for
embedded systems, e.g., smart cards, microprocessors, DSPs, etc. We
hope that the workshop will help to fill the gap between the
cryptography research community and the application areas of
cryptography. Consequently, we encourage submissions from academia,
industry, and other organizations. All submitted papers will be
reviewed.
This will be the fourth CHES workshop. CHES '99 and CHES 2000 were
held at WPI, and CHES 2001 was held in Paris. The number of
participants has grown to more than 200, with attendees coming from
industry, academia, and government organizations. The topics of CHES
2002 include but are not limited to:
* Computer architectures for public-key and secret-key cryptosystems
* Efficient algorithms for embedded processors
* Reconfigurable computing in cryptography
* Cryptographic processors and co-processors
* Cryptography in wireless applications (mobile phone, LANs, etc.)
* Security in pay-TV systems
* Smart card attacks and architectures
* Tamper resistance on the chip and board level
* True and pseudo random number generators
* Special-purpose hardware for cryptanalysis
* Embedded security
* Device identification
Instructions for Authors
Authors are invited to submit original papers. The preferred
submission form is by electronic mail to
submission@chesworkshop.org. The submissions must be anonymous, with
no author names, affiliations, acknowledgments, or obvious
references. Papers should be formatted in 12pt type and not exceed 12
pages (not including the title page and the bibliography). Please
submit the paper in Postscript or PDF, together with an extra file
containing the email and physical address of the authors, and an
indication of the corresponding author. We recommend that you generate
the PS or PDF file using LaTeX, however, MS Word is also
acceptable. All submissions will be refereed. Only original research
contributions will be considered. Submissions must not substantially
duplicate work that any of the authors have published elsewhere or
have submitted in parallel to any other conferences or workshops that
have proceedings.
Important Dates
Submission Deadline: May 1st, 2002.
Acceptance Notification: July 1st, 2002.
Final Version due: August 1st, 2002.
Workshop: August 13th - 15th, 2002.
NOTE: The CHES dates August 13th - 15th are the Tuesday through
Thursday preceeding CRYPTO 2002 which starts on evening of Sunday,
August 18th.
Mailing List
If you want to receive emails with subsequent Call for Papers and
registration information, please send a brief mail to
mailinglist@chesworkshop.org.
Program Committee
Beni Arazi, Ben Gurion University, Israel
Jean-Sebastien Coron, Gemplus Card International, France
Kris Gaj, George Mason University, USA
Craig Gentry, DoCoMo Communications Laboratories, USA
Jim Goodman, Lumic Electronics, Canada
M. Anwar Hasan, University of Waterloo, Canada
David Jablon, Phoenix Technologies, USA
Peter Kornerup, Odense University, Denmark
Pil Joong Lee, Pohang Univ. of Sci. & Tech., Korea
Preda Mihailescu, University of Paderborn, Germany
David Nacchache, Gemplus Card International, France
Bart Preneel, Universite Catholique de Louvain, Belgium
Jean-Jacques Quisquater, Universite Catholique de Louvain, Belgium
Erkay Savas, rTrust Technologies, USA
Joseph Silverman, Brown University and NTRU Cryptosystems, Inc., USA
Jacques Stern, Ecole Normale Superieure, France
Berk Sunar, Worcester Polytechnic Institute, USA
Colin Walter, Computation Department - UMIST, U.K.
Organizational Committee
All correspondence and/or questions should be directed to either of
the Organizational Committee Members:
Burt Kaliski
(Program Chair)
RSA Laboratories
20 Crosby Drive
Bedford, MA 01730, USA
Phone: +1 781 687 7057
Fax: +1 781 687 7213
Email: bkaliski@rsasecurity.com
Cetin Kaya Koc
(Local Organization)
Dept. of Electrical & Computer Engineering
Oregon State University
Corvallis, Oregon 97331, USA
Phone: +1 541 737 4853
Fax: +1 541 737 8377
Email: Koc@ece.orst.edu
Christof Paar
(Publicity Chair)
Electrical Eng. & Information Sciences Dept.
Ruhr-Universitaet Bochum
44780 Bochum, Germany
Phone: +49 234 32 23988
Fax: +49 234 32 14444
Email: cpaar@crypto.ruhr-uni-bochum.de
Workshop Proceedings
The post-proceedings will be published in Springer-Verlag's Lecture
Notes in Computer Science (LNCS) series. Notice that in order to be
included in the proceedings, the authors of an accepted paper must
guarantee to present their contribution at the workshop.
Article: 36919Has anyone successfully used Leonardo Spectrum as synthesis tool when using xilinx Logicore PCI32 in a xc4028xla? I'm running into all kinds of problems which i think is the synthesis phase "fault". * In M2.1i in map phase all logic is removed! if i use use the -u switch the logic remains and the core simulates. This is probably due to that the PCI clock buffer is defined inside the PCI-CORE and as i use the PCI-core clock output to rest of my design it is crucial that the clock buffer inside the core is recognized. I gladly tell you more about the problem.... Kind Regards Peter GustafssonArticle: 36920
1. At least the log file should show you that there were some clocks detected. You will fínd a statement in which Synplify tells you that it is assuming clock frequency to be the same as "default" frequency. If you would use SynplifyPro you could use HDL Analyst debugging tool to search for those inferred clocks. Just open up "Technology View", flatten it and use the "Find" function to detect Synplify´s "keepbufs". Those keeepbufs will show you that Synplify was able to detect internally generated clocks. 2. IBUF means an Xilinx Input buffer, obviously FDR and FDS are Flops with Reset and Set. Just think over what kind of components BUF and INV could be. 3. A gray LUT is not only gray but also shows you how the LUT was used. In general YOU SHOULD NOT use dervide clocks. Why don´t you use Clock Enable Inputs for derived frequencies?Article: 36921
John Larkin <jjlarkin@highlandSNIPTHIStechnology.com> writes: > > Even on 4-layer boards, we specify a very thin dielectric layer > between the power and ground planes to get the best plane effects. The > PCB fab houses don't seem to mind. > How thin do you go on 4 layer boards? And what track widths/impedances/heights above planes do you end up with on the tracking layer? > > The TDR we used has a net risetime of about 30 ps, or about 0.1" > resolution inside FR4. Yes, it surprised me that the bypass cap > location made no discernable difference to the impedance seen at the > SMA test point. I think the FR4 material is lossy enough to smear out > any reflections (or, in the frequency domain, kill the Q of any > resonances, which would be well into the GHz range here). > FR4 is certainly more lossy at those sort of frequencies. And the skin effect will cause resistive losses also I imagine. > I embarked on this because (besides it being fun) I had just finished > a board that, using the usual ROTs, had something like 200 bypass > caps, and it occurred to me that a) this was silly and b) I had never > designed a multilayer board that actually failed because of > insufficient logic bypasses. > :-) Good reasons! > Hey, I'm an engineer; I don't have to understand it, I only have to > make it work! > Once we understand it we can then persuade others that they don't 200 caps also.... Cheers, MartinArticle: 36922
Peter, you write "the granularity of the clocking scheme is 300 ps at best". Can you please elaborate on what this assertion is based upon. From: AN 130, CDR in Mercury Devices, page 8: "... Each of the eight equally-spaced phase clocks is divided into seven fractions; therefore, the resulting best-case clock granularity is 1/56 of the clock period. ..." 1/56 of a 1.25 GHz clock is equal to about 14 ps. 14 ps in today's Altera devices compared to 50 ps granularity in future Xilinx devices - please correct me if I have misinterpreted something here, but guess which one I like better. Wolfgang http://www.elca.de "Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag news:3C015E9A.B98CA518@earthlink.net... > Here are some observations from my not-so-impartial viewpoint: > > 1. The Altera clock recovery requires a specialized training sequence. > > 2. The claim that it eliminates the need for balanced pc-bord trace length is > somewhat strange, since the granularity of the clocking scheme is 300 ps at > best. That is equivalent to about 2 inches or 5 cm trace length. For any of the > more realistic smaller differences in trace length, this adaptive per-bit > clocking scheme offers no advantage. > > 3. And finally, Altera makes bogus claims about LVDS power consumption, where > they quote not the consumed power (Vcc x Icc ) in the driver, but rather the > power dissipated in the 100 Ohm termination resistor. Nobody cares about this > nice low number, which makes it a candidate for the "Misleading Marketing" > award of the year. > > Parallel busses with 800 Mbps per channel are challenging today. > Altera goes for coarse-granularity ( 300 ps ) individual per-bit clocking. > Xilinx goes for fine-granularity ( 50 ps ) common clocking. > Guess which one I like better. > > And next year, self-clocking bit-serial 2.5 Gbps, > with 4-channel bonding for 10 Gbps data traffic will become the standard. > > Peter Alfke, Xilinx Applications Engineering. > ======================================== > Arie Zychlinski wrote: > > > I would be much obliged to learn for your experience with the ALTERA's > > Mercury CDR using the M1GXCVR core. we intend to use it in a new project for > > 800 Mbps links. > > thank you in advance. > > > > -- > > > > yours - > > Arie Z. > > > > ============================================ > > Arie Zychlinski > > R&D Consulting & Development > > P.O.Box 536 > > Kfar-Saba 44104 > > ISRAEL > > > > Mobile: 972-58-320230 > > Phone: W: 972-9-7673074 H: 972-9-7658268 > > > > E-Mail: ariez@attglobal.net > > =========================================== >Article: 36923
hi, i'm using spartan fpga in a design having microcontroller. I want to program the fpga through a microcontroller. i have gone through xapp058. but to implement this code one needs an operating system and also this code is too complicated to make any changes to it. is there any other way to achieve this? rgds swanArticle: 36924
<swan> wrote in message news:ee7354f.-1@WebX.sUN8CHnE... > hi, > i'm using spartan fpga in a design having microcontroller. I want to program the fpga through a microcontroller. i have gone through xapp058. but to implement this code one needs an operating system and also this code is too complicated to make any changes to it. is there any other way to achieve this? > rgds > swan xapp058 does the full JTAG thing and is attempting to be universal so that makes it very complicated. If you want to write your own code its much simpler to forget about JTAG and do it using the slave serial mode process. Read xapp098 which tells you hwo to do it. The last time I actually wrote a serial config progam was for an XC1800 (I think) and the processor was a Motorola 68HC11. Its a while ago but I think the code was less than 100 lines of C. Michael Kellett www.mkesc.co.uk
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