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
Andy Peters wrote: > > When using FPGA Express, you tell it which file contains your top-level > entity. Let's use the FPGA Express GUI 'cause it's simple to start from > there. First, add all of your sources. They should automatically analyze > when you add them, and you can always force them to be analyzed. In the GUI, > there's a list-box that contains all of your entities. Click that list box > and select the name of the top-level entity. That's all there is to it. My design was a one-file design, so the problem was not caused by this. But since I have not yet created a multi-file design, I did not know how to tell FPGA Express which file was the top-level. So, thanks for this info. > My designs are all-VHDL and I haven't had a problem getting I/O pads to > automatically instantiate. (I did have a problem with IOFFs, but that was > "user error.") Guess what: my problem was user-generated as well. Like I said in the answer to Michel, I do not know exactly what caused the problem but it is solved now. Thanks for reaction anyway, -- name : Jo Depreitere | University of Ghent e-mail : jdp@elis.rug.ac.be | Electronics and Information Systems Dept. Phone : ++32+9/264 34 09 | Sint-Pietersnieuwstraat 41, B-9000 Ghent Fax : ++32+9/264 35 94 | http://www.elis.rug.ac.be/~jdpArticle: 15276
CALL FOR PAPERS 4th International Workshop on Applications of the Reed-Müller Expansion in Circuit Design August 20-21, 1999, University of Victoria, Victoria B.C., Canada Non-Restrictive topic list includes: AND-XOR representations, decision diagrams, spectral techniques, testability issues Submission Deadline: April 1, 1999 Submit 5 copies of drafts up to 20 pages in length to: Michael Miller, Workshop Chair Department of Computer Science University of Victoria Victoria, B.C., Canada V8W 3P6 or email PS, PDF, Latex or MS Word files to: rm99@csr.uvic.ca For more information: http://www.csr.uvic.ca/~mmiller/RM99Article: 15277
Check out the low cost solutions for PCs and FPGTAs at APS at http://www.apsfpga.com NO-SPAM damiano wrote: > Hi all, > > I just ended my studies to become an electronic engineer and I'd like > to start a few projects. > This is intended for learning purposes. > I heard that FPGA can be managed with a PC and a few hunred dollars, > is it true? > What can I do using FPGA at the moment? > > Damiano Rullo > Trezzano S/N > Milan, Italy > http://members.it.tripod.de/Damianoux/index.html > mailto: dmn@cheerful.com > mailto: damiano@mclink.it -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 15278
>This is a little more pain than I would personally want to endure for >FPGA based designs, but I agree with Tom ... a 1st order estimation of >power consumption seems like it should be fairly straight forward and >integral to a simulator environment ... the basic technique for >extracting node/gate parasitics needed for power simulation seems like >it should be similar to those already employed by place & route tools >for extracting a timing model (i.e. netlist & SDF file). I have said this lots of times. Dynamic power estimation would be an easy function to add to a simulator. I know I will be accused of pushing a conspiracy theory, but a power estimator would quickly show that an ASIC will have much lower dynamic Icc than an FPGA. This is largely because in an FPGA you are toggling a lot more stuff to achieve the same end. In one recent design I got a 5x improvement in an FPGA -> ASIC conversion, and this was critical for that battery powered product. And that improvement was *after* I had already used various dirty power-saving tricks in the FPGA, e.g. local clock nets, gated clocks, etc. Such tricks would have been dubious in an FPGA production application, unless done very carefully. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y. Please do NOT copy usenet posts to email - it is NOT necessary.Article: 15279
Due to expansion, MicroPix Technologies require an FPGA/ASIC engineer, to be based at their facility at Dalgety Bay, near Edinburgh, Scotland. For further details, visit http://www.micropix.comArticle: 15280
This is a multi-part message in MIME format. --------------30BCE1369BAE59146295E468 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think that even if it could be difficult, vendors has a lot of information to realize a tool to estimate power, Atmel's tools do it, even if the result represents a worst case, Why? Because they know some importants datas like internal capacitance, they have (I assumes) SPICE models of each internal sub-element, I have two years working in this and I can not estimate power consumption of a reel algoritm, because I need the information that vendors have, I can only make measurements. On the other hand, it is not easy because you need to estimate the activity of EACH NODE inside the FPGA, at leas you should be able to precise the toggling rate of the LUT, the DFF, the interconnect and the I/O. and that is only possible using a good simulation tool that allows to obtain the simulation of most part of internal nodes (MaxPLus II do it, and Foundation do it also, I don't know about the others). And even if you can do that, you need reels test vectors, you can not test an encoder using test vectors from a gray counter, or a filter using a sinoidal input signal with a little hammer, or something like that. If you know internal capacitances, load capacitances, the internal power distribution, and the activity rate of each node, you can, then, estimate power, and power, I repeat, doesn't depends on a K factor. Sorry about Altera. I found that most part of power comes from the logic elements itself and the interconnect, even the clock tree is not an important factor because I/Os consume more than clock buffer. Finally, some people think that power consumption in FPGAs is not important because this circuits are popular only to build prototypes and in prototypes power is not important, FPGAs are more and more used to build products because they are cheaper than Asic, and, talking about prototypes, I don't know if it's good idea to use a big 10 or 20 amps power supply in designs with FPGAs. In this case, power is becoming important. And I prefer not to talk about wireless applications based on FPGAs. Thank you for your coments, they will help me. Andres David --------------30BCE1369BAE59146295E468 Content-Type: text/x-vcard; charset=us-ascii; name="garcia.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Andres David Garcia Garcia Content-Disposition: attachment; filename="garcia.vcf" begin:vcard n:Garcia Garcia;Andres David tel;pager:http://www-elec.enst.fr/~garcia/index.html tel;fax:(33-1)45-80-40-36 tel;home:(33-1)-44-16-18-90 tel;work:(33-1)-45-81-78-03 x-mozilla-html:TRUE org:Ecole Nationale Superieure des Telecommunications;Communications et Electronique version:2.1 email;internet:garcia@elec.enst.fr title:PhD Student on Electronics and Communications adr;quoted-printable:;;46, rue Barrault=0D=0A;Paris;;75634;France fn:PhD Student end:vcard --------------30BCE1369BAE59146295E468--Article: 15281
Take a look at my website. There is a tutorial page there on multiplication in FPGAs, which will give you the basics of how it is done. For an FFT it is considerably more area efficient to use distributed arithmetic techniques than a brute force multiply and add/subtract. You might look at the Xilinx logicore for an FFT if it is the right flavor for what you are doing. Unfortunately, going that way does not provide much insight as to how it works, so if this is more of a learning experience then you'll have to slug through the sparse literature on distributed arithmetic and FFT implementations. You may find some early papers entitled something like "fastest FFT in the west" somewhere on xilinx's website (www.xilinx.com) that will give some hints. label wrote: > hello! > i'm looking for a design of a multiplier (16 bit) and a adder (19bit) > using FPGA xc4005. > I want to design a FFT module on FPGA > Thanks. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 15282
In FPGAs with carry chains, the performance of the optimized ripple carry chain is very difficult and expensive to improve upon until you get to about 30 bits. Even then, dividing it into upper and lower halves and using a fairly simple carry select scheme is hard to beat. On the other hand, if this is for a school project (and it does sound like it is to me too), then you can ignore the carry chains to try out other schemes. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 15283
As an exercise for our students we have developed and implemented a 16 bit minimal processor. The processor can address 64 kByte and supports hardware interrupts. It is built with 65 flip-flops and about 250 gates. The documentation and schematics can be found at ftp://137.193.64.130/pub/mproz/Article: 15284
To test our verilog model of an XC6216 I need a simple example (size of one 2:1 multiplexer) of configuration data as a raw bitstream or CAL-file. We have no XACTstep update for the 6200er series, but they have promised me (I think, it was summer '97) to install it soon... Kai WoskaArticle: 15285
Thanks for the link! The ambitious 440 page draft spec looks interesting, but I wonder within what horizon one can expect vendors of affordable tools to implement all that stuff? I have simplified my minimum requirements somewhat - here's MY draft spec 0.01 :) From a routed FPGA design, I want to be able to dump an ASCII text file consisting a series of lines containing node_name, C_node, and V_node values. node_name corresponds to that used in the simulation netlist, C_node in pF, V_node is voltage swing. Lines are ASCII sorted by node name. Optional extensions include R_pullup, V_pullup for bus pullup/pulldown power estimates. Buffered nets are reduced to a single equivalent C_node, V_node. Header may contain a DC_power term. Lines should be CR/LF terminated for WinDos compatibility. Vendors insecure about releasing C and V data could substitute a single P_node value, where P_node is energy per transition in picoJoules, though this would rule out pullup power calculations. Without activity data, this would be enough to estimate clock idle power if the clock nets were identified, and pathological (all nodes toggling) power. From the simulator, after running a test vector sequence, I want a text file, each line consisting of node_name, #transitions, where #transitions is the number of times the node toggled during the run. For pullup power, an optional duty_cycle value can be provided. (0 = constant low, 1.0 = constant high). Lines are also ASCII sorted by node_name. Header should contain a sim_duration value (in nanoseconds). The simulator should not play tricks that would distort the results (for example, not simulating unobserved nets) An Excel spreadsheet or trivial C program could easily do the rest. Sorting both files by node name eliminates the need to build symbol tables. Comments welcome. regards, tom Richard Guerin wrote: > <snipped> > > Guess the good news is that there is hope on the foreseeable horizon ... > Keep checking the IEEE P1481 Delay & Power Calculation Working Group > site http://www.eda.org/dpc/ > > BTW ... Does this mean that VITAL will become obsolete ? >Article: 15286
I've been looking through the details of a Virtex slice (1/2 of a CLB) using the editblock functionality of EPIC. I've run across a state that I want to verify cannot exist. At least as far as I can tell, provided you're not using the BY input, it's impossible to have Y=1, XB<>YB. That is to say, the following logic expression holds: Y*(XB@YB) = 0 where I have used the Xilinx syntax: * AND + OR ~ NOT @ XOR Can anyone confirm that this expression is invariably true? Alex Rast arast@inficom.comArticle: 15287
On Wed, 17 Mar 1999 11:01:15 -0800, Tom Burgess <tom.burgess@hia.nrc.ca> wrote: >Thanks for the link! The ambitious 440 page draft spec looks >interesting, >but I wonder within what horizon one can expect vendors of affordable >tools >to implement all that stuff? They have :-) >I have simplified my minimum requirements somewhat - here's MY draft >spec 0.01 :) > <snip> >From the simulator, after running a test vector sequence, I want a text >file, each line consisting of node_name, #transitions, where >#transitions >is the number of times the node toggled during the run. For pullup <snip> There follows below (attached) a zipped toggle report from ModelSim. It was generated from running a 4 bit counter in Virtex back annotated with sdf from M1.5i for 500 us with a 50 MHz clock. This gives you the node name, the toggle count, hazard count, the time spent at zero and one, and the time at x for float accounting etc. "All" it then requires is for the P&R tool to take the die, and annotate the necessary physical charactaristics, and your wish can come true with some parsing and simple math. So I wonder which FPGA vendor will have the (4/3 pi r cubed)'s to make that data available, or provide a tool to parse such a netlist and report power back. By using a combination of RTL code coverage for better testbench coverage toggle information and toggle coverage you can achieve some good Mr Alfke, would you care to pass comment? Cheers Stuart An employee of Saros Technology: Model Technology, Exemplar Logic, TransEDA, Renoir. www.saros.co.ukArticle: 15288
begin 644 report.zip
M4$L#!!0````(`&6I<2;E=+CQT`0``,X<```*````<F5P;W)T+G1X=+U9RY+J
M-A#=4\4_>)F[2*%NO9=99I-*I;+(3C7#,,1U9V#*F(3Y^PC)#R%;EN#>7"T8
M>X!SU*U^G#;KU>_'?W=-]<?NX]BTU:^'=M?\\_2V7G'2K?5J??N9Q/KM^+)S
M%W]N_9_:O[[OJE_:"L(;$M[\M5[]_'^N]6I^OW9MVMVI-<^[P_;OS?;M:U4Y
MH_U[[@_V7IC<](LDX4/P9G?:=8Z#[GO7%Z:U"!%9(7P$?7YK?Z)?[/\I(';?
MN[X@TU($NT<*A(@!16G-2N'Q"B^0,?^)!#R1'`<4C4R5PH.%!_MY'<%KR;CH
MX$%3H'2$9P"E\.1+!S>!)QH2\%**6_@0]WQNKP%CGL^O>W.J]^XH=01O%P#M
MX./(44K.['Z.HSZT"7A%",[#@WUS`A^#NZ#T\.X[`;Q%YUJ/P1('YC1R8O#Z
MPKBI+R#,T>U6A6D%C"JN%;H;R@50CG0,3*;9)#`3F[<'X-^?[AZ0]WBQ[R7O
MX&=0;;R8E_,',<2<FL-QQCDWB(Y+2CG"H\V#?O?+^)=C8R.'2B9#YSAG!6D%
MFBFF!W@.O(O[9?#MY_OY\CKU/0K)F4+M;ZA-:2')F+4VE%0Q_/Z;CG:98-\<
MWUU1T,O.$1S9`$_9F+7+\*\.?N*<*3RRL2A0R67QT<[YWB$2HB=<'MX&[7J5
MV??KIWDZ?1ZV]LKL3XTY-O[+DPB]QJ&[FD1HY?I*CN?RG7C<WR4RO"O1QM-`
MQ*+3P"[1$!07`;SK7T!57T.14@4C/%.$YS,!AT0#)6G8'BO)@4GM.S*SS8U)
M!D$F"(%EN_>9D&_N@A,UP%.F"^%])ER;.X_AZ=A]K7/"]DB#[IOU_:O??`RO
M*/,;OL(#<`RKD,Q$*-Z5"2C=U22$JFPFX%V9L,Q3S:V8W#+X-R)X"#-!1QTM
M@E\PJ%`HVH[3=T]+S?M,R,/W0G$22YR*(-'"6+H'OA.*F9[P\.X[H9CI"7/P
M4_W#N9>'%[/]:B\VM:D_7M)",:'DK%`<E5Q*P07P;DL!?-&(D7`),<=S:['-
MOCV9MJE[CH>D=((#$AP/30,)#DQP/#30)#AHBN.1F2PO&PW?U#!X*B>1"(SQ
M2K7BI0QD..^<A.0\5J@E\M&(3?U4;(60,%I!49=S/!?;(5C8A$3ZO&..T^ZM
MU!!;,&)!G)'"FZ>7AA3[286"&!9R+X2GY?"A#``ALTHRV'V!WI:AB,&KB"F`
MQV)X'B0T90L)'0AY(X=D*V#HY+UG*%#T7C\:-:1"`0<+="KE*GL&`\<0IGD2
MVSGBL7"9Q%)8)6]?%WK1S800]2(_.&=..Q!]/4W!``V!%N,*\S$;TKB',,G6
M+81.M&Y*\SX+Q6707J=3(Z<^[6Z,<\L6K0)[+C_"'C]I&<`A7_+MCP][J%Q$
M9/(EH.@K8G[NPN#X_5BW3.$J8K$%0H$<X"DHFITH@HHX/W=Q;]',W&57$3PN
MP5LUGH`'DBFX?J`S0,<CGJ5`3*A]*EC6_P-%HFW,/&0"&`.U9'KL*B*PH>PF
M[*`Z90=FLR$@24B0.4MD:`G<8<E0W&=-022)4_>/(I99BHM[#SLI[KFJB[/%
MO>"A#=`Q_:R>RQ:0'U3<<;:XSSX(L?5IL"=Z$")91K_A]RSNW4W,=P7-C;$E
MOY3E?ZS[AG7]G?(_4$L!`A0`%`````@`9:EQ)N5TN/'0!```SAP```H`````
M`````0`@`+:!`````')E<&]R="YT>'102P4&``````$``0`X````^`0`````
`
end
Article: 15289I created a very simple test to see if the part was configuring properly. The design just inverts a signal on one pin and puts it out on another. The bitstream appears to transfer without a hitch, since the download software doesn't complain about the DONE pin not going high. However, when I probe pins after configuration, the DONE pin is low, HDC is high, and LDC is low. It looks like the part didn't configure at all. I couldn't see any documentation on how to configure the part for use with the Parallel III cable, so I tried both master and slave serial. Apparently, the part is supposed to be configured as slave serial (MODE left floating). The bitstream appears to transfer without a hitch, since the download software doesn't complain about the DONE pin not going high. However, when I probe pins after configuration, the DONE pin is low, HDC is high, and LDC is low. It looks like the part didn't configure at all. I'm guessing that the bitstream may be invalid, since when I run bitgen, I get the message: Loading device database for application Bitgen from file "foo.bar". "foo" is an NCD, version 2.27, device xcs05, package pc84, speed -3 Loading device for application Bitgen from file 4003e.nph The last line confuses me. Why is it using 4003e.nph? When I checked the directories, I found that the Spartan XL has its own set of nph files, but the 5V Spartan device does not. Is it the same as the 4003's, or is bitgen using a default? Thank you, JeffArticle: 15290
On Wed, 17 Mar 1999 11:01:15 -0800, Tom Burgess <tom.burgess@hia.nrc.ca> wrote: >Thanks for the link! The ambitious 440 page draft spec looks >interesting, >but I wonder within what horizon one can expect vendors of affordable >tools >to implement all that stuff? Sounds like a good link - I must have a look when I've got a couple of hours spare. But, if it's like any other IEEE working group, then it'll be a few years before anyone notices it, and a few more before anyone does anything about it. >I have simplified my minimum requirements somewhat - here's MY draft >spec 0.01 :) I don't think this is practical, because everybody has to co-operate - the silicon vendor must produce the data, the simulator vendor must change their software to produce their dump file, and the end-user then has to do the donkey work with some other application. Here's another suggestion for a 'quick' fix. There's already an existing, proven, route to carry out half the problem - the SDF/VITAL combination. The silicon vendor already places timing data in the SDF file, and a simulator back-annotates this into the VHDL simulation model for the component. Wouldn't the easiest route be for the silicon vendor to add some more data to the SDF - at a minimum, the P_node value? This is then available to the VHDL model for the component, and it can then simply add up the energy as it goes along, and produce a power value at the end of the simulation. There are 3 stages here - 1) the silicon vendor adds an optional extension to the SDF output - this feels like it should be straightforward 2) the model writer can use this data to produce power for this component (including nets into the component) 3) this is the fly in the ointment. The simulator vendor has to back-annotate the P-node data into the VHDL model, and getting them to accept SDF extensions would almost certainly be a problem. One quick fix here would be to redefine an existing value which is already back-annotated, but which isn't normally used. For instance, the silicon vendor could put the required data into the delay from a 'Z' to an 'X', which - I guess - is unlikely to be used by any FPGA simulation. Any thoughts? EvanArticle: 15291
Hi, This can result from the absence of Windows NT Service Pack 3. WinNT Service Pack 3 is required to run Foundation F1.5/F1.5i. Service Pack 3 may be downloaded from Microsoft at http://www.microsoft.com Hope this helps Pete. Andres David Garcia Garcia wrote: > I'm trying to install Foundation 1.5i in my computer, and I have > the following error : > > pcm : automation caused an exception, exit code 80080005 > > I'm using windows NT and a license for a IP addresse. > > Did anybody see this error message in Foundation 1.5i version? > > thank you.Article: 15292
Here's a designer's perspective: 1. Peter, your snotty comment about Altera's K-factor is most unbecoming. Your demeanour is usually more professional. Xilinx is not in a position to claim the high moral ground. 2. Peter's arguments that to do a good job, "you need a complete undestanding of..." (and so forth), are (deliberately or otherwise) ducking the issue. Engineering is not an exact science; wafer fab or fpga production are (similarly) inexact sciences. We deal in practical reality, folks, not theoretical certainty. (At least not *all the time*!). 3. It is frustrating that, in the absence of a "perfect" power estimation tool, the silicon vendors have so far provided nothing in the way of an automated tool or aid. This is, and has been (for *years*) an ongoing issue with both of the two largest FPGA vendors in the industry (who shall go nameless :=) ). 4. On one hand, Peter's point that you can "try them out without spending a fortune and waiting for months" is bogus on two counts. a. "trying them out" is very expensive in terms of design time and resources. Parts cost is *not* the measure of the cost of experimentation. b. "trying them out" is incredibly inexact, given the uncertainty over process (and speed-power product) variations from lot to lot. You could build a thousand prototypes without any certainty that next week's production would match (in terms of power dissipation). This is the great fallacy of gathering real-life experimental data and extrapolating into the future. It is darn near impossible to get a "random and representative sampling" of parts, unless you are the manufacturer. 5. Having said that perfectly accurate results from a either a power estimator, or from sample testing, are unattainable; there is still a compelling argument for a software power estimation tool. Relative power estimation. You have a design, you get a power estimate from your handy dandy estimation tool. You know the "absolute number is bogus, but that doesn't stop you from continuing your design project. You *think* you're close to the limit of power/heat/current. You make some design changes. Did the changes improve the situation, did the problem get worse, or is the power consumption unchanged? The power estimator tells you that your "absolute power consumption" has dropped by 15%. The absolute Watts figure may be bogus, but this is still good news. This saved you hours of fussing and prototyping. Thank you, power estimator! Another "take" on the power estimation tool: You know that the tool doesn't give accurate absolute numbers. But over time, you've learned from experience that for certain distinct types of designs (e.g. data paths doing number crunching, microprocessor interface logic, etc.) there are different scale factor you can apply to infer the *real* power levels from the power estimates generated from the tool. Your cognitive skills have bridged the gap from this imperfect tool to real-life expectations. I apologize for the "venting", but my conviction is that some FPGA vendors that we all know and love have simply got their heads stuck in the sand when it comes to this particular issue. I get impatient with the standard pro-forma position 'if we can't do it right [whatever marketing thinks that means at the time], we won't want to do it (at all)'. PLEASE! Suggestion: Provide a spreadsheet type of tool that a. groups power consumption "factors" (e.g. gross net capacitance, gross gate capacitance) by clock net "driving" the power consuming components. b. provides parameters for each group (each group is driven by a different clock!) for i. clock frequency ii. average toggle factor (# clock cycles between state changes) c. multiplies the right correction factors by the entered parameters and the derived gate count/capacitance numbers, and adds the products to an estimated power consumption number, taking into account the process parameters (or range of parameters) for the fpga in use. It won't be perfect, its results won't be guaranteed, but it would still be a *big* help. And my guess is that the data required to "code" this is already lying around in the engineering dept. Does anyone agree that this would help ? Does anyone agree that this is worth doing ? Does anyone have any better solutions, or improvements ? Peter, we've discussed this once or twice in the last 8 years (or so). Has anything really changed ? -- Bob Elkind Peter Alfke wrote: > > Thanks, Andres. You hit the nail right on the head. > > The existing power consumption estimators are just > bookkeeping spreadsheets that add up all the power > ingredients. The manufacturers obviously know all the > capacitances and the internal voltage swings on each node. > Missing is just one "tiny" ingredient: the toggle rate of > each node. > Finding that toggle rate is left as an "exercise for the > student". Altera's silly invention of a k-factor just tries > to make you believe that everything behaves like a 16-bit > counter. No such luck! > > To estimate dynamic power, you need a complete understanding > of all fast-moving nets in the design, which therefore means > you need information about the statistical behavior of all > chip inputs plus of course the easy part, the internal chip > design. > And you need accuracy. Plus-minus 30% would give you a > two-to-one power uncertainty, which is really worthless when > you are concerned about thermal issues. ( Perhaps acceptable > when you are only concerned about battery life ). > > FPGAs have a big advantage over ASICs: > You can try them out without spending a fortune and waiting > for months. > Sounds corny, but it's still the best advice.. > I'll be the first to sing the praise of a real power > estimator. > I'm taking singing lessons... > > Peter Alfke, not trying to start a flame war.Article: 15293
Hmm. Looks like this would do just fine. I assume that this was from the ModelSim Elite ~$20,000 (U.S.) tool? Regrettably this exceeds my nonexistent tools budget by a couple of orders of magnitude, but it does serve as an existence proof. Stuart Clubb wrote: > > There follows below (attached) a zipped toggle report from ModelSim. > > It was generated from running a 4 bit counter in Virtex back annotated > with sdf from M1.5i for 500 us with a 50 MHz clock. This gives you the > node name, the toggle count, hazard count, the time spent at zero and > one, and the time at x for float accounting etc. > regards, Tom BurgessArticle: 15294
> Apparently, the part is supposed to be configured as slave serial (MODE > left floating). Though the MODE pin has a weak pullup (so leaving it floating should be OK....), I don't leave that to chance. You might want to stick a scope on the mode pin and see what it looks like. What did you do with the INIT pin? That is a very sensitive pin, and would put the part into reconfiguration if not used properly. Do you have a pullup on it, and make sure it's not tied to any signals on your board. Also, make sure pins M1 and M2 are not connected. I basically have my parts hooked up as follows: M0 = jumper to +5 (thru resistor) or Gnd M1 = unconnected M2 = unconnected DIN - DATA of PROM and pin 5 of config header CCLK - CLK of PROM and pin 3 of config header /INIT - 10k pullup, /OE of PROM and pin 7 of config header DONE - /CE of PROM and pin 4 of config header /PROGRAM - pin 6 of config header VPP of PROM is tied to +5, and /CEO is left unconnected, power and ground are hooked up as they should be... I also have pin 1 of config header tied to +5 and pin 2 to GND Good luck, AustinArticle: 15295
ems@riverside-machines.com.NOSPAM wrote: > <snipped> (sorry, my fascist news server hates long quotes)> > > I don't think this is practical, because everybody has to co-operate - > the silicon vendor must produce the data, the simulator vendor must > change their software to produce their dump file, and the end-user > then has to do the donkey work with some other application. > As a matter of expedience, I thought it might be easier to get vendors to bolt on a quick and dirty dump utility than to get them to come to an agreement with other vendors about ad hoc SDF extensions. I don't know if either is realistically possible. Vendors might be tempted to avoid easy piecemeal solutions now in favor of universal do-all standards like P1481 (who knows how much later?). regards, Tom BurgessArticle: 15296
Jeff Hunsinger wrote: > I created a very simple test to see if the part was > configuring > properly. The design just inverts a signal on one pin and > puts it out on > another. > snip > > The bitstream appears to transfer without a hitch, The > last line confuses me. Why is it using 4003e.nph? When I > checked the > directories, I found that the Spartan XL has its own set > of nph files, > but the 5V Spartan device does not. Is it the same as the > 4003's, or is > bitgen using a default? > > The best way to check whether the configuration has at least started on the right foot, is to look at Dout, which must mimic Din for the first 40 bits, including the length count, and then go High again. No preamble output on Dout = no configuration, usually because of the wrong mode.If the configuration starts properly, but later runs into a bit or clock error, CRC will detect that and pull INIT Low again. DONE must go High to indicate successful configuration. We keep you informed ! If you leave the mode pin floating, check at least with a scope or multimeter whether it is properly High. XC4003E and XCS10 are functionally so similar that they share a bitstream, but XCSxxXL is quite different from XC4000XL ( less routing, fewer bits in the bitstream). Peter Alfke, XilinxArticle: 15297
bob elkind wrote: > Here's a designer's perspective: > > 1. Peter, your snotty comment about Altera's K-factor is > most unbecoming. Have to blow my nose and wipe my tears. Don't want to be snotty. PeterArticle: 15298
In article <36f015d9@news.nwlink.com>, Alex Rast <arast@inficom.com> wrote: >I've been looking through the details of a Virtex slice (1/2 of a CLB) using >the editblock functionality of EPIC. I've run across a state that I want to >verify cannot exist. At least as far as I can tell, provided you're not using >the BY input, it's impossible to have Y=1, XB<>YB. That is to say, the >following logic expression holds: > >Y*(XB@YB) = 0 > This is nonsensical question since Y, XB and YB are all outputs. It is highly irregular to think of outputs as a "state" of a slice, since the outputs are solely dependent on the slice configuration and the inputs to the slice. If you change the inputs then you change the outputs. If you change which basic elements (LUT, MUXCY, XORCY, MULT_AND, MUXF5, MUXF6, Register) are connected to which you change the input-to-output function. But since you asked, the above "equation" is not true. It is possible to get the following output values at the same time from the same slice, Y=1, YB=0, XB=1 which would give you a 1 in the above "equation". And you can do this without using the BY input. It requires 1 LUT, 2 MUXCY (XB, YB) and 1 XORCY cell (Y). The LUT would be the top one (G) and configured to only generate a 0. The Bottom MUXCY is configured with a static S of 1 and the BX mux configured as a 0. The output of the lower MUXCY is connected to the upper MUXCY and XORCY with the other output driven from assoiciated LUT. There are some other alternative ways of achieving the same result as well. What use this has is beyond me, but it can be done. Ed McGettiganArticle: 15299
Got an email response to my queries last week about Actel SX free tool support and on IBIS model availability: Dear Tom Burgess, I saw your message below. I thought I should respond to your questions: 1. Free tools definitely include all current SX devices: SX08, SX16, SX16P and SX32. 2. The SX IBIS models were just put on the Web last week in the IBIS models area. From the Actel home page: Click on Applications Click on Actel User's Page Scroll down and enter your email address on the bottom of the page Click on IBIS models Please let me know if you are unable to access them. Thanks Yousef Khalilollahi Director of Product Marketing Actel Corporation Tom Burgess wrote: > > At the risk of turning this into a "fast FPGA I/O" thread, > I have no problem with vendors pushing uniquely fast parts backed by > good data and application notes. The SX parts have very nice I/O > timing and are certainly worth a look. (http://www.actel.com) > It wasn't clear to me whether or not the free tools actually > support the SX parts yet. This would definitely encourage > designers with limited tool budgets to give them a try. > Availability of SX IBIS I/O models would be nice, too (they > weren't in the IBIS area when I checked) > -- Tom Burgess
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