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 64250

Article: 64250
Subject: Re: FIR Filter cores for Virtex-][
From: Ray Andraka <ray@andraka.com>
Date: Mon, 22 Dec 2003 14:30:10 -0500
Links: << >>  << T >>  << A >>
The stepping number is a function of the part number, as I recall there is a decode sheet somewhere on the Xilinx website.
I think only the -4's have the stepping 0, which equates to something about 130 MHz on a fully pipelined multiplier...if you
also add pipeline registers immediately before and after the multiplier and place them properly.  I don't think it will be
an issue with the -5 parts.

Jim George wrote:

> This may be sheer laziness, but how do I find out the stepping of a
> V2?
> I had worked out a design where I ran a MAC-based filter at 130 MHz, I
> hope my V2's multipliers (-5 grade) can take it. I'm not looking at
> very large precision, so I wont need multiple passes through the
> multipliers.
>     -Jim.
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3FE34730.C68AB68@andraka.com>...
> > Ah yes, without placement, the DA filters, especially with parallel bits don't fare well with the place and route
> > tools.  I've got a design I'm putting the finishing touches on right now that has DA filters implemented in a 2V3000-4
> > (stepping 0).  It has 30 bit coefficients, and in some places up to 40 bits arithmetic.  I have no problem getting to
> > to run at a 160 MHz clock in the -4 part.  The areas I have had timing difficulties are in routing to-from the brams
> > that are used as delay queues, mostly because I was too lazy to place them and the placer does a lousy job placing
> > brams.  Anyway, in this case, using multipliers would have required a bigger part.  The multipliers in the stepping 0
> > devices can't be clocked at 160 MHz, plus due to the data widths I'd need to use four multiplies to complete each
> > multiplication.  In this design, the DA approach was a clear winner.
> >
> > There is a data ordering quirk with the decimating MAC filter.  You have a similar quirk with a DA filter if you are
> > sending multiple channels thorugh the filter.  Nothing a bit of ingenuity won't fix.
> >

--
--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: 64251
Subject: A simple horizontal frequency doubler PLL for TV line doubler.
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Mon, 22 Dec 2003 19:30:14 GMT
Links: << >>  << T >>  << A >>

Now I am very happy I got this working, PLL always did cost me
many hours of thinking and tinkering...
This takes a 50 MHz clock, and a horizontal trigger of about 1 to 5 clocks
high (purified H sync in).
It generates a 32KHz sync pulse for the monitor.
The stability seems very good.
So anyways I got a picture from the linedoubler, only BW for now.
Also some test on timebase correction worked..
Thought I share this with you, as it is the first thing needed for
a line doubler, and could be used for other things too I am sure.

Input is htrigger64, output is test_h, clock is real_clock.
Never mind the reset, it will run continuously.
It will go wild without input, and kill your monitor perhaps.. so have some
fail safe circuit.

// start frequency multiplier 
parameter MULTIP = 2;

// 2h oscillator
reg [10:0] reload;
reg test_h;
reg [15:0] th_count;
reg th;
always @(posedge real_clock)
begin
case(th_count)
        0:
            begin
            test_h = 0;
            th = 1;
            th_count = 1;
            end
        10:
            begin
            th = 0;
            th_count = 11;
            end
        200:
            begin
            test_h = 1;
            th_count = 201;
            end
        reload:
            begin
            th_count = 0;
            end
        default:
            th_count = th_count + 1;
    endcase    
end

// incoming line length detection
reg [15:0] llen;
reg [15:0] cllen;
reg hflag;
always @(posedge real_clock)
begin
if(htrigger64 == 1)
    begin
    if(! hflag)
        begin
        cllen = llen;
        llen = 0;
        hflag = 1;
        end
    end
else 
    begin
    llen = llen + 1;
    hflag = 0;
    end
end

// frequency discriminator
reg [10:0] sh;
reg [7:0] lcnt;
reg [10:0] ccnt;
always @(posedge real_clock)
begin
if(htrigger64 == 1)
    begin
    if(test_h2 == 0)
        begin
        if(sh > 0) sh = sh - 1;
        end
    else 
        begin
        if(sh < 400) sh = sh + 1;
        end

    // hehe, the trick
    reload = (cllen / MULTIP) + sh;
    end
end
// end frequency multiplier


Article: 64252
Subject: Re: Spartan II Block Ram
From: "John Retta" <jretta@rtc-inc.com>
Date: Mon, 22 Dec 2003 19:34:28 GMT
Links: << >>  << T >>  << A >>
Kind of a puzzle since you say that the .mrp report states there are
exactly the number of block rams that you expect, yet the warning
claims there are additional RAM cells implemented in distributed
LUTs.

Is it clear that the LUT RAMs are the intended block RAMs, or
that they are an entirely new block of logic altogether?

Other poster has good point about using coregen.

I personally avoid coregen.  Not much more effort to instantiate
blockrams directly (see lib.pdf), and you get exactly what you
want.

Take another look at bottom of .mrp file.  There is also a section
which describes the initialization values used for the block rams.
It sounds like you are intializing the block rams, so the values
you expect to use should show up down here.

-- 
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

email : jretta@rtc-inc.com
web :  www.rtc-inc.com


"Chuck Gales" <cgales@_NOSPAM_nc.rr.com> wrote in message
news:pan.2003.12.22.11.30.11.552120@_NOSPAM_nc.rr.com...
> On Mon, 22 Dec 2003 04:51:48 +0000, John Retta wrote:
>
> > The other respondant had the correct idea.  Lots of times outputs
signals
> > from one logic function to another might be misnamed, and hence the
source
> > block might be optimized away.  Problem is that the offending problem
may
> > be several layers past the block which has been eliminated, and for some
> > reason the synthesis tools are not as clear as they used to be where the
> > problem is located.
> >
> > The simulator is usually a good place to isolate these problems,
although
> > it sounds like you have tracked the data paths already.
> >
> > Check the .mrp report in your synthesis directory, and make sure the
> > number of block rams are what you expect.  If I have 100 synthesis runs
> > for a design over 2 months, I check this file every run.
>
> Looking at the .mrp report, I see the 4 block rams as expected.  Also, the
> post-synthesis HDL model functions correctly, so it seems that everything
> is being synthesized correctly.
>
>  There doesn't seem to be any critical warnings or errors about the Block
> Ram.  I do receive the following warning:
>
> WARNING:Xst:1772 - You have explicitly defined initial contents for this
> RAM, which are currently ignored when the RAM is implemented with LUT
> resources, leading to incorrect circuit behavior. Changing the RAM
> description so that it is read synchronously will allow implementation on
> block RAM resources for which we provide full initial contents support.
>
> I am not really sure why this warning is received, since the ram is
> designed with RAMB_S4 primitives and accessed synchronously.
>
> Could this lead to something?
>
> Chuck



Article: 64253
Subject: Re: WHAT APPLICATION WE CAN IMPLEMENT ON VERTEX II PRO
From: Ray Andraka <ray@andraka.com>
Date: Mon, 22 Dec 2003 14:52:08 -0500
Links: << >>  << T >>  << A >>
The sky is the limit.  The larger devices have vast amounts of free
logic to use for whatever application you can dream up.  Usually,
this is approached with a specific application in mind and the
question is: can this be done with an FPGA, and if so, how big an
FPGA is needed.  I've done a large number of DSP designs including a
complete shortwave receiver as well as several radar and sonar
processors using FPGAs far smaller than the largest V2 Pro parts.
Some examples are presented on the gallery page of my website.

Brian Drummond wrote:

> On 20 Dec 2003 23:04:12 -0800, fac_4u@hotmail.com (Farhan) wrote:
>
> >Hi!
> >
> >Is there anyone who have ideas that what sort of DSP or telecom
> >applications we an implement on Vertex II Pro ....
> >
> >thanxs
>
> A *really* nice vending machine.
> Or traffic light control for a whole city!
>
> - Brian

--
--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: 64254
Subject: Re: Spartan3 availability
From: Ray Andraka <ray@andraka.com>
Date: Mon, 22 Dec 2003 14:55:10 -0500
Links: << >>  << T >>  << A >>
The Altera parts still don't have a workable equivalent of the Xilinx SRL-16,
which can be used to huge advantage in DSP applications...if you code to it.
Otherwise, I'd agree.


>

--
--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: 64255
Subject: Re: Spartan II Block Ram
From: "Chuck Gales" <cgales@_NOSPAM_nc.rr.com>
Date: Mon, 22 Dec 2003 22:40:48 GMT
Links: << >>  << T >>  << A >>
On Mon, 22 Dec 2003 16:51:42 +0000, tbx135 wrote:

> Check this one out too.
> http://toolbox.xilinx.com/docsan/xilinx4/data/docs/sim/vtex11.html
> 
> My guess is that you behaviorally changed this and XST now is
> instantiating a LUT version of the memory. That would be a new one on
> me...

Well,
 Here is the SRAM module I have created:

// Spartan II SRAM based on Xilinx MemBlock Primative
//
`timescale 1ns/1ns

module spartanii_sram (
    reset_n,
    we_n,
    ce_n,
    clk,
    addr,
    din,
    dout
);

input           reset_n;
input           we_n;
input           ce_n;
input           clk;
input   [9:0]   addr;
input   [7:0]   din;
output  [7:0]   dout;

RAMB4_S4 sram_low(
    .EN         (~ce_n          ),
    .RST        (~reset_n       ),
    .WE         (~we_n          ),
    .CLK        (clk            ),
    .ADDR       (addr           ),
    .DI         (din[3:0]       ),
    .DO         (dout[3:0]      )
);

RAMB4_S4 sram_hi(
    .EN         (~ce_n          ),
    .RST        (~reset_n       ),
    .WE         (~we_n          ),
    .CLK        (clk            ),
    .ADDR       (addr           ),
    .DI         (din[7:4]       ),
    .DO         (dout[7:4]      )
);

endmodule

There are no values assigned, yet for some reason, XST thinks that there
are???  Looking at the final report, it states that there are 4 RAM BLOCKS
generated (I include this module twice), which seems correct.

I also define a ROM module, which might be picked up as a RAM block, but
that works fine, and looking at the synthesis report, the ROM seems to be
inmplemented as LUTs.

Article: 64256
Subject: Re: Spartan II Block Ram
From: "Chuck Gales" <cgales@_NOSPAM_nc.rr.com>
Date: Mon, 22 Dec 2003 22:46:26 GMT
Links: << >>  << T >>  << A >>
On Mon, 22 Dec 2003 19:34:28 +0000, John Retta wrote:

> Kind of a puzzle since you say that the .mrp report states there are
> exactly the number of block rams that you expect, yet the warning claims
> there are additional RAM cells implemented in distributed LUTs.
> 
> Is it clear that the LUT RAMs are the intended block RAMs, or that they
> are an entirely new block of logic altogether?
> 
> Other poster has good point about using coregen.
> 
> I personally avoid coregen.  Not much more effort to instantiate blockrams
> directly (see lib.pdf), and you get exactly what you want.
> 
> Take another look at bottom of .mrp file.  There is also a section which
> describes the initialization values used for the block rams. It sounds
> like you are intializing the block rams, so the values you expect to use
> should show up down here.
I looked at the .mrp and see no initialization of RAM.  Here is the
complete .mrp file.  I see nothing which would indicate a problem.

Release 6.1.03i Map G.26
Xilinx Mapping Report File for Design 'spartanii_z80'

Design Information
------------------
Command Line   : C:/Xilinx/bin/nt/map.exe -intstyle ise -p xc2s200-fg456-5 -cm
area -pr b -k 4 -c 100 -tx off -o spartanii_z80_map.ncd spartanii_z80.ngd
spartanii_z80.pcf 
Target Device  : x2s200
Target Package : fg456
Target Speed   : -5
Mapper Version : spartan2 -- $Revision: 1.16 $
Mapped Date    : Sun Dec 21 16:38:57 2003

Design Summary
--------------
Number of errors:      0
Number of warnings:    3
Logic Utilization:
  Number of Slice Flip Flops:       441 out of  4,704    9%
  Number of 4 input LUTs:         2,670 out of  4,704   56%
Logic Distribution:
    Number of occupied Slices:                       1,528 out of  2,352   64%
    Number of Slices containing only related logic:  1,528 out of  1,528  100%
    Number of Slices containing unrelated logic:         0 out of  1,528    0%
        *See NOTES below for an explanation of the effects of unrelated logic
Total Number 4 input LUTs:        2,797 out of  4,704   59%
      Number used as logic:                     2,670
      Number used as a route-thru:                 63
      Number used for Dual Port RAMs:              64
      (Two LUTs used per Dual Port RAM)
   Number of bonded IOBs:            18 out of    284    6%
   Number of Tbufs:                   8 out of  2,464    1%
   Number of Block RAMs:              4 out of     14   28%
   Number of GCLKs:                   1 out of      4   25%
   Number of GCLKIOBs:                1 out of      4   25%

Total equivalent gate count for design:  91,669
Additional JTAG gate count for IOBs:  912
Peak Memory Usage:  78 MB

NOTES:

   Related logic is defined as being logic that shares connectivity -
   e.g. two LUTs are "related" if they share common inputs.
   When assembling slices, Map gives priority to combine logic that
   is related.  Doing so results in the best timing performance.

   Unrelated logic shares no connectivity.  Map will only begin
   packing unrelated logic into a slice once 99% of the slices are
   occupied through related logic packing.

   Note that once logic distribution reaches the 99% level through
   related logic packing, this does not mean the device is completely
   utilized.  Unrelated logic packing will then begin, continuing until
   all usable LUTs and FFs are occupied.  Depending on your timing
   budget, increased levels of unrelated logic packing may adversely
   affect the overall timing performance of your design.


Table of Contents
-----------------
Section 1 - Errors
Section 2 - Warnings
Section 3 - Informational
Section 4 - Removed Logic Summary
Section 5 - Removed Logic
Section 6 - IOB Properties
Section 7 - RPMs
Section 8 - Guide Report
Section 9 - Area Group Summary
Section 10 - Modular Design Summary
Section 11 - Timing Report
Section 12 - Configuration String Information
Section 13 - Additional Device Resource Counts

Section 1 - Errors
------------------

Section 2 - Warnings
--------------------
WARNING:Pack:266 - The function generator z80_u0_mcode_ALU_Op<2>27 failed to
   merge with F5 multiplexer z80_u0_mcode_ALU_Op<2>219.  There is a conflict for
   the FXMUX.  The design will exhibit suboptimal timing.
WARNING:Pack:249 - The following adjacent carry multiplexers occupy different
   slice components.  The resulting carry chain will have suboptimal timing.
   	z80_u0_I149_inst_cy_67
   	z80_u0_I149_inst_cy_68
WARNING:Pack:249 - The following adjacent carry multiplexers occupy different
   slice components.  The resulting carry chain will have suboptimal timing.
   	z80_u0_I149_inst_cy_68
   	z80_u0_I149_inst_cy_69

Section 3 - Informational
-------------------------
INFO:LIT:95 - All of the external outputs in this design are using slew rate
   limited output drivers. The delay on speed critical outputs can be
   dramatically reduced by designating them as fast outputs in the schematic.
INFO:MapLib:562 - No environment variables are currently set.

Section 4 - Removed Logic Summary
---------------------------------
   2 block(s) optimized away

Section 5 - Removed Logic
-------------------------

Optimized Block(s):
TYPE 		BLOCK
GND 		XST_GND
VCC 		XST_VCC

To enable printing of redundant blocks removed and signals merged, set the
detailed map report option and rerun map.

Section 6 - IOB Properties
--------------------------

+------------------------------------------------------------------------------------------------------------------------+
| IOB Name                           | Type    | Direction | IO Standard | Drive    | Slew | Reg (s)  | Resistor | IOB   |
|                                    |         |           |             | Strength | Rate |          |          | Delay |
+------------------------------------------------------------------------------------------------------------------------+
| CLK                                | GCLKIOB | INPUT     | LVTTL       |          |      |          |          |       |
| DISP_1A                            | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| DISP_1B                            | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| DISP_1C                            | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| DISP_1D                            | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| DISP_1E                            | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| DISP_1F                            | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| DISP_1G                            | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| DISP_2A                            | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| DISP_2B                            | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| DISP_2C                            | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| DISP_2D                            | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| DISP_2E                            | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| DISP_2F                            | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| DISP_2G                            | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| LED                                | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
| RESET_n                            | IOB     | INPUT     | LVTTL       |          |      |          |          |       |
| RXD                                | IOB     | INPUT     | LVTTL       |          |      |          |          |       |
| TXD                                | IOB     | OUTPUT    | LVTTL       | 12       | SLOW |          |          |       |
+------------------------------------------------------------------------------------------------------------------------+

Section 7 - RPMs
----------------

Section 8 - Guide Report
------------------------
Guide not run on this design.

Section 9 - Area Group Summary
------------------------------
No area groups were found in this design.

Section 10 - Modular Design Summary
-----------------------------------
Modular Design not used for this design.

Section 11 - Timing Report
--------------------------
This design was not run using timing mode.

Section 12 - Configuration String Details
-----------------------------------------
Use the "-detail" map option to print out Configuration Strings

Section 13 - Additional Device Resource Counts
----------------------------------------------
Number of JTAG Gates for IOBs = 19
Number of Equivalent Gates for Design = 91,669
Number of RPM Macros = 0
Number of Hard Macros = 0
PCI IOBs = 0
PCI LOGICs = 0
CAPTUREs = 0
BSCANs = 0
STARTUPs = 0
DLLs = 0
GCLKIOBs = 1
GCLKs = 1
Block RAMs = 4
TBUFs = 8
Total Registers (Flops & Latches in Slices & IOBs) not driven by LUTs = 144
IOB Latches not driven by LUTs = 0
IOB Latches = 0
IOB Flip Flops not driven by LUTs = 0
IOB Flip Flops = 0
Unbonded IOBs = 0
Bonded IOBs = 18
Shift Registers = 0
Static Shift Registers = 0
Dynamic Shift Registers = 32
16x1 ROMs = 0
16x1 RAMs = 0
32x1 RAMs = 0
Dual Port RAMs = 32
MULTANDs = 1
MUXF5s + MUXF6s = 457
4 input LUTs used as Route-Thrus = 63
4 input LUTs = 2670
Slice Latches not driven by LUTs = 0
Slice Latches = 0
Slice Flip Flops not driven by LUTs = 144
Slice Flip Flops = 441
Slices = 1528
Number of LUT signals with 4 loads = 50
Number of LUT signals with 3 loads = 87
Number of LUT signals with 2 loads = 307
Number of LUT signals with 1 load = 1983
NGM Average fanout of LUT = 2.19
NGM Maximum fanout of LUT = 77
NGM Average fanin for LUT = 3.5270
Number of LUT symbols = 2670
Number of IPAD symbols = 3
Number of IBUF symbols = 2


Article: 64257
Subject: Re: Spartan II Block Ram
From: "tbx135" <tbx135@msn.com>
Date: Mon, 22 Dec 2003 22:49:41 GMT
Links: << >>  << T >>  << A >>
Did you find a .coe file?
"Chuck Gales" <cgales@_NOSPAM_nc.rr.com> wrote in message
news:pan.2003.12.22.22.36.07.341609@_NOSPAM_nc.rr.com...
> On Mon, 22 Dec 2003 16:51:42 +0000, tbx135 wrote:
>
> > Check this one out too.
> > http://toolbox.xilinx.com/docsan/xilinx4/data/docs/sim/vtex11.html
> >
> > My guess is that you behaviorally changed this and XST now is
> > instantiating a LUT version of the memory. That would be a new one on
> > me...
>
> Well,
>  Here is the SRAM module I have created:
>
> // Spartan II SRAM based on Xilinx MemBlock Primative
> //
> `timescale 1ns/1ns
>
> module spartanii_sram (
>     reset_n,
>     we_n,
>     ce_n,
>     clk,
>     addr,
>     din,
>     dout
> );
>
> input           reset_n;
> input           we_n;
> input           ce_n;
> input           clk;
> input   [9:0]   addr;
> input   [7:0]   din;
> output  [7:0]   dout;
>
> RAMB4_S4 sram_low(
>     .EN         (~ce_n          ),
>     .RST        (~reset_n       ),
>     .WE         (~we_n          ),
>     .CLK        (clk            ),
>     .ADDR       (addr           ),
>     .DI         (din[3:0]       ),
>     .DO         (dout[3:0]      )
> );
>
> RAMB4_S4 sram_hi(
>     .EN         (~ce_n          ),
>     .RST        (~reset_n       ),
>     .WE         (~we_n          ),
>     .CLK        (clk            ),
>     .ADDR       (addr           ),
>     .DI         (din[7:4]       ),
>     .DO         (dout[7:4]      )
> );
>
> endmodule
>
> There are no values assigned, yet for some reason, XST thinks that there
> are???  Looking at the final report, it states that there are 4 RAM BLOCKS
> generated (I include this module twice), which seems correct.
>
> I also define a ROM module, which might be picked up as a RAM block, but
> that works fine, and looking at the synthesis report, the ROM seems to be
> inmplemented as LUTs.



Article: 64258
Subject: Re: Hyperthreading vs. Dual proc
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 22 Dec 2003 23:03:06 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <gFzFb.1536$zK7.50@newssvr25.news.prodigy.com>,
Martin Euredjian <0_0_0_0_@pacbell.net> wrote:
>I just got done reading a through a couple of recent threads on the subject
>of "the best machine" to build for Xilinx tools.  Last week I had a
>conversation the head a a design group who said that "getting hyperthreading
>systems for my engineers made a huge difference in performance".
>
>I'm looking to replace a 1.8GHz P4 with the latest and greatest and I find
>myself confused between hyperthreading and dual processor boxes as two
>distinct options at (maybe) different ends of the scale.  Also, Xeon vs. P4?

SMT (Hyperthreading) and SMP (Symmetric multiprocessing) are
orthoginal and complementary.

Get either just SMT (single processor) or SMP+SMT (Dual processor
using P4-HT or Xeons).

Xeons have much better cache, but are otherwise effectively identical
in function.  Some of the Xeon chipsets are better (eg, better ECC
support etc).

GET ECC MEMORY/ECC SUPPORTING MOTHERBOARD.

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 64259
Subject: Re: Spartan II Block Ram
From: "John Retta" <jretta@rtc-inc.com>
Date: Mon, 22 Dec 2003 23:09:52 GMT
Links: << >>  << T >>  << A >>
You need the -d option in map .... then take a look at
section 12 of the map .rpt.

So if you did the addition on the number of block rams,
and it totaled 4, and that what was in the map file, then
you have dual ports elsewhere implemented with LUTs.




-- 
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

email : jretta@rtc-inc.com
web :  www.rtc-inc.com


"Chuck Gales" <cgales@_NOSPAM_nc.rr.com> wrote in message
news:pan.2003.12.22.22.41.18.876240@_NOSPAM_nc.rr.com...
> On Mon, 22 Dec 2003 19:34:28 +0000, John Retta wrote:
>
> > Kind of a puzzle since you say that the .mrp report states there are
> > exactly the number of block rams that you expect, yet the warning claims
> > there are additional RAM cells implemented in distributed LUTs.
> >
> > Is it clear that the LUT RAMs are the intended block RAMs, or that they
> > are an entirely new block of logic altogether?
> >
> > Other poster has good point about using coregen.
> >
> > I personally avoid coregen.  Not much more effort to instantiate
blockrams
> > directly (see lib.pdf), and you get exactly what you want.
> >
> > Take another look at bottom of .mrp file.  There is also a section which
> > describes the initialization values used for the block rams. It sounds
> > like you are intializing the block rams, so the values you expect to use
> > should show up down here.
> I looked at the .mrp and see no initialization of RAM.  Here is the
> complete .mrp file.  I see nothing which would indicate a problem.
>
> Release 6.1.03i Map G.26
> Xilinx Mapping Report File for Design 'spartanii_z80'
>
> Design Information
> ------------------
> Command Line   : C:/Xilinx/bin/nt/map.exe -intstyle ise -p
xc2s200-fg456-5 -cm
> area -pr b -k 4 -c 100 -tx off -o spartanii_z80_map.ncd spartanii_z80.ngd
> spartanii_z80.pcf
> Target Device  : x2s200
> Target Package : fg456
> Target Speed   : -5
> Mapper Version : spartan2 -- $Revision: 1.16 $
> Mapped Date    : Sun Dec 21 16:38:57 2003
>
> Design Summary
> --------------
> Number of errors:      0
> Number of warnings:    3
> Logic Utilization:
>   Number of Slice Flip Flops:       441 out of  4,704    9%
>   Number of 4 input LUTs:         2,670 out of  4,704   56%
> Logic Distribution:
>     Number of occupied Slices:                       1,528 out of  2,352
64%
>     Number of Slices containing only related logic:  1,528 out of  1,528
100%
>     Number of Slices containing unrelated logic:         0 out of  1,528
0%
>         *See NOTES below for an explanation of the effects of unrelated
logic
> Total Number 4 input LUTs:        2,797 out of  4,704   59%
>       Number used as logic:                     2,670
>       Number used as a route-thru:                 63
>       Number used for Dual Port RAMs:              64
>       (Two LUTs used per Dual Port RAM)
>    Number of bonded IOBs:            18 out of    284    6%
>    Number of Tbufs:                   8 out of  2,464    1%
>    Number of Block RAMs:              4 out of     14   28%
>    Number of GCLKs:                   1 out of      4   25%
>    Number of GCLKIOBs:                1 out of      4   25%
>
> Total equivalent gate count for design:  91,669
> Additional JTAG gate count for IOBs:  912
> Peak Memory Usage:  78 MB
>
> NOTES:
>
>    Related logic is defined as being logic that shares connectivity -
>    e.g. two LUTs are "related" if they share common inputs.
>    When assembling slices, Map gives priority to combine logic that
>    is related.  Doing so results in the best timing performance.
>
>    Unrelated logic shares no connectivity.  Map will only begin
>    packing unrelated logic into a slice once 99% of the slices are
>    occupied through related logic packing.
>
>    Note that once logic distribution reaches the 99% level through
>    related logic packing, this does not mean the device is completely
>    utilized.  Unrelated logic packing will then begin, continuing until
>    all usable LUTs and FFs are occupied.  Depending on your timing
>    budget, increased levels of unrelated logic packing may adversely
>    affect the overall timing performance of your design.
>
>
> Table of Contents
> -----------------
> Section 1 - Errors
> Section 2 - Warnings
> Section 3 - Informational
> Section 4 - Removed Logic Summary
> Section 5 - Removed Logic
> Section 6 - IOB Properties
> Section 7 - RPMs
> Section 8 - Guide Report
> Section 9 - Area Group Summary
> Section 10 - Modular Design Summary
> Section 11 - Timing Report
> Section 12 - Configuration String Information
> Section 13 - Additional Device Resource Counts
>
> Section 1 - Errors
> ------------------
>
> Section 2 - Warnings
> --------------------
> WARNING:Pack:266 - The function generator z80_u0_mcode_ALU_Op<2>27 failed
to
>    merge with F5 multiplexer z80_u0_mcode_ALU_Op<2>219.  There is a
conflict for
>    the FXMUX.  The design will exhibit suboptimal timing.
> WARNING:Pack:249 - The following adjacent carry multiplexers occupy
different
>    slice components.  The resulting carry chain will have suboptimal
timing.
>    z80_u0_I149_inst_cy_67
>    z80_u0_I149_inst_cy_68
> WARNING:Pack:249 - The following adjacent carry multiplexers occupy
different
>    slice components.  The resulting carry chain will have suboptimal
timing.
>    z80_u0_I149_inst_cy_68
>    z80_u0_I149_inst_cy_69
>
> Section 3 - Informational
> -------------------------
> INFO:LIT:95 - All of the external outputs in this design are using slew
rate
>    limited output drivers. The delay on speed critical outputs can be
>    dramatically reduced by designating them as fast outputs in the
schematic.
> INFO:MapLib:562 - No environment variables are currently set.
>
> Section 4 - Removed Logic Summary
> ---------------------------------
>    2 block(s) optimized away
>
> Section 5 - Removed Logic
> -------------------------
>
> Optimized Block(s):
> TYPE BLOCK
> GND XST_GND
> VCC XST_VCC
>
> To enable printing of redundant blocks removed and signals merged, set the
> detailed map report option and rerun map.
>
> Section 6 - IOB Properties
> --------------------------
>
>
+---------------------------------------------------------------------------
---------------------------------------------+
> | IOB Name                           | Type    | Direction | IO Standard |
Drive    | Slew | Reg (s)  | Resistor | IOB   |
> |                                    |         |           |             |
Strength | Rate |          |          | Delay |
>
+---------------------------------------------------------------------------
---------------------------------------------+
> | CLK                                | GCLKIOB | INPUT     | LVTTL       |
|      |          |          |       |
> | DISP_1A                            | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | DISP_1B                            | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | DISP_1C                            | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | DISP_1D                            | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | DISP_1E                            | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | DISP_1F                            | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | DISP_1G                            | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | DISP_2A                            | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | DISP_2B                            | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | DISP_2C                            | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | DISP_2D                            | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | DISP_2E                            | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | DISP_2F                            | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | DISP_2G                            | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | LED                                | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
> | RESET_n                            | IOB     | INPUT     | LVTTL       |
|      |          |          |       |
> | RXD                                | IOB     | INPUT     | LVTTL       |
|      |          |          |       |
> | TXD                                | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
>
+---------------------------------------------------------------------------
---------------------------------------------+
>
> Section 7 - RPMs
> ----------------
>
> Section 8 - Guide Report
> ------------------------
> Guide not run on this design.
>
> Section 9 - Area Group Summary
> ------------------------------
> No area groups were found in this design.
>
> Section 10 - Modular Design Summary
> -----------------------------------
> Modular Design not used for this design.
>
> Section 11 - Timing Report
> --------------------------
> This design was not run using timing mode.
>
> Section 12 - Configuration String Details
> -----------------------------------------
> Use the "-detail" map option to print out Configuration Strings
>
> Section 13 - Additional Device Resource Counts
> ----------------------------------------------
> Number of JTAG Gates for IOBs = 19
> Number of Equivalent Gates for Design = 91,669
> Number of RPM Macros = 0
> Number of Hard Macros = 0
> PCI IOBs = 0
> PCI LOGICs = 0
> CAPTUREs = 0
> BSCANs = 0
> STARTUPs = 0
> DLLs = 0
> GCLKIOBs = 1
> GCLKs = 1
> Block RAMs = 4
> TBUFs = 8
> Total Registers (Flops & Latches in Slices & IOBs) not driven by LUTs =
144
> IOB Latches not driven by LUTs = 0
> IOB Latches = 0
> IOB Flip Flops not driven by LUTs = 0
> IOB Flip Flops = 0
> Unbonded IOBs = 0
> Bonded IOBs = 18
> Shift Registers = 0
> Static Shift Registers = 0
> Dynamic Shift Registers = 32
> 16x1 ROMs = 0
> 16x1 RAMs = 0
> 32x1 RAMs = 0
> Dual Port RAMs = 32
> MULTANDs = 1
> MUXF5s + MUXF6s = 457
> 4 input LUTs used as Route-Thrus = 63
> 4 input LUTs = 2670
> Slice Latches not driven by LUTs = 0
> Slice Latches = 0
> Slice Flip Flops not driven by LUTs = 144
> Slice Flip Flops = 441
> Slices = 1528
> Number of LUT signals with 4 loads = 50
> Number of LUT signals with 3 loads = 87
> Number of LUT signals with 2 loads = 307
> Number of LUT signals with 1 load = 1983
> NGM Average fanout of LUT = 2.19
> NGM Maximum fanout of LUT = 77
> NGM Average fanin for LUT = 3.5270
> Number of LUT symbols = 2670
> Number of IPAD symbols = 3
> Number of IBUF symbols = 2
>



Article: 64260
Subject: Re: Spartan3 availability
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Mon, 22 Dec 2003 15:11:56 -0800
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> The Altera parts still don't have a workable equivalent of the Xilinx SRL-16,
> which can be used to huge advantage in DSP applications...if you code to it.
> Otherwise, I'd agree.

What's the downside of using the stratix block memory shifters?

     -- Mike Treseler


Article: 64261
Subject: Re: Spartan II Block Ram
From: "Chuck Gales" <cgales@_NOSPAM_nc.rr.com>
Date: Tue, 23 Dec 2003 01:02:01 GMT
Links: << >>  << T >>  << A >>
On Mon, 22 Dec 2003 22:46:26 +0000, Chuck Gales wrote:

> On Mon, 22 Dec 2003 19:34:28 +0000, John Retta wrote:
> 
>> Kind of a puzzle since you say that the .mrp report states there are
>> exactly the number of block rams that you expect, yet the warning claims
>> there are additional RAM cells implemented in distributed LUTs.
>> 
>> Is it clear that the LUT RAMs are the intended block RAMs, or that they
>> are an entirely new block of logic altogether?
>> 
>> Other poster has good point about using coregen.
>> 
>> I personally avoid coregen.  Not much more effort to instantiate
>> blockrams directly (see lib.pdf), and you get exactly what you want.
>> 
>> Take another look at bottom of .mrp file.  There is also a section which
>> describes the initialization values used for the block rams. It sounds
>> like you are intializing the block rams, so the values you expect to use
>> should show up down here.
OK...I re-ran with the detailed map report.  As expected, the initial
values were all 0's:

Section 12 - Configuration String Details
-----------------------------------------
GCLK "CLK_BUFGP/BUFG": Configuration String is:
   "DISABLE_ATTR:LOW"

BLOCKRAM "ram0_sram_hi": Configuration String is:
   " CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA  PORTA_ATTR:1024X4
PORTB_ATTR:#OFF"
   INIT_0f = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0e = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0d = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0c = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0b = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0a = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_09 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_08 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_07 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_06 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_05 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_04 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_03 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_02 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_01 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_00 = 0000000000000000000000000000000000000000000000000000000000000000

BLOCKRAM "ram1_sram_low": Configuration String is:
   " CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA  PORTA_ATTR:1024X4
PORTB_ATTR:#OFF"
   INIT_0f = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0e = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0d = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0c = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0b = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0a = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_09 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_08 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_07 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_06 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_05 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_04 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_03 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_02 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_01 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_00 = 0000000000000000000000000000000000000000000000000000000000000000

BLOCKRAM "ram1_sram_hi": Configuration String is:
   " CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA  PORTA_ATTR:1024X4
PORTB_ATTR:#OFF"
   INIT_0f = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0e = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0d = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0c = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0b = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0a = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_09 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_08 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_07 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_06 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_05 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_04 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_03 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_02 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_01 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_00 = 0000000000000000000000000000000000000000000000000000000000000000

BLOCKRAM "ram0_sram_low": Configuration String is:
   " CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA  PORTA_ATTR:1024X4
PORTB_ATTR:#OFF"
   INIT_0f = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0e = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0d = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0c = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0b = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_0a = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_09 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_08 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_07 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_06 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_05 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_04 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_03 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_02 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_01 = 0000000000000000000000000000000000000000000000000000000000000000
   INIT_00 = 0000000000000000000000000000000000000000000000000000000000000000

This seems to show that indeed there were SRAMs implemented as Block Rams,
with all 0's as initial.

Any other ideas???

Chuck

Article: 64262
Subject: Re: Spartan II Block Ram
From: "John Retta" <jretta@rtc-inc.com>
Date: Tue, 23 Dec 2003 03:11:47 GMT
Links: << >>  << T >>  << A >>
Well ... it looks like the memory is there.   You might want to bring
some signals to test points to verify control operation .....

I guess the original thread was that the memory appeared not to
be present.  So add signals to track data flow/control signal
generation to determine problem.

Simulation is terrific.  But is not the end-all.  There might be
constraint problems/synchronization between time domains
problems, etc .. etc ....   Judicious use of tracking testpoints
to track correct operation, until error tracked is best step.

Good luck.

-- 
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

email : jretta@rtc-inc.com
web :  www.rtc-inc.com


"Chuck Gales" <cgales@_NOSPAM_nc.rr.com> wrote in message
news:pan.2003.12.23.00.56.56.474091@_NOSPAM_nc.rr.com...
> On Mon, 22 Dec 2003 22:46:26 +0000, Chuck Gales wrote:
>
> > On Mon, 22 Dec 2003 19:34:28 +0000, John Retta wrote:
> >
> >> Kind of a puzzle since you say that the .mrp report states there are
> >> exactly the number of block rams that you expect, yet the warning
claims
> >> there are additional RAM cells implemented in distributed LUTs.
> >>
> >> Is it clear that the LUT RAMs are the intended block RAMs, or that they
> >> are an entirely new block of logic altogether?
> >>
> >> Other poster has good point about using coregen.
> >>
> >> I personally avoid coregen.  Not much more effort to instantiate
> >> blockrams directly (see lib.pdf), and you get exactly what you want.
> >>
> >> Take another look at bottom of .mrp file.  There is also a section
which
> >> describes the initialization values used for the block rams. It sounds
> >> like you are intializing the block rams, so the values you expect to
use
> >> should show up down here.
> OK...I re-ran with the detailed map report.  As expected, the initial
> values were all 0's:
>
> Section 12 - Configuration String Details
> -----------------------------------------
> GCLK "CLK_BUFGP/BUFG": Configuration String is:
>    "DISABLE_ATTR:LOW"
>
> BLOCKRAM "ram0_sram_hi": Configuration String is:
>    " CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA  PORTA_ATTR:1024X4
> PORTB_ATTR:#OFF"
>    INIT_0f =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0e =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0d =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0c =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0b =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0a =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_09 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_08 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_07 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_06 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_05 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_04 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_03 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_02 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_01 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_00 =
0000000000000000000000000000000000000000000000000000000000000000
>
> BLOCKRAM "ram1_sram_low": Configuration String is:
>    " CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA  PORTA_ATTR:1024X4
> PORTB_ATTR:#OFF"
>    INIT_0f =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0e =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0d =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0c =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0b =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0a =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_09 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_08 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_07 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_06 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_05 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_04 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_03 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_02 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_01 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_00 =
0000000000000000000000000000000000000000000000000000000000000000
>
> BLOCKRAM "ram1_sram_hi": Configuration String is:
>    " CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA  PORTA_ATTR:1024X4
> PORTB_ATTR:#OFF"
>    INIT_0f =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0e =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0d =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0c =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0b =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0a =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_09 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_08 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_07 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_06 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_05 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_04 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_03 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_02 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_01 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_00 =
0000000000000000000000000000000000000000000000000000000000000000
>
> BLOCKRAM "ram0_sram_low": Configuration String is:
>    " CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA  PORTA_ATTR:1024X4
> PORTB_ATTR:#OFF"
>    INIT_0f =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0e =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0d =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0c =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0b =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_0a =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_09 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_08 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_07 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_06 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_05 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_04 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_03 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_02 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_01 =
0000000000000000000000000000000000000000000000000000000000000000
>    INIT_00 =
0000000000000000000000000000000000000000000000000000000000000000
>
> This seems to show that indeed there were SRAMs implemented as Block Rams,
> with all 0's as initial.
>
> Any other ideas???
>
> Chuck



Article: 64263
Subject: Avnet Virtex II Pro Dvpt board : linux drivers ??
From: Mancini Stephane <nospam@nospam.nospam>
Date: Tue, 23 Dec 2003 10:18:55 +0100
Links: << >>  << T >>  << A >>
Hi,
Please could you tell me if there's a linux driver of the Virtex II Pro
development board from Avnet (Silica) ?
I would like to know if there's an equivalent to the PCIUtility for Linux.
Indeed, I would like to have my workstation with linux and work with the
board directly through the pci bus.
What could I do ?
Thanks for your help
Stephane


Article: 64264
Subject: Net name convention for Xilinx UCF files.
From: "One Day & A Knight" <kelvin8157@hotmail.com>
Date: Tue, 23 Dec 2003 18:19:24 +0800
Links: << >>  << T >>  << A >>
Hi, all:

I am writing some UCF files for synthesis. In XST I set the hierarchy
seperator to / and bus symbol to []...

Now after I write the UCF files and build, the ISE6.1 complain can't find
the net-names.

How do I find the correct names of the various symbols in my Verilog codes?
Is it possible to write a "netlist" in the NGC files?


Best Regards,
Kelvin




In core.v
Module main;

testctl u_testctrl(
    ...
    .srck_i(p_srck_i),                     //testctrl  input

    .arstn_testrx_i(arstn_testrx),         //testctrl  input
    .clk36_pll_i(clk_36),                  //testctrl  input
);

...
endmodule

in core_ucf.ucf
NET "u_testctrl/clk36_pll_o" TNM_NET = "u_testctrl_clk36_pll_o";
TIMESPEC "TS_u_testctrl_clk36_pll_o" = PERIOD "u_testctrl_clk36_pll_o" 27.8
ns HIGH 50 %;


Error in core.bld
ERROR:NgdBuild:756 - Line 87 in core_ucf.ucf': Could not find net(s)
   'u_testctrl/clk36_pll_i' in the design.  To suppress this error specify
the
   correct net name or remove the constraint.




Article: 64265
Subject: pcix core in XC2VP7
From: Matthias =?iso-8859-1?Q?M=FCller?= <mur@iis.fhg.de>
Date: Tue, 23 Dec 2003 11:21:37 +0100
Links: << >>  << T >>  << A >>
Hello,
I'm developing a pcix-card and I will use the PCIX-core from Xilinx in a
XC2VP7-5FF896 FPGA. Does anyone know if there is the need for using
special pins of the FPGA to connecet  the PCIX-signals to the
bus-connector. Or can I use any FPGA-pin for any PCIX-signal?
Thank you for answers!
Matthias Müller

**************
Please remove the  *no*spam*  from my email-address, if you want to mail
to me!


Article: 64266
Subject: Re: pcix core in XC2VP7
From: Mark Schellhorn <mark@seawaynetworks.com>
Date: Tue, 23 Dec 2003 07:47:44 -0500
Links: << >>  << T >>  << A >>
Check out answer record #14965:

http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=14965

The databook I have (older) mentioned some banking restrictions but it looks 
like they have disappeared with newer software.

Make sure you obey the PCI-X trace length restrictions on the card. I would 
establish the orientation of your FPGA on the card and then choose a pinout that 
   lines up with the edge card pins. Worked for me.

    Mark


Matthias Müller wrote:
> Hello,
> I'm developing a pcix-card and I will use the PCIX-core from Xilinx in a
> XC2VP7-5FF896 FPGA. Does anyone know if there is the need for using
> special pins of the FPGA to connecet  the PCIX-signals to the
> bus-connector. Or can I use any FPGA-pin for any PCIX-signal?
> Thank you for answers!
> Matthias Müller
> 
> **************
> Please remove the  *no*spam*  from my email-address, if you want to mail
> to me!
> 


Article: 64267
Subject: Re: Hyperthreading vs. Dual proc
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Tue, 23 Dec 2003 15:19:03 GMT
Links: << >>  << T >>  << A >>
Apparently there's something called "Pentium4 Extreme"?
Are marketing guys making it confusing on purpose?

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
news:bs7t7a$2n2s$1@agate.berkeley.edu...
> In article <gFzFb.1536$zK7.50@newssvr25.news.prodigy.com>,
> Martin Euredjian <0_0_0_0_@pacbell.net> wrote:
> >I just got done reading a through a couple of recent threads on the
subject
> >of "the best machine" to build for Xilinx tools.  Last week I had a
> >conversation the head a a design group who said that "getting
hyperthreading
> >systems for my engineers made a huge difference in performance".
> >
> >I'm looking to replace a 1.8GHz P4 with the latest and greatest and I
find
> >myself confused between hyperthreading and dual processor boxes as two
> >distinct options at (maybe) different ends of the scale.  Also, Xeon vs.
P4?
>
> SMT (Hyperthreading) and SMP (Symmetric multiprocessing) are
> orthoginal and complementary.
>
> Get either just SMT (single processor) or SMP+SMT (Dual processor
> using P4-HT or Xeons).
>
> Xeons have much better cache, but are otherwise effectively identical
> in function.  Some of the Xeon chipsets are better (eg, better ECC
> support etc).
>
> GET ECC MEMORY/ECC SUPPORTING MOTHERBOARD.
>
> -- 
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu



Article: 64268
Subject: Re: Net name convention for Xilinx UCF files.
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Tue, 23 Dec 2003 15:23:24 GMT
Links: << >>  << T >>  << A >>
> How do I find the correct names of the various symbols in my Verilog
codes?
> Is it possible to write a "netlist" in the NGC files?

FPGA Editor helps.  You can also use the Constraints Editor.

Also try:   "*u_testctrl/clk36_pll_o"
instead of: "u_testctrl/clk36_pll_o"

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"





Article: 64269
Subject: Re: Hyperthreading vs. Dual proc
From: "tbx135" <tbx135@msn.com>
Date: Tue, 23 Dec 2003 15:37:15 GMT
Links: << >>  << T >>  << A >>
> I'm looking to replace a 1.8GHz P4 with the latest and greatest and I find
> myself confused between hyperthreading and dual processor boxes as two
> distinct options at (maybe) different ends of the scale.  Also, Xeon vs.
P4?

I don't believe Xilinx is utilizing this feature (Hyperthreading-HT)
availible in the later P4 chips. It is not an intrinsic feature that
software would utilize (ie such as a faster processor speed). SW would have
to be designed to take advantage of this. Currently XP Professional utilizes
the HT for some operating system functions (ie print) but can not
specifically in the application.

There are issues with cache utilization in hyperthreading where performance
could actually be degraded as well as potential bottlenecking the FSB with
concurrent processes - scheduling would again burden the application.

I would personally like to see HT utilized for MTI simulation.



Article: 64270
Subject: Re: pcix core in XC2VP7
From: muthu_nano@yahoo.co.in (Muthu)
Date: 23 Dec 2003 07:43:51 -0800
Links: << >>  << T >>  << A >>
Matthias Müller <mur@iis.fhg.de> wrote in message news:<3FE81731.2EDF3DE9@iis.fhg.de>...
> Hello,
> I'm developing a pcix-card and I will use the PCIX-core from Xilinx in a
> XC2VP7-5FF896 FPGA. Does anyone know if there is the need for using
> special pins of the FPGA to connecet  the PCIX-signals to the
> bus-connector. Or can I use any FPGA-pin for any PCIX-signal?
> Thank you for answers!
> Matthias Müller
> 
> **************
> Please remove the  *no*spam*  from my email-address, if you want to mail
> to me!

Hi,

You should use the PCIX IOs listed in Datasheet.

These IOs meet the PCIX specification standards.

Regards,
Muthu

Article: 64271
Subject: Re: Net name convention for Xilinx UCF files.
From: muthu_nano@yahoo.co.in (Muthu)
Date: 23 Dec 2003 07:51:33 -0800
Links: << >>  << T >>  << A >>
"One Day & A Knight" <kelvin8157@hotmail.com> wrote in message news:<3fe7b5c1$1@news.starhub.net.sg>...
> Hi, all:
> 
> I am writing some UCF files for synthesis. In XST I set the hierarchy
> seperator to / and bus symbol to []...
> 
> Now after I write the UCF files and build, the ISE6.1 complain can't find
> the net-names.
> 
> How do I find the correct names of the various symbols in my Verilog codes?
> Is it possible to write a "netlist" in the NGC files?
> 
> 
> Best Regards,
> Kelvin
> 
> 
> 
> 
> In core.v
> Module main;
> 
> testctl u_testctrl(
>     ...
>     .srck_i(p_srck_i),                     //testctrl  input
> 
>     .arstn_testrx_i(arstn_testrx),         //testctrl  input
>     .clk36_pll_i(clk_36),                  //testctrl  input
> );
> 
> ...
> endmodule
> 
> in core_ucf.ucf
> NET "u_testctrl/clk36_pll_o" TNM_NET = "u_testctrl_clk36_pll_o";
> TIMESPEC "TS_u_testctrl_clk36_pll_o" = PERIOD "u_testctrl_clk36_pll_o" 27.8
> ns HIGH 50 %;
> 
> 
> Error in core.bld
> ERROR:NgdBuild:756 - Line 87 in core_ucf.ucf': Could not find net(s)
>    'u_testctrl/clk36_pll_i' in the design.  To suppress this error specify
> the
>    correct net name or remove the constraint.

Hi,

Your .ucf having "pll_o" and ERROR shows "pll_i". I think you have
copied wrong lines. thats ok.

XST tools will not change the instance names during synthesis. so,
whatever you type in RTL should be valid in PAR too.

I am doubting, the hiearchy seperator only. Because, XST by default
takes "." as hiearchy seperator. Pls check that again, whether you
have forced correctly to "/"

and you can generate netlist after Translation phase.

it is "ngd2ver" application from Xilinx tools.

Get back for any clarification.

Regards,
Muthu

Article: 64272
Subject: Problems with Xilinx ISE6.1i P&Rs for Virtex II
From: swarnakumar_ba@yahoo.com (Swarna B)
Date: 23 Dec 2003 08:13:35 -0800
Links: << >>  << T >>  << A >>
Hi everybody,

I am having a problem with one of my designs on Virtex II.
I have been trying to get this working for quite some time now ( I
have generated around 50 BIT files by now) and have not yet got it :(
I have noticed that the BIT files I generate do not behave
consistently (most of the times it's working erroneously). i.e if I
make some small modification and regenerate the BIT file it goes
haywire. I am just sending out a constant data through a mux and some
registers. The data gets corrupted. This I observed by connecting the
outputs to a logic analyzer. I also am using ChipScope and I can see
that the data gets corrupted even as seen in ChipScope.
Currently I am suspecting things like -
- The DCM I have used to multiply an input clock by 2X. (I use the
multiplied clock all over the design.)
- My timing constraints, because, some of the corruptions I observed
hint at clock skew > Data delay.
- A high fanin MUX in the data path.

But ISE is not giving me any errors/warnings in this regards. It says
all constraints met as seen in the TWR file.

Is this a known issues of somekind! I can post more details(what?) if
somebody can analyze the specific nature of the problem.

Any information regarding this would be greatly helpful!

I looked through some of the older posts in this groups which talked
about clock jitter. One thing I have to do is - I have to look at my
input clock jitter spec. I definitely need more info :)

Thanks and Regards,
Swarna

Article: 64273
Subject: Re: Spartan3 availability
From: already5chosen@yahoo.com (Michael S)
Date: 23 Dec 2003 09:19:15 -0800
Links: << >>  << T >>  << A >>
Mike Treseler <mike.treseler@flukenetworks.com> wrote in message news:<3FE77A3C.9020805@flukenetworks.com>...
> Ray Andraka wrote:
> > The Altera parts still don't have a workable equivalent of the Xilinx SRL-16,
> > which can be used to huge advantage in DSP applications...if you code to it.
> > Otherwise, I'd agree.
> 
> What's the downside of using the stratix block memory shifters?
> 
>      -- Mike Treseler

May be, the fact that $tratix M512 blocks unavailable in the Cheaplon?

Article: 64274
Subject: Xilinx Johnson counter Verilog example bug?
From: Chris Carlen <crcarle@BOGUS.sandia.gov>
Date: Tue, 23 Dec 2003 10:25:05 -0800
Links: << >>  << T >>  << A >>
Greetings:

I have set out to learn Verilog, and thus to learn to use the ModelSim 
XE II v5.7c Starter simulation program that comes with Xilink WebPack 
5.2i.  Yesterday I got the software all installed and ready for today's 
first venture into my shiny new textbook "A Verilog HDL Primer" by J 
Bhasker.

I began by making sure I knew how to use the software by compiling and 
simulating the example jc2_top.v together with jc2_test.tf (the test 
bench) from the WebPack .../ISEexamples/jc2_ver directory.

The readme for the verilog source says that it should implement a 
Johnson counter with the pattern (depending on the count direction 
selected):

left	right
0000	0000
0001	1000
0011	1100
0111	1110
1111	1111
1110	0111
1100	0011
1000	0001
0000	0000	(repeats)


But in fact the counter produces the following result in the simulator 
(initial state not shown, only repeated pattern):

left	right
0001	1000
0011	1100
0111	1110
1110	0111
1100	0011
1000	0001
0001	1000	(repeats)

The Verilog they provided is (just counter section within an always @ 
(posedge clk) begin procedural construct):

//Counter section:
    if(run) begin
       if(dir) begin
          q[3:1] = q[2:0];	//Shift lower bits (Left Shift)
          q[0] = !q[3];		//Circulate inverted MSB to LSB
       end
       else begin
          q[2:0] = q[3:1];	//Shift upper bits (Right Shift)
          q[3] = !q[0];		//Circulate inverted LSB to MSB
       end
    end


Before knowing anything at all about Verilog, I proceded to tinker with 
this code.  I suspected that this represents stated logic, and so all 
statements are executed in parallel at each clock edge (which turns out 
not to be the right assumption, which I learned after reading a bit from 
my Verilog text).

So I modified the code to be this way to test this hypothesis:

//Counter section:
    if(run) begin
       if(dir) begin
          q[0] = !q[3];		//Circulate inverted MSB to LSB
          q[3:1] = q[2:0];	//Shift lower bits (Left Shift)
       end
       else begin
          q[3] = !q[0];		//Circulate inverted LSB to MSB
          q[2:0] = q[3:1];	//Shift upper bits (Right Shift)
       end
    end

Which of course produced the following pattern:

left	right
0011	1100
0111	1110
1111	1111
1100	0011
1000	0001
0000	0000
0011	1100	(repeats)

This led me to suspect that the code is actually executed sequentially 
not in parallel.  Looking at my new Verilog text confirmed this to be 
the case.

The questions are thus:

1. Why did Xilinx incorrectly implement what was described in the README?

2.  Has anyone encountered this screwed up example before?

3.  What is the correct implentation?

Oh no, that's too easy.  I'm supposed to be learning this language, so 
I'll take a crack at it.

After several frustrating attempts to fix the counter code, I realized 
that there was no conceivable logic with which to determine the value of 
the q[0] bit *after* copying the q[2:0] bits over the q[3:1] bits, 
because I need to work with the original q[3] bit (left counting case).

One way would be to put in another register bit, but this would be a 
kuldgy waste of ffs.  At the brink of demoralization (and recognizing 
that the brick wall was self-imposed by my not knowing how to do 
anything besides the behavioral style of coding, which forces the 
sequential execution which I don't want, I finally happened upon the 
answer to my hopes: a way to assign the bits of the result based on the 
bits of the previous state, all in parallel.  That is the concatenation 
operation, leading to:

//Counter section:
    if(run) begin
       if(dir) begin
          q[3:0] = {q[2], q[1], q[0], ~q[3]};
       end
       else begin
          q[3:0] = {~q[0], q[3], q[2], q[1]};
       end
    end

Whew, it works!

What a way to learn a language.  This was my first day of Verilog.  I 
planned to start by typing in an example from my textbook, but instead I 
just couldn't resist trying to fix the Xilinx example.  Now off to 
typing in my first Verilog code from scratch to finish.

Good day!



-- 
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov




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