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 44900

Article: 44900
Subject: How to improve this VHDL code ?
From: ted_jmt@zapta.com
Date: Thu, 04 Jul 2002 17:21:57 -0700
Links: << >>  << T >>  << A >>
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,

Tal 

Article: 44901
Subject: Please ignore my previous postings
From: ted_jmt@zapta.com
Date: Thu, 04 Jul 2002 17:49:21 -0700
Links: << >>  << T >>  << A >>

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,

Tal 

Article: 44902
Subject: Re: Type conversion - adding integer to logic_vector
From: Ray Andraka <ray@andraka.com>
Date: Fri, 05 Jul 2002 02:45:59 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Macro/Function in VHDL testbench ?
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Fri, 05 Jul 2002 07:07:59 GMT
Links: << >>  << T >>  << A >>
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: 44904
Subject: Re: Type conversion - adding integer to logic_vector
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 05 Jul 2002 08:50:52 +0100
Links: << >>  << T >>  << A >>
Ray 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/conekt

Article: 44905
Subject: Re: Could someone please simplify Synplify for me...
From: "Arash Salarian" <arash.salarian@epfl.ch>
Date: Fri, 5 Jul 2002 09:53:33 +0200
Links: << >>  << T >>  << A >>
"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
Arash



Article: 44906
Subject: Re: How to improve this VHDL code ?
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 05 Jul 2002 08:53:53 +0100
Links: << >>  << T >>  << A >>
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/conekt

Article: 44907
Subject: Re: Anyone use the full Aldec 5.1 flow?
From: "Kate Atkins" <Kate.Atkins@siranospameonosplat.co.uk.nosplat>
Date: Fri, 5 Jul 2002 09:35:55 +0100
Links: << >>  << T >>  << A >>

"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.

Kate



Article: 44908
Subject: Triscend: SDK CD-ROM : where ?
From: Laurent Gauch <laurent.gauch@amontec.com>
Date: Fri, 05 Jul 2002 10:38:00 +0200
Links: << >>  << T >>  << A >>
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


Article: 44909
Subject: Re: How to improve this VHDL code ?
From: Laurent Gauch <laurent.gauch@amontec.com>
Date: Fri, 05 Jul 2002 11:24:49 +0200
Links: << >>  << T >>  << A >>
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
Subject: VHDL Simili INOUT Problem
From: "Ryan" <ryans@cat.co.za>
Date: Fri, 5 Jul 2002 12:02:16 +0200
Links: << >>  << T >>  << A >>
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
Ryan





Article: 44911
Subject: choosing RC100 over RC1000?
From: lktan24@hotmail.com (lktan)
Date: 5 Jul 2002 03:56:44 -0700
Links: << >>  << T >>  << A >>
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,
lktan

Article: 44912
Subject: Re: Fixed point arithmetic
From: "Jonathan Bromley" <jonathan.bromley@doulos.com>
Date: Fri, 5 Jul 2002 11:56:52 +0100
Links: << >>  << T >>  << A >>
> -----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: 44913
Subject: Xilinx Spartan-E LVDS at 622Mbps?
From: jpnicholls@pwav.com (JP Nicholls)
Date: 5 Jul 2002 05:47:57 -0700
Links: << >>  << T >>  << A >>
I 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
Subject: Re: Type conversion - adding integer to logic_vector
From: Ray Andraka <ray@andraka.com>
Date: Fri, 05 Jul 2002 13:31:07 GMT
Links: << >>  << T >>  << A >>
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: 44915
Subject: Re: Maximum frequency in Virtex and Virtex-E Devices
From: hamish@cloud.net.au
Date: 05 Jul 2002 14:26:21 GMT
Links: << >>  << T >>  << A >>
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>

Article: 44916
Subject: Re: Routing Virtex-II 256 pin BGA on 4 layers
From: "Manfred Kraus" <newsreply@cesys.com>
Date: Fri, 5 Jul 2002 16:32:19 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: Maximum frequency in Virtex and Virtex-E Devices
From: Ray Andraka <ray@andraka.com>
Date: Fri, 05 Jul 2002 15:28:22 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Xpower accuracy (is there anybody from Xilinx out there ?)
From: Dennis McCrohan <mccrohan@xilinx.com>
Date: Fri, 05 Jul 2002 08:34:54 -0700
Links: << >>  << T >>  << A >>

--------------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 McCrohan







Article: 44919
Subject: Setting individual slewrate on Xilinx Coolrunner II
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Fri, 5 Jul 2002 15:35:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
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
Subject: Re: Xpower accuracy (is there anybody from Xilinx out there ?)
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 05 Jul 2002 19:29:26 +0100
Links: << >>  << T >>  << A >>


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
Subject: Re: Xpower accuracy (is there anybody from Xilinx out there ?)
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sat, 06 Jul 2002 09:28:55 +1200
Links: << >>  << T >>  << A >>
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 ? :)

-jg

Article: 44922
Subject: Re: Setting individual slewrate on Xilinx Coolrunner II
From: Mark Ng <mark.ng@xilinx.com>
Date: Fri, 05 Jul 2002 15:04:49 -0700
Links: << >>  << T >>  << A >>
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
Subject: N-bit, 2-input adder
From: "cfk" <cfk_alter_ego@pacbell.net>
Date: Fri, 05 Jul 2002 23:09:13 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Triscend: SDK CD-ROM : where ?
From: Janusz Raniszewski <rniski@man.koszalin.pl>
Date: Sat, 06 Jul 2002 01:29:35 +0200
Links: << >>  << T >>  << A >>
> 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:
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