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 Thu, 01 Feb 2001 17:22:47 GMT, frouatbi@my-deja.com wrote: why don't you work on some satellite communications systems implementing VSAT ;-) Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 29001
Karim LIMAM schrieb: > > 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. I think so. Iam afraid you do the same simple mistake like I did. Go to the Implementations Optins Menu Implementation/Option Control files-> Edit Click Startup select JTAG as startup clock. Now you have to implement the design (the bitfile must be updated) This should work. -- MFG FalkArticle: 29002
Gerhard Griessnig schrieb: > > 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. You can feed a clock into any IO pin, BUT when using normal routing ressources as clock nets, you should use secondary clock nets for this to minimize clock skew. This is done in the UCF with the statement NET My_clock uselowskewlines; -- MFG FalkArticle: 29003
Gerhard, I have used 5 clocks in a Spartan-2, but be careful. The constraint: NET <net name> USELOWSKEWLINES; forces the virtex router to use secondary Clock lines, which will be much better than regular route, but does not compare to GCLK. Another suggestion is this: 25 Mhz is slow for the internals of a virtex. Perhaps you could consider using a much faster clock (150 Mhz?) to sample the clock and data waveforms. Unless your 25 Mhz timing is very tight, you should be able to have a reliable data interface by using one fast clock for all of your clock domains. Jason Daughenbaugh http://www.aedinc.net In article <3A793ED3.A0565E7D@sbox.tu-graz.ac.at>, Gerhard Griessnig <grie@sbox.tu-graz.ac.at> wrote: > 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 Gerhard > > Sent via Deja.com http://www.deja.com/Article: 29004
If you use a binary counter, you incur the extra carry delay, which in Virtex-E is about 50 ps per bit. That's 3.2 ns over 64 bits, so we getting close to your 5 ns budget. But since your counter is always free-running, we can play a trick: we keep the LSB out of the carry chain, and use its Q as clock enable for all the higher bits. The counter is still synchronous, using a 200 MHz clock, but the carry chain now has two clock periods to propagate. So from a carry propagation point of view, it's a 100 MHz counter, but it has the full synchronous resolution of 200 MHz. This concept can be driven further by implementing a 3-bit front-end counter, decoding its state "6" and pipelining it in the fourth flip-flop, and using this Q as the count enable for all the higher bits. Now the carry chain has eight clock periods to propagate, and the counter is still fully 200-MHz synchronous. Since the carry chain runs vertically ( up only ), the layout is automatic. Peter Alfke, Xilinx Applications Krishnan wrote: > 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: 29005
Hi, I am about to use an A54SX32A from ACTEL. My questions may seem easy to answer but I am new to ACTEL so please be forgiving. How do I manage large fanout signals such as a set or a reset in an actel part since there is a limitation in the fanout of a signal ? Does anybody have some experience with the SX-A family since the only datasheet I could find on the web is preliminary and incomplete ? Were there any problems/good surprises using this family ? Thank you for your time and information. J.F. HassonArticle: 29006
In article <foqb7tkfd1tnsl4g32opsofphjvm3mbk3m@4ax.com>, z80@ds2.com (Peter) wrote: > > >But: There is a self-discharge mechanism that is the real limitation. > >Good 3-V Lithium batteries have a shelf life of 15 years or more. > > This is a much bigger issue than it first appears. I have designed a > number of very low power products powered by lithium watch-type cells, > did a lot of evaluations of different cells, and it was amazing to > find how bad some cells were. One make (European) had a shelf life > consistently of about 1 year (to <20% capacity), the best Japanese > makes were probably >10 years, but "bad batches" happen right across > the board. > > I would be very unhappy relying on a shelf life of 10-15 years for a > critical application, e.g. where loss of battery power would make a > product *permanently* (i.e. even if the battery is replaced) > non-functional. All you need is a bad batch of cells and maybe 5 years > later you get a whole lot of extremely unhappy customers... I'm not sure I'd be very happy with a product that was guaranteed to die after 15 years even with a 'perfect' battery. -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 29007
In article <94q4mr$crh$4@noao.edu>, "apeters <"@> n o a o [.] e d u> (Andy Peters) wrote: > Falk Brunner wrote: > > > > Peter Alfke schrieb: > > > > > > The internal back-up memory in Virtex-II consumes 100 ( really 1000 > > > ) times > > > less current, and consumes this current only when Vcc is not > > > present. > > > > Why not using wrist watch technology like solar cells / automatic > > drive > > to charge a rechargable battery or a super cap when the power is off > > . . > > . ;-))) > > Oh, you electrical engineers always think things have to have > electricity to be useful! Such narrowmindedness and always unwilling to > "think outside the box!" > > I've got a Seiko automatic (self-winding) jewelled-movement watch. Very > nice. No batteries, no winding. Doesn't die since I wear it all the > time. I know the nanotech people have been making noises about mechanical computers (little molecular rods and wheels and stuff) for ages, but non-electrical FPGAs are currently even more difficult to get hold of than Xilinx products :-) -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 29008
Mikko <mheikker@cc.hut.fi> writes:
> Does anyone know how to create .scf file from a jedec (.jed) file generated by
jtagprog -svf -batch jtagprog
Where jtagprog.cmd contains:
part XC95144XL:pld
program -v pld
quit
This is under Solaris. I think DOS/Win gets confused by the file
jtagprog.cmd, try to rename it to something else.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
Article: 29009There are _NO_ secondary clock nets in Virtex, Virtex-E, and Spartan-II. This was 'unfortunate nomenclature' in Virtex data sheets. This constraint gets you low skew, but not no skew. You can use it to register/FIFO some inputs but you need to move the data to one of the four GCLK domains as soon as possible. And check this part of the design even more than you usually do. "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:3A79A278.53A18F76@gmx.de... > Gerhard Griessnig schrieb: > > > > 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. > > You can feed a clock into any IO pin, BUT when using normal routing > ressources as clock nets, you should use secondary clock nets for this > to minimize clock skew. This is done in the UCF with the statement > > NET My_clock uselowskewlines;Article: 29010
Krishnan wrote: > > > > 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. Peter Alfke wrote: > > If you use a binary counter, you incur the extra carry delay, which in Virtex-E is > about 50 ps per bit. That's 3.2 ns over 64 bits, so we getting close to your 5 ns > budget. > But since your counter is always free-running, we can play a trick: we keep the LSB > out of the carry chain, and use its Q as clock enable for all the higher bits. The > counter is still synchronous, using a 200 MHz clock, but the carry chain now has > two clock periods to propagate. So from a carry propagation point of view, it's a > 100 MHz counter, but it has the full synchronous resolution of 200 MHz. > > This concept can be driven further by implementing a 3-bit front-end counter, > decoding its state "6" and pipelining it in the fourth flip-flop, and using this Q > as the count enable for all the higher bits. Now the carry chain has eight clock > periods to propagate, and the counter is still fully 200-MHz synchronous. > > Since the carry chain runs vertically ( up only ), the layout is automatic. What Krishnan wants is a 5nS time resolution, which you can get with 100MHz counter, if you capture the CLOCK in the latch. (CLOCK needs to be ~50% duty cycle.) The challenge in this design is the LATCH - does it have to capture while the counter is running ? If yes, then you need to ensure the aperture where all Q's toggle is avoided, as you can capture any value there. Solutions could be Syncronise state engine ( probably two, one for each clock edge ) or maybe a Grey Code counter. Peter, can you use your XOR-D Grey converter both ways ? - ie count binary, capture Grey, and then Grey -> Bin convert afterwards -jgArticle: 29011
Hi Laurent, Virtex only supports edif netlists- so xnf generation is not possible for this part. As far as why ngdbuild isn't finding those nets... not sure. Normally the default notation for vector indicies is to use <x> as opposed to (x). I believe there is a switch in Leonardo which can change this. Perhaps you could try changing that option, modifying the constraints accordingly, and see if that makes a difference. Hope this helps, Tim Laurent Gauch wrote: > Hi all, > > I have actually a problem to reuse a .edf file generated by > LeonardoSpectrum in the Design manager of Foundation. > > When I look my report file generated by Foundation, I can see the > following lines: > ---------------------- > Annotating constraints to design from file "concatened.ucf" ... > ERROR:NgdBuild:397 - Could not find NET 'mini_ezx_pin(3)' in design > 'interface'. NET entry is 'NET mini_ezx_pin(3) LOC = P42 ; > ' > ERROR:NgdBuild:397 - Could not find NET 'mini_ezx_pin(2)' in design > 'interface'. NET entry is 'NET mini_ezx_pin(2) LOC = P41 ; > ' > ERROR:NgdBuild:397 - Could not find NET 'mini_ezx_pin(1)' in design > 'interface'. NET entry is 'NET mini_ezx_pin(1) LOC = P40 ; > ' > ERROR:NgdBuild:397 - Could not find NET 'mini_ezx_pin(0)' in design > 'interface'. NET entry is 'NET mini_ezx_pin(0) LOC = P39 ; > ---------------------- > > Now, If I edit my .edf file to find 'mini_ezx_pin(3)' port, I can see > the lines : > ---------------------- > (port (rename p0 "mini_ezx_pin(3)") (direction INPUT)) > (port (rename p1 "mini_ezx_pin(2)") (direction INPUT)) > (port (rename p2 "mini_ezx_pin(1)") (direction INPUT)) > (port (rename p3 "mini_ezx_pin(0)") (direction INPUT)) > > I do not understand why LeonardoSpectrum rename all my vectors when I > generate my output .edf file ??? > > Also, working with Virtex and Virtex-E, what is the better format to use > between EDIF and XNF. > > Thank you in advance. > > Regards > Laurent > for Amontec (www.amontec.com)Article: 29012
We have multiple opportunities for engineers with FPGA experience in Boston, Dallas, Austin and Southern CA. If you are interested please take a look at my web site or call/ email my directly. www.execstaffing.com Thank you. Todd McKenzie Account Manager Executech Staffing 3626 N Hall Suite 818 Dallas, TX 75219 877.295.3838 toll free 214.559.0061 x 300 214.559.0062 fax 214.693.6678 cell tmckenzie@execstaffing.comArticle: 29013
Hi all - Perhaps someone can shed some light on a couple of questions about the Spartan-II tristate support, which I used in place of some multiplexors to reduce gate count... (1) Anybody know how the Spartan-II tristate is really implemented ? I was very surprised when I got the following warning (Murphy's law, with 15 sources required): -- ERROR:Place:867 - Design contains TBUF output net I159_I1_I0 driven by 15 TBUF -- drivers. Device you have selected can only accomodate up to 14 tbuf drivers -- on a net. (2) I worked around the above problem, but I still get the following warnings from XST D.22, surprising but seems harmless: WARNING : (HDL__0001). Signal <xyz> has a multisource. I'm using the WebPack... Thanks in advance for any insight, Best Regards, DaveArticle: 29014
Hi all, I am contemplating to take up a job in IC design, but the only experience I've had is FPGA design (Xilinx) using schematics. I understand that IC designers work with VHDL/Verilog and the verification/testing process is more elaborate. Besides the front-end design language, what are the major difference between FPGA design and IC design? I am concentrating on digital IC only. Regards, LCArticle: 29015
Falk Brunner wrote: > 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. > > - Hi, Falk Your guesses are not too far off. And I believe that, at room temperature, 13.2 MHz are possible. But what happens at cold temperature, or hot? And what happens when we tweak the process to give us faster transistors? We have done that many times in the past, so we have some experience. We must make sure that "old" 2001 designs still work with 2003 devices. So we do not want to guarantee something that we know works today, but will get you in trouble a few years from now. If you want to build a one-off design, be my guest and measure the min frequency, and then add some guardband. But, please, never go into production with such a design. Give my regards to Dresden. Beautiful city, even after what was done to it in 1945. Viele Grüße Peter Alfke, Xilinx ApplicationsArticle: 29016
In Virtex-II ( yes I know, availability is limited ) you can use the 18 x
18 multiplier to act as a 0...18 bit combinatorial shifter ( just
multiply by the right power of two). That may make the design more
compact and less pipelined. Even the smallest XC2V40 has 4 such
multipyers. Prop delay is 7 ns max.
Peter Alfke, Xilinx
sulimma@my-deja.com wrote:
> 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: 29017
jean-francois hasson wrote:
>
> Hi,
>
> I am about to use an A54SX32A from ACTEL. My questions may seem easy to
> answer but I am new to ACTEL so please be forgiving.
> How do I manage large fanout signals such as a set or a reset in an
> actel part since there is a limitation in the fanout of a signal ?
Use one of the two global buffers. There is also the HCLK which you can
use for clocks.
-----------------------------------------------------------------------
rk Choose either A, B, C, or D:
stellar engineering, ltd. A: Glass is part full
stellare@erols.com.NOSPAM B: Glass is part empty
Hi-Rel Digital Systems Design C: Glass is too big
D: Volume of the glass derated.
Article: 29018Steve Rencontre wrote: > I'm not sure I'd be very happy with a product that was guaranteed to die > after 15 years even with a 'perfect' battery. > Most watches use batteries, as do cameras and many PalmPilots. Smoke alarms need a battery, kind of every year. Cars need a new battery, new tires and a new muffler now and then. More seriously: As long as Vcc is applied, you can pull out ( or unsolder ) the old battery, as long as you put in a new one before you turn off Vcc. I just don't believe the story about many lithium batteries being short-lived. Peter Alfke, XilinxArticle: 29019
I am looking for an FPGA board with a PCI interface (or PMC). I hope the FPGA would have access to at least 4 banks of memory (preferably SRAM) of 32-bit data. And I hope each bank of memory would have large capacities (>= 4M bytes). Does anyone know any board of this type? I did a search myself and the closest one I could find are the RC1000 board from Alpha Data (4 banks, 32-bit interface, 2M bytes for each bank) and SMT406 from Sundance (4 banks, 36-bit interface, 2.25M bytes for each bank). I wonder if there is anything bigger than that. Thanks, -- Zhen LuoArticle: 29020
Falk Brunner wrote: > Gerhard Griessnig schrieb: > > > > 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. > > You can feed a clock into any IO pin, BUT when using normal routing > ressources as clock nets, you should use secondary clock nets for this > to minimize clock skew. This is done in the UCF with the statement > > NET My_clock uselowskewlines; > > -- > MFG > Falk I get an error message although i use the UCF( NET "P2_TXCLK" USELOWSKEWLINES;). I had try to declare P2_TXCLK as IBUF, as IBUFG and without buffer! My error mesage: ERROR:MapLib:93 - Illegal LOC on symbol "P2_TXCLK.PAD" (pad signal=P2_TXCLK) or BUFGP symbol "C37642" (output signal=P2_TXCLK_BUFGPed), IPAD-IBUFG should only be LOCed to GCLKIOB site. Thanks, GerhardArticle: 29021
I am guess I am hittin the same drum as Ray Andraka: The Multiplier will make the design simpler. You can argue about size. (If I am right, you need 16 Multipliers for the gearbox) But it will slow the design down. The logiblox multipliers had a latency of 3 clock cycles. Why didn't you follow the same approach for the hardwired ones? CU, In article <3A7A3451.8F43D27@earthlink.net>, palfke@earthlink.net wrote: > In Virtex-II ( yes I know, availability is limited ) you can use the 18 x > 18 multiplier to act as a 0...18 bit combinatorial shifter ( just > multiply by the right power of two). That may make the design more > compact and less pipelined. Even the smallest XC2V40 has 4 such > multipyers. Prop delay is 7 ns max. > > Peter Alfke, Xilinx > > sulimma@my-deja.com wrote: Sent via Deja.com http://www.deja.com/Article: 29022
Hi, The JTAG Clock is already selected as start up clock. When I try to configure the FGPA with a bypass through the SPROM .. I get a doctor Watson error ?? Thanks. Falk Brunner <Falk.Brunner@gmx.de> a écrit dans le message : 3A79A1A6.8C7C0D61@gmx.de... > Karim LIMAM schrieb: > > > > 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. > > I think so. Iam afraid you do the same simple mistake like I did. > > Go to the Implementations Optins > > Menu Implementation/Option > Control files-> Edit > Click Startup > select JTAG as startup clock. > > Now you have to implement the design (the bitfile must be updated) > > This should work. > > -- > MFG > FalkArticle: 29023
In article <3A7A385B.C979A413@earthlink.net>, palfke@earthlink.net (Peter Alfke) wrote: > Steve Rencontre wrote: > > > I'm not sure I'd be very happy with a product that was guaranteed to > > die > > after 15 years even with a 'perfect' battery. > > > > Most watches use batteries, as do cameras and many PalmPilots. > Smoke alarms need a battery, kind of every year. > Cars need a new battery, new tires and a new muffler now and then. Oh, I agree entirely. However, I fear that 15 years is well over the horizon for many engineering and all marketing departments, and that providing battery-monitoring circuitry, and/or the case mechanics to allow safe battery changing with power applied will be seen as unnecessary expense in too many instances. -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 29024
"Dave Nadler" <drn@nadler.com> wrote in message news:95eal5$mu1$1@bob.news.rcn.net... > I was very surprised when I got the following warning (Murphy's > law, with 15 sources required): > -- ERROR:Place:867 - Design contains TBUF output net I159_I1_I0 driven > by 15 TBUF > -- drivers. Device you have selected can only accomodate up to 14 > tbuf drivers > -- on a net. The device you have chosen has only 14 columns of TBUF buffers. You can get round this by splitting the outputs between two longlines and merging the results. And yes, the (Virtex) TBUFs are not really tristate buffers. Xilinx published the real implementation in a patent and in a presentation road show they did at the time that Virtex was launched. If anyone has the slides from that roadshow...
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