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
Hello, My VHDL model contains the following code: .... constant BITS: integer := 8; .... subtype Addresses is std_logic_vector((BITS-1) downto 0); constant ADDRESS_ZERO : Addresses := "00000000"; constant ADDRESS_THREE : Addresses := "00000011"; This code has two disadvantages: 1. When the value of BITS changes to let's say 9, the value of the constants ADDRESS_ZERO and ADDRESS_THREE must be adjusted to have the right number of bits. 2. The values of the constant ADDRESS_THREE is given in binary radix, I would prefer to have it in decimal form. Andy idea how to fix these two problems ? Thanks, TalArticle: 44901
Please ignore my previous postings. Apparently I posted them to the wrong group (FPGA, should be VHDL). If you would like to help anyway, you can reply by email or respond to my postings in comp.lang.vhdl ;-) Thanks, TalArticle: 44902
Use ieee.numeric_std
address<=std_logic_vector(to_unsigned(3*count,8)); -- 8 is the number
of bits, you can also use to_signed
ted_jmt@zapta.com wrote:
> Hello,
>
> I am new to VHDL and am looking for a cleaner way to perform type
> conversion from integer to std_logic_vector.
>
> My existing code looks like
>
> ....
>
> constant COUNT : integer := 120;
>
> ....
>
> subtype Addresses is std_logic_vector(7 downto 0);
>
> constant ZERO_ADDRESS : Addresses := "00000000";
>
> ....
>
> signal ADDRESS: Addresses;
>
> ....
>
> ADDRESS <= ZERO_ADDRESS + (3 * COUNT); --- CONVERSION
>
> Is there a more elegant way to perform the type conversion from the
> integer expression (3 * COUNT) to Addresses in the last statement ?
>
> Thanks,
>
> Tal
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 44903
On Thu, 04 Jul 2002 17:04:35 -0700, ted_jmt@zapta.com wrote:
>Hello,
>
>My VHDL test bench looks like:
>
> ...
>
> DATA <= "0000001";
> wait 1us;
> CLK <= '1';
> wait 1us;
> CLK <= '0';
> wait 1us;
>
> '''
>
>Is there a way to write a macro or function such that the above code
>can be invoked with something like:
>
> CYCLE("00000001");
> CYCLE("00000001");
>
>I am new to VHDL so please be specific in your answer (e.g., where the
>macro/function should be defined, its syntax, etc).
Hi Tal,
You need to use a *procedure*. Procedures in VHDL can be declared
inside a process, in which case the procedure shares drivers with the
process. You can call it as written in your example above.
Procedures can also be declared outside the scope of a process, in
which case the signals to be driven by the procedure must be passed to
the procedure as arguments.
You will need to call it as CYCLE(CLK, DATA, "0000001");
But take note of Ben Cohen's reply in news:comp.lang.vhdl
He suggested having a clock generator:
clk <= not clk after 1 us;
and then a separate process to generate the data.
process (clk)
begin
if rising_edge(clk) then
data <= stuff;
...
etc.
Regards,
Allan.
Article: 44904Ray Andraka <ray@andraka.com> writes: > Use ieee.numeric_std > > address<=std_logic_vector(to_unsigned(3*count,8)); -- 8 is the number > of bits, you can also use to_signed > Or even use unsigned (or even integer) as the type for your address - fundamentally, it's a number after all, not just an arbitrary collection of bits, which is what a std_logic_vector implies to me... Just a small hobby horse of mine, as I see too much code written in a strongly typed language which doesn't take advantage of the types, so std_logic(_vector) is used for almost everything, except constants for some reason... All IMHO of course! Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 44905
"Nathan Baulch" <nathan.baulch@microsell.com.au> wrote in message news:3d22523a$1@post.newsfeed.com... > *** post for FREE via your newsreader at post.newsfeed.com *** > > Why is my "Run" button disabled? > > I have: > - created a project > - inserted my VHDL files > - ensured that the last one in the list is the main one > - setup my implementation options > > Am I missing something? > Perhaps there is a simple tutorial I could find online somewhere? > > > Cheers. > > Nathan Baulch > > > > > -----= Posted via Newsfeed.Com, Uncensored Usenet News =----- > http://www.newsfeed.com - The #1 Newsgroup Service in the World! > -----== 100,000 Groups! - 19 Servers! - Unlimited Download! =----- I can only think of a problem with your license key settings... Check it with the synplify's support group. You can write an email to them and usually the answer very quickly. Regards ArashArticle: 44906
ted_jmt@zapta.com writes: Similar answer given above to another query, but... > Hello, > > My VHDL model contains the following code: > > .... > > constant BITS: integer := 8; > > .... > > subtype Addresses is std_logic_vector((BITS-1) downto 0); > Why not use ieee.numeric_std, and then use the unsigned type for your address, which after all is a number? > constant ADDRESS_ZERO : Addresses := "00000000"; > constant ADDRESS_THREE : Addresses := "00000011"; > Then you can do constant ADDRESS_ZERO : Addresses := to_unsigned(0, Addresses'length); constant ADDRESS_THREE : Addresses := to_unsigned(3, Addresses'length); of course if you want to stick with slvs, you can constant ADDRESS_ZERO : Addresses := std_logic_vector(to_unsigned(0, Addresses'length)); constant ADDRESS_THREE : Addresses := std_logic_vector(to_unsigned(3, Addresses'length)); > This code has two disadvantages: > > 1. When the value of BITS changes to let's say 9, the value of the > constants ADDRESS_ZERO and ADDRESS_THREE must be adjusted to have the > right number of bits. > The above code now deals with this directly > 2. The values of the constant ADDRESS_THREE is given in binary radix, > I would prefer to have it in decimal form And this... Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 44907
"Ken Mac" <aeu96186@yahoo.co.uk> wrote in message news:afueiq$qcc$1@dennis.cc.strath.ac.uk... > > Hello folks, > > I use Active-HDL 5.1, Synplify 7.x and Xilinx ISE 4.x. > > At the moment I do my HDL entry and simulation in Active-HDL, then use > Synplify (creating a new project in Synplify manually) to synthesise and > then invoke ISE from Synplify to implement designs. > > I know Active-HDL 5.1 offers the full flow from its frontend and I was > wondering if anyone is/has using/used it and if it is any good? > > If it works - I guess it would make doing things like back annoted > simulation really easy? > > So - what do you guys do for the flow? > > Thanks for your time, > > Ken > > Hi Last time I tried, it only worked with Synplify Pro, not Synplify. KateArticle: 44908
Hi, Does anybody know where can I download the complete Triscend SDK CD-ROM? I bought the Triscend A7 Development Kit, but the package don't include the SDK CD-ROM. LaurentArticle: 44909
NOTE: don't use ieee.std_logic_arith and ieee.numeric_std in the same entity or arch. or package ! Laurent www.amontec.com Markus Sponsel wrote: > Hi Ted, > > >>My VHDL model contains the following code: >> >> .... >> >> constant BITS: integer := 8; >> >> .... >> >> subtype Addresses is std_logic_vector((BITS-1) downto 0); >> >> constant ADDRESS_ZERO : Addresses := "00000000"; >> constant ADDRESS_THREE : Addresses := "00000011"; >> >>This code has two disadvantages: >> >>1. When the value of BITS changes to let's say 9, the value of the >>constants ADDRESS_ZERO and ADDRESS_THREE must be adjusted to have the >>right number of bits. >> > > a solution could be: > > constant ADDRESS_ZERO : Addresses := (OTHERS => '0'); > constant ADDRESS_THREE : Addresses := (0 => '1', 1 => '1', OTHERS => '0'); > > >>2. The values of the constant ADDRESS_THREE is given in binary radix, >>I would prefer to have it in decimal form. >> > > you could include the library ieee.std_logic_arith (others will state > that you should use numeric_std) and could use a conversion function: > > constant ADDRESS_THREE : Addresses := CONV_STD_LOGIC_VECTOR(3,BITS); > > hope this helps a bit, > > Markus Sponsel > > ################################################# > profichip GmbH > Einsteinstraße 6 > 91074 Herzogenaurach > Germany > > Tel.: +49.9132.744-205 > Fax: +49.9132.744-204 > > email: MSponsel@profichip.com > www: www.profichip.com > ################################################# > >Article: 44910
Hi I am using the free version of Symphony EDA Simili. As far as simulation is concerned, you have to use a test-bench where the test bench feeds data to the module under test. I am trying to implement a data bus in the module under test hence it must be bi-directional. I have declared the bus of type INOUT, I have created a component of the entity and used it in the test-bench as well. The problem that I am having is that the data that I am writing from the test bench is not being read correctly by the module. When I print out what is on the data bus in the module, I get a string of "U"s. Before reading in the data, I write a string of "Z"'s to the data bus. Is this correct as far as setting the port to high impedance is concerned? Surely once the port is set to "Z" then you should be able to read from it? Could there be a problem from the test-bench side? If anyone can suggest anything, it would be greatly appreciated. Thanks RyanArticle: 44911
Hello, I am new to FPGA development boards; I would like to know what are the added advantages if I will to chose Celoxica RC100 over RC1000 board. I would like to use RC100 board due to its portability but was afraid that I would miss out on some of the RC1000's advantages. Any advice would be greatly appreciated. Thanks, lktanArticle: 44912
> -----Original Message-----
> From: John Williams [mailto:j2.williams@qut.edu.au]
> Does anybody know of a synthesisable VHDL package/library for
> generalised fixed point arithmetic?
>
> I'm picturing a scheme whereby you specify the number of
> fractional and
> integer bits in the operands and result, and it handles the shifts and
> bit padding etc seamlessly. Supported ops would be addition,
> subtraction, multiplication, with signed and unsigned
> options, that sort
> of thing (basically an extension to the existing signed/unsigned
> support).
Adelante (www.adelantetechnologies.com) have A/RT Library
which is a C++ fixed point package, with all the benefits (?!)
of C++ type templates, and A/RT Builder which can compile the
C++ FP descriptions into VHDL. It will cost you serious money.
It's a bit tricky in VHDL because there is nothing like C++
or Ada type templates. We really need a std_logic_vector
to carry around with it some meta-data describing its fixed
point format, but of course we don't want that meta-data
to be synthesised in any way - it should just influence
compilation.
Hey, I have a really good idea... VHDL arrays DO carry some
meta-data round with them... in their subscript range. In
ordinary VHDL-land, an UNSIGNED(7 DOWNTO 0) is entirely
equivalent to an UNSIGNED(9 DOWNTO 2). How say we invent
a new type UFIX in which the lower (right) subscript bound
determines the position of the binary point? Here's a bit
of a package to get this idea started. Right at the end there's
also a procedure AddAndTrunc() which gives some ideas about how
the return value from the "+" operator could be processed.
I suspect a suitably creative RESIZE() function could be written
to do any re-scaling you might need.
If I'm feeling energetic I might expand this a bit over the
weekend. I can already see some potential difficulties, but
maybe it's worth the effort nonetheless...
-------------------------------- start code snippet --------------
---
--- These packages describe fixed point arithmetic based around
--- the existing numeric_std package.
---
--- You need to decide the maximum number of binary-fraction digits
--- that will be used anywhere in your design, and set up the
--- CONSTANT Point to be that number. Now if you want to set up
--- a fixed-point number with (say) five integer bits and three
--- fraction bits, you declare it like this:
---
--- SUBTYPE UFix_5_3 IS UFix(5+Point-1 DOWNTO Point-3);
--- You can sugar the syntax of constants thus:
--- CONSTANT Hogwarts_Platform: UFix_5_3 :=3D "01001" & "110";
--- 9 . 75
---
--- An N-bit whole-number (integer) should then be declared
--- as UFix(N+Point-1 DOWNTO Point).
---
--- Any subprogram that gets one of these values as an actual
--- parameter can then look at 'LEFT and 'RIGHT and use them
--- to determine the required scaling.
---
--- Note that the choice of value for Point doesn't constrain
--- your choice of width and precision in any way, except that
--- it limits the maximum number of fraction bits that can be
--- used anywhere in your design.
PACKAGE fixed_point_config IS
CONSTANT Point : natural;
END;
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;
PACKAGE fixed_point IS
-- Unsigned fixed point
TYPE UFix IS ARRAY (natural RANGE <>) OF std_logic;
-- Signed fixed point
TYPE SFix IS ARRAY (natural RANGE <>) OF std_logic;
-- Fixed point addition, unsigned
FUNCTION "+"(L, R: UFix) RETURN UFix;
-- ... and many more ! ...
END;
PACKAGE BODY fixed_point IS
-- Max and Min functions needed for some of the routines
FUNCTION max(A, B: natural) RETURN natural IS
BEGIN
IF A>B THEN
RETURN A;
ELSE
RETURN B;
END IF;
END; -- max()
FUNCTION min(A, B: natural) RETURN natural IS
BEGIN
IF A<B THEN
RETURN A;
ELSE
RETURN B;
END IF;
END; -- max()
-- Fixed point addition, unsigned
FUNCTION "+"(L, R: UFix) RETURN UFix IS
-- Find how much space we need
CONSTANT L_max : natural :=3D max(L'LEFT, R'LEFT);
CONSTANT R_min: natural :=3D min(L'RIGHT, R'RIGHT);
-- Invent a suitable subtype
SUBTYPE widest IS unsigned(L_max DOWNTO R_min);
-- Variables to do the calculations
VARIABLE LL, RR, SS: widest :=3D (OTHERS =3D> '0');
BEGIN
-- Normalise both parameters
LL(L'RANGE) :=3D unsigned(L);
RR(R'RANGE) :=3D unsigned(R);
-- Generate result
RETURN UFix(LL + RR);
END; -- UFix :=3D UFix + UFix
-- Example of how we could exploit this functionality...
--
PROCEDURE AddAndTrunc(L, R: in UFix; S: out UFix) IS
-- This CONSTANT declaration lets us capture the
-- subscript range created by the "+" operator.
CONSTANT SS: UFix :=3D L+R;
BEGIN
S :=3D SS(S'RANGE);
END;
END; -- PACKAGE BODY fixed_point;
--- This needs to be in a separate file, ideally.
---
PACKAGE BODY fixed_point_config IS
CONSTANT Point : natural :=3D 8;
END;
----------------------------------- end code snippet --------------
--
Jonathan Bromley
HDL Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project =
Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 =
1AW, UK
Tel: +44 (0)1425 471223 mail: =
jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: =
http://www.doulos.com
This e-mail and any attachments are confidential and Doulos Ltd. =
reserves
all rights of privilege in respect thereof. It is intended for the use =
of
the addressee only. If you are not the intended recipient please delete =
it
from your system, any use, disclosure, or copying of this document =
is
unauthorised. The contents of this message may contain personal views =
which
are not the views of Doulos Ltd., unless specifically stated.
Article: 44913I know from Xilinx App Note XAPP233, "Multi-Channel 622Mbps LVDS for Virtex-E" that Virtex-E devices can support an LVDS interface at this speed. Since Spartan-E has the same suffix, I am wondering if the part has the same technolgy as Virtex-E. Can the Spartan-E support an LVDS interface at 622Mbps?Article: 44914
Internally, that is fine, but at your component ports, you should use
std_logic and std_logic_vector for compatibility.
Martin Thompson wrote:
> Just a small hobby horse of mine, as I see too much code written in a
> strongly typed language which doesn't take advantage of the types, so
> std_logic(_vector) is used for almost everything, except constants for
> some reason...
>
> All IMHO of course!
> Martin
>
> --
> martin.j.thompson@trw.com
> TRW Conekt, Solihull, UK
> http://www.trw.com/conekt
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 44915Ray Andraka <ray@andraka.com> wrote: > Frankly, I've been finding that the VirtexII-4 is about the same performance as > a VirtexE-6 as far as arithmetic is concerned for carefully handplaced designs. > Stuff that doesn't use the carry chain does appear to be faster in the VirtexII. I don't do much arithmetic, so I've found the VirtexII much faster than the E. I have noticed that carry chain entry/exit times are much higher than the VirtexE equivalents, making carry chains relatively expensive for small functions. As a result, a couple of carry chains in series between flip flops worked okay at 160MHz in Virtex-E but not at the same speed in Virtex-II. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 44916
Hi Steve, I had the same doubts when I tried to route an BG256 with only 4 Layers. In principle it is possible, but your pcb design will violate almost all rules for decoupling and EMI. Since I didnt want to take a risk, I switched to 6 Layers. Everything was fine. Please tell me your experiences, if you decide to use only 4 Layers. - Manfred "Steve Joures" <sjoures@saiman.co.uk> schrieb im Newsbeitrag news:ee77b3b.-1@WebX.sUN8CHnE... > Is it possible to layout a Virtex-II 256 pin FPBGA on 4 PCB Layers ? > > By reading Xilinx application note XAPP157 you would think that it was. I am trying to use the 2 outer layers for routing, and two inner layers as power planes. The problems I am having (which are not mentioned in XAPP157) are to do with VCC_INT and decoupling capacitors. > > If you use all the decoupling capacitors recommened in XAPP158, then they completely surround the device. (I've used 0603 capaictors on upper layer only) So the upper layer routing, once out of the FPGA area is restricted by these. > > It is difficult to use one power plane to route VCCO and VCC_INT, because you are forced to split VCC_INT into 4 areas under the BGA. Each of these areas could be brought out from under each corner of the FBGA, but then it is impossible to connect then with out cutting right across the VCCO plane. If I bring the VCC_INT areas to the surface to connect them, then I cut across the routing layers. One option I have thought of is to bring each of the VCC_INT area of the power plane diagonally out from each corner of the BGA to the edge of the (small) PCB. Then I connect them with a section of power plane that runs right round the PCB perimeter. Is the a good idea ? > > Has anyone come across the same problems, and if so what solution did they come up with ?Article: 44917
We do mostly arithmetic since we specialize in DSP applications of FPGAs. Between the
slow multiplier speeds in V2 before those produced this spring and the dreadfully slow
times getting on and off the carry chains, and the smaller number of slices per
marketing gate (and indirectly per dollar) we have found the VirtexE to be generally a
much better value for DSP applications.
Even with the fixed multiplier speeds, you will presumably be using other arithmetic
in conjunction with the multipliers, and at 18 bits your speed gets limited by the
carry chain to something about equivalent to VirtexE.
hamish@cloud.net.au wrote:
> Ray Andraka <ray@andraka.com> wrote:
> > Frankly, I've been finding that the VirtexII-4 is about the same performance as
> > a VirtexE-6 as far as arithmetic is concerned for carefully handplaced designs.
> > Stuff that doesn't use the carry chain does appear to be faster in the VirtexII.
>
> I don't do much arithmetic, so I've found the VirtexII much faster than
> the E. I have noticed that carry chain entry/exit times are much higher
> than the VirtexE equivalents, making carry chains relatively expensive
> for small functions. As a result, a couple of carry chains in series between
> flip flops worked okay at 160MHz in Virtex-E but not at the same speed
> in Virtex-II.
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 44918--------------ABB5D693F2634A2147FD604A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Filipkiewicz wrote: > Dennis McCrohan wrote: > > > Austin Lesea wrote: > > > > > John, > > > > > > To emphasize Peter's point (below), > > > > > > How good are your simulation test vectors? > > > > > > Where we find inaccuracy, we find lack of vectors. > > > > > > > We (members of the XPower team at Xilinx) go round'n'round on this topic. I have > > often been asked "isn't there a simple answer to whether my simulation-generated > > VCD file will yield accurate results when used with XPower?" > > > > Like most things with engineering, there is a simple, elegant, and wrong answer > > ;-) > > > > Only the logic designer knows if the stimulus generated by this testfixture > > accurately reflects how the device will be stimulated in the real-world (and as a > > former logic designer, I know that even designers sometimes don't know the > > answer). In addition, it is important to run the simulation long enough that the > > I/O frequencies captured are reasonably accurate. In other words, if XPower says > > that your power-on-reset toggled at 1MHz, you didn't simulate long enough... The > > flip side is running too long of a simulation yields an excessive amount of data. > > Judgement call... My personal rule-of-thumb is to look at the clock frequency > > reported in XPower after loading a VCD file. If it is within 1% of the actual > > clock speed, I'm generally happy. > > > > -Dennis McCrohan > > Xilinx CPLD S/W > > > > Its all very well, and completely correct, to say that realistic sim runs are needed > to provide enough raw data for Xpower to get an accurate estimate. The problem comes > when realistic = long => **huge** VCD files. Hearing reports that Xpower takes > forever to load these sometimes enormous VCD files, assuming it doesn't crash on the > way, is basically putting me off using it. [Defn. humungous = size of VCD file > produced by 2msec post-route sim of XCV600E @ 90%). > Your analysis is pretty good. We choose VCD as our initial format for simulator support because of it's universality. We have been working on the load time issues within XPower, and the next release should offer substantial improvements. W.R.T file size, we knew that would be an issue, but as I said our initial goal was to use a format where we could offer support for as many different simulators as quickly as possible. That kinda forces one towards the LCD, which in this case was VCD (very, very lame pun). > > While the antique VCD format has the clear merit of portability it is, IMV, clearly > inappropriate in this contex since for power calc. purposes we need to dump all nodes > and not just a small subset to pipe through a VCD waveform viewer. > > A patch solution might be a Perl script that extracts required info from the VCD and > outputs a simple binary file (with a defined format) containing just the toggle count > per node and node type. That way I could run the extractor on a machine with decent > virtual memory performance - aka a Unix box [according to my O/S guru colleague even > Linux isn't really good enough for this yet]. We have (and are) looking at various other approaches to simulator interface. So far, they all have the downside of being less universal, requiring a higher level of support, and being more complicated for the end-user. Speaking for myself and not Xilinx, -Dennis McCrohanArticle: 44919
Hallo, can I set the slew rate for an individual pin in a Xilinx Coolrunner II device? xapp378.pdf doesn't talk about that, I find no way to enter it in the constraint editor and editing the UCF directly like PIN ram0_we_n SLOW; didn't result in the *rpt file telling about the slow attribute, despite I rerun the translate step too. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 44920
Dennis McCrohan wrote: > We have (and are) looking at various other approaches to simulator > interface. So far, they all have the downside of being less universal, > requiring a higher level of support, and being more complicated for > the end-user. > > Speaking for myself and not Xilinx, > How about instrumenting each of the simprims models with a toggle counter. Then at the end of a sim run use a PLI routine to go in and extract the count for each instantiation and output the results to a (much smaller) file. Then all Xpower has to do is compute the - fanout dependent - power consumption for each driver and add them all up (?) ... or something like that. Even better if NGDANNO/NGB2<VER | VHDL> could set a parameter in the model to give the pJ/transition value, Xpower would then in effect be integrated into post-route simulation. Continuing this theme a bit further you could define a single, parametrisable, "power catcher" between the output of any model and the net it drives ...Article: 44921
Rick Filipkiewicz wrote: > > Dennis McCrohan wrote: > > > We have (and are) looking at various other approaches to simulator > > interface. So far, they all have the downside of being less universal, > > requiring a higher level of support, and being more complicated for > > the end-user. > > > > Speaking for myself and not Xilinx, > > > > How about instrumenting each of the simprims models with a toggle > counter. Then at the end of a sim run use a PLI routine to go in and > extract the count for each instantiation and output the results to a > (much smaller) file. Then all Xpower has to do is compute the - fanout > dependent - power consumption for each driver and add them all up (?) > ... or something like that. Even better if NGDANNO/NGB2<VER | VHDL> > could set a parameter in the model to give the pJ/transition value, > Xpower would then in effect be integrated into post-route simulation. > Continuing this theme a bit further you could define a single, > parametrisable, "power catcher" between the output of any model and the > net it drives ... Rather than carry all the 'sim-baggage', which is from vectors with poor real-world power-profile anyway, why not apply a simpler scheme : As Rick suggests, in post-route, create an 'as routed' set of 'power dissapation capacitance' values ( == pJ/edge), for the clock BUS and all routed BUS. Then, an 'Average Operating Freq' is keyed into these values, and out comes the power. Freq is very precise for CLOCK nets, more of a guess for the others, but I suspect the clock nets will dominate. An advantage of this, is designers can see where the 'hot spots' are This same table of values, could also take Ricks' post-sim-edge count if you want 'another opinion' on frequencies. A combination that allowed user edit of obvious skews would be ideal. ( someone mentioned Reset toggle at 1MHz ? :) -jgArticle: 44922
Hello Uwe, Yes you can set slew rate for individual ouputs in CoolRunner-II devices - Use the following line in your UCF: NET mysignal SLOW; After reimplementing, this will result in the .rpt file stating that your signal was successfully implemented as slow slew rate. (You can see this in the output summary section - There is a column there which states whether the signal is using fast or slow slew rate). Best Regards, Mark Uwe Bonnes wrote: > Hallo, > > can I set the slew rate for an individual pin in a Xilinx Coolrunner II > device? xapp378.pdf doesn't talk about that, I find no way to enter it in > the constraint editor and editing the UCF directly like > PIN ram0_we_n SLOW; > didn't result in the *rpt file telling about the slow attribute, despite I > rerun the translate step too. > > Bye > > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 44923
According to the Xilinx website, one cannot code an N-bit, 2-input adder w/
carry-in simply by writing:
assign {Cout,SUM} = A + B + Cin;
(as my partner, a very Verilog-literate person naively would), where SUM, A,
and B are N-bit numbers, and Cin is a one-bit carry-in.
Instead, they insist that one write:
assign{Cout, SUM, dummy} = {A, Cin} + {B, Cin};
I am told that this stems from an inability to entertain a carry-in
properly.
Question: Does this restriction apply to the ISE 4.02 / Virtex E
2000-6BG560 software/hardware combination , or merely
to FPGA Express or older versions?
Article: 44924> Hi, > Does anybody know where can I download the complete Triscend SDK CD-ROM? > I bought the Triscend A7 Development Kit, but the package don't include > the SDK CD-ROM. > Laurent Hi, I have got the software from Triscend. I have asked about it in technical support, it's free. Supposedly the SDK is included in Fastchip 2.4. JanuszR
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