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
Peter Alfke <peter@xilinx.com> wrote: > Xilinx welcomes Steve Knapp, back from 5 years trying his luck > elsewhere. > We are glad he found the way back home, where he belongs ! ALl right! Good to hear. Steve was my FAE back in late 1985 when I started using the XC2064. I had a design which wouldn't quite fit. He was convinced he could squeeze in the one last net I needed to route. He beat on it for hours but finally had to admit I'd filled it all the way up. Had to put 1 discrete 3-in NOR on the PCB :-) Anyway he was definitely a great FAE. What will he be doing now? Tom (at StorageTek in Colorado)Article: 46476
I asked: > XAPP450 says that Vccint and Vcco should be applied simultaneously to the > Spartan-IIE devices, but does not mention the Spartan-II. Will bad things > happen with the Spartan II if Vcco is available earlier than Vccint? Austin Lesea <austin.lesea@xilinx.com> writes: > Nope. Spartan II does not care if Vcco is applied before, or after (or with) > Vccint. So a half hour earlier or three weeks later is OK? Thanks for answering my questions, it looks like everything should work out the way I'd hoped. Those Spartan II parts seem to be a great value.Article: 46477
Peter, I think you have re-acquired a fine asset there! Good luck Steve with the return. Hope they give you time to continue your excellent web pages in an FPGA neutral way. I expect you'll be yet another Xilinx newsgroup poster. Hopefully that'll encourage Altera to half-heartedly attempt to do the same. I've been an Altera user all my working life (386-20 with original Maxplus :) ) but due to the levels of support for Xilinx here and elsewhere I think I know who my next large FPGA job will be with. PS You need to sign up Ray to write that holy grail book describing how to get the most out of your Xilinix chip. Paul "Peter Alfke" <peter@xilinx.com> wrote in message news:3D6FE22D.959F4F3B@xilinx.com... > Xilinx welcomes Steve Knapp, back from 5 years trying his luck > elsewhere. > Some of you may remember his Optimagic Jumpstation. > Here we remember him as a hell of an Applications engineer, > a good writer, and a genuinely nice guy. > We are glad he found the way back home, where he belongs ! > > Peter Alfke, Xilinx Applications >Article: 46478
Dear Sir:
I like the fpga design. This is the first time i login in the
news gruop by google.com. But i think it is very complex to use google
to login.Can you tell me a simple way to use MS-outlook express to
login.
Thank you!!
Greetings
Jianrong Wang
Article: 46479"Jianrong Wang" <goodpanda35@sohu.com> schrieb im Newsbeitrag news:9b325b3d.0208310154.6f673fd8@posting.google.com... > Dear Sir: > I like the fpga design. This is the first time i login in the > news gruop by google.com. But i think it is very complex to use google > to login.Can you tell me a simple way to use MS-outlook express to > login. Just find a news server, create a account in Outlook for news, you are done. I use a free news server from germany http://news.cis.dfn.de/ You need to register, but its all free. -- MfG FalkArticle: 46480
"Denis Gleeson" <dgleeson@utvinternet.com> schrieb im Newsbeitrag news:6f080894.0208301342.1e68894d@posting.google.com... > Hi Peter > > Thanks for your response. > One of the things that concerns me is the number of pins on a device. > If it comes to it I am hoping to mount these devices on the PCB myself. > Certainly for prototypes anyway. > > So in keeping to a PLCC84 package I see that I could get a XCS05XL > or XCS10XL at low cost in small quantities. I see that I can even get > a PLCC84 XCS05 spartan device at a good price. Why using a SPARTAN?? Peter suggested a SPARTAN-II or SPARTAN-IIE. Sounds similar, but is very different. Yes, these families are not available in PLCC, but you can solder a QFP by hand without major problems. Even a BGA has been soldered by hobbyists. http://wwwbode.cs.tum.edu/~acher/bga/index.html ;-))) > Can you comment on possible problems I might come across when gating the > 100MHz > clk with say the XCS05XL. 1st. better use Spartan-II. 2nd, if you are going to gate the 100MHz, you do this usually be using a AND gate, with one input beeing the clock, the other the enable signal. To make the gated clock glitch free, you must generate the enable signal by a FlipFlop, which is clocked on the falling edge of the 100 MHz. -- MfG Falk P.S: Is there a difference/definition of glitch and runt pulse?Article: 46481
On Fri, 30 Aug 2002 15:09:17 GMT, spam_hater_7@email.com (Spam Hater) wrote: >Paul, > >The place to check to see if it's "very common" is Intel's PC100 >specification. > >IME, all SDRAMs will do auto-precharge, but... > >1) It's only useful if you always do the same size burst. > >2) It doesn't really save you any cycles. You activate C while >transferring from B, you can precharge A while transferring from B >also. Unless you're using precharge to terminate the burst... But you can't use auto-precharge in that mode anyway. > >$.02, >SH7 >Article: 46482
> I would like to know, if it is possible to have a top level schematic spread > over more than one sheet, I tried this but couldn't get it to work. If I understand your question, the answer is yes. Right click on an otherwise empty part of your schematic and click Object Properties. You'll see a property dialog for sheets. Click new. Then you can add sheets. The sheets will show tabs to the left. Nets named the same thing connect even if they don't look connected. You might be interested in our WebPack tutorial (we have one for Altera too) at http://tutor.al-williams.com Good luck! Al Williams AWC CPLD Prototyping boards: http://www.al-williams.com/pldhome.htmArticle: 46483
Excellent! Are there any more WebPack tutorials you can recommend for a total newbie like me? Frank "Al Williams" <alw@al-williams.com> wrote in message > > You might be interested in our WebPack tutorial (we have one for > Altera too) at http://tutor.al-williams.comArticle: 46484
In my latest project to shoehorn an impossible amount of functionality into a tiny pile of LUTs, I am once again banging my head against the tools. You already know how I feel about the demise of TBUF-based muxes. And how I found a way, using carry-logic and MULT_AND tricks, to implement o = sel ? a + b : c; in one LUT per bit. Call this an "addmux". Unfortunately the tools model the timing through this construction too pessimally. In my latest design, I would like to have a series of addmuxes in series, and the estimated timing is about 100% higher than reality (including several bogus charges of Topcyf and Tcinx) (in effect blowing out the cycle time). Please see http://groups.google.com/groups?selm=995523%24paj%241%40slb6.atl.mindspring. net for a recap and explanation of what I am talking about. In a nutshell, in implementing "o = sel ? a + b : c;" in one LUT per bit as described, the timing tools propagate delays along false paths from all inputs c[i] to all outputs o[j], j>i and unnecessarily incurring Topcyf and Tcinx on these false paths from c[i] to o[j]. A finer grained timing modeler could determine (by considering the slice's LUT and mux switch settings) that there is no carry out when sel is 0, and thus while there are timing paths from a[i] to o[j], j>i, and from b[i] to o[j], j>i, there are none from c[i] to its carry out, and thence to o[j], j>i, and no Topcyf and Tcinx on paths from c[i], either. In my design, to make timing, it appears necessary to unfactor both addmuxes into separate adds and muxes, two LUTs per bit: sum = a + b o = sel ? sum : c for which, even though twice as large and a Tilo slower, the timing tools do the right thing with. Proposal 1: It would be nice if this topolgy were automatically recognized by the path timer. Or... Proposal 2: I would also be happy to ANNOTATE the LUT asserting that input c[i] is insensitive to the carry chain and to asserting that c[i] delays do not propagate up the carry chain. Or... Proposal 3: I would also be happy to instantiate a special ADDMUX PRIMITIVE which rings the appropriate bells in the path timer, and sets the LUT and associated muxes up the same way I am trying to do manually. Or... Proposal 4: I would also be happy to use some convenient TIG like mechanism to deny these false paths. Currently it looks like I have to ignore the path from c[0] to o[1..31], from c[1] to o[2..31], ... c[30] to o[31], and so on for several dozens of such addmuxes in a big design. What do you think, Xilinx? Do you understand what I am asking for? Is it too far off the mainstream? If you fixed this, then the synthesis vendors could take advantage of this trick and halve areas of certain circuits. Ken McElvain, would Synplicity use this addmux technology mapping trick if the Xilinx path timer did a better job? Thank everyone, Jan Gray, Gray Research LLCArticle: 46485
Hi, Did anyone build a controller for thermoelectric coolers by PWM method and FPGAs? I want to do this, but i didn't know pwm frequency for 0.01C resolution. I guess there are other potential problems. please let know them best regards masoud naderiArticle: 46486
Hi Falk, Thanks for your reply. I have further checked the datasheet of Coolrunner-II. Actually they don't have clock doubler. However, it contains DualEDGE register which allows something like DDR operation inside. As a result, it allows a clock input which is half of your targeted operating frequency. Regards, Kenneth Falk Brunner wrote: > > "Kenneth" <kenneth.lee@terapower.com.hk> schrieb im Newsbeitrag > news:3D6F189F.972F1C46@terapower.com.hk... > > Dear All, > > > > Currently I have a design which is quite simple and am planning to > > implement it in a CPLD. However, the target operating speed is > > around 300MHz. > > > > After searching, I found that some CPLDs from Xilinx and Lattice > > are claimed to be able to operate at more than 300MHz. However, > > it seems that there is no PLL/DLL inside their CPLDs. So how can > > they operate at this high frequency? Does it mean that I need to > > AFAIR the new Coolrunner-II have a clock doubler inside. > > -- > MfG > FalkArticle: 46487
Thank you Al, this was of great help! Regards, Stephan FlockArticle: 46488
> Did anyone build a controller for thermoelectric coolers by PWM method > and FPGAs? > I want to do this, but i didn't know pwm frequency for 0.01C > resolution. Hi, I don't know what is relation between frequency of the PWM and temperature resolution. You may consider only PWM resolution. Is enough 8 bit resolution of the PWM only for setup temperature and 10 bit for adjust. Frequency of the PWM is important for thermal inertion of the adjusted object. Another matter is more easier solution by microcontroller with PWM. JanuszRArticle: 46489
Just a guess, but... IS this Virtex 2? In article <aksal0$oee$1@slb2.atl.mindspring.net>, Jan Gray <jsgray@acm.org> wrote: >Proposal 4: I would also be happy to use some convenient TIG like mechanism >to deny these false paths. Currently it looks like I have to ignore the path >from c[0] to o[1..31], from c[1] to o[2..31], ... c[30] to o[31], and so on >for several dozens of such addmuxes in a big design. Write a perl script to generate these? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 46490
> Are there any more WebPack tutorials you can recommend for a total newbie > like me? Glad you enjoyed the tutorial. I wrote it because I was very frustrated that there were few practical examples that actually talked about simulation. There are many good Verilog and VHDL tutorials, and a few that work with schematic entry. Most use Foundation or some other tool, too. http://www.ee.byu.edu/ee/class/ee224/tutorials/tools_tutorial/xilinx/xilinx.html has a terse tutorial. You can find many with a google search on WebPack and tutorial, but like I say, many ignore simulation. Al Williams AWC http://www.al-williams.comArticle: 46491
Wow, after posting, I did a quick google search and dug for some I had not seen before. This site has an excellent looking tutorial in PDF: http://www.trenz-electronic.de/down/tc-XC2S-SoC-2.pdf Geared at Spartan II, but the WebPack stuff is pretty much the same (pretty much, not exactly) no matter which part you are using. Al Williams AWC http://www.al-williams.com/pldhome.htmArticle: 46492
Hi, any thoughts on muxing a tristate bus? I have the following scenario in a Virtex design: About 10 blocks that all communicate to a CPU via a single tristate bus, one at a time of course. However, two of these blocks are deemed "safety critical". So, to enhance the design safety, it has been decided that these two blocks should be isolated from the rest. To this end, their outputs will be permanently enabled, and fed to a mux., but what to do with the other 8 or so blocks? It is a major redesign to make them all permanent outputs and mux all 10 buses. (Not difficult, but very time consuming). So, is it a "safe" design to put the 8 block tristate bus into the mux; the mux thus having 3 bus inputs and a single bus output to the CPU? I should add that I've built a noddy design that does just this, and no complaints from synth. or PAR. However, the RTL sim. gives different response to gate level sim. The RTL passes the 'Z's state thru' the mux (as expected), but the gate level sim. passes "FF" (all '1's) thru' the mux. when the tristate bus is selected (and undriven). This all seems OK, but not sure of the validity of it all. What exactly is pulling the tristate bus up within the chip, there is nothing obvious when looking at the chip editor. Any help much appreciated, NIV.Article: 46493
"Masoud Naderi" <naderimisc@yahoo.com> wrote in message news:2ba3bbea.0208312227.646e1ad3@posting.google.com... > Hi, > Did anyone build a controller for thermoelectric coolers by PWM method > and FPGAs? > I want to do this, but i didn't know pwm frequency for 0.01C > resolution. I guess there are other potential problems. please let > know them > best regards > masoud naderi I believe that TEC's are very sensitive to AC ripple on the DC power. I also believe that most TEC manufacturers do not recommend PWM for this reason.Article: 46494
The renowned Masoud Naderi <naderimisc@yahoo.com> wrote: > Hi, > Did anyone build a controller for thermoelectric coolers by PWM method > and FPGAs? > I want to do this, but i didn't know pwm frequency for 0.01C > resolution. I guess there are other potential problems. please let > know them The hardware on many microcontrollers will let you do this without an FPGA. I suggest you consider L-C filtering of the output, because, as another poster mentioned, the RMS-to-average ratio should be kept as close to 1 as possible, as these things are VERY inefficient, and you want to minimize I^2R heating. A frequency in the 20-40kHz range should be okay, and can be done by off-the-shelf micros with their onboard hardware. OTOH, if you used an FPGA you could go very high in frequency and use a smaller filter inductor, with a more sophisticated output stage. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com 9-11 United we StandArticle: 46495
Hi Nicholas Thanks for your response. This goes to everybody else as well. There are a few terms here that I am not familiar with, can you point me at a device so that I might understand "DLL" and "opad" Denis nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote in message news:<akob6o$1gpd$1@agate.berkeley.edu>... > In article <6f080894.0208291343.4746da5a@posting.google.com>, > Denis Gleeson <dgleeson@utvinternet.com> wrote: > >Hello all > > > >Im new to this FPGA design stuff so any help or redirection > >will be appreciated. > > > >My problem is this. I am feeding an FPGA with a 100MHz clock. > >Under certain conditions I want to feed this clock to a pin > >on my FPGA as an output. > >To allow for the condition I need to gate the Main clock > >with what I have below. > > One possibility, on a more modern part: You could take the 100 MHz > clock, feed it through the DLL to get a 200 MHz clock as well, have > THAT be the clock on the Opad flip flop, and have the 100 MHz clock, > gated, be the input to that flip flop. Voila, no clock glitching, > runt pulses, or anything. > > >PS. I am targeting a xilinx XC3020 > > You're making a 3020 run at 100 MHz? You sure you have the part > number right?Article: 46496
In article <6f080894.0209010952.24239dee@posting.google.com>, Denis Gleeson <dgleeson@utvinternet.com> wrote: >Hi Nicholas > >Thanks for your response. This goes to everybody else as well. > >There are a few terms here that I am not familiar with, can you point >me at a device so that I might understand "DLL" and "opad" OPAD is just the output pad. The current Xilinx parts include flip flops on the output pads. The DLL or Delay Lock Loop is present in Virtex/Spartan II and beyond, its the device for generating a clean clock. It can take an input clock and double it, and take both the clock and the doubled clock and distribute it across the chip. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 46497
Masoud, can you please explain to me and other non-experts: What is a thermo-electric cooler? Do you mean an electronic Peltier-effect device? Or do you mean a fan? Where do you get the sub-one-degree accuracy from, and why does it matter? I would think that the purpose is to cool the IC, and the difficulty is measuring the junction temperture. And at significant localized power dissipation, where and how do you measure the temperature? Lots of questins before we start arguing PWW frequency... Maybe I just do not understand the basics. Peter Alfke, Xilinx Applications Masoud Naderi wrote: > Hi, > Did anyone build a controller for thermoelectric coolers by PWM method > and FPGAs? > I want to do this, but i didn't know pwm frequency for 0.01C > resolution. I guess there are other potential problems. please let > know them > best regards > masoud naderiArticle: 46498
For the add-mux you're implementing, I used the following syntax in
Verilog to get the desired results:
o <= (sel ? a : c)
+ (sel ? b : 0);
which results in the carry chain / mult-and combo from the tool, no
tricks with primitives or with manually constructing carry chains. The
only conceptual trick is that the synthesis sees the adder at a level
above the logical manipulation - it's tough to look into a mux of two
adders for optimization but easier to add two muxes.
For the timing problems, I've used a "TPTHRU" constraint on a few items
that - with the appropriate wildcards - may give you what you need. In
the constraints guide for TPTHRU you'll find UCF syntax that might get
you going.
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/cgd/t9.html
There may be a need to stick to "one" through-point per spec, but syntax
would get you there even if the timing report is ugly (as long as you
have reliable naming). If multiple TPTHRU elements can be lumped
together, I'd expect something on the order of:
NET o_cry* TPTHRU = addmuxcry;
TIMESPEC TSloadTiming = FROM c[*] THRU addmuxcry TO o[*] 20 ns;
where 20ns is a value that's way beyond your timing needs (roughly
equivalent to a timing ignore) and the o_cry* would be the MUXCY output
net names. This allows the points from a or b through the carries to
still use the timespec defined elsewhere and from c[*] to o[*] directly
to also be specified. The FROM and TO points should both be flops which
might make the specification interesting in your cascaded addmux
elements but doable.
- John_hasntusedtbufinyears_H
Jan Gray wrote:
> In my latest project to shoehorn an impossible amount of functionality into
> a tiny pile of LUTs, I am once again banging my head against the tools.
>
> You already know how I feel about the demise of TBUF-based muxes. And how I
> found a way, using carry-logic and MULT_AND tricks, to implement
> o = sel ? a + b : c;
> in one LUT per bit. Call this an "addmux".
>
> Unfortunately the tools model the timing through this construction too
> pessimally. In my latest design, I would like to have a series of addmuxes
> in series, and the estimated timing is about 100% higher than reality
> (including several bogus charges of Topcyf and Tcinx) (in effect blowing out
> the cycle time).
>
> Please see
> http://groups.google.com/groups?selm=995523%24paj%241%40slb6.atl.mindspring.
> net for a recap and explanation of what I am talking about.
>
> In a nutshell, in implementing "o = sel ? a + b : c;" in one LUT per bit as
> described, the timing tools propagate delays along false paths from all
> inputs c[i] to all outputs o[j], j>i and unnecessarily incurring Topcyf and
> Tcinx on these false paths from c[i] to o[j].
>
> A finer grained timing modeler could determine (by considering the slice's
> LUT and mux switch settings) that there is no carry out when sel is 0, and
> thus while there are timing paths from a[i] to o[j], j>i, and from b[i] to
> o[j], j>i, there are none from c[i] to its carry out, and thence to o[j],
> j>i, and no Topcyf and Tcinx on paths from c[i], either.
>
> In my design, to make timing, it appears necessary to unfactor both addmuxes
> into separate adds and muxes, two LUTs per bit:
> sum = a + b
> o = sel ? sum : c
> for which, even though twice as large and a Tilo slower, the timing tools do
> the right thing with.
>
> Proposal 1: It would be nice if this topolgy were automatically recognized
> by the path timer. Or...
>
> Proposal 2: I would also be happy to ANNOTATE the LUT asserting that input
> c[i] is insensitive to the carry chain and to asserting that c[i] delays do
> not propagate up the carry chain. Or...
>
> Proposal 3: I would also be happy to instantiate a special ADDMUX PRIMITIVE
> which rings the appropriate bells in the path timer, and sets the LUT and
> associated muxes up the same way I am trying to do manually. Or...
>
> Proposal 4: I would also be happy to use some convenient TIG like mechanism
> to deny these false paths. Currently it looks like I have to ignore the path
> from c[0] to o[1..31], from c[1] to o[2..31], ... c[30] to o[31], and so on
> for several dozens of such addmuxes in a big design.
>
> What do you think, Xilinx? Do you understand what I am asking for? Is it
> too far off the mainstream? If you fixed this, then the synthesis vendors
> could take advantage of this trick and halve areas of certain circuits.
>
> Ken McElvain, would Synplicity use this addmux technology mapping trick if
> the Xilinx path timer did a better job?
>
> Thank everyone,
> Jan Gray, Gray Research LLC
>
>
>
>
Article: 46499Virtex chips use a tristate emulation for the internal tristates busses; there is no "undriven" state with undefined outputs (defaults to logic-high when undriven) and there is no bus contention (multiple drivers result in a zero winning out over ones). For some simulation problems with tristates in the past (old gate level models or possibly RTL), I defined the drivers as weak high, strong low and added pullups to the nets. The result is behavior like the tristate emulation logic - no drivers result in logic high and a single logic low for multiple drivers has a logic low result for the net. Perhaps you can work the strength and pullup into your RTL simulation. Niv wrote: > Hi, any thoughts on muxing a tristate bus? > > I have the following scenario in a Virtex design: > > About 10 blocks that all communicate to a CPU via a single tristate bus, one > at a time of course. > However, two of these blocks are deemed "safety critical". So, to enhance > the design safety, it has been decided that these two blocks should be > isolated from the rest. > > To this end, their outputs will be permanently enabled, and fed to a mux., > but what to do with the other 8 or so blocks? > > It is a major redesign to make them all permanent outputs and mux all 10 > buses. (Not difficult, but very time consuming). > > So, is it a "safe" design to put the 8 block tristate bus into the mux; the > mux thus having 3 bus inputs and a single bus output to the CPU? I should > add that I've built a noddy design that does just this, and no complaints > from synth. or PAR. However, the RTL sim. gives different response to gate > level sim. The RTL passes the 'Z's state thru' the mux (as expected), but > the gate level sim. passes "FF" (all '1's) thru' the mux. when the tristate > bus is selected (and undriven). This all seems OK, but not sure of the > validity of it all. > > What exactly is pulling the tristate bus up within the chip, there is > nothing obvious when looking at the chip editor. > > Any help much appreciated, NIV. > > >
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