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 119575

Article: 119575
Subject: Re: LVCMOSS33 I/O sink current
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 23 May 2007 16:06:20 +1200
Links: << >>  << T >>  << A >>

Test01 wrote:
> I am using spartan3 fpga with lvcmos33 output pin set to 16 mA drive strength and fast slew rate. I am assuming that 16 mA is the source current at 3.3V as my VCCO voltage is 3.3V. I would like to know what is the sink current capability for LVCMOS33 OUTPUT pin is. Or is there any way I can increase the sink current capability?
> 
> I am using this output pin as open drain type with 150 Ohm pulllup to 1.8V Plane. 

With this I am seeing low swing of 400mV.

If the sink current was truely 16 mA, then the low swing should have 
been 0v.

I raised the pullup value to 330 Ohms and the low swing was 200mV.
> 
> In my opinion the 16 mA is source current capability. I need to make the output go down to 0v.
> 
> Any help will be great.

CMOS drive, Sink current is not a pure current source, it is spec'd at 
some Vol level, and for a given PinDrive selection it will sink MORE 
than that level.
Real CMOS drivers are MOSFETS that look resistors, in the sub-volt 
saturation region. In your example, the 400mV is the expected drop 
across that resistor, and that is why it drops to 200mV when you halve 
the load current, by 150 => 330 Ohms.
What is this driving ? - 400mV maybe fine as a Vol, or you could go to a 
higher Drive option and lower that 400mV.

-jg


Article: 119576
Subject: Design running on board but timing are not met
From: "J.Ram" <jrgodara@gmail.com>
Date: 22 May 2007 22:05:57 -0700
Links: << >>  << T >>  << A >>
Hi All,
I have developed a design which obtained max freq. 56Mhz. So i applied
global clock constraint
to implement design and timimg is met.
This design has sub-modules which are running above 100Mhz.
my requirement is run this design at 90Mhz.
when i applied global clock constraint for 90Mhz, then timing is not
met.
Finally i downloaded this design on board and see that design is
working at 90Mhz.
My question why tool is not meeting timing but design is working at
board.
I am not included false and multi-cycle path in design constraint
file .


Article: 119577
Subject: M-RAM allocation in Stratix EPS125B672C6
From: nandits11@gmail.com
Date: 22 May 2007 22:07:00 -0700
Links: << >>  << T >>  << A >>
Hi ,

I am using Altera Quartus II version 4.0 . The EPS125 device has
 138  M4K blocks
224  M512 blocks
 2 number of  512K Mram blocks

has a total of 1,944,576 bits.

(http://www.altera.com/products/devices/stratix/features/stx-
trimatrix.html )

the problem i am facing is i am trying to fit in 4  buffer data blocks
each of size 16384*14 bits
(total 229376*4 =917504)
plus i have additional fifo and single port Ram of sizes 8192 , and
1500 bits

The problem is though there is adequate RAM available , I am not able
to fit in all the memory; only 48% of the RAM is used.

The fitter resourse summary says more M-Ram  blocks are required but
most of M4K and M512 blokcs are not used. ie 40/224 M512 blocks are
used, 2/138 M4K blocks and 2-MRam blocks...


I am fairly new to FPGAs and stuff so i would appreciate all help.

thanks  and regards.


Article: 119578
Subject: Re: Design running on board but timing are not met
From: Peter Alfke <alfke@sbcglobal.net>
Date: 22 May 2007 22:40:52 -0700
Links: << >>  << T >>  << A >>
You asked the same question 2 days ago, and you got 9 replies.
Why do you start again?
Peter Alfke

On May 22, 10:05 pm, "J.Ram" <jrgod...@gmail.com> wrote:
> Hi All,
> I have developed a design which obtained max freq. 56Mhz. So i applied
> global clock constraint
> to implement design and timimg is met.
> This design has sub-modules which are running above 100Mhz.
> my requirement is run this design at 90Mhz.
> when i applied global clock constraint for 90Mhz, then timing is not
> met.
> Finally i downloaded this design on board and see that design is
> working at 90Mhz.
> My question why tool is not meeting timing but design is working at
> board.
> I am not included false and multi-cycle path in design constraint
> file .



Article: 119579
Subject: Re: Config PROM for Spartan II
From: Antti <Antti.Lukats@googlemail.com>
Date: 23 May 2007 00:12:46 -0700
Links: << >>  << T >>  << A >>
On 6 Apr., 21:04, Markus Knauss <markus.kna...@gmx.net> wrote:
> Jon Elson wrote:
>
> > Markus Knauss wrote:
>
> >> Hi all,
>
> >> at the moment, we are using AT17LV010 configuration devices for a
> >> spartan 2S100.
> >> I have to look for a different solution which is not so expensive.
>
> >> The Xilinx XC17V01 is OTP and more expensive than the AT17LV010.
>
> >> Does someone know a different prom (OTP, EEPROM, Flash)?
>
> > SST makes a series of VERY cheap serial flash memories.  I figured out
> > how to
> > create the command bit stream that it needs to command a read starting
> > from addr
> > zero function, using just 2 SSI CMOS chips in SSOP packages, so the
> > interface is
> > under $1, and the SST chip is well under $2 in small quantities.  I had
> > to make my
> > own programmer, and a little C program to read the .MCS file and program
> > the
> > device.  I haven't actually produced a product using this setup yet, but
> > I did build
> > a prototype board for Spartan 2E and verify that it could do the FPGA
> > configure.
> > I did this for the 2S50E part, but SST has up to 4 mbit chips, I think,
> > that should
> > handle the 2S100.
>
> > Jon
>
> Thank you Jon for the hint. It should be possible to get a preprogrammed
>   8 bit controller (PIC, AVR) for 1$ and with a little bit banging in
> software you could use the original .mcs file.
>
> Markus- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

you can get dev-kit for such microcontroller for 5 USD ;)
http://www.dev-kit.org

and yes there are plenty of sub 1USD microcontroller that can use
as SPI to xilinx master serial adapter

mcu holds FPGA in de-config (prog_b low), and clocks in the
read instruction into SPI flash, then FPGA released and it
will configure at programmed into bitstream clock rate from the SPI
flash

Antti



Article: 119580
Subject: Re: JTAG FPGA Debugging
From: Antti <Antti.Lukats@googlemail.com>
Date: 23 May 2007 01:09:08 -0700
Links: << >>  << T >>  << A >>
On 22 Mai, 22:03, Matthew Hicks <mdhic...@uiuc.edu> wrote:
> Yes, there is documentation on the Xilinx site about how to do it and also
> many previous posts on this very newsgroup about it.  Think BSCAN.
>
> ---Matthew Hicks

http://code.google.com/p/fpga-tools/downloads/list

and there is VHDL source code of the BSCAN primitive as well

Antti


Article: 119581
Subject: Re: how 33-bit BRAM?
From: MNiegl <Michael.Niegl@cern.ch>
Date: 23 May 2007 01:33:56 -0700
Links: << >>  << T >>  << A >>
or you just take any next sized primitive (or 2 in parallel) and pad
the rest with zeros.


Article: 119582
Subject: Re: DDR Controller Blue
From: francescopoderico@googlemail.com
Date: 23 May 2007 02:25:05 -0700
Links: << >>  << T >>  << A >>
On 22 May, 13:41, sudhakar...@gmail.com wrote:
> On May 22, 2:00 pm, francescopoder...@googlemail.com wrote:
>
>
>
> > On 22 May, 03:49, Digital Mike <michaelmk...@gmail.com> wrote:
>
> > > Dear all,
>
> > > I am working on a DDR controller that stores captured video frames
> > > from which a VGA controller retrieves data. It (DDR controller) works
> > > fine for the first few frames but seems dead afterward. I wonder if
> > > anyone experienced similar problem. What I did (for initial testing
> > > purpose) is to capture and store a frame into the DDR then retrieve
> > > the same frame (a 640x480 pixels area) over and over again.
>
> > > Comments?
>
> > > -M
>
> > Hi Mike,
> > I've got some experience with DDR2 controller.
> > If you send me your code I can have a look.
>
> > Francesco
>
> Hi
> Francesco
> I am currently working on DDR2 controller for BL 8.
> My own code is giving good results when i  verified with memory model
> from MICRON.
> Now my problem is memory on the board  is not sending 4 DQS   clock
> pulses. it seems to be sending for burst lenth 4.
>
> For ur IDEA  some results  i observed
>
> If i  won't   Initialize properly  it is not responding at all . no
> DQS nothing is comming .
> if i initialize it properly its giving DQS signal of two sine clock
> pulses.
> If i write with 101010101 .... of each location i am getting two sine
> clock pulses on DQ pin while reading .
> if i write with all ZERO's i am getting ZERO' on DQ pin.
>
> so i think inialization is happenig properly. some problem persistence
> still some where .
> If u have any IDEA please help me regarding  this.
> with regards......
> sudhakar

Hi sudhakar,
What kind of FPGA wre you using?
On the samsung website you can download some ddr2 memory model to
verify that the initialization is ok.
I don't have enought informations from you to help you.
Last time I used MIG 7.1 succesfully .
So if you are using a Xilinx FPGA I can reccomend you to use the MIG.

Francesco



Article: 119583
Subject: Re: JTAG FPGA Debugging
From: "Silver" <K.Pisaniec@gmail.com>
Date: Wed, 23 May 2007 11:32:59 +0200
Links: << >>  << T >>  << A >>
Thank you all very much, that's really helpful!

Chris 



Article: 119584
Subject: Re: Does FPGA need CPU for processing a packet/frame
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: 23 May 2007 02:58:16 -0700
Links: << >>  << T >>  << A >>
On 22 Mai, 18:21, NewToFPGA <het...@yahoo.com> wrote:
> Does Operating System need to provide an FPGA a device driver?

Let me ask back: Does a graphics card require a device driver?
No, it does not. It's the operating system that requires a
devices driver to provide abstracted graphics card features to other
programs.

It's the same for FPGAs. If you want to provide FPGA based services
to user space programs you need a device driver in most operating
systems.
In other operating systems you just read or write memory mapped
registers
directly from user space.
If the FPGA is operating stand alone or is only used in kernel space
there is no
device driver required.

Kolja Sulimma



Article: 119585
Subject: Re: Xilinx doesn't detect setup/hold violations on synchronous reset
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 23 May 2007 11:53:10 +0100
Links: << >>  << T >>  << A >>
"Frai" <maybetooparanoid@gmail.com> wrote in message 
news:1179853461.318175.38170@36g2000prm.googlegroups.com...
> I'm using a clock with 10 ns period. The delay of the path between
> "locked_a_reg" and the synchronous reset of some FFs happens to be
> very close to 10 ns. Therefore, the clock signal from the DCM
> "dsp_clk_a" arrives at the FF almost at the same time as the reset
> signal is released, throwing a SETUP violation in Modelsim. In the
> real world, the FFs would just recover from this, but Modelsim doesn't
> seem to handle this, and it stays with many unknown values at FFs that
> prevent me from simulating my design.
>
> I've done quite much research on this topic with no success. I would
> appreciate any information about why Xilinx doesn't detect such a
> violation.
>
Hi Frai,
So, here are some more questions. Apologies if they sound obvious, I'm 
unsure of your experience with the (often painful) world of FPGA design! :-)

1) Are you doing a timing simulation after place and route?
  I assume you are, otherwise you wouldn't have delays in your simulation!

2) Have you told the Xilinx software the period of the clock in your UCF 
file?
  The software can only detect timing errors if it knows the frequency of 
the clock.

3) Have you used the Xilinx timing analyser tool?
  As I said in my previous post, this will tell you what paths the P&R 
software is checking.

4) Also, is the clock buffered with a BUFG or somesuch onto a global clock 
net?
  If not, hang your head in shame! The skew on a clock routed in the general 
routing resource will make meeting timing a nightmare.

I'm surprised that the net has delays of 10ns. That's quite a long time in 
today's parts. (You can try duplicating the FF that generates the reset to 
reduce this delay, but that doesn't address your question as to why the 
tools don't report timing errors.)

HTH, Syms. 



Article: 119586
Subject: Re: SelectIO banking rules
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 23 May 2007 12:25:06 +0100
Links: << >>  << T >>  << A >>

"John_H" <newsgroup@johnhandwork.com> wrote in message 
news:gUB4i.4817$ns.251@trndny05...
> What a pretty list....
>
> What device is this for?
> I suggested going to the data sheet to see what inputs can be powered by 
> alternate VCCIOs.  I can't go to the data sheet for you without knowing 
> which device - at least which family - you're using.
>
A google of IO_L74P_4/GCLK2P site:xilinx.com would suggest
2vp7ff672 HTH, Syms.
>
> LilacSkin wrote:
>> That's my BANK 4:
>> IO_L67P_4       BIDIR      LVTTL
>> IO_L05_4/No_Pair INPUT      LVTTL
>> IO_L07P_4/VREF_4 OUTPUT   LVTTL
>> IO_L19P_4       OUTPUT   LVTTL



Article: 119587
Subject: Re: How to include pcores librarys from XilinxProcessorIPLib (EDK) into ISE project???
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Wed, 23 May 2007 13:01:13 +0100
Links: << >>  << T >>  << A >>
On Tue, 22 May 2007 19:07:41 +0200, "L. Schreiber" <l.s.rockfan@web.de>
wrote:

>Brian Drummond schrieb:
>> On Tue, 15 May 2007 19:00:05 +0200, "L. Schreiber" <l.s.rockfan@web.de>
>> wrote:
>> 

>
>okay, this doesn't seem to work for the repos modules inside the 
>EDK/hw/XilinxProcessorIPLib/pcores. The error occoures before implement 
>design state (translate) in synthesize stage (syntax checking).
>
>XST tells me ERROR: HDLParsers:3317 - file_name.vhd Line xx. Library 
>lib_name cannot be found. For example library proc_sys_reset_v1_00_a.
>
>I think answer record #14027 says, I should add every missing library 
>(from EDK-directory) manually into my ISE project. I 've already tried 
>this. It has worked quite good until I tried to add a source file from 
>another library, which had the same name as one module included before.
>
>I got stuck again.
>
>Any advice?

For me, XST simply black-boxed the EDK components below the top-level
"system.vhd" file and the PAR tools picked them up later. I don't recall
using "black-box" attributes; XST simply left them un-instantiated.

However I think what you are doing SHOULD work. Except...
it sounds like you have another problem : XST's handling of libraries
seems to be consistently broken (at least on 6.1 and 7.1; I haven't
tried newer versions). And this is completely independent of EDK; it
seems to do this with any libraries. 

Which ISE version are you using?

It is perfectly valid in VHDL to have the same entity name in several
different libraries, and select a particular one for instantiation in
any place with "library/use" clauses, and embedded configuration
statements "for ... use " etc.

But ISE simply instantiates the first component it finds with the right
name and ignores your explicit bindings (in my experience). Now I ought
to have  spent a day or so creating a test case, reproducing the error
with the test case, packaging the lot up and opening a Webcase with
Xilinx, but I was under time pressure and it was quicker for me to
simply rename one of the entities and carry on working.

My experience with Webcases is typically, several iterations with the
support staff, ending up with "Yes it's a bug". Sometimes with a
scheduled fix in the next major release. And a recommendation to use the
workaround I came up with in the first place.

- Brian




Article: 119588
Subject: Re: SelectIO banking rules
From: Gabor <gabor@alacron.com>
Date: 23 May 2007 05:32:08 -0700
Links: << >>  << T >>  << A >>
On May 23, 7:25 am, "Symon" <symon_bre...@hotmail.com> wrote:
> "John_H" <newsgr...@johnhandwork.com> wrote in message
>
> news:gUB4i.4817$ns.251@trndny05...> What a pretty list....
>
> > What device is this for?
> > I suggested going to the data sheet to see what inputs can be powered by
> > alternate VCCIOs.  I can't go to the data sheet for you without knowing
> > which device - at least which family - you're using.
>
> A google of IO_L74P_4/GCLK2P site:xilinx.com would suggest
> 2vp7ff672 HTH, Syms.
>
>
>
> > LilacSkin wrote:
> >> That's my BANK 4:
> >> IO_L67P_4       BIDIR      LVTTL
> >> IO_L05_4/No_Pair INPUT      LVTTL
> >> IO_L07P_4/VREF_4 OUTPUT   LVTTL
> >> IO_L19P_4       OUTPUT   LVTTL


A look at Table 8 in the Virtex II Pro datasheet (Supported
Single-ended I/O Standards) shows that LVCMOS25 requires
2.5V Vcco for input as well as output.  This is confirmed
in Table 12 (Summary of Voltage Supply Requirements
for All Input and Output Standards).  That being said,
it is possible to drive an LVTTL input from an LVCMOS25
source.  The important point is to check Voh (min) of the
driving part and make sure it exceeds Vih (min) for
the LVTTL input standard (2.0V per the datasheet).  The
other approach when using inputs that are not compatible
with the Vcco reference is to use a standard like SSTL
that uses the Vref to determine the logic threshold.
In your case, since the Vref pins are already assigned
to I/O, you don't have that option.

HTH,
Gabor


Article: 119589
Subject: Re: LVCMOSS33 I/O sink current
From: Test01 <cpandya@yahoo.com>
Date: Wed, 23 May 2007 05:52:35 -0700
Links: << >>  << T >>  << A >>
As per my understanding, you are suggesting an external transistor in parallel with the n-channel transistor to ground. The external transistor will turn on when the FPGA is driving low and will provide low resistance path to ground.

Also you are suggesitng to raise the sink current value to 24 mA. Currently I am using 16 mA driver. I am assuming that 24 mA sink current will some how lower the resistance of the n-channel mosfet in the FPGA when it is on and help reduce the voltage drop across it. It will be great if you can expand on this. I am assuming that this solution will not require any external transistor to ground.

Thanks for your feedback.

Article: 119590
Subject: How the synthesizer acutally works.
From: subint <subin.82@gmail.com>
Date: 23 May 2007 06:00:03 -0700
Links: << >>  << T >>  << A >>
Hi guys,
      To know how the synthesizer behave,i wrote logic to add 4
vectors in three different ways.And i got differnet result from the
synthesizer(used both ISE and synplify).
These are the three different approchs i made
1.***************************************************************************************************
module add(
			input clk,
			input [1:0] a,b,
			input d,
			input [63:0] c,
			output reg [64:0] out
			);

reg [1:0] in1,in2;
reg in4;
reg [63:0] in3;
wire [64:0] result;

always @ (posedge clk) begin
	{in1,in2,in3,in4}= {a,b,c,d};
	out= result;
end
	assign result= in1+in2+in3+in4;

endmodule
2.***************************************************************************************************
module add1(
			input clk,
			input [1:0] a,b,
			input d,
			input [63:0] c,
			output reg [64:0] out
			);

reg [1:0] in1,in2;
reg in4;
reg [63:0] in3;
wire [64:0] temp;
wire [64:0] temp2;
wire [64:0] result;

always @ (posedge clk) begin
	{in1,in2,in3,in4}= {a,b,c,d};
	out= result;
end

	assign temp= in1+in2;
	assign temp2= temp+in4;
	assign result= temp2+in3;

endmodule
3.***************************************************************************************************
module add2(
			input clk,
			input d,
			input [1:0] a,b,
			input [63:0] c,
			output reg [64:0] out
			);

reg [1:0] in1,in2;
reg in4;
reg [63:0] in3;
reg [64:0] result;

always @ (posedge clk) begin
	{in1,in2,in3,in4}= {a,b,c,d};
	out= result;
end
always @ (*) begin
case({in4,in1,in2})
5'b00000: result= in3+3'b000;
5'b00001: result= in3+3'b001;
5'b00010: result= in3+3'b010;
5'b00011: result= in3+3'b011;
5'b00100: result= in3+3'b001;
5'b00101: result= in3+3'b010;
5'b00110: result= in3+3'b011;
5'b00111: result= in3+3'b100;
5'b01000: result= in3+3'b010;
5'b01001: result= in3+3'b011;
5'b01010: result= in3+3'b100;
5'b01011: result= in3+3'b101;
5'b01100: result= in3+3'b011;
5'b01101: result= in3+3'b100;
5'b01110: result= in3+3'b101;
5'b01111: result= in3+3'b110;

5'b10000: result= in3+3'b001;
5'b10001: result= in3+3'b010;
5'b10010: result= in3+3'b011;
5'b10011: result= in3+3'b100;
5'b10100: result= in3+3'b010;
5'b10101: result= in3+3'b011;
5'b10110: result= in3+3'b100;
5'b10111: result= in3+3'b101;
5'b11000: result= in3+3'b011;
5'b11001: result= in3+3'b100;
5'b11010: result= in3+3'b101;
5'b11011: result= in3+3'b110;
5'b11100: result= in3+3'b100;
5'b11101: result= in3+3'b101;
5'b11110: result= in3+3'b110;
5'b11111: result= in3+3'b111;

endcase
end

endmodule

And the results for these from the ISE are
1.***************************************************************************************************
Selected Device : 4vlx15sf363-12

 Number of Slices:                     105  out of   6144     1%
 Number of Slice Flip Flops:           134  out of  12288     1%
 Number of 4 input LUTs:               128  out of  12288     1%
 Number of bonded IOBs:                135  out of    240    56%
 Number of GCLKs:                        1  out of     32     3%



   Minimum period: 5.212ns (Maximum Frequency: 191.872MHz)
   Minimum input arrival time before clock: 1.445ns
   Maximum output required time after clock: 3.921ns
   Maximum combinational path delay: No path found

2.***************************************************************************************************
Selected Device : 4vlx15sf363-12

 Number of Slices:                      76  out of   6144     1%
 Number of Slice Flip Flops:           134  out of  12288     1%
 Number of 4 input LUTs:                72  out of  12288     0%
 Number of bonded IOBs:                135  out of    240    56%
 Number of GCLKs:                        1  out of     32     3%


   Minimum period: 4.793ns (Maximum Frequency: 208.616MHz)
   Minimum input arrival time before clock: 1.445ns
   Maximum output required time after clock: 3.921ns
   Maximum combinational path delay: No path found
3.***************************************************************************************************
Selected Device : 4vlx15sf363-12

 Number of Slices:                     712  out of   6144    11%
 Number of Slice Flip Flops:           135  out of  12288     1%
 Number of 4 input LUTs:              1329  out of  12288    10%
 Number of bonded IOBs:                135  out of    240    56%
 Number of GCLKs:                        1  out of     32     3%


   Minimum period: 6.377ns (Maximum Frequency: 156.803MHz)
   Minimum input arrival time before clock: 1.459ns
   Maximum output required time after clock: 3.921ns
   Maximum combinational path delay: No path found

*****************************And the Result from the Synplify
are*****************************************************************
1.***************************************************************************************************
Mapping to part: xc4vlx15sf363-10
Cell usage:
FD              134 uses
GND             1 use
MUXCY           1 use
MUXCY_L         127 uses
XORCY           128 uses
LUT1            125 uses
LUT2            4 uses


Mapping Summary:
Total  LUTs: 129 (1%)


-----------------------------------------------------------------------------------------------------------------------
add|clk            1.0 MHz       143.8 MHz     1000.000
6.952         993.048     inferred     Inferred_clkgroup_0
=======================================================================================================================
2.***************************************************************************************************
Mapping to part: xc4vlx15sf363-10
Cell usage:
FD              134 uses
GND             1 use
MUXCY           1 use
MUXCY_L         127 uses
XORCY           128 uses
LUT1            125 uses
LUT2            4 uses


Mapping Summary:
Total  LUTs: 129 (1%)

Starting Clock     Frequency     Frequency     Period
Period        Slack       Type         Group
-----------------------------------------------------------------------------------------------------------------------
add1|clk           1.0 MHz       143.8 MHz     1000.000
6.952         993.048     inferred     Inferred_clkgroup_0
=======================================================================================================================
3.***************************************************************************************************
Mapping to part: xc4vlx15sf363-10
Cell usage:
FD              134 uses
GND             1 use
MULT_AND        2 uses
MUXCY           1 use
MUXCY_L         63 uses
VCC             1 use
XORCY           63 uses
LUT1            61 uses
LUT2            1 use
LUT3            3 uses
LUT4            2 uses


Global Clock Buffers: 1 of 32 (3%)

-----------------------------------------------------------------------------------------------------------------------
add2|clk           1.0 MHz       139.9 MHz     1000.000
7.146         992.854     inferred     Inferred_clkgroup_0


Can any one please help me why i am getting this much difference in
the result and what should be the real approch to write in HDL to get
most optimised result.
Thanks in advance


Article: 119591
Subject: Re: PLB behaviours strangely during burst transactions
From: Alan Nishioka <alan@nishioka.com>
Date: 23 May 2007 06:10:59 -0700
Links: << >>  << T >>  << A >>
On May 22, 2:23 pm, luciorech <lucior...@gmail.com> wrote:
> On 22 maio, 17:28, Alan Nishioka <a...@nishioka.com> wrote:
>
>
>
> > On May 22, 7:03 am, luciorech <lucior...@gmail.com> wrote:
>
> > > I'm using PLB to read and write 64bit data through burst transactions.
> > > I can read and write data correctly, but watching the signals through
> > > chipscope I can see a strange behavior: the PLB_MWrDAck and
> > > PLB_MRdDAck don't occur in consecutive clock cycles. For instance,
> > > during a 16 words burst read, instead of taking 16 clock cycles to
> > > read all data after the bus has been granted to my peripheral, it
> > > takes about 190 clock cycles. Did anyone have the same problem??
>
> > PLB burst can indeed read/write in consecutive clock cycles.
> > Perhaps your peripheral can't supply data fast enough?
> > Assuming Xilinx ppc, the cache only reads/write 4 cycles (8 words) at
> > a time.
>
> > Alan Nishioka
>
> Hi,
>
> I'm reading/writing directly from the DDR, so this can't be the
> problem. The peripheral is also using the highest priority and I
> double checked the signals, they are exactly how the IBM's Guide say.
>
> Lucio Rech


But you still have not supplied enough information.  What is on both
sides of the bus transfer?  Is one side your own custom peripheral?
Are you trying to use IPIF? What speed are you running the bus?  What
chip are you using? Where in the world is Carmen Sandiego?

Alan Nishioka


Article: 119592
Subject: Re: How the synthesizer acutally works.
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 23 May 2007 13:36:48 GMT
Links: << >>  << T >>  << A >>
Top posting to avoid the 4 pages of original post, included at the end...

The synthesizers appear generally not to be smart enough to group the 
additions by size first.  We can't ask them to do all the work but it 
would have been nice to get better results without the extra nudge.  The 
nudge?  In Synplify it's called a syn_keep and there's a similar 
attribute in XST (though I know not what it's called.

The specific knowledge of the hardware can be used to get the "best" 
results.  Since we know 4-input LUTs are available in the Virtex-4 
(larger in the Virtex-5) it would be "most" efficient to add in1 and in2 
with LUTs then add that result with in3 and have in4 be a carr-in to 
this last add.

While "temp" values are great for readability, there's no guaranteed 
behavior when those values are combinatorial with no directives 
attached; the synthesizer will look at the overall combinatorial "logic 
cone" feeding the output reg.

To get you "best" result, us a 3-bit temp variable

(* syn_keep=1 *) wire [2:0] temp = in1+in2;  // Verilog2k attribute syntax

and add this to th 64-bit vector with a carry-in

out <= in3 + temp + in4;

You are NOT guaranteed any build-up order by using the blocking operator 
(=) and should generally use the non-blocking operator for your register 
assignments.  There are rare circumstances when the blocking operator is 
useful, but they are rare.  The synthesizer will still look at the 
entire logic cone in an attempt to find a "best" solution.

Question: do you intend that a, b, c, and d actually be input registers? 
    The blocking operators would have completely ignored the input 
register aspect given the order you coded them if you used out = 
in1+in2+in3+in4; rather than out = result;.  As it is, I'm surprised 
both synthesizers gave you input registers.  It's for this reason you 
should NOT use the blocking operator!

So - let me know what you get with the syn_keep and the non-blocking 
operator.  Heck.... maybe the synthesizers will do a better job out of 
the gate without the extra blocking operator confusion.

But be sure to figure out what the equivalent XST attribute is for the 
syn_keep before relying on those results to match the "keep" intent.

- John_H



subint wrote:
> Hi guys,
>       To know how the synthesizer behave,i wrote logic to add 4
> vectors in three different ways.And i got differnet result from the
> synthesizer(used both ISE and synplify).
> These are the three different approchs i made
> 1.***************************************************************************************************
> module add(
> 			input clk,
> 			input [1:0] a,b,
> 			input d,
> 			input [63:0] c,
> 			output reg [64:0] out
> 			);
> 
> reg [1:0] in1,in2;
> reg in4;
> reg [63:0] in3;
> wire [64:0] result;
> 
> always @ (posedge clk) begin
> 	{in1,in2,in3,in4}= {a,b,c,d};
> 	out= result;
> end
> 	assign result= in1+in2+in3+in4;
> 
> endmodule
> 2.***************************************************************************************************
> module add1(
> 			input clk,
> 			input [1:0] a,b,
> 			input d,
> 			input [63:0] c,
> 			output reg [64:0] out
> 			);
> 
> reg [1:0] in1,in2;
> reg in4;
> reg [63:0] in3;
> wire [64:0] temp;
> wire [64:0] temp2;
> wire [64:0] result;
> 
> always @ (posedge clk) begin
> 	{in1,in2,in3,in4}= {a,b,c,d};
> 	out= result;
> end
> 
> 	assign temp= in1+in2;
> 	assign temp2= temp+in4;
> 	assign result= temp2+in3;
> 
> endmodule
> 3.***************************************************************************************************
> module add2(
> 			input clk,
> 			input d,
> 			input [1:0] a,b,
> 			input [63:0] c,
> 			output reg [64:0] out
> 			);
> 
> reg [1:0] in1,in2;
> reg in4;
> reg [63:0] in3;
> reg [64:0] result;
> 
> always @ (posedge clk) begin
> 	{in1,in2,in3,in4}= {a,b,c,d};
> 	out= result;
> end
> always @ (*) begin
> case({in4,in1,in2})
> 5'b00000: result= in3+3'b000;
> 5'b00001: result= in3+3'b001;
> 5'b00010: result= in3+3'b010;
> 5'b00011: result= in3+3'b011;
> 5'b00100: result= in3+3'b001;
> 5'b00101: result= in3+3'b010;
> 5'b00110: result= in3+3'b011;
> 5'b00111: result= in3+3'b100;
> 5'b01000: result= in3+3'b010;
> 5'b01001: result= in3+3'b011;
> 5'b01010: result= in3+3'b100;
> 5'b01011: result= in3+3'b101;
> 5'b01100: result= in3+3'b011;
> 5'b01101: result= in3+3'b100;
> 5'b01110: result= in3+3'b101;
> 5'b01111: result= in3+3'b110;
> 
> 5'b10000: result= in3+3'b001;
> 5'b10001: result= in3+3'b010;
> 5'b10010: result= in3+3'b011;
> 5'b10011: result= in3+3'b100;
> 5'b10100: result= in3+3'b010;
> 5'b10101: result= in3+3'b011;
> 5'b10110: result= in3+3'b100;
> 5'b10111: result= in3+3'b101;
> 5'b11000: result= in3+3'b011;
> 5'b11001: result= in3+3'b100;
> 5'b11010: result= in3+3'b101;
> 5'b11011: result= in3+3'b110;
> 5'b11100: result= in3+3'b100;
> 5'b11101: result= in3+3'b101;
> 5'b11110: result= in3+3'b110;
> 5'b11111: result= in3+3'b111;
> 
> endcase
> end
> 
> endmodule
> 
> And the results for these from the ISE are
> 1.***************************************************************************************************
> Selected Device : 4vlx15sf363-12
> 
>  Number of Slices:                     105  out of   6144     1%
>  Number of Slice Flip Flops:           134  out of  12288     1%
>  Number of 4 input LUTs:               128  out of  12288     1%
>  Number of bonded IOBs:                135  out of    240    56%
>  Number of GCLKs:                        1  out of     32     3%
> 
> 
> 
>    Minimum period: 5.212ns (Maximum Frequency: 191.872MHz)
>    Minimum input arrival time before clock: 1.445ns
>    Maximum output required time after clock: 3.921ns
>    Maximum combinational path delay: No path found
> 
> 2.***************************************************************************************************
> Selected Device : 4vlx15sf363-12
> 
>  Number of Slices:                      76  out of   6144     1%
>  Number of Slice Flip Flops:           134  out of  12288     1%
>  Number of 4 input LUTs:                72  out of  12288     0%
>  Number of bonded IOBs:                135  out of    240    56%
>  Number of GCLKs:                        1  out of     32     3%
> 
> 
>    Minimum period: 4.793ns (Maximum Frequency: 208.616MHz)
>    Minimum input arrival time before clock: 1.445ns
>    Maximum output required time after clock: 3.921ns
>    Maximum combinational path delay: No path found
> 3.***************************************************************************************************
> Selected Device : 4vlx15sf363-12
> 
>  Number of Slices:                     712  out of   6144    11%
>  Number of Slice Flip Flops:           135  out of  12288     1%
>  Number of 4 input LUTs:              1329  out of  12288    10%
>  Number of bonded IOBs:                135  out of    240    56%
>  Number of GCLKs:                        1  out of     32     3%
> 
> 
>    Minimum period: 6.377ns (Maximum Frequency: 156.803MHz)
>    Minimum input arrival time before clock: 1.459ns
>    Maximum output required time after clock: 3.921ns
>    Maximum combinational path delay: No path found
> 
> *****************************And the Result from the Synplify
> are*****************************************************************
> 1.***************************************************************************************************
> Mapping to part: xc4vlx15sf363-10
> Cell usage:
> FD              134 uses
> GND             1 use
> MUXCY           1 use
> MUXCY_L         127 uses
> XORCY           128 uses
> LUT1            125 uses
> LUT2            4 uses
> 
> 
> Mapping Summary:
> Total  LUTs: 129 (1%)
> 
> 
> -----------------------------------------------------------------------------------------------------------------------
> add|clk            1.0 MHz       143.8 MHz     1000.000
> 6.952         993.048     inferred     Inferred_clkgroup_0
> =======================================================================================================================
> 2.***************************************************************************************************
> Mapping to part: xc4vlx15sf363-10
> Cell usage:
> FD              134 uses
> GND             1 use
> MUXCY           1 use
> MUXCY_L         127 uses
> XORCY           128 uses
> LUT1            125 uses
> LUT2            4 uses
> 
> 
> Mapping Summary:
> Total  LUTs: 129 (1%)
> 
> Starting Clock     Frequency     Frequency     Period
> Period        Slack       Type         Group
> -----------------------------------------------------------------------------------------------------------------------
> add1|clk           1.0 MHz       143.8 MHz     1000.000
> 6.952         993.048     inferred     Inferred_clkgroup_0
> =======================================================================================================================
> 3.***************************************************************************************************
> Mapping to part: xc4vlx15sf363-10
> Cell usage:
> FD              134 uses
> GND             1 use
> MULT_AND        2 uses
> MUXCY           1 use
> MUXCY_L         63 uses
> VCC             1 use
> XORCY           63 uses
> LUT1            61 uses
> LUT2            1 use
> LUT3            3 uses
> LUT4            2 uses
> 
> 
> Global Clock Buffers: 1 of 32 (3%)
> 
> -----------------------------------------------------------------------------------------------------------------------
> add2|clk           1.0 MHz       139.9 MHz     1000.000
> 7.146         992.854     inferred     Inferred_clkgroup_0
> 
> 
> Can any one please help me why i am getting this much difference in
> the result and what should be the real approch to write in HDL to get
> most optimised result.
> Thanks in advance

Article: 119593
Subject: Re: System-synchronous interface clocking between FPGA's
From: Gabor <gabor@alacron.com>
Date: 23 May 2007 06:44:50 -0700
Links: << >>  << T >>  << A >>
On May 22, 1:25 pm, "bwilso...@gmail.com" <bwilso...@gmail.com> wrote:
> This may seem like an elementary question/application, but I'll bring
> it up nonetheless in hopes of getting a thorough understanding...
>
> In our design, there are 80MHz system-synchronous interfaces between
> two FPGA's.  There is a common clock source on the board with matched
> trace lengths to each of the FPGA's.  The clocks then go into DCM's
> and the DCM 1x output clock is used to clock the IOB registers and
> also used as internal feedback to the DCM.  Can we [almost] guarantee
> that the clocks coming out of the DCM's on the separate FPGA's are
> near phase-aligned, assuming matched trace lengths coming in?  These
> are V4-LX160 parts.  I was looking over the V4 user guide and couldn't
> find a fitting clocking application example.  It seems it can never be
> fully guaranteed, since the DCM's deskew compensation on each of the
> FPGA's will certainly differ, not to mention small process
> variations.  Since we have a 12.5ns period, I think we should have
> room in our timing budget to absorb these small phase differences.  I
> will ensure that all the inputs and outputs utilize the IOB registers.
>
> If anyone could reassure me that this design is relatively common and
> safe, and provide me with some information regarding the DCM output
> clock relationships on the separate devices, I will feel much better.
> I've definitely worked with these types of designs in the past, but
> never fully understood why things just work.


At 80 MHz setup timing is really easy to meet with up-to-date FPGA's.
If there is any issue on this interface it will be hold-time related.
To meet hold time requirements, the receiving FPGA should use the
flip-flops in the IOB with the delay element enabled.  This is the
default for input flip-flops unless you specify NODELAY.  This
guarantees a 0 hold time vs. the external clock pin.  When using
the DCM as a clock source, your hold time will actually be negative.
This means that as long as the input changes after the clock
edge, or even at the clock edge, your input flip-flop will correctly
sample the input as the value from the previous edge.  Any additional
delay after the clock is "gravy".  Using a relatively slow I/O
standard like LVTTL will guarantee your hold time even with unmatched
clock traces and part-to-part DCM variations.  i.e. your minimum
clock to out delay on one part will be in the handful of nanoseconds
range and you input hold time requirement will be negative, so
you can live with a few nanosconds (that's a lot these days) of
skew.  As you describe your system I would guess the clock skew to
be well under 1 nS.

If you still don't believe this will work, add timing constraints
to your inputs and outputs and take a look at the datasheet report
at the end of your post P&R timing report.

I have made similar interfaces without using DCM or DLL.  Normally
using a global clock input pin ensures a minimum of delay from the
pin to the global clock net, and minimum delay also translates
into minumum part-to-part skew (part-to-part skew is a percentage
of total delay).  Since the incoming clocks are phase-aligned, and
assuming you have no other sources of data using these clocks than
the FPGA's, the internal delay is irrelevant as long as the two
FPGA's are relatively matched, or have long enough minimum clock
to output delays to deal with the part-to-part variance.

HTH,
Gabor


Article: 119594
Subject: Re: PLB behaviours strangely during burst transactions
From: luciorech <luciorech@gmail.com>
Date: 23 May 2007 06:52:15 -0700
Links: << >>  << T >>  << A >>
On May 23, 3:10 pm, Alan Nishioka <a...@nishioka.com> wrote:
> On May 22, 2:23 pm, luciorech <lucior...@gmail.com> wrote:
>
>
>
> > On 22 maio, 17:28, Alan Nishioka <a...@nishioka.com> wrote:
>
> > > On May 22, 7:03 am, luciorech <lucior...@gmail.com> wrote:
>
> > > > I'm using PLB to read and write 64bit data through burst transactions.
> > > > I can read and write data correctly, but watching the signals through
> > > > chipscope I can see a strange behavior: the PLB_MWrDAck and
> > > > PLB_MRdDAck don't occur in consecutive clock cycles. For instance,
> > > > during a 16 words burst read, instead of taking 16 clock cycles to
> > > > read all data after the bus has been granted to my peripheral, it
> > > > takes about 190 clock cycles. Did anyone have the same problem??
>
> > > PLB burst can indeed read/write in consecutive clock cycles.
> > > Perhaps your peripheral can't supply data fast enough?
> > > Assuming Xilinx ppc, the cache only reads/write 4 cycles (8 words) at
> > > a time.
>
> > > Alan Nishioka
>
> > Hi,
>
> > I'm reading/writing directly from the DDR, so this can't be the
> > problem. The peripheral is also using the highest priority and I
> > double checked the signals, they are exactly how the IBM's Guide say.
>
> > Lucio Rech
>
> But you still have not supplied enough information.  What is on both
> sides of the bus transfer?  Is one side your own custom peripheral?
> Are you trying to use IPIF? What speed are you running the bus?  What
> chip are you using? Where in the world is Carmen Sandiego?
>
> Alan Nishioka


Well, I don't think I can answer the last question, so let's move to
the others :) What I am trying to do is a 64bit burst transfer with
variable length between my peripheral and a DDRAM, both connected to
the PLB Bus (the memory uses the plb_ddr v2.00a). I'm stimulating the
bus myself, thus not using the IPIF. The bus runs at 100 MHz and I'm
using a Virtex2 Pro (XC2VP30).

Lucio Rech


Article: 119595
Subject: Re: LVCMOSS33 I/O sink current
From: Peter Alfke <alfke@sbcglobal.net>
Date: 23 May 2007 07:23:57 -0700
Links: << >>  << T >>  << A >>
On May 23, 5:52 am, Test01 <cpan...@yahoo.com> wrote:
> As per my understanding, you are suggesting an external transistor in parallel with the n-channel transistor to ground. The external transistor will turn on when the FPGA is driving low and will provide low resistance path to ground.
No, no, no. I am not suggesting an external transistor. I just wanted
to give you an understanding of the CMOS output structure. A very
basic understanding.
Peter Alfke
>
> Also you are suggesitng to raise the sink current value to 24 mA. Currently I am using 16 mA driver. I am assuming that 24 mA sink current will some how lower the resistance of the n-channel mosfet in the FPGA when it is on and help reduce the voltage drop across it. It will be great if you can expand on this. I am assuming that this solution will not require any external transistor to ground.
>
> Thanks for your feedback.



Article: 119596
Subject: Re: LVCMOSS33 I/O sink current
From: austin <austin@xilinx.com>
Date: Wed, 23 May 2007 07:41:48 -0700
Links: << >>  << T >>  << A >>
Test01,

The voltage can not be made to go to 0 volts.

That would be a 0 ohm impedance for the driver.

There is no such thing as a FET with 0 ohms ON resistance.

So, realizing this, what voltage do you actually need when driving low?

Austin

Article: 119597
Subject: DDR SDRAM in custom board
From: Pablo <pbantunez@gmail.com>
Date: 23 May 2007 08:21:52 -0700
Links: << >>  << T >>  << A >>
Hi everyone. I have a virtex II pro in a custom board (sundance board)
and a Micron MT46V16M16. I use edk to create a design with PowerPC and
the DDR. I select custom board and I finally get my design. The
problems is the following:

- sys_proc_reset only work with  "PORT Dcm_locked = dcm_0_lock" and
not with the default  "PORT Dcm_locked = dcm_2_lock". I suppose that
dcm_module blocks don't work fine.
- This could be related with the second problem: Net
fpga_0_GEN_DDR_CLK_FB LOC=; I have read the ucf file provide by the
company and I don't find any feedback for the ddr.

How could I resolve this?. How could I integrate DDR in my powerpc
design?. It is very important, because my program has to be loaded in
this sdram.

Thanks


Article: 119598
Subject: Xilinx ML405 / VxWorks 6.3 Bootloader
From: raven <rarockley@qinetiq.com>
Date: 23 May 2007 09:03:26 -0700
Links: << >>  << T >>  << A >>
Hi, Anyone had experience of creating a VxWorks Bootloader that will
run on a Xilinx ML40x Evaluation Platform? I have created a bootloader
and have loaded it into flash but it will not run from there. Any
ideas why? Thanks


Article: 119599
Subject: Re: How the synthesizer acutally works.
From: Newman <newman5382@yahoo.com>
Date: 23 May 2007 09:46:34 -0700
Links: << >>  << T >>  << A >>
On May 23, 9:00 am, subint <subin...@gmail.com> wrote:
> Hi guys,
>       To know how the synthesizer behave,i wrote logic to add 4
> vectors in three different ways.And i got differnet result from the
> synthesizer(used both ISE and synplify).
> These are the three different approchs i made
> 1.***********************************************************************=
**=AD**************************
> module add(
>                         input clk,
>                         input [1:0] a,b,
>                         input d,
>                         input [63:0] c,
>                         output reg [64:0] out
>                         );
>
> reg [1:0] in1,in2;
> reg in4;
> reg [63:0] in3;
> wire [64:0] result;
>
> always @ (posedge clk) begin
>         {in1,in2,in3,in4}=3D {a,b,c,d};
>         out=3D result;
> end
>         assign result=3D in1+in2+in3+in4;
>
> endmodule
> 2.***********************************************************************=
**=AD**************************
> module add1(
>                         input clk,
>                         input [1:0] a,b,
>                         input d,
>                         input [63:0] c,
>                         output reg [64:0] out
>                         );
>
> reg [1:0] in1,in2;
> reg in4;
> reg [63:0] in3;
> wire [64:0] temp;
> wire [64:0] temp2;
> wire [64:0] result;
>
> always @ (posedge clk) begin
>         {in1,in2,in3,in4}=3D {a,b,c,d};
>         out=3D result;
> end
>
>         assign temp=3D in1+in2;
>         assign temp2=3D temp+in4;
>         assign result=3D temp2+in3;
>
> endmodule
> 3.***********************************************************************=
**=AD**************************
> module add2(
>                         input clk,
>                         input d,
>                         input [1:0] a,b,
>                         input [63:0] c,
>                         output reg [64:0] out
>                         );
>
> reg [1:0] in1,in2;
> reg in4;
> reg [63:0] in3;
> reg [64:0] result;
>
> always @ (posedge clk) begin
>         {in1,in2,in3,in4}=3D {a,b,c,d};
>         out=3D result;
> end
> always @ (*) begin
> case({in4,in1,in2})
> 5'b00000: result=3D in3+3'b000;
> 5'b00001: result=3D in3+3'b001;
> 5'b00010: result=3D in3+3'b010;
> 5'b00011: result=3D in3+3'b011;
> 5'b00100: result=3D in3+3'b001;
> 5'b00101: result=3D in3+3'b010;
> 5'b00110: result=3D in3+3'b011;
> 5'b00111: result=3D in3+3'b100;
> 5'b01000: result=3D in3+3'b010;
> 5'b01001: result=3D in3+3'b011;
> 5'b01010: result=3D in3+3'b100;
> 5'b01011: result=3D in3+3'b101;
> 5'b01100: result=3D in3+3'b011;
> 5'b01101: result=3D in3+3'b100;
> 5'b01110: result=3D in3+3'b101;
> 5'b01111: result=3D in3+3'b110;
>
> 5'b10000: result=3D in3+3'b001;
> 5'b10001: result=3D in3+3'b010;
> 5'b10010: result=3D in3+3'b011;
> 5'b10011: result=3D in3+3'b100;
> 5'b10100: result=3D in3+3'b010;
> 5'b10101: result=3D in3+3'b011;
> 5'b10110: result=3D in3+3'b100;
> 5'b10111: result=3D in3+3'b101;
> 5'b11000: result=3D in3+3'b011;
> 5'b11001: result=3D in3+3'b100;
> 5'b11010: result=3D in3+3'b101;
> 5'b11011: result=3D in3+3'b110;
> 5'b11100: result=3D in3+3'b100;
> 5'b11101: result=3D in3+3'b101;
> 5'b11110: result=3D in3+3'b110;
> 5'b11111: result=3D in3+3'b111;
>
> endcase
> end
>
> endmodule
>
> And the results for these from the ISE are
> 1.***********************************************************************=
**=AD**************************
> Selected Device : 4vlx15sf363-12
>
>  Number of Slices:                     105  out of   6144     1%
>  Number of Slice Flip Flops:           134  out of  12288     1%
>  Number of 4 input LUTs:               128  out of  12288     1%
>  Number of bonded IOBs:                135  out of    240    56%
>  Number of GCLKs:                        1  out of     32     3%
>
>    Minimum period: 5.212ns (Maximum Frequency: 191.872MHz)
>    Minimum input arrival time before clock: 1.445ns
>    Maximum output required time after clock: 3.921ns
>    Maximum combinational path delay: No path found
>
> 2.***********************************************************************=
**=AD**************************
> Selected Device : 4vlx15sf363-12
>
>  Number of Slices:                      76  out of   6144     1%
>  Number of Slice Flip Flops:           134  out of  12288     1%
>  Number of 4 input LUTs:                72  out of  12288     0%
>  Number of bonded IOBs:                135  out of    240    56%
>  Number of GCLKs:                        1  out of     32     3%
>
>    Minimum period: 4.793ns (Maximum Frequency: 208.616MHz)
>    Minimum input arrival time before clock: 1.445ns
>    Maximum output required time after clock: 3.921ns
>    Maximum combinational path delay: No path found
> 3.***********************************************************************=
**=AD**************************
> Selected Device : 4vlx15sf363-12
>
>  Number of Slices:                     712  out of   6144    11%
>  Number of Slice Flip Flops:           135  out of  12288     1%
>  Number of 4 input LUTs:              1329  out of  12288    10%
>  Number of bonded IOBs:                135  out of    240    56%
>  Number of GCLKs:                        1  out of     32     3%
>
>    Minimum period: 6.377ns (Maximum Frequency: 156.803MHz)
>    Minimum input arrival time before clock: 1.459ns
>    Maximum output required time after clock: 3.921ns
>    Maximum combinational path delay: No path found
>
> *****************************And the Result from the Synplify
> are*****************************************************************
> 1.***********************************************************************=
**=AD**************************
> Mapping to part: xc4vlx15sf363-10
> Cell usage:
> FD              134 uses
> GND             1 use
> MUXCY           1 use
> MUXCY_L         127 uses
> XORCY           128 uses
> LUT1            125 uses
> LUT2            4 uses
>
> Mapping Summary:
> Total  LUTs: 129 (1%)
>
> -------------------------------------------------------------------------=
--=AD--------------------------------------------
> add|clk            1.0 MHz       143.8 MHz     1000.000
> 6.952         993.048     inferred     Inferred_clkgroup_0
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=AD=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 2.***********************************************************************=
**=AD**************************
> Mapping to part: xc4vlx15sf363-10
> Cell usage:
> FD              134 uses
> GND             1 use
> MUXCY           1 use
> MUXCY_L         127 uses
> XORCY           128 uses
> LUT1            125 uses
> LUT2            4 uses
>
> Mapping Summary:
> Total  LUTs: 129 (1%)
>
> Starting Clock     Frequency     Frequency     Period
> Period        Slack       Type         Group
> -------------------------------------------------------------------------=
--=AD--------------------------------------------
> add1|clk           1.0 MHz       143.8 MHz     1000.000
> 6.952         993.048     inferred     Inferred_clkgroup_0
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=AD=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 3.***********************************************************************=
**=AD**************************
> Mapping to part: xc4vlx15sf363-10
> Cell usage:
> FD              134 uses
> GND             1 use
> MULT_AND        2 uses
> MUXCY           1 use
> MUXCY_L         63 uses
> VCC             1 use
> XORCY           63 uses
> LUT1            61 uses
> LUT2            1 use
> LUT3            3 uses
> LUT4            2 uses
>
> Global Clock Buffers: 1 of 32 (3%)
>
> -------------------------------------------------------------------------=
--=AD--------------------------------------------
> add2|clk           1.0 MHz       139.9 MHz     1000.000
> 7.146         992.854     inferred     Inferred_clkgroup_0
>
> Can any one please help me why i am getting this much difference in
> the result and what should be the real approch to write in HDL to get
> most optimised result.
> Thanks in advance

Some speculation ....

In the add2 architecture, I suspect that XST is implementing 8 (64 bit
+ "3 approx" bit) adders  and muxing out the result where Synplicity
may have figured out to mux out the 3 bit vector and then add it to
the 64 bit input.  This would fit with the much larger footprint given
by XST for add2. BTW, I own stock in Synplicity ;,)

It maybe that the the width of temp and temp2 in add1 maybe adding
noise to the statistics.   The statistics after Map in P&R tools may
give better numbers and give apples to apples comparisons between the
synthesizers.


-Newman




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