Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 15275

Article: 15275
Subject: Re: Inferring IO's
From: Jo Depreitere <jdp_nospam@elis.rug.ac.be>
Date: Wed, 17 Mar 1999 10:12:20 +0100
Links: << >>  << T >>  << A >>
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/~jdp
Article: 15276
Subject: CFP: Reed-Muller Workshop
From: Mitch Thornton <mitch@mail.dicksonstreet.com>
Date: Wed, 17 Mar 1999 06:02:24 -0600
Links: << >>  << T >>  << A >>
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/RM99



Article: 15277
Subject: Re: Want to learn about FPGA.
From: APS <resp@associatedpro.com>
Date: Wed, 17 Mar 1999 07:07:43 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: Power Estimiation
From: z80@ds2.com (Peter)
Date: Wed, 17 Mar 1999 12:36:08 GMT
Links: << >>  << T >>  << A >>

>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
Subject: Vacancy - FPGA/ASIC engineer - Scotland
From: "MicroPix Technologies" <info@micropix.com>
Date: Wed, 17 Mar 1999 14:15:41 -0000
Links: << >>  << T >>  << A >>
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.com



Article: 15280
Subject: Re: Power Estimiation
From: Andres David Garcia Garcia <garcia@elec.enst.fr>
Date: Wed, 17 Mar 1999 16:32:36 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: help!
From: Ray Andraka <randraka@ids.net>
Date: Wed, 17 Mar 1999 10:34:50 -0500
Links: << >>  << T >>  << A >>
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/~randraka


Article: 15282
Subject: Re: How can I improve an adder?
From: Ray Andraka <randraka@ids.net>
Date: Wed, 17 Mar 1999 10:41:13 -0500
Links: << >>  << T >>  << A >>
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/~randraka


Article: 15283
Subject: 16 bit minimal processor
From: klee@mistress.informatik.unibw-muenchen.de (Herbert Kleebauer)
Date: Wed, 17 Mar 1999 09:02:14
Links: << >>  << T >>  << A >>

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
Subject: Searching binary data for configurating Xilinx XC6216
From: Kai Woska <woska@ti.et-inf.uni-siegen.de>
Date: Wed, 17 Mar 1999 17:08:32 +0100
Links: << >>  << T >>  << A >>
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 Woska
Article: 15285
Subject: Re: Power Estimiation
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Wed, 17 Mar 1999 11:01:15 -0800
Links: << >>  << T >>  << A >>
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
Subject: Allowed logic functions in Virtex LE
From: arast@inficom.com (Alex Rast)
Date: Wed, 17 Mar 1999 20:51:37 GMT
Links: << >>  << T >>  << A >>
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.com

Article: 15287
Subject: Re: Power Estimiation - report.zip (0/1)
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Wed, 17 Mar 1999 21:56:18 GMT
Links: << >>  << T >>  << A >>
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.uk
Article: 15288
Subject: Re: Power Estimiation - report.zip (1/1)
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Wed, 17 Mar 1999 21:56:19 GMT
Links: << >>  << T >>  << A >>
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: 15289
Subject: Xilinx Spartan configuration troubles
From: Jeff Hunsinger <huns@mediaone.net>
Date: Wed, 17 Mar 1999 16:13:30 -0600
Links: << >>  << T >>  << A >>
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.

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,
Jeff
Article: 15290
Subject: Re: Power Estimiation
From: ems@riverside-machines.com.NOSPAM
Date: Wed, 17 Mar 1999 22:19:28 GMT
Links: << >>  << T >>  << A >>
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?

Evan

Article: 15291
Subject: Re: Problems with foundation
From: Fernley Boxall <boxalls@sparbox.demon.co.uk>
Date: Wed, 17 Mar 1999 22:26:45 +0000
Links: << >>  << T >>  << A >>
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
Subject: Re: Power Estimiation
From: bob elkind <eteam@aracnet.com>
Date: Wed, 17 Mar 1999 14:33:25 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Power Estimiation - report.zip (0/1)
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Wed, 17 Mar 1999 14:58:34 -0800
Links: << >>  << T >>  << A >>
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 Burgess
Article: 15294
Subject: Re: Xilinx Spartan configuration troubles
From: "Austin Franklin" <austin@dark9room.com>
Date: 17 Mar 1999 23:05:20 GMT
Links: << >>  << T >>  << A >>
> 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,

Austin

Article: 15295
Subject: Re: Power Estimiation
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Wed, 17 Mar 1999 15:38:14 -0800
Links: << >>  << T >>  << A >>
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 Burgess
Article: 15296
Subject: Re: Xilinx Spartan configuration troubles
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 17 Mar 1999 16:43:51 -0800
Links: << >>  << T >>  << A >>
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, Xilinx
  

Article: 15297
Subject: Re: Power Estimiation
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 17 Mar 1999 16:57:11 -0800
Links: << >>  << T >>  << A >>
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.

Peter

Article: 15298
Subject: Re: Allowed logic functions in Virtex LE
From: mcgett@feynman.xsj.xilinx.com (Ed McGettigan)
Date: 17 Mar 1999 17:26:29 -0800
Links: << >>  << T >>  << A >>
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 McGettigan
Article: 15299
Subject: Re: experience with Xilinx 4K series I/Os
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Wed, 17 Mar 1999 17:44:28 -0800
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search