Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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
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: 64252Kind 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? > > ChuckArticle: 64253
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
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
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
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: 64257Did 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
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.eduArticle: 64259
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
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: 64261On 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??? ChuckArticle: 64262
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??? > > ChuckArticle: 64263
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 StephaneArticle: 64264
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: 64265Hello, 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
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: 64267Apparently 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.eduArticle: 64268
> 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
> 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
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, MuthuArticle: 64271
"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, MuthuArticle: 64272
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, SwarnaArticle: 64273
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
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:
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