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
2017JanFebMarApr2017

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 37700

Article: 37700
Subject: Re: How can I reduce Spartan-II routing delays to meet 33MHz PCI's Tsu < 7 ns requirement?
From: "Carl Brannen" <carl.brannen@terabeam.com>
Date: Wed, 19 Dec 2001 09:06:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
Kevin,  Are you at a relatively high utilization on the part (presumably with
logic from something other than the PCI interface)?

If you are, one great strategy is to remove all your logic but a stub, and then
get the PCI interface to route to perfection.  Then you use that result as a
guide file (or copy the PCI placement into the UCF file).

If this works, then you've just got the tool to do the routing for you.  I
don't know if it will help here, but the technique works great on Altera
designs especially.

The idea is to route the critical logic first, but do it while unloading the
place and route from having to deal with the uncritical logic.

Best of luck.

Carl


-- 
Posted from firewall.terabeam.com [216.137.15.2] 
via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 37701
Subject: Re: How to initialize the block ram of xilinx SpartanII FPGA?(Verilog)
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Wed, 19 Dec 2001 11:40:17 +0200
Links: << >>  << T >>  << A >>
deerlux wrote:
> 
> I use the following code to initialize the block RAM of SpartanII FPGA as
> the handbook of Xilinx:
> module MYMEM(clk,we,addr,din,dout);
> input clk,we;
> input [7:0]din;
> output [7:0]dout;
> input [8:0]addr;
> wire logic0,logic1;
> assign logic0=1'b0;
> assign logic1=1'b1;
> 
> RAMB4_S8
> ram0(.WE(we),.EN(logic1),.RST(logic0),.CLK(clk),.ADDR(addr),.DI(din),.DO(dou
> t));
> // synopsys translate_off
> defparam ram0.INIT_00=
> 256h'0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF;
> defparam ram0.INIT_01=
> 256'hFEDCBA9876543210FEDCBA9876543210FEDCBA9876543210FEDCBA9876543210;
> // synopsys translate_on
> endmodule
> But when I implement it using Xilinx Foundation3.1i.It shows INIT_xx
> including INIT_00 and INIT_01 not initialized.I use Synopsys FPGA Express to
> synthesis.
> Who can tell me how to initialize the block RAM?
> Thank you!

  Because you don't synthesize defparams of RAMB_S8 by using
  translate_on/off, synthesizer seems to have no initialization
  constructs to get synthesized. Please look at the Synopsys manuals,
  how to do it.

  Utku

Article: 37702
Subject: Re: MIPS or MOPS?
From: Murali Jayapala <mjayapal@esat.kuleuven.ac.be>
Date: Wed, 19 Dec 2001 11:00:18 +0100
Links: << >>  << T >>  << A >>
I guess the first step is to check the proper definitions of MIPS and MOPS.
As far as I know  MIPS stands for Millions of instructions per second and MOPS
is millions of operations per second.
Now if you have mapped the algorithm on a VLIW/parallel machine, then each
'instruction' has more than one 'operation'.  However if the platform is a
risc machine then each instruction has just one operation. So in case of
parallel machines it would be fair to evaluate through MOPS., while in risc
machines MOPS and MIPS both signify the same result..


-MJ

AAP3 wrote:

> Hi..to all
> I wrote some functions for a CDMA receiver and I want to find the number of
> MIPS required by each function. How do I calculate it?
> and which is more accurate measure, MIPS  or MOPS?
> More info:
> data rate 2Mbps.
> system clock 50MHz.
> 4 time over sampling.
> 16 Spreading factor.
>
> Thanks.


Article: 37703
Subject: How can I check my PLD program ?
From: "Martin Fischer" <Martin.Fischer@fzi.de>
Date: Wed, 19 Dec 2001 11:13:53 +0100
Links: << >>  << T >>  << A >>
Hello,

Is it possible to check the program in my PLD
(Xilinx 3064XL) with an mikrocontroller ?
Can I read the program out and generate a checksum ?
Or is it only possible with an PC and the program in
the PLD to verify ?


Thanks

Martin.Fischer@fzi.de



Article: 37704
Subject: Re: DCM stability in Virtex2 -ES
From: "John Adair" <newsanswer@removethisenterpoint.co.uk>
Date: Wed, 19 Dec 2001 11:37:27 -0000
Links: << >>  << T >>  << A >>
We have been doing a DDR interface and have encountered similar problems.

There are some limitations on DCMs in ES silicon specifically. Obtain the
errata sheet from your FAE. You will find some reset limitations, jitter
specs and multiplication ration issues that may be causing your issues.

John Adair
Enterpoint Ltd.
Unit 4
Malvern Hills Science Park
Geraldine Road
Malvern
Worcestershire
United Kingdom
www.enterpoint.co.uk

The views expressed in this message are those of the writer and not
necessarily those of Enterpoint Ltd.. The use of information in this message
is without warranty and persons using the information are advised to make
their own checks as to it's validity. No responsibility will be accepted for
any incorrect, inaccurate or missleading information supplied.


David Miller <spam@quartz.net.nz> wrote in message
news:3C201C58.2040903@quartz.net.nz...
> Hi,
>
> Here's a problem that does not qualify as kindergarten stuff.
>
> A DCM in a xc2v1000 engineering sample is behaving oddly.  I am using
> this DCM to generate and deskew a clock and antiphased clock (0 & 180
> degrees) for a DDR RAM.  It is being fed by a 100MHz crystal buffered
> with a CY2308 zero-delay clock buffer (ie, a pll.)
>
> The period of the clock seen at the board is 10 ns - usually.
> Occasionally, the clock periods is lengthened by between 2.5 and 3 ns.
>   The stretch is always in the low half of the cycle.
>
> What could be causing this?
>
> Relevant facts:
> - Chip is a xc2v1000bg456-4 -ES
> - Software is Xilinx Alliance 3.3.08i with the VirtexII device update
> files and the bitgen patch applied.
> - SelectIO type HSTL class II with DCI is being used
>
> I used a 1 gigahertz (5 gigasample) oscilloscope to look at this clock
> pin, so sampling error isn't it.  The oscilloscope showed that sometimes
> (perhaps 1 of 4 stretched periods), the clock starts to go high at the
> right time, then changes its mind literally half way through the rise
> time -- it gets to half way between Vol and Voh (or Vref; this is HSTL)
> and then returns to Vol again.  between 2.5 and 3 ns later, it does a
> proper rising edge.
>
> I've even tried locking the DCM to different parts of the chip and it
> made no difference.
>
> I've searched the xilinx answers and found no clues.  Any suggestions
> gratefully received!
>
> --
> David Miller, BCMS (Hons)  | When something disturbs you, it isn't the
> Endace Measurement Systems | thing that disturbs you; rather, it is
> Mobile: +64-21-704-djm     | your judgement of it, and you have the
> Fax:    +64-21-304-djm     | power to change that.  -- Marcus Aurelius
>



Article: 37705
Subject: Re: MIPS or MOPS?
From: Sander Vesik <sander@haldjas.folklore.ee>
Date: Wed, 19 Dec 2001 12:02:49 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch Murali Jayapala <mjayapal@esat.kuleuven.ac.be> wrote:
> I guess the first step is to check the proper definitions of MIPS and MOPS.
> As far as I know  MIPS stands for Millions of instructions per second and MOPS
> is millions of operations per second.
> Now if you have mapped the algorithm on a VLIW/parallel machine, then each
> 'instruction' has more than one 'operation'.  However if the platform is a
> risc machine then each instruction has just one operation. So in case of

Wrong - consider any SIMD instructions (practicly all risc processors have
them these days) or for that matter, muladd.

> parallel machines it would be fair to evaluate through MOPS., while in risc
> machines MOPS and MIPS both signify the same result..

Well... most dsp processors advertise both, esp as they do have muladds and
similar...

> -MJ

> AAP3 wrote:

>> Hi..to all
>> I wrote some functions for a CDMA receiver and I want to find the number of
>> MIPS required by each function. How do I calculate it?
>> and which is more accurate measure, MIPS  or MOPS?
>> More info:
>> data rate 2Mbps.
>> system clock 50MHz.
>> 4 time over sampling.
>> 16 Spreading factor.
>>
>> Thanks.


-- 
	Sander

+++ Out of cheese error +++

Article: 37706
Subject: Best-case timing?
From: "Stephen Byrne" <byrne@ddc-web.com>
Date: Wed, 19 Dec 2001 12:46:53 GMT
Links: << >>  << T >>  << A >>
I originally posted this yesterday on google groups, but I'm not seeing it
on my home news server.  In case it is not visible to all, I'm reposting.

Hello All,

My company is currently comparing 66MHz PCI core solutions from Xilinx
and Altera, as well as debating using a home-spun core.  One issue
I've come upon is the PCI requirement for a MAX clock-to-out time of 6
ns and MIN clock-to-out time of 2 ns.  Both the Xilinx ISE and Altera
Quartus II tools seem very helpful in supplying MAX (worst-case) Tco
times, but I don't see any info on best-case times.  Apparently the
SDF files for back-annotated timing sim have the same worst-case
numbers repeated 3 times, resulting in the same simulation regardless
of case selection.  My question is: how is anyone (FPGA vendors
included) guaranteeing a MIN Tco of 2 ns across all conditions and
parts if the design tools don't even yield that information?

Thank You,

Stephen Byrne





Article: 37707
Subject: Re: MIPS or MOPS?
From: Murali Jayapala <mjayapal@esat.kuleuven.ac.be>
Date: Wed, 19 Dec 2001 14:26:44 +0100
Links: << >>  << T >>  << A >>
> Wrong - consider any SIMD instructions (practicly all risc processors have
> them these days) or for that matter, muladd.
>

But isnt the granularity of each of the operation in a SIMD instruction smaller
than one 'regular' opertation ?.  It would be fair to compare operations of similar
granularity. In vliw archs,  each operation in an instruction have  graularity
similar to  one of regular risc style instruction. While the graularity of one SIMD
instruction  still has  same granularity as the granularity of one regular risc
instruction (even though each SIMD might have more than one operation). Isnt this
true?? I am still under the impression that this is true.... but I could be wrong.

-MJ



Article: 37708
Subject: Re: Divide by 3, with remainder, efficient and fast, for Altera or Xilinx
From: "Eric Pearson" <ecp@mgl.ca>
Date: Wed, 19 Dec 2001 08:28:37 -0500
Links: << >>  << T >>  << A >>
My favorite "divide by 3" circuit is to multiply by 85 and then divide by
256.
85 is 0x55. To multiply by 0x55, only 2 adders are required.

Input A,
Output B = A / 3

t1 = A + (A<<2);    -- multiply by 0x05
t2 = t1 + (t1<<4);    -- multiply by 0x11
B = t2 >> 8;            -- divide by 256

Not quite as elegant as below, but very fast and small. It is useful when
the remainder is not required as in the orginal post.

Eric Pearson



"Carl Brannen" <carl.brannen@terabeam.com> wrote in message
news:48a39dc55b77e0cdb6c1f9895bfe4eb6.51709@mygate.mailgate.org...
> Let's see how long a VHDL chunk will fit in this forum...
>
> library IEEE;
> use IEEE.std_logic_1164.all;
>
> -- Divide by 3 circuit example.  Uses only 85 LUTs
> -- (up to 4-input) to compute the quotient and
> -- remainder when a 32-bit input is divided by 3.
> --
> -- Designer:  Carl Brannen
> --
> -- Feel free to modify this circuit and use it in
> -- your own designs. I am aware of no patents that
> -- it infringes on, but you will have to make your
> -- own determination of this.  My only request is
> -- that you leave a comment to the effect that your
> -- knowledge of the algorithm is through me.
> --
> -- Synthesize with optimize set for "low", and
> -- "area".  This circuit is already optimized,
> -- the computer will only be waste its time (and likely
> -- increase the size and delay of the result) if it
> -- tries to optimize further.
> --
> -- This code was written in response to this post
> -- on the comp.arch.FPGA thread:
> --
> -- <<<
> -- "I need to implement in an fpga an algorithm that will divide an
integer
> -- by 3.  The dividend length is still to be determined but will be
> -- somewhere between 20 and 30 bits, and the divisor is always the number
> -- 3.
> --
> -- Does anyone know an efficient combinatoric algorithm that can
accomplish
> -- this?
> -- >>>
> --
> -- http://www.fpga-faq.com/archives/11400.html#11409
>
> entity DIV32_3 is
>     port (
>         CLK:    in  STD_LOGIC;
>         AIN:    in  STD_LOGIC_VECTOR(31 downto 0);
>         REMOUT: out STD_LOGIC_VECTOR( 1 downto 0);
>         QOUT:   out STD_LOGIC_VECTOR(30 downto 0);
>         TEST:   out STD_LOGIC_VECTOR(53 downto 0)
>     );
> end DIV32_3;
>
> architecture DIV32_3_arch of DIV32_3 is
>
> -- Partial remainders:
> signal R1V:  STD_LOGIC_VECTOR(15 downto 0);  --  16 LUTs
> signal R2V:  STD_LOGIC_VECTOR( 7 downto 0);  --   8 LUTs
> signal R4V:  STD_LOGIC_VECTOR( 3 downto 0);  --   4 LUTs
> signal R8V:  STD_LOGIC_VECTOR( 1 downto 0);  --   2 LUTs
> signal P4V:  STD_LOGIC_VECTOR( 1 downto 0);  --   2 LUTs
> signal P3V:  STD_LOGIC_VECTOR( 1 downto 0);  --   2 LUTs
> signal P2V:  STD_LOGIC_VECTOR( 1 downto 0);  --   2 LUTs
> signal P1V:  STD_LOGIC_VECTOR( 1 downto 0);  --   2 LUTs
> signal P0V:  STD_LOGIC_VECTOR( 1 downto 0);  --   2 LUTs
>
> -- Rearrangement of partial remainders only:
> signal PRV:  STD_LOGIC_VECTOR(15 downto 0);  --  16 LUTs
>
> -- carries internal to blocks:
> signal X0V:  STD_LOGIC_VECTOR(13 downto 0);  --  14 LUTs
>
> -- Flip-flop for QOUT:
> signal QOUTQ,QOUTD: STD_LOGIC_VECTOR(30 downto 0);  --  31 LUTs
>
> -- Flip-flop for Remainder:
> signal REMQ,REMD:   STD_LOGIC_VECTOR( 1 downto 0);
>
>
> --                                           --  -------
>
> -- Total LUT count:                          --  85 LUTs (45 slices or 23
CLBs)
>
> -- Force tool to not "optimize" (i.e. bloat) the design
> -- by creating a set of flip-flop outputs.
> signal FKD,FKQ: STD_LOGIC_VECTOR(53 downto 0);
>
>
> begin
>
> -- Scheme for quickest determination of remainder when dividing by 3.
> -- Example, 32-bit input, R80 provides the 2-bit remainder result in
> -- just 4 stages of 4-input LUTs:
> --
> --                   AIN
> -- 3322 2222 2222 1111 1111 1100 0000 0000
> -- 1098 7654 3210 9876 5432 1098 7654 3210
> -- ---- ---- ---- ---- ---- ---- ---- ----
> --  R17  R16  R15  R14  R13  R12  R11  R10
> --   \   /     \   /     \   /     \   /
> --    R23       R22       R21       R20
> --        \    /              \    /
> --         R41                 R40
> --            -----\    /-----
> --                  R80
> --
> -- Scheme for computing quotients from the above
> -- remainder scheme.  More partial remainders have
> -- to be computed, as compared to the above remainders,
> -- these ones are called PRs.
> --
> -- The quotient for the highest four bits is computed
> -- directly from (no greater than 4-input) LUTs.  The
> -- lower quotients all require a remainder input.  That
> -- remainder allows direct computation of the quotient
> -- for the high two bits, and a partial remainder needs
> -- to be computed to get the lower 2 bits as well.  The
> -- following diagram suppresses Rxx that aren't used, and
> -- only shows how the PRs are calculated.  The lowest
> -- value in each column gives the Rxx or PRx that computes
> -- the partial remainder at that column:
> --
> --                   AIN
> -- 3322 2222 2222 1111 1111 1100 0000 0000
> -- 1098 7654 3210 9876 5432 1098 7654 3210
> -- ---- ---- ---- ---- ---- ---- ---- ----
> --  R17       R15       R13       R11
> --             |         |         |
> --            P4         |   R21   |
> --           /           |    |  \ |
> --       R23             P3   P2   P1
> --                      /     /    |
> --                     /     /     P0
> --                    /-----/-----/
> --                 R41
> --
> -- ---- ---- ---- ---- ---- ---- ---- ----
> --  R17  R23  P4   R41  P3   P2   P0   R8
> --  PR7  PR6  PR5  PR4  PR3  PR2  PR1  PR0
> --
> --
> -- From the above tables, it's clear that the
> -- longest computation is that of the quotient
> -- at position 0, as would be expected.  The
> -- number of stages of logic is only 6, and the
> -- longest paths are as follows:
> --
> -- R17 R16 R15 R14 R13 R12
> --   \  /    \  /    \  /
> --   R23     R22     R21
> --      \    /         \
> --       R41            P1
> --            \     /
> --              P0
> --               |
> --              Remainder[3:2]
> --               |
> --              Quotient[1:0]
> --
> --
> -- In order to make the VHDL shorter, I've packed
> -- the remainders into longer STD_LOGIC_VECTORs
> -- as follows:
> -- R1V <= R17 & R16 & ... R10
> -- R2V <= R23 & R22 & R21 & R20
> -- R4V <= R41 & R40
> -- R8V <= R80
> --
> --
> -- I normally don't like to complicate things any more
> -- than they have to, but I hate to have to create all
> -- those unnecessary "SEL" assignments.
>
> -- If Xilinx would support a select statement like this:
> --
> --     with AIN(4*I+3 downto 4*I)
> --
> -- I wouldn't have to do this this way, but this is the first
> -- way to implement this that comes to mind.  I guess I could
> -- define LUT4s, since none of these are trivial, but that wouldn't
> -- port to Altera.
>
> -- Generate the R1x logic (16 LUTs)
> G1: for I in 0 to 7 generate
> R1V(I*2 + 0)
>  <= ((not AIN(4*I+3)) and (not AIN(4*I+2)) and (not AIN(4*I+1)) and (
> AIN(4*I+0)))
>  or ((not AIN(4*I+3)) and (    AIN(4*I+2)) and (not AIN(4*I+1)) and (not
> AIN(4*I+0)))
>  or ((not AIN(4*I+3)) and (    AIN(4*I+2)) and (    AIN(4*I+1)) and (
> AIN(4*I+0)))
>  or ((    AIN(4*I+3)) and (not AIN(4*I+2)) and (    AIN(4*I+1)) and (not
> AIN(4*I+0)))
>  or ((    AIN(4*I+3)) and (    AIN(4*I+2)) and (not AIN(4*I+1)) and (
> AIN(4*I+0)));
> R1V(I*2 + 1)
>  <= ((not AIN(4*I+3)) and (not AIN(4*I+2)) and (    AIN(4*I+1)) and (not
> AIN(4*I+0)))
>  or ((not AIN(4*I+3)) and (    AIN(4*I+2)) and (not AIN(4*I+1)) and (
> AIN(4*I+0)))
>  or ((    AIN(4*I+3)) and (not AIN(4*I+2)) and (not AIN(4*I+1)) and (not
> AIN(4*I+0)))
>  or ((    AIN(4*I+3)) and (not AIN(4*I+2)) and (    AIN(4*I+1)) and (
> AIN(4*I+0)))
>  or ((    AIN(4*I+3)) and (    AIN(4*I+2)) and (    AIN(4*I+1)) and (not
> AIN(4*I+0)));
> end generate;
>
> -- Generate the R2x logic (8 LUTs)
> G2: for I in 0 to 3 generate
> R2V(I*2 + 0)
>  <= ((not R1V(4*I+3)) and (not R1V(4*I+2)) and (not R1V(4*I+1)) and (
> R1V(4*I+0)))
>  or ((not R1V(4*I+3)) and (    R1V(4*I+2)) and (not R1V(4*I+1)) and (not
> R1V(4*I+0)))
>  or ((not R1V(4*I+3)) and (    R1V(4*I+2)) and (    R1V(4*I+1)) and (
> R1V(4*I+0)))
>  or ((    R1V(4*I+3)) and (not R1V(4*I+2)) and (    R1V(4*I+1)) and (not
> R1V(4*I+0)))
>  or ((    R1V(4*I+3)) and (    R1V(4*I+2)) and (not R1V(4*I+1)) and (
> R1V(4*I+0)));
> R2V(I*2 + 1)
>  <= ((not R1V(4*I+3)) and (not R1V(4*I+2)) and (    R1V(4*I+1)) and (not
> R1V(4*I+0)))
>  or ((not R1V(4*I+3)) and (    R1V(4*I+2)) and (not R1V(4*I+1)) and (
> R1V(4*I+0)))
>  or ((    R1V(4*I+3)) and (not R1V(4*I+2)) and (not R1V(4*I+1)) and (not
> R1V(4*I+0)))
>  or ((    R1V(4*I+3)) and (not R1V(4*I+2)) and (    R1V(4*I+1)) and (
> R1V(4*I+0)))
>  or ((    R1V(4*I+3)) and (    R1V(4*I+2)) and (    R1V(4*I+1)) and (not
> R1V(4*I+0)));
> end generate;
>
> -- Generate the R4x logic (4 LUTs)
> G4: for I in 0 to 1 generate
> R4V(I*2 + 0)
>  <= ((not R2V(4*I+3)) and (not R2V(4*I+2)) and (not R2V(4*I+1)) and (
> R2V(4*I+0)))
>  or ((not R2V(4*I+3)) and (    R2V(4*I+2)) and (not R2V(4*I+1)) and (not
> R2V(4*I+0)))
>  or ((not R2V(4*I+3)) and (    R2V(4*I+2)) and (    R2V(4*I+1)) and (
> R2V(4*I+0)))
>  or ((    R2V(4*I+3)) and (not R2V(4*I+2)) and (    R2V(4*I+1)) and (not
> R2V(4*I+0)))
>  or ((    R2V(4*I+3)) and (    R2V(4*I+2)) and (not R2V(4*I+1)) and (
> R2V(4*I+0)));
> R4V(I*2 + 1)
>  <= ((not R2V(4*I+3)) and (not R2V(4*I+2)) and (    R2V(4*I+1)) and (not
> R2V(4*I+0)))
>  or ((not R2V(4*I+3)) and (    R2V(4*I+2)) and (not R2V(4*I+1)) and (
> R2V(4*I+0)))
>  or ((    R2V(4*I+3)) and (not R2V(4*I+2)) and (not R2V(4*I+1)) and (not
> R2V(4*I+0)))
>  or ((    R2V(4*I+3)) and (not R2V(4*I+2)) and (    R2V(4*I+1)) and (
> R2V(4*I+0)))
>  or ((    R2V(4*I+3)) and (    R2V(4*I+2)) and (    R2V(4*I+1)) and (not
> R2V(4*I+0)));
> end generate;
>
> -- The R80 logic: (2 LUTs)
> R8V(0)
>  <= ((not R4V(3)) and (not R4V(2)) and (not R4V(1)) and (    R4V(0)))
>  or ((not R4V(3)) and (    R4V(2)) and (not R4V(1)) and (not R4V(0)))
>  or ((not R4V(3)) and (    R4V(2)) and (    R4V(1)) and (    R4V(0)))
>  or ((    R4V(3)) and (not R4V(2)) and (    R4V(1)) and (not R4V(0)))
>  or ((    R4V(3)) and (    R4V(2)) and (not R4V(1)) and (    R4V(0)));
> R8V(1)
>  <= ((not R4V(3)) and (not R4V(2)) and (    R4V(1)) and (not R4V(0)))
>  or ((not R4V(3)) and (    R4V(2)) and (not R4V(1)) and (    R4V(0)))
>  or ((    R4V(3)) and (not R4V(2)) and (not R4V(1)) and (not R4V(0)))
>  or ((    R4V(3)) and (not R4V(2)) and (    R4V(1)) and (    R4V(0)))
>  or ((    R4V(3)) and (    R4V(2)) and (    R4V(1)) and (not R4V(0)));
>
> -- P4 = R23 # R15 (2 LUTs)
> P4V(0)
>  <= ((not R2V(7)) and (not R2V(6)) and (not R1V(11)) and (    R1V(10)))
>  or ((not R2V(7)) and (    R2V(6)) and (not R1V(11)) and (not R1V(10)))
>  or ((not R2V(7)) and (    R2V(6)) and (    R1V(11)) and (    R1V(10)))
>  or ((    R2V(7)) and (not R2V(6)) and (    R1V(11)) and (not R1V(10)))
>  or ((    R2V(7)) and (    R2V(6)) and (not R1V(11)) and (    R1V(10)));
> P4V(1)
>  <= ((not R2V(7)) and (not R2V(6)) and (    R1V(11)) and (not R1V(10)))
>  or ((not R2V(7)) and (    R2V(6)) and (not R1V(11)) and (    R1V(10)))
>  or ((    R2V(7)) and (not R2V(6)) and (not R1V(11)) and (not R1V(10)))
>  or ((    R2V(7)) and (not R2V(6)) and (    R1V(11)) and (    R1V(10)))
>  or ((    R2V(7)) and (    R2V(6)) and (    R1V(11)) and (not R1V(10)));
>
> -- P3 = R41 # R13 (2 LUTs)
> P3V(0)
>  <= ((not R4V(3)) and (not R4V(2)) and (not R1V(7)) and (    R1V(6)))
>  or ((not R4V(3)) and (    R4V(2)) and (not R1V(7)) and (not R1V(6)))
>  or ((not R4V(3)) and (    R4V(2)) and (    R1V(7)) and (    R1V(6)))
>  or ((    R4V(3)) and (not R4V(2)) and (    R1V(7)) and (not R1V(6)))
>  or ((    R4V(3)) and (    R4V(2)) and (not R1V(7)) and (    R1V(6)));
> P3V(1)
>  <= ((not R4V(3)) and (not R4V(2)) and (    R1V(7)) and (not R1V(6)))
>  or ((not R4V(3)) and (    R4V(2)) and (not R1V(7)) and (    R1V(6)))
>  or ((    R4V(3)) and (not R4V(2)) and (not R1V(7)) and (not R1V(6)))
>  or ((    R4V(3)) and (not R4V(2)) and (    R1V(7)) and (    R1V(6)))
>  or ((    R4V(3)) and (    R4V(2)) and (    R1V(7)) and (not R1V(6)));
>
> -- P2 = R41 # R21 (2 LUTs)
> P2V(0)
>  <= ((not R4V(3)) and (not R4V(2)) and (not R2V(3)) and (    R2V(2)))
>  or ((not R4V(3)) and (    R4V(2)) and (not R2V(3)) and (not R2V(2)))
>  or ((not R4V(3)) and (    R4V(2)) and (    R2V(3)) and (    R2V(2)))
>  or ((    R4V(3)) and (not R4V(2)) and (    R2V(3)) and (not R2V(2)))
>  or ((    R4V(3)) and (    R4V(2)) and (not R2V(3)) and (    R2V(2)));
> P2V(1)
>  <= ((not R4V(3)) and (not R4V(2)) and (    R2V(3)) and (not R2V(2)))
>  or ((not R4V(3)) and (    R4V(2)) and (not R2V(3)) and (    R2V(2)))
>  or ((    R4V(3)) and (not R4V(2)) and (not R2V(3)) and (not R2V(2)))
>  or ((    R4V(3)) and (not R4V(2)) and (    R2V(3)) and (    R2V(2)))
>  or ((    R4V(3)) and (    R4V(2)) and (    R2V(3)) and (not R2V(2)));
>
> -- P1 = R11 # R21 (2 LUTs)
> P1V(0)
>  <= ((not R1V(3)) and (not R1V(2)) and (not R2V(3)) and (    R2V(2)))
>  or ((not R1V(3)) and (    R1V(2)) and (not R2V(3)) and (not R2V(2)))
>  or ((not R1V(3)) and (    R1V(2)) and (    R2V(3)) and (    R2V(2)))
>  or ((    R1V(3)) and (not R1V(2)) and (    R2V(3)) and (not R2V(2)))
>  or ((    R1V(3)) and (    R1V(2)) and (not R2V(3)) and (    R2V(2)));
> P1V(1)
>  <= ((not R1V(3)) and (not R1V(2)) and (    R2V(3)) and (not R2V(2)))
>  or ((not R1V(3)) and (    R1V(2)) and (not R2V(3)) and (    R2V(2)))
>  or ((    R1V(3)) and (not R1V(2)) and (not R2V(3)) and (not R2V(2)))
>  or ((    R1V(3)) and (not R1V(2)) and (    R2V(3)) and (    R2V(2)))
>  or ((    R1V(3)) and (    R1V(2)) and (    R2V(3)) and (not R2V(2)));
>
> -- P0 = R41 # PR1 (2 LUTs)
> P0V(0)
>  <= ((not R4V(3)) and (not R4V(2)) and (not P1V(1)) and (    P1V(0)))
>  or ((not R4V(3)) and (    R4V(2)) and (not P1V(1)) and (not P1V(0)))
>  or ((not R4V(3)) and (    R4V(2)) and (    P1V(1)) and (    P1V(0)))
>  or ((    R4V(3)) and (not R4V(2)) and (    P1V(1)) and (not P1V(0)))
>  or ((    R4V(3)) and (    R4V(2)) and (not P1V(1)) and (    P1V(0)));
> P0V(1)
>  <= ((not R4V(3)) and (not R4V(2)) and (    P1V(1)) and (not P1V(0)))
>  or ((not R4V(3)) and (    R4V(2)) and (not P1V(1)) and (    P1V(0)))
>  or ((    R4V(3)) and (not R4V(2)) and (not P1V(1)) and (not P1V(0)))
>  or ((    R4V(3)) and (not R4V(2)) and (    P1V(1)) and (    P1V(0)))
>  or ((    R4V(3)) and (    R4V(2)) and (    P1V(1)) and (not P1V(0)));
>
> -- Assemble the partial remainders into the inputs for the quotient
> -- calculations:
> PRV(15 downto 0)         --      Remainder of
>   <= R1V(15 downto 14)   -- R17  AIN[31:28]
>   &  R2V( 7 downto  6)   -- R23  AIN[31:24]
>   &  P4V( 1 downto  0)   -- P4   AIN[31:20]
>   &  R4V( 3 downto  2)   -- R41  AIN[31:16]
>   &  P3V( 1 downto  0)   -- P3   AIN[31:12]
>   &  P2V( 1 downto  0)   -- P2   AIN[31:8]
>   &  P0V( 1 downto  0)   -- P0   AIN[31:4]
>   &  R8V( 1 downto  0);  -- R8   AIN[31:0]
>
> -- The highest quotient block has no remainder coming in,
> -- so compute it directly: (3 LUTs)
> with AIN(31 downto 28) select
>   QOUTD(30 downto 28) <=
>     "000" when "0000" | "0001" | "0010",
>     "001" when "0011" | "0100" | "0101",
>     "010" when "0110" | "0111" | "1000",
>     "011" when "1001" | "1010" | "1011",
>     "100" when "1100" | "1101" | "1110",
>     "101" when others;
>
> -- 0000 00
> -- 0001 00
> -- 0010 00
>
> -- 0011 01
> -- 0100 01
> -- 0101 01
>
> -- 0110 10
> -- 0111 10
> -- 1000 10
>
> -- 1001 11
> -- 1010 11
> -- 1011 11
>
>
> -- Compute the quotient in blocks of 4 bits
> Q: for I in 0 to 6 generate
>   -- Top two bits are computed directly from the carry-in and AIN
>  QOUTD(4*I + 2)
>   <= ((not PRV(2*I+3)) and (not PRV(2*I+2)) and (    AIN(4*I+3)) and (
> AIN(4*I+2)))
>   or ((not PRV(2*I+3)) and (    PRV(2*I+2)) and (not AIN(4*I+3)) and (not
> AIN(4*I+2)))
>   or ((not PRV(2*I+3)) and (    PRV(2*I+2)) and (not AIN(4*I+3)) and (
> AIN(4*I+2)))
>   or ((    PRV(2*I+3)) and (not PRV(2*I+2)) and (not AIN(4*I+3)) and (
> AIN(4*I+2)))
>   or ((    PRV(2*I+3)) and (not PRV(2*I+2)) and (    AIN(4*I+3)) and (not
> AIN(4*I+2)))
>   or ((    PRV(2*I+3)) and (not PRV(2*I+2)) and (    AIN(4*I+3)) and (
> AIN(4*I+2)));
>  QOUTD(4*I + 3)
>   <= ((not PRV(2*I+3)) and (    PRV(2*I+2)) and (    AIN(4*I+3)) and (not
> AIN(4*I+2)))
>   or ((not PRV(2*I+3)) and (    PRV(2*I+2)) and (    AIN(4*I+3)) and (
> AIN(4*I+2)))
>   or ((    PRV(2*I+3)) and (not PRV(2*I+2)) and (not AIN(4*I+3)) and (not
> AIN(4*I+2)))
>   or ((    PRV(2*I+3)) and (not PRV(2*I+2)) and (not AIN(4*I+3)) and (
> AIN(4*I+2)))
>   or ((    PRV(2*I+3)) and (not PRV(2*I+2)) and (    AIN(4*I+3)) and (not
> AIN(4*I+2)))
>   or ((    PRV(2*I+3)) and (not PRV(2*I+2)) and (    AIN(4*I+3)) and (
> AIN(4*I+2)));
>   -- I need to compute the remainder out of the top two bits for the lower
two
> bits
>  X0V(2*I + 0)
>   <= ((not PRV(2*I+3)) and (not PRV(2*I+2)) and (not AIN(4*I+3)) and (
> AIN(4*I+2)))
>   or ((not PRV(2*I+3)) and (    PRV(2*I+2)) and (not AIN(4*I+3)) and (not
> AIN(4*I+2)))
>   or ((not PRV(2*I+3)) and (    PRV(2*I+2)) and (    AIN(4*I+3)) and (
> AIN(4*I+2)))
>   or ((    PRV(2*I+3)) and (not PRV(2*I+2)) and (    AIN(4*I+3)) and (not
> AIN(4*I+2)))
>   or ((    PRV(2*I+3)) and (    PRV(2*I+2)) and (not AIN(4*I+3)) and (
> AIN(4*I+2)));
>  X0V(2*I + 1)
>   <= ((not PRV(2*I+3)) and (not PRV(2*I+2)) and (    AIN(4*I+3)) and (not
> AIN(4*I+2)))
>   or ((not PRV(2*I+3)) and (    PRV(2*I+2)) and (not AIN(4*I+3)) and (
> AIN(4*I+2)))
>   or ((    PRV(2*I+3)) and (not PRV(2*I+2)) and (not AIN(4*I+3)) and (not
> AIN(4*I+2)))
>   or ((    PRV(2*I+3)) and (not PRV(2*I+2)) and (    AIN(4*I+3)) and (
> AIN(4*I+2)))
>   or ((    PRV(2*I+3)) and (    PRV(2*I+2)) and (    AIN(4*I+3)) and (not
> AIN(4*I+2)));
>   -- Now I can compute the lowest two bits:
>  QOUTD(4*I + 0)
>   <= ((not X0V(2*I+1)) and (not X0V(2*I+0)) and (    AIN(4*I+1)) and (
> AIN(4*I+0)))
>   or ((not X0V(2*I+1)) and (    X0V(2*I+0)) and (not AIN(4*I+1)) and (not
> AIN(4*I+0)))
>   or ((not X0V(2*I+1)) and (    X0V(2*I+0)) and (not AIN(4*I+1)) and (
> AIN(4*I+0)))
>   or ((    X0V(2*I+1)) and (not X0V(2*I+0)) and (not AIN(4*I+1)) and (
> AIN(4*I+0)))
>   or ((    X0V(2*I+1)) and (not X0V(2*I+0)) and (    AIN(4*I+1)) and (not
> AIN(4*I+0)))
>   or ((    X0V(2*I+1)) and (not X0V(2*I+0)) and (    AIN(4*I+1)) and (
> AIN(4*I+0)));
>  QOUTD(4*I + 1)
>   <= ((not X0V(2*I+1)) and (    X0V(2*I+0)) and (    AIN(4*I+1)) and (not
> AIN(4*I+0)))
>   or ((not X0V(2*I+1)) and (    X0V(2*I+0)) and (    AIN(4*I+1)) and (
> AIN(4*I+0)))
>   or ((    X0V(2*I+1)) and (not X0V(2*I+0)) and (not AIN(4*I+1)) and (not
> AIN(4*I+0)))
>   or ((    X0V(2*I+1)) and (not X0V(2*I+0)) and (not AIN(4*I+1)) and (
> AIN(4*I+0)))
>   or ((    X0V(2*I+1)) and (not X0V(2*I+0)) and (    AIN(4*I+1)) and (not
> AIN(4*I+0)))
>   or ((    X0V(2*I+1)) and (not X0V(2*I+0)) and (    AIN(4*I+1)) and (
> AIN(4*I+0)));
> end generate;
>
>
> -- The following flip-flop implication of all the partial logic is
included
> only
> -- to prevent the synthesis tool from optimizing out the beautiful logic
I've
> -- created.
> FKD(53 downto 0) <= R1V & R2V & R4V & R8V & P4V & P3V & P2V & P1V & P0V &
X0V;
>
> -- Register the remainder
> REMD(1 downto 0) <= PRV(1 downto 0);
>
> process (CLK)
> begin
>   if CLK'event and CLK='1' then
>     FKQ   <= FKD;
>     QOUTQ <= QOUTD;
>     REMQ  <= REMD;
>   end if;
> end process;
>
>
> -- Output assignment:
>
> REMOUT <= REMQ(1 downto 0);
> QOUT   <= QOUTQ(30 downto 0);
>
> -- Test output (unused, but included for synthesis restriction).
> TEST   <= FKQ;
>
> end DIV32_3_arch;
>
>
> --
> Posted from firewall.terabeam.com [216.137.15.2]
> via Mailgate.ORG Server - http://www.Mailgate.ORG



Article: 37709
Subject: Re: Google Groups problems?
From: Harish Y S <harish@ti.com>
Date: Wed, 19 Dec 2001 19:34:41 +0530
Links: << >>  << T >>  << A >>
Yes,  there seems to be some problem with Google Groups. Even my postings
were just visible on Google Groups and didn't appear on other news servers.
Dunno whats wrong!!!!

Regards,
Harish
http://hdlplanet.tripod.com


Kevin Brace wrote:

> I know this topic is not directly related to this newsgroup, but I
> noticed some postings I made to comp.arch.fpga through Google Groups got
> posted on Google Groups' comp.arch.fpga archive, but wasn't there when I
> checked my postings through mailgate.org's service
> (http://www.mailgate.org).
> Anyone else noticed this problem?
>
> Kevin Brace (don't respond to me directly, respond within the newsgroup)


Article: 37710
Subject: Re: Barrel shifter puts three 2->1 muxes / slice in Xilinx
From: "Stephen Melnikoff" <s.j.melnikoff@iee.org>
Date: Wed, 19 Dec 2001 14:18:24 -0000
Links: << >>  << T >>  << A >>
> The problem with doing it is that it's hard to get the output of the "F"
LUT
> out of the slice.  But it can be done by brining it out the CARRY-OUT.

Perhaps I'm missing something, but why can't you send the output of the
F-LUT to output X, and the output of the F5-MUX to output F5?

Stephen Melnikoff.

--
Stephen Melnikoff - s.j.melnikoff@iee.org
Electronic, Electrical and Computer Engineering
University of Birmingham, Birmingham, UK




Article: 37711
Subject: Re: MIPS or MOPS?
From: Murali Jayapala <mjayapal@esat.kuleuven.ac.be>
Date: Wed, 19 Dec 2001 15:31:11 +0100
Links: << >>  << T >>  << A >>
Murali Jayapala wrote:

> > Wrong - consider any SIMD instructions (practicly all risc processors have
> > them these days) or for that matter, muladd.
> >
>
> But isnt the granularity of each of the operation in a SIMD instruction smaller
> than one 'regular' opertation ?.  It would be fair to compare operations of similar
> granularity. In vliw archs,  each operation in an instruction have  graularity
> similar to  one of regular risc style instruction. While the graularity of one SIMD
> instruction  still has  same granularity as the granularity of one regular risc
> instruction (even though each SIMD might have more than one operation). Isnt this
> true?? I am still under the impression that this is true.... but I could be wrong.

Oops sorry about that.. I think I am wrong here. I was thinking of sub-word parallel
instructions in SIMD style...


-MJ


Article: 37712
Subject: Boundary Scn, Bist
From: "Martin Fischer" <Martin.Fischer@fzi.de>
Date: Wed, 19 Dec 2001 16:08:56 +0100
Links: << >>  << T >>  << A >>
Hello,

What is the difference between Boundary Scan and
BIST ? And what can I do with them ?
With Boundary Scan I can read out the checksum from
an PLD, how can I read the cheksum out with an
Mikrocontroller ?

Thanks

Martin.Fischer@fzi.de



Article: 37713
Subject: clk_dll general question
From: dottavio@ised.it (Antonio)
Date: 19 Dec 2001 07:27:53 -0800
Links: << >>  << T >>  << A >>
I would want to use clk_dll to divide a clock by 3, where can I found
an example of this ?? Can I also apply some constrain to the clk_dll
??


Thanks

Article: 37714
Subject: Clocks and Synplify
From: dottavio@ised.it (Antonio)
Date: 19 Dec 2001 07:33:24 -0800
Links: << >>  << T >>  << A >>
In my project I've a master clock and a clock derived by it via
combinatorial logic, in Synplify I could apply constrain to the first,
I also could apply constrain to the second if I select it, my question
is what's the System clock that synplify show me together with the
other clocks.
It'a a problem if it doesn't respect the constrain on the master clock
??

Thanks

Article: 37715
Subject: Re: You take the low road and I'll ......
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 19 Dec 2001 08:00:55 -0800
Links: << >>  << T >>  << A >>
Austin,

You say potato, and I say potato.  Sounds like we are in agreement?

Anything can be well documented, but unfortunately most designs are not.

If I see hdl code, at least I can see where it is going, even if it is written
badly.  In fact, if it is written badly, then I can:  not hire the consultant
ever again, lay off that engineer, reject the code and get it done right.

Nice thing about software is that people have figured out how to manage it, and
document it.  Not that we have many good examples (Microsoft is the usual bad
example, but even here Apple Computer has an equally poor reputation for bad
code -- they actually printed t-shirts that said something like "OS7:  7000
bugs and counting").

If I examine a design, from top to bottom, I can make a determination of the
quality of the design by examining the hdl code.  It is possible, but more
difficult to see what is going on in schematic.  It is impossible to know what
is going on if I need to go look in FPGA Editor (unless I did it).  As a
technical manager, code review is one tool that should be used to make sure the
project is on track, following the rules, and has a higher likelihood of
success.

Austin

Austin Franklin wrote:

> > A design that is well architected, self documented, commented, and
> reliable is
> > more important to many customers.  I prefer to throw all of my energies
> into
> > supporting those designs (in hdl's) which now account for 99% of what is
> being
> > done out there.
>
> Well, Austin, that's all well and good...but one can do, in my opinion, an
> equally as well documented, if not better documented and certainly a more
> reliable design in schematics.  When the synthesis tools change, the design
> changes.  That's hardly reliability.  That is, unless you instantiate
> everything...but that's hardly synthesis...that's just a netlister.
>
> I also believe it's erroneous to claim that HDL code is "self documenting",
> that's not reality.  It takes care and time to correctly document a design.
>
> If you make the FPGAs big enough and fast enough, synthesis works.  If you
> make the CPUs fast enough, and have enough memory and disk space, Microsoft
> code works.  Same thing.  I'm not saying it's right or wrong, but it is a
> fact.
>
> Regards,
>
> Austin


Article: 37716
Subject: Re: Kindergarten Stuff
From: David Hawke <dhawke@xilinx.com>
Date: Wed, 19 Dec 2001 16:03:03 +0000
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------BD37B04DA684C5022DB6EDD2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bryan,

FPGA Editor does support routing, but TRACE has a few problems dealing with
it....

Also for everyone here, you might also want to try the Directed Routing
constraint (which appends it to the ucf or ncf file) Tools > Directed Routing
cst....

Dave

Bryan wrote:

> So lets talk controversial....
>
> If Lucent can support hard macros in Epic with hard routing, then why can't
> Xilinx.  My application requires it and Xilinx doesn't support it in FPGA
> editor(which was programmed by the same softies as Epic).  Oh, I remember
> why they don't support it.  Because nobody cares about designs that push the
> limitations of FPGAs.  Because everybody else that is making designs for
> Xilinx parts is still in kindergarten finger painting with verilog and hdl.
> Ha, I didn't get my EE degree to be a soft weirdo.  Anybody can throw code
> together and get poor performance.
>
> flame away kindergarten kids
>
> Bryan
>
> "Peter Alfke" <peter.alfke@xilinx.com> wrote in message
> news:3C1F8AEC.BFD2E067@xilinx.com...
> > This is a friendly and helpful newsgroup, but let's make sure that it does
> not
> > get abused.
> > Lots of textbooks explain how to divide by a power of 2, where the
> remainder is,
> > and how you sign-extend the MSB. Explaining that is not the purpose of
> this
> > newsgroup.
> >
> > Let's use our "bandwidth" for more complex and perhaps controversial
> questions
> > that are not explained in textbooks and data books.
> >
> > Peter Alfke, Xilinx Applications
> >
> >

--------------BD37B04DA684C5022DB6EDD2
Content-Type: text/x-vcard; charset=us-ascii;
 name="dhawke.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Hawke
Content-Disposition: attachment;
 filename="dhawke.vcf"

begin:vcard 
n:;David Hawke
tel;cell:(44) 778 875 5002
tel;fax:(44) 1291 621 541
tel;home:(44) 1291 621 655
tel;work:(44) 870 7350 517
x-mozilla-html:FALSE
org:Xilinx UK;Northern European Sales
version:2.1
email;internet:dhawke@xilinx.com
title:Xilinx Field Applications Engineer
adr;quoted-printable:;;Benchmark House=0D=0A203 Brooklands Road=0D=0A;Weybridge;Surrey;KT14 ORH;United Kingdom
fn:David Hawke
end:vcard

--------------BD37B04DA684C5022DB6EDD2--


Article: 37717
Subject: Re: DCM stability in Virtex2 -ES
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 19 Dec 2001 08:08:42 -0800
Links: << >>  << T >>  << A >>

--------------54E62841DE335C4C12624456
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

The most important errata from the errata sheet for the DCM is to reset it after
the part is configured and the clocks are running after a delay.

The delay is required because the power supply that runs the delay lines did not
power on for a long time until after the part is done configuring.  The delay can
be seconds if cold, and about 200 ms at room temperature.

The recommendation is to wait 500 ms at room temp (longer if cold), to assert RST
for a short period (say 100 us or less -- as it stops all of the clocks, and you
may be switching a lot of stuff, and power supplies don't like going from 0 load
to 100% load!), and then see if LOCKED is true, and CLIN_IN_LOST is false, and
(if the CLKFX outputs are used) CLK_FX_STOPPED is false.  If the status bits are
good, then the device is running OK.  If the status bits are not OK, reset it
again.

Austin

David Miller wrote:

> Hi,
>
> Here's a problem that does not qualify as kindergarten stuff.
>
> A DCM in a xc2v1000 engineering sample is behaving oddly.  I am using
> this DCM to generate and deskew a clock and antiphased clock (0 & 180
> degrees) for a DDR RAM.  It is being fed by a 100MHz crystal buffered
> with a CY2308 zero-delay clock buffer (ie, a pll.)
>
> The period of the clock seen at the board is 10 ns - usually.
> Occasionally, the clock periods is lengthened by between 2.5 and 3 ns.
>   The stretch is always in the low half of the cycle.
>
> What could be causing this?
>
> Relevant facts:
>         - Chip is a xc2v1000bg456-4 -ES
>         - Software is Xilinx Alliance 3.3.08i with the VirtexII device update
> files and the bitgen patch applied.
>         - SelectIO type HSTL class II with DCI is being used
>
> I used a 1 gigahertz (5 gigasample) oscilloscope to look at this clock
> pin, so sampling error isn't it.  The oscilloscope showed that sometimes
> (perhaps 1 of 4 stretched periods), the clock starts to go high at the
> right time, then changes its mind literally half way through the rise
> time -- it gets to half way between Vol and Voh (or Vref; this is HSTL)
> and then returns to Vol again.  between 2.5 and 3 ns later, it does a
> proper rising edge.
>
> I've even tried locking the DCM to different parts of the chip and it
> made no difference.
>
> I've searched the xilinx answers and found no clues.  Any suggestions
> gratefully received!
>
> --
> David Miller, BCMS (Hons)  | When something disturbs you, it isn't the
> Endace Measurement Systems | thing that disturbs you; rather, it is
> Mobile: +64-21-704-djm     | your judgement of it, and you have the
> Fax:    +64-21-304-djm     | power to change that.  -- Marcus Aurelius

--------------54E62841DE335C4C12624456
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
David,
<p>The most important errata from the errata sheet for the DCM is to reset
it after the part is configured and the clocks are running after a delay.
<p>The delay is required because the power supply that runs the delay lines
did not power on for a <b>long</b> time until after the part is done configuring.&nbsp;
The delay can be seconds if cold, and about 200 ms at room temperature.
<p>The recommendation is to wait 500 ms at room temp (longer if cold),
to assert RST for a short period (say 100 us or less -- as it stops all
of the clocks, and you may be switching a lot of stuff, and power supplies
don't like going from 0 load to 100% load!), and then see if LOCKED is
true, and CLIN_IN_LOST is false, and (if the CLKFX outputs are used) CLK_FX_STOPPED
is false.&nbsp; If the status bits are good, then the device is running
OK.&nbsp; If the status bits are not OK, reset it again.
<p>Austin
<p>David Miller wrote:
<blockquote TYPE=CITE>Hi,
<p>Here's a problem that does not qualify as kindergarten stuff.
<p>A DCM in a xc2v1000 engineering sample is behaving oddly.&nbsp; I am
using
<br>this DCM to generate and deskew a clock and antiphased clock (0 &amp;
180
<br>degrees) for a DDR RAM.&nbsp; It is being fed by a 100MHz crystal buffered
<br>with a CY2308 zero-delay clock buffer (ie, a pll.)
<p>The period of the clock seen at the board is 10 ns - usually.
<br>Occasionally, the clock periods is lengthened by between 2.5 and 3
ns.
<br>&nbsp; The stretch is always in the low half of the cycle.
<p>What could be causing this?
<p>Relevant facts:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Chip is a xc2v1000bg456-4
-ES
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Software is Xilinx Alliance
3.3.08i with the VirtexII device update
<br>files and the bitgen patch applied.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - SelectIO type HSTL class
II with DCI is being used
<p>I used a 1 gigahertz (5 gigasample) oscilloscope to look at this clock
<br>pin, so sampling error isn't it.&nbsp; The oscilloscope showed that
sometimes
<br>(perhaps 1 of 4 stretched periods), the clock starts to go high at
the
<br>right time, then changes its mind literally half way through the rise
<br>time -- it gets to half way between Vol and Voh (or Vref; this is HSTL)
<br>and then returns to Vol again.&nbsp; between 2.5 and 3 ns later, it
does a
<br>proper rising edge.
<p>I've even tried locking the DCM to different parts of the chip and it
<br>made no difference.
<p>I've searched the xilinx answers and found no clues.&nbsp; Any suggestions
<br>gratefully received!
<p>--
<br>David Miller, BCMS (Hons)&nbsp; | When something disturbs you, it isn't
the
<br>Endace Measurement Systems | thing that disturbs you; rather, it is
<br>Mobile: +64-21-704-djm&nbsp;&nbsp;&nbsp;&nbsp; | your judgement of
it, and you have the
<br>Fax:&nbsp;&nbsp;&nbsp; +64-21-304-djm&nbsp;&nbsp;&nbsp;&nbsp; | power
to change that.&nbsp; -- Marcus Aurelius</blockquote>
</html>

--------------54E62841DE335C4C12624456--


Article: 37718
Subject: Re: Kindergarten Stuff
From: "Bryan" <bryan@srccomp.com>
Date: Wed, 19 Dec 2001 09:20:37 -0700
Links: << >>  << T >>  << A >>
Ok, this is great.  Two other times I posted to this group about making hard
macros and got no response.  The low road paid off it seems.  I really want
to get these hard macros with locked routing to work.  What I see when I try
to make a hard macro is that I cannot manually route the nets in editor.  I
want to hand route the clock signal on local routing and hand route an
enable.  The first thing that happens is I start routing the clock through a
switchbox from a normal IBUF, works fine.  Then I try to re-select the input
sight to the switchbox to make a split in the routing.  I cannot select the
input bubble again and if I just select the net and a new destination out of
the switchbox it complains.  I have a routed design open in editor right
next to the one I am hand routing.  Since I couldn't get this to work, I
decided to first see if I could route the line by hand like the router did.
I know I am selecting usable sights because I am cheating of a routed
design.  So how do I re-select that bubble to continue hand routing?

From what I have seen on the group most people are letting the tool route
the "macro" then going into editor and turning the ncd to a macro.  Then
lock routing.  What I have been doing is placement only and then open the
ncd to hand route my couple nets.  What I am building into a macro is a 16
bit FIFO, I have 16 of these FIFOs in the design and each one contains IOB
latches.  Since they contain IOB latches none of them have the identical IOB
placement because of prohibit sites.  If I hand route I can keep al of the
clock tree in the logic portion the same and only change which IOBs it goes
to for each macro.

Any help greatly appreciated, but if you can answer this why can't my Xilinx
FAE?

Bryan

"Bret Wade" <bret.wade@xilinx.com> wrote in message
news:3C1FDBC2.A88FF9B8@xilinx.com...
> Hello Bryan,
>
> FPGA Editor  and the other implementation tools do support routed hard
macros.
> Hard macros aren't widely used because of the limitations in the timing
analysis
> tools in dealing with the macros, but the support is there.
>
> Regards,
> Bret Wade
> Xilinx Product Applications
>
> Bryan wrote:
>
> > So lets talk controversial....
> >
> > If Lucent can support hard macros in Epic with hard routing, then why
can't
> > Xilinx.  My application requires it and Xilinx doesn't support it in
FPGA
> > editor(which was programmed by the same softies as Epic).  Oh, I
remember
> > why they don't support it.  Because nobody cares about designs that push
the
> > limitations of FPGAs.  Because everybody else that is making designs for
> > Xilinx parts is still in kindergarten finger painting with verilog and
hdl.
> > Ha, I didn't get my EE degree to be a soft weirdo.  Anybody can throw
code
> > together and get poor performance.
> >
> > flame away kindergarten kids
> >
> > Bryan
> >
> > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message
> > news:3C1F8AEC.BFD2E067@xilinx.com...
> > > This is a friendly and helpful newsgroup, but let's make sure that it
does
> > not
> > > get abused.
> > > Lots of textbooks explain how to divide by a power of 2, where the
> > remainder is,
> > > and how you sign-extend the MSB. Explaining that is not the purpose of
> > this
> > > newsgroup.
> > >
> > > Let's use our "bandwidth" for more complex and perhaps controversial
> > questions
> > > that are not explained in textbooks and data books.
> > >
> > > Peter Alfke, Xilinx Applications
> > >
> > >
>



Article: 37719
Subject: Re: Kindergarten Stuff
From: "Bryan" <bryan@srccomp.com>
Date: Wed, 19 Dec 2001 09:21:50 -0700
Links: << >>  << T >>  << A >>

"Carl Brannen" <carl.brannen@terabeam.com> wrote in message
news:58d3bc222c92128795a51aed1bc2d4d1.51709@mygate.mailgate.org...
> "Bryan" <bryan@srccomp.com> wrote in message
> news:3c1fc73b$0$22747$724ebb72@reader2.ash.ops.us.uu.net...
>
> > So lets talk controversial....
> >
> > If Lucent can support hard macros in Epic with hard routing, then why
can't
> > Xilinx.  My application requires it and Xilinx doesn't support it in
FPGA
> > editor(which was programmed by the same softies as Epic).
>
> Just curious, which constraint is it that is driving you to hard macros?
I've
> long wished for better support for the little things.  I haven't got it,
so
> I've drifted towards optimizing VHDL to get what I want.
>

My design is in a XC2V3000 part.  I have 16 asynchronous FIFOs that
interface to my core logic design.  Each of these FIFOs has its own write
clock, so there is not enough resources in the chip to put these on low skew
global clocks.  I also have 4 other clocks in the design.  So I have just
run out of clock resources.  That is not a big deal if I could hand route
the FIFO write clocks for repeatability.  See my other response to Bret Wade

Bryan



Article: 37720
Subject: Re: Kindergarten Stuff
From: David Hawke <dhawke@xilinx.com>
Date: Wed, 19 Dec 2001 17:07:22 +0000
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------02E14D37B3671B885B255E54
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bryan,

I tend to use the add command when selecting one net with the pin of the COMP
that I want to connect to. I generally then let the router pick the route
throught the switch matrix. The router may or may not use the same net and split
it. Personally when routing the clocks, I use tight constraints in PAR, then
lock the clock net down (if met) using the directed routing constraint...Much
easier and less hassle!

btw : I am an FAE and have just one customer doing this kind of stuff.....I
wouldn't recommend it to any of my customers, but it is fantastic to guarantee
local clocks working!

Dave

Bryan wrote:

> Ok, this is great.  Two other times I posted to this group about making hard
> macros and got no response.  The low road paid off it seems.  I really want
> to get these hard macros with locked routing to work.  What I see when I try
> to make a hard macro is that I cannot manually route the nets in editor.  I
> want to hand route the clock signal on local routing and hand route an
> enable.  The first thing that happens is I start routing the clock through a
> switchbox from a normal IBUF, works fine.  Then I try to re-select the input
> sight to the switchbox to make a split in the routing.  I cannot select the
> input bubble again and if I just select the net and a new destination out of
> the switchbox it complains.  I have a routed design open in editor right
> next to the one I am hand routing.  Since I couldn't get this to work, I
> decided to first see if I could route the line by hand like the router did.
> I know I am selecting usable sights because I am cheating of a routed
> design.  So how do I re-select that bubble to continue hand routing?
>
> From what I have seen on the group most people are letting the tool route
> the "macro" then going into editor and turning the ncd to a macro.  Then
> lock routing.  What I have been doing is placement only and then open the
> ncd to hand route my couple nets.  What I am building into a macro is a 16
> bit FIFO, I have 16 of these FIFOs in the design and each one contains IOB
> latches.  Since they contain IOB latches none of them have the identical IOB
> placement because of prohibit sites.  If I hand route I can keep al of the
> clock tree in the logic portion the same and only change which IOBs it goes
> to for each macro.
>
> Any help greatly appreciated, but if you can answer this why can't my Xilinx
> FAE?
>
> Bryan
>
> "Bret Wade" <bret.wade@xilinx.com> wrote in message
> news:3C1FDBC2.A88FF9B8@xilinx.com...
> > Hello Bryan,
> >
> > FPGA Editor  and the other implementation tools do support routed hard
> macros.
> > Hard macros aren't widely used because of the limitations in the timing
> analysis
> > tools in dealing with the macros, but the support is there.
> >
> > Regards,
> > Bret Wade
> > Xilinx Product Applications
> >
> > Bryan wrote:
> >
> > > So lets talk controversial....
> > >
> > > If Lucent can support hard macros in Epic with hard routing, then why
> can't
> > > Xilinx.  My application requires it and Xilinx doesn't support it in
> FPGA
> > > editor(which was programmed by the same softies as Epic).  Oh, I
> remember
> > > why they don't support it.  Because nobody cares about designs that push
> the
> > > limitations of FPGAs.  Because everybody else that is making designs for
> > > Xilinx parts is still in kindergarten finger painting with verilog and
> hdl.
> > > Ha, I didn't get my EE degree to be a soft weirdo.  Anybody can throw
> code
> > > together and get poor performance.
> > >
> > > flame away kindergarten kids
> > >
> > > Bryan
> > >
> > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message
> > > news:3C1F8AEC.BFD2E067@xilinx.com...
> > > > This is a friendly and helpful newsgroup, but let's make sure that it
> does
> > > not
> > > > get abused.
> > > > Lots of textbooks explain how to divide by a power of 2, where the
> > > remainder is,
> > > > and how you sign-extend the MSB. Explaining that is not the purpose of
> > > this
> > > > newsgroup.
> > > >
> > > > Let's use our "bandwidth" for more complex and perhaps controversial
> > > questions
> > > > that are not explained in textbooks and data books.
> > > >
> > > > Peter Alfke, Xilinx Applications
> > > >
> > > >
> >

--------------02E14D37B3671B885B255E54
Content-Type: text/x-vcard; charset=us-ascii;
 name="dhawke.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Hawke
Content-Disposition: attachment;
 filename="dhawke.vcf"

begin:vcard 
n:;David Hawke
tel;cell:(44) 778 875 5002
tel;fax:(44) 1291 621 541
tel;home:(44) 1291 621 655
tel;work:(44) 870 7350 517
x-mozilla-html:FALSE
org:Xilinx UK;Northern European Sales
version:2.1
email;internet:dhawke@xilinx.com
title:Xilinx Field Applications Engineer
adr;quoted-printable:;;Benchmark House=0D=0A203 Brooklands Road=0D=0A;Weybridge;Surrey;KT14 ORH;United Kingdom
fn:David Hawke
end:vcard

--------------02E14D37B3671B885B255E54--


Article: 37721
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: Andy Peters <andy@exponentmedia.nospam.com>
Date: Wed, 19 Dec 2001 17:09:57 GMT
Links: << >>  << T >>  << A >>
S. Ramirez wrote:

>      I don't know about you guys and gals and pals, but everytime I do a
> design, without exception, I ALWAYS go into the Xilinx Design Manager
> Design --> Optiions --> Implementation Edit Options and select and select
> "Inputs and Outputs" for Pack I/O Registers/Latches into IOBs for.  I ALWAYS
> want my designs to use IOB flip flops if possible.  It seems to me that the
> default "Off" is a waste of these flip flops.  Does anyone here every turn
> this off?

Simon,

Amen.

---a




Article: 37722
Subject: Re: Kindergarten Stuff
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Wed, 19 Dec 2001 17:12:03 -0000
Links: << >>  << T >>  << A >>
"David Hawke" <dhawke@...inx.com> wrote

> Also for everyone here, you might also want to try the Directed Routing
> constraint (which appends it to the ucf or ncf file) Tools > Directed Routing
> cst....

I guess "Tools > Directed Routing cst" is not to be
confused with "Tools > DRC" :)

Which revision of FPGA Editor for DirectedRoutingCst ?





Article: 37723
Subject: Re: Best-case timing?
From: Andy Peters <andy@exponentmedia.nospam.com>
Date: Wed, 19 Dec 2001 17:19:58 GMT
Links: << >>  << T >>  << A >>
Stephen Byrne wrote:

> I originally posted this yesterday on google groups, but I'm not seeing it
> on my home news server.  In case it is not visible to all, I'm reposting.
> 
> Hello All,
> 
> My company is currently comparing 66MHz PCI core solutions from Xilinx
> and Altera, as well as debating using a home-spun core.  One issue
> I've come upon is the PCI requirement for a MAX clock-to-out time of 6
> ns and MIN clock-to-out time of 2 ns.  Both the Xilinx ISE and Altera
> Quartus II tools seem very helpful in supplying MAX (worst-case) Tco
> times, but I don't see any info on best-case times.  Apparently the
> SDF files for back-annotated timing sim have the same worst-case
> numbers repeated 3 times, resulting in the same simulation regardless
> of case selection.  My question is: how is anyone (FPGA vendors
> included) guaranteeing a MIN Tco of 2 ns across all conditions and
> parts if the design tools don't even yield that information?


You like to live dangerously if you depend on best-case timing information.

--a


Article: 37724
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Wed, 19 Dec 2001 17:24:31 GMT
Links: << >>  << T >>  << A >>
"Austin Franklin" <austin@dark98room.com> wrote in message
news:u1va20nslv01fe@corp.supernews.com...
> Hi Simon,
>
> That's what you get for using Design Mangler...er...Manager ;-)
>
> Austin

Hi Austin,
    Is Max Pus II any better?
Simon





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
2017JanFebMarApr2017

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