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
Simon Bacon schrieb: > > A clock doubler chip from ICS may be simpler for most people. > And it would be small and cheap. Hmmm, yes and no. My thougts are: Somewere I read that the granularity of the DLL is 40ps, because its absolut digital. One delay element incorporates a delay of 40ps. So the datasheet says the minimum frequency is 25 MHz, which has a period of 20ns. Hmmmm I guess the delay line consits of 1024 elements, but I think there are more elements for safety reason/ part to part variations / temperature compensation and so on. But when I see that the DLL runs even on 13.2 MHz, this looks like plenty of safety. As I said, I will check out the temperature dependence in a few days. Stay tuned folks. Hey Peter and Ken, say something. -- MFG Falk P.S. Why is the granularity in the new virtex 2 specifyed with 45 ps when the "old" Spartan 2 achives 40ps (I didnt measure it, just read about it)???Article: 28976
Hi! I would like to know whether it is possible to implement a 64-bit counter running at 200 MHz and a 64-bit latch (to latch counter state using an external input) on any currently available FPGA. Any pointers/related product info will be greatly appreciated. Thank you -krishnan krish@wam.umd.edu.invalid.gov.com (delete stuff after .edu)Article: 28977
Look at that: http://www.altera.com/document/tb/tb70.pdf I suppose you can find here some additional information about DLL internal structure. Valeri Serebrianski. In article <3A789783.CD930548@gmx.de>, Falk Brunner <Falk.Brunner@gmx.de> wrote: > Simon Bacon schrieb: > > > > A clock doubler chip from ICS may be simpler for most people. > > And it would be small and cheap. > > Hmmm, yes and no. My thougts are: > > Somewere I read that the granularity of the DLL is 40ps, because its > absolut digital. One delay element incorporates a delay of 40ps. > So the datasheet says the minimum frequency is 25 MHz, which has a > period of 20ns. Hmmmm I guess the delay line consits of 1024 elements, > but I think there are more elements for safety reason/ part to part > variations / temperature compensation and so on. But when I see that the > DLL runs even on 13.2 MHz, this looks like plenty of safety. As I said, > I will check out the temperature dependence in a few days. > Stay tuned folks. > > Hey Peter and Ken, say something. > > -- > MFG > Falk > > P.S. Why is the granularity in the new virtex 2 specifyed with 45 ps > when the "old" Spartan 2 achives 40ps (I didnt measure it, just read > about it)??? > Sent via Deja.com http://www.deja.com/Article: 28978
Hi,
mccarley wrote:
>
> Hi all,
>
> I have this 'gearbox' coded up in Verilog and it is large
> and not quite fast enough when implemented in an FPGA.
>
> The 'gearbox' function is straight forward: 64 bit data
> bus input at 200 MHz needs to output a 66 bit data bus at
> 206.25 MHz. Same bandwidth. The clock rate conversion
> isn't a problem (I'm using 2 clocks), but the data width
> conversion is getting big and sluggish on me.
>
> The way I have coded it up is a 33 modulo counter and a
> case statement (MUXes) with the condition the counter
> value at which the data is shifted into the output
> register (after prefill). Like:
>
> case(cnt33) /*synthesis parallel_case*/
> 6'd0: {gearbox_reg[189:0]} <= #1 {datain_64b,
> gearbox_reg[191:66]};
> 6'd1: {gearbox_reg[187:0]} <= #1 {datain_64b,
> gearbox_reg[189:66]};
> .
> .
> .
> 6'd30: {gearbox_reg[129:0]} <= #1 {datain_64b,
> gearbox_reg[131:66]};
> 6'd31: {gearbox_reg[127:0]} <= #1 {datain_64b,
> gearbox_reg[129:66]};
> default: gearbox_reg[191:128] <= #1 datain_64b;
> endcase
>
> I also pipelined this by using an modulo 4 counter nested
> in a modulo 8 counter and a temporary register stage. I
> got quite a bit more speed then, but the area (# of FPGA
> logic blocks) is getting too large.
>
> I also tried to do this function with memory and address
> and data pointers, but it became a mess that didn't work
> well with the block memories in the FPGA.
>
> So, my question is: does anyone have any ideas or
> suggestions on a better way to accomplish this 'gearbox'
> function?
Buy an Ethernet core?
Do you really need to run at 200MHz? If this is what I think it is, you
don't really need to run above 160-something MHz.
Adjust your system design, and make life easy for yourself.
Regards,
Allan.
--
Allan Herriman mailto:allan_herriman.hates.spam@agilent.com
Agilent Technologies Voice: +61 3 9210 5527
Advanced Networks Division Fax: +61 3 9210 5550
347 Burwood Highway Forest Hill 3131 Australia
Article: 28979I have ORCA OC2C06 serie FPGA. I want to program using PROTEL 99 SE. The device is not native to Protel PLD library. On Protel web site, it say that I have to set device to 'Virtual', which I did. I also downloaded fitter files. I compile the file but I get only a PLD/PLA/... but after that, how can I generate the file for the specific target I want (ORCA OR2C06...)?Article: 28980
Yes, but how depends on yoru requirements. If the count sequence is not important, an LFSR will easily do this in any VirtexE and later parts. If the count sequence must be binary, you will probably have to pipeline the carry by breaking the counter into several chunks. This means that any load values and controls also have to be pipelined. Krishnan wrote: > > Hi! > > I would like to know whether it is possible to implement a 64-bit counter > running at 200 MHz and a 64-bit latch (to latch counter state using an > external input) on any currently available FPGA. > Any pointers/related product info will be greatly appreciated. > > Thank you > > -krishnan > krish@wam.umd.edu.invalid.gov.com (delete stuff after .edu) -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 28981
Austin Lesea wrote: > > For the smaller devices, the old Multilinx cable is OK. For anything larger, > get the newer updated programming cable. What is this "newer updated programming cable" ? Does it go any where near the 8MHz JTAG speed ? We were going to get the Multilynx cables hoping to solve the 15+ minutes download time for our Virtex chain with a parallel cable. We found out that the Multilynx JTAG clock is running at 30KHz vs about 160KHz on the 500MHz PC we have in the lab. Further attempts to speed up downloading by means of a PCI based parallel port card (vs motherboard built-in) under Windows 2000 was proved to be fruitless as Xilinx software HARDCODED !!! the parallel port addresses to the old PC/AT days. This kinda of make you think if they really want us to prototype with the bigger chips. K. C. LeeArticle: 28982
Pete Dudley wrote: > > I have another application where the driver is lvds. Is it possible to do > away with the external 100 Ohm termination resistors in that situation? LVDS uses constant current drivers, so you would really need the 100 ohms to convert that into voltage. Both LVDS and LVPECL needed that for terminating the differential transmission line. Some ASIC (actually almost all I am using) has internal terminations. > Pete Dudley K. C. LeeArticle: 28983
Thanks for the response. I am interested in a 64-bit binary counter; not an LFSR. -krishnan krish@wam.umd.edu.invalid.gov.com (delete stuff after .edu) Ray Andraka <ray@andraka.com> wrote: > Yes, but how depends on yoru requirements. If the count sequence is not > important, an LFSR will easily do this in any VirtexE and later parts. If the > count sequence must be binary, you will probably have to pipeline the carry by > breaking the counter into several chunks. This means that any load values and > controls also have to be pipelined. > > Krishnan wrote: > > > > Hi! > > > > I would like to know whether it is possible to implement a 64-bit counter > > running at 200 MHz and a 64-bit latch (to latch counter state using an > > external input) on any currently available FPGA. > > Any pointers/related product info will be greatly appreciated. > > > > Thank you > > > > -krishnan > > krish@wam.umd.edu.invalid.gov.com (delete stuff after .edu) > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com or http://www.fpga-guru.comArticle: 28984
Does it have to be synchronous? In otherwords are you, for example, keying the counter on and off? If you can tolerate a synchonous counter it is a piece of cake with even a SpartanXL in the fastest grade, Otherwize it is probably do-able in a SpartanII or Virtex Series part. Given the 200MHz clock what is the clock source? If it is being distributed as a LVPECL signal the VirtexE sounds like a shoe in for the task. I have been using a sixteen bit counter with a 160MHz counter to count pulse width in a SpartanXL. I tried a 200MHz clock but I had problems that I suspect were clock related (i.e. no clock input), unfortunately I do not have easy access to a fast enough scope to trouble shoot it. Verification works at 250MHz (implementation predicts about 190MHz if I remember and synthesis predicts only aabout 107MHz) using Xilinx foundation. I used the logiblox binary up-counter but I don't know if Logiblox will do a 64 bit counter. (I just tried it and it will. Unfortunately my license on my student edition has just expired and so I cannot check it any further that that. Sorry, if you have any problem E-Mail and I will try it at work and perhaps I can help you then.) Good luck, Theron Krishnan wrote: > Hi! > > I would like to know whether it is possible to implement a 64-bit counter > running at 200 MHz and a 64-bit latch (to latch counter state using an > external input) on any currently available FPGA. > Any pointers/related product info will be greatly appreciated. > > Thank you > > -krishnan > krish@wam.umd.edu.invalid.gov.com (delete stuff after .edu)Article: 28985
http://www.xilinx.com/support/programr/cables.htm for the "new" cables that use USB for faster configuration. It is called Multilinx III. Don't do it through JTAG (takes longer). Austin Me wrote: > Austin Lesea wrote: > > > > For the smaller devices, the old Multilinx cable is OK. For anything larger, > > get the newer updated programming cable. > > What is this "newer updated programming cable" ? Does it go any where > near the > 8MHz JTAG speed ? > > We were going to get the Multilynx cables hoping to solve the 15+ > minutes > download time for our Virtex chain with a parallel cable. We found out > that > the Multilynx JTAG clock is running at 30KHz vs about 160KHz on the > 500MHz > PC we have in the lab. > > Further attempts to speed up downloading by means of a PCI based > parallel port > card (vs motherboard built-in) under Windows 2000 was proved to be > fruitless > as Xilinx software HARDCODED !!! the parallel port addresses to the old > PC/AT > days. > > This kinda of make you think if they really want us to prototype with > the bigger > chips. > > K. C. LeeArticle: 28986
A fully synchronous 64-bit counter at 200 MHz is close to Virtex-II capability. If you can give up on any features, it would be easier. Is a prescaler possible? What do you expect to do with the latches? Do you ever stop and start the counter? Any pre-load? A better understanding of your systems requirements would help. As I said, a textbook pushbutton implementation is about 10 MHz shy of your stated requirements. And I still intend to count 1 GHz with a ripple counter... Peter Alfke, Xilinx Applications ================================== Krishnan wrote: > Hi! > > I would like to know whether it is possible to implement a 64-bit counter > running at 200 MHz and a 64-bit latch (to latch counter state using an > external input) on any currently available FPGA. > Any pointers/related product info will be greatly appreciated. > > Thank you > > -krishnan > krish@wam.umd.edu.invalid.gov.com (delete stuff after .edu)Article: 28987
This is only a test.Article: 28988
I design PCI target controller on VHDL now. This core will be implement in hardware so I need good testbench for this core . Where can I find free testbench for this core ? I will be very grateful for any help. Best regards, VladArticle: 28989
Hi, we've bought a SpartanII Demo board (XC2S100) and we're trying without success to configure the FPGA via the JTAG port using Alliance FPGA programmer . Has someone experience with Insight demo cards. Thanks for the time. Karim.Article: 28990
Hi, does anybody know, how i can use more than 4 extrenal clocks in my VIRTEX 300? All clocks have the same frequence (25MHz) but not the same phase. I need these clocks to write out data to a MII Interface. Thanks GerhardArticle: 28991
I found a problem:while implementing a VHDL design I declared all the variables I need as variable statement on a process : variable temp : std_logic_vector(Bu-1 downto 0); variable t : integer; variable dato : dati; variable coeff : coefficienti; where dati and coefficienti are type. The timing report of this design after flow engine run is : Design statistics: Minimum period: 51.279ns (Maximum frequency: 19.501MHz) Maximum net delay: 9.185ns Changing the declaration of the variables as signal statement outside the process...: signal temp : std_logic_vector(Bu-1 downto 0); signal t : integer; signal dato : dati; signal coeff : coefficienti; ..I found this result: Design statistics: Minimum period: 18.102ns (Maximum frequency: 55.243MHz) Maximum net delay: 7.240ns Please,does anybody tell me why? The design with signal statement does not give a right simulation. Thanks in advanceArticle: 28992
Dear sir/madam I am working for the Centre for Continuing Education at Imperial College in London, UK and we are organising short courses. I am wondering if it would be appropriate to put this announcement onto your group discussion page. Advances in Digital Signal Processing 12 - 16 March 2001 @ Imperial College, London, UK Advances in VLSI technology have facilitated the introduction of fast and specialised Digital Signal Processors (DSP) and associated Integrated Circuits, which can be used in a wide range of communication and multimedia applications. However, to make effective use of these circuits engineers require an understanding both of the underlying principles by which they operate, and of the diverse range of applications to which they might be suitably applied, in particular when systems must operate within the constraints of real-time. In addition, the introduction of Field Programmable Gate Arrays (FPGAs), which allow the user to reconfigure the hardware dynamically, offers new opportunities for enhancing fast real-time DSP algorithms. We would be most grateful if you could pass this information on to your colleagues who might be interested. Further details from: Ulrika Wernmark, Centre for Continuing Education, Imperial College, Room 526 Sherfield Building, Exhibition Road, London SW7 2AZ, UK. Tel: +44(0)20 7594 6886; Fax: +44(0)20 7594 6883; Email: u.wernmark@ic.ac.uk http://www.ad.ic.ac.uk/cpd/mst.htm Kind regard Ulrika Wernmark ---------------------------------------- Ulrika Wernmark Programme Administrator Centre for Continuing Education Room 526, Sherfield Building Imperial College Exhibition Road London SW7 2AZ UK ---------------------------------------- Tel: +44 (0)20 7594 6886 Fax: +44 (0)20 7594 6883 Email: u.wernmark@ic.ac.uk http://www.ad.ic.ac.uk/cpd ----------------------------------------Article: 28993
Did you try a logarithmic shifter?
You present data and a shift count to a pipeline.
The first stage shifts (Or does not shift) by 32-Bits and subtracts
32-from the shift count.
The second stage shifts by 16, and substracts 16, and so on.
You need about 96+80+72+68+66 < 400 LUTs plus controll.
It is a little bit tricky to get the output right.
I had a design where I had to merge codes of length 1 to 19 into a
50-Bit register. This is smaller, but more complicated than your
application.
The first Implementation ran at 115MHz without floorplanning on a
slowest speedgrade virtex.
This means, if you interleave two of these you are well above 200 MHz.
At little more than 200 CLBs.
Floorplanning and a Virtex-E could also get you to 200 MHz.
CU,
Kolja
In article <3A785EBE.F575788D@austin.rr.com>,
mccarley <mccarley@austin.rr.com> wrote:
> Hi all,
>
> I have this 'gearbox' coded up in Verilog and it is large
> and not quite fast enough when implemented in an FPGA.
>
> The 'gearbox' function is straight forward: 64 bit data
> bus input at 200 MHz needs to output a 66 bit data bus at
> 206.25 MHz. Same bandwidth. The clock rate conversion
> isn't a problem (I'm using 2 clocks), but the data width
> conversion is getting big and sluggish on me.
>
> The way I have coded it up is a 33 modulo counter and a
> case statement (MUXes) with the condition the counter
> value at which the data is shifted into the output
> register (after prefill). Like:
>
> case(cnt33) /*synthesis parallel_case*/
> 6'd0: {gearbox_reg[189:0]} <= #1 {datain_64b,
> gearbox_reg[191:66]};
> 6'd1: {gearbox_reg[187:0]} <= #1 {datain_64b,
> gearbox_reg[189:66]};
> .
> .
> .
> 6'd30: {gearbox_reg[129:0]} <= #1 {datain_64b,
> gearbox_reg[131:66]};
> 6'd31: {gearbox_reg[127:0]} <= #1 {datain_64b,
> gearbox_reg[129:66]};
> default: gearbox_reg[191:128] <= #1 datain_64b;
> endcase
>
> I also pipelined this by using an modulo 4 counter nested
> in a modulo 8 counter and a temporary register stage. I
> got quite a bit more speed then, but the area (# of FPGA
> logic blocks) is getting too large.
>
> I also tried to do this function with memory and address
> and data pointers, but it became a mess that didn't work
> well with the block memories in the FPGA.
>
> So, my question is: does anyone have any ideas or
> suggestions on a better way to accomplish this 'gearbox'
> function?
>
>
Sent via Deja.com
http://www.deja.com/
Article: 28994Hi. !! newbie warning !! I need info about how to write a circuit for testing this display, or how to do anything else with it.... I have tried writing a test circuit that should generate patterns on the display, but it doesn't work. (sometimes I can see the patterns, but only temporairly). ps. I write in VHDL on a xilinx xc9572 cpld.Article: 28995
Hi Krishnan, just tried your design, a 64-bit binary, synchronous, free running counter with asychnronous clear feeding a 64-bit register (D-type) enabled by a synchronized signal from a pin. Push button result in Quartus II was 246.31 MHz. Altera is just a little more conservative in their press releases. They recently stated 60% improvement with Quartus II, while Xilinx boasted "XILINX VERSION 3.3i SOFTWARE WITH VIRTEX-II DEVICES DELIVERS 86 PERCENT HIGHER CLOCK FREQUENCIES VERSUS COMPETING SOFTWARE " Regards Wolfgang Krishnan <nospam@this.is.invalid> wrote in message news:95aba7$kik$1@dailyplanet.wam.umd.edu... > Hi! > > I would like to know whether it is possible to implement a 64-bit counter > running at 200 MHz and a 64-bit latch (to latch counter state using an > external input) on any currently available FPGA. > Any pointers/related product info will be greatly appreciated. > > Thank you > > -krishnan > krish@wam.umd.edu.invalid.gov.com (delete stuff after .edu)Article: 28996
"Austin Lesea" <austin.lesea@xilinx.com> wrote in message news:3A78D9EB.8BE30435@xilinx.com... > http://www.xilinx.com/support/programr/cables.htm > > for the "new" cables that use USB for faster configuration. > It is called Multilinx III. Don't do it through JTAG (takes longer). Hmmm - your recent postings regarding names of the different cables might confuse people... There are only two (Xilinx) cables available to day: 1) Parallel Cable III (PC parallel port) 2) MultiLINX (USB and RS-232 serial) There used to be another one called XChecker (RS-232) but it is no longer in production. I don't know if anyone have compared configuration speed of Parallel Cable III versus Multilinx (using USB), but it is my impression that the low-cost solution (Parallel Cable III) does not stand back when it comes to configuration speed. Rune BaeverrudArticle: 28997
Hi, I'm having quite a problem with the Xilinx PCI Core in a Virtex-E design. Everything is fine with the synthesis (Synplify 6.0) but I'm having these errors with ngdbuild: ERROR:NgdBuild:455 - logical net 'PCI_CORE/VCC' has multiple drivers ERROR:NgdBuild:462 - input pad net 'PCI_CORE/VCC' drives multiple buffers ERROR:NgdBuild:466 - input pad net 'PCI_CORE/VCC' has illegal connection I know that this has to be a connection error in the top level or somewhere else. The problem is that "PCI_CORE/VCC" does not really indicate where the problem could be... Any tips or ideas? Thanks! Martin GuibertArticle: 28998
.... I can't watch while misleaading information is spread around: If you want to know what the 20KE PLL really does, measure it with other things happening in the part. This is what Altera doesn't want you to see. It is their "perfect" PLL losing it (665 ps P-P !!! > 3X spec) because it can't deal with logic plane switching (no IO's toggling in this experiement, it gets worse). I have said once before that jitter is a complex process, and requires careful attention to signal integrity, source clock jitter, etc. Once eveything gets going, that's when the jitter is going to matter. The nice thing about the DLL is that it is digital, and what you see is what you get. No bizarre behavior due to something else going on on chip (like is demonstrated above). For the complete bake-off comparison, the tech-note will appear in the web site soon. Thanks to all of you who requested the early version of the tech-note and provided your helpful comments. Austin serebr@my-deja.com wrote: > Look at that: http://www.altera.com/document/tb/tb70.pdf > I suppose you can find here some additional information about DLL > internal structure. > > Valeri Serebrianski. > > In article <3A789783.CD930548@gmx.de>, > Falk Brunner <Falk.Brunner@gmx.de> wrote: > > Simon Bacon schrieb: > > > > > > A clock doubler chip from ICS may be simpler for most people. > > > And it would be small and cheap. > > > > Hmmm, yes and no. My thougts are: > > > > Somewere I read that the granularity of the DLL is 40ps, because its > > absolut digital. One delay element incorporates a delay of 40ps. > > So the datasheet says the minimum frequency is 25 MHz, which has a > > period of 20ns. Hmmmm I guess the delay line consits of 1024 elements, > > but I think there are more elements for safety reason/ part to part > > variations / temperature compensation and so on. But when I see that > the > > DLL runs even on 13.2 MHz, this looks like plenty of safety. As I > said, > > I will check out the temperature dependence in a few days. > > Stay tuned folks. > > > > Hey Peter and Ken, say something. > > > > -- > > MFG > > Falk > > > > P.S. Why is the granularity in the new virtex 2 specifyed with 45 ps > > when the "old" Spartan 2 achives 40ps (I didnt measure it, just read > > about it)??? > > > > Sent via Deja.com > http://www.deja.com/Article: 28999
I finally mastered it, How to design FPGAs, From VHDL coding, Coding for synthesis, synthesis, simulation, post-layout simulation, Writing testbenching, handling microprocessors, writing C to simulate my FPGAs, timing Analysis. Buiding the damn thing, using Logic analyzer to debug it. And was able to build some hardware boards successfully. Yes man ... I finally found the recepy. Now it's time to move on to something new. Who should we attack, DSP, Protocols, Analog, whats I'm so smart my friends. Sent via Deja.com http://www.deja.com/
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