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 106200

Article: 106200
Subject: Re: Simple code to check out Spartan3 starter kit?
From: ptkwt@aracnet.com (Phil Tomson)
Date: 9 Aug 2006 05:35:12 GMT
Links: << >>  << T >>  << A >>
In article <ebbn9h019ci@enews1.newsguy.com>,
Phil Tomson <ptkwt@aracnet.com> wrote:
>
>I've got ISE 8.1 running under Linux (Gentoo, 2.6.15 kernel, amd64 - I 
>plan to use the xc3sprog program to send the bitsream to the board) and 
>now I'd like to hook up the starter kit board and try it out...
>I'd like a simple design that I could run through ISE and download to the 
>board that would do something on the LEDs so I know things are working, 
>but I don't see anything like that - according to the README for xc3sprog 
>there is some design called echo_out that does something like this, but I 
>can't find it anywhere.  Is it (or something similar) available on the web 
>anywhere?

Oops, I misread the README for x3sprog: the echo_out.bit file comes with 
it.  Still, it would be nice to have the source to echo_out 
(echo_out.vhd?) as well as other designs which manipulate specific items 
on the starter kit board (like the 7-segment LEDs, for example).

Phil

Article: 106201
Subject: Re: 100 Mbit manchester coded signal in FPGA
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 9 Aug 2006 08:05:49 +0200
Links: << >>  << T >>  << A >>
"Phil Hays" <spampostmaster@comcast.net> schrieb im Newsbeitrag 
news:pan.2006.08.09.02.22.18.236185@comcast.net...
> Antti Lukats wrote:
>
>> "Austin Lesea" wrote:
>
>>> The use of a CPLD or FPGA inversion is not recommended for a crystal
>>> oscillator.
>
>> hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2
>> caps and crystal will not oscillate under some conditions?
>
>
>> It should be 100% a-stable as it can not stay in non-oscillating state.
>
>
> Back in the 1970's, an engineer I was working for decided to save a part
> on a design and use a spare 7414 inverter rather than a 7404 inverter as
> an oscillator.
>
> A TTL inverter, like the 7404, properly connected, makes a good
> oscillator. A 7414, which is a schmitt-trigger inverter, doesn't.
>
> Yes, it would always oscillate.  But only sometimes at the correct
> frequency.  More often at the third or fifth harmonic of the crystal.  And
> sometimes higher harmonics.
>
> This left me with the idea that a good engineer should make sure that an
> oscillator design is a good design before building boards.  Not afterward.
>
>
> -- 
> Phil Hays
>
gosh the 7404 and 7414 are totally different chips (in the context of making 
oscillators).
it wasnt much of an engineer who tried crystal osc with 7414.
7414 is good for making RC oscillator with 1 R and 1C (7404 is not)

http://focus.ti.com/lit/ds/symlink/sn74lvc1404.pdf

and CPLD osc about the same as from above should work.
sure it has to tested to work properly on the correct freq and not harmonics

Antti 



Article: 106202
Subject: Re: Simple code to check out Spartan3 starter kit?
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 9 Aug 2006 08:12:35 +0200
Links: << >>  << T >>  << A >>
Phil Tomson wrote:

> I've got ISE 8.1 running under Linux (Gentoo, 2.6.15 kernel, amd64 - I 
> plan to use the xc3sprog program to send the bitsream to the board) and 
> now I'd like to hook up the starter kit board and try it out...

try this:

http://www.xilinx.com/products/boards/DO-SPAR3-DK/reference_designs.htm

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 106203
Subject: Re: Open source Xilinx JTAG programmer with Digilent USB support
From: vit.matteo@gmail.com
Date: 9 Aug 2006 00:17:04 -0700
Links: << >>  << T >>  << A >>
Peter C. Wallace ha scritto:

> On Mon, 07 Aug 2006 16:26:36 -0700, fpgakid@gmail.com wrote:
>
> > I've written a Xilinx JTAG programmer. It runs on Win32 and Linux
> >
> > Following cables are supported:
> >
> > Parallel III
> > Digilent USB (on Linux it needs libusb, Win32 needs the original driver
> > from digilent, utilizes full USB transfer speed!)
> >
>
> Could it support the FTDI-2232?

If you need support for FTDI-2232 i wrote a porting for Jamplayer. I
think you can use it with Xilinx devices. You can find it here

http://teoscorner.byethost6.com/?page_id=6

Matteo


Article: 106204
Subject: Re: MIG 1.6 DDR2 testing problems (FIFO16 related?)
From: heinerlitz@gmx.de
Date: 9 Aug 2006 01:13:41 -0700
Links: << >>  << T >>  << A >>
HI,

I hope someone is still reading this thread. I am quite sure now that
the matter really are the wrong calibrated
clk_count_rise/clk_count_fall signals.

Ok, i tried to hardcode them but there are 8 possibliities for both the
rising and falling edge. Too many to be tried out. How should I
hardcode these  two signals??

I tried myself be observing them via chipscope. My hope was that they
were set to a different value in the case where everything works fine
than in the case where the read out value is wrong.

however chipscope ALWAYS showed that the signals are set to
rd_en_rise <=3D rd_en_r4;
rd_en_fall <=3D rd_en_r3;

Firstly, this does not match with my theorie, second I dont trust
chipscope, third when I tried the above hardcoded values, I got errrors
@EVERY read, so these are not the right values.

thx again for any help

heiner


heinerlitz@gmx.de schrieb:

> As I wrote above:
>
> I observed  clk_count_rise and clk_count_fall using chipscope and found
> out that they never change which means they are defacto hardcoded. The
> delay is hence always the same even without hardcoding the value.
> However faillures are still there.
>
> heiner
>
>
> Joseph Samson schrieb:
>
> > GaLaKtIkUs=99 wrote:
> >
> > > Did you hard coded the number of needed clock cycles or the delay in
> > > the IDELAY??
> > > Thanks for help!
> >
> > The number of clock cycles needed, not the IODelay.
> >=20
> >=20
> > ---
> > Joe Samson
> > Pixel Velocity


Article: 106205
Subject: Re: Spartan 3 StarterKit Weirdness
From: Mike Harrison <mike@whitewing.co.uk>
Date: Wed, 09 Aug 2006 08:24:18 GMT
Links: << >>  << T >>  << A >>
On Tue, 08 Aug 2006 23:44:43 GMT, "John_H" <newsgroup@johnhandwork.com> wrote:

>I didn't see the verify work and I haven't gone back to see if it could.
>The several times I've reprogrammed, the direct JTAG works fine; I've only 
>programmed the flash load once or twice since direct seems to work.  I do 
>recall some DCM lock problems that *shouldn't* have been there as far as I 
>could tell (and DCM reset didn't help) but I was actively changing the 
>design and a next load usually took care of it.  Rapid development masks 
>bugs?
>
>- John_H
>
>"David Carne" <david-removeme-carne@shaw.ca> wrote in message 
>news:20060808162224915-0700@news.vc.shawcable.net...
>> I'm experiencing something strange with my Spartan 3 starter kit. It
>> seems that when I download a bitstream via jtag directly, things don't
>> always work the way they should. However, when I generate a mcs/prm file,
>> then burn that prom file to the onboard prom via jtag + boot the fpga
>> via that, it works perfectly! I've seen this behavior on multiple
>> different designs... no common attribute as to when it happens + when it
>> doesnt. I've tried forcing it to verify, but I've never once had that
>> succeed, so I don't know if the verify functionality even works.
>>
>> Has anyone seen this before, and if so, any ideas about a solution?
>>
>>
>> Cheers,
>>
>> --David Carne 

I've also seen this happen - not downloading correctly, a second download then works OK. Happenned
sufficiently infrequently to not bother investigating further.
Note that verify will always fail when downloading via JTAG - this only works when programming the
flash. 

Article: 106206
Subject: Newcomer question
From: Johannes Hausensteiner <johannes.hausensteiner@pcl.at>
Date: Wed, 09 Aug 2006 11:08:12 +0200
Links: << >>  << T >>  << A >>
Hi there,

I am doing my first FPGA/VHDL design. Previously I did CPLD designs
utilizing Altera's AHDL.
I coded the VHDL source files and simulated it successfully with
Modelsim. Then I made the I/O pin assignments and made the .bit
file and loaded it to the FPGA. To my disappointment only some of
the signals are correct; the functionality of the system does not
work.
I am using ispLEVER and a Lattice LFEC33 FPGA.
There is a "Post Place and Route Simulation" action available within
ispLEVER (actually it starts Modelsim), but this does not work.
Modelsim always complains "Error loading design".
What possibilities do I have to debug my design?

Thanks a lot,

Johannes

Article: 106207
Subject: Re: Who is your favourite FPGA guru?
From: Kolja Sulimma <news@sulimma.de>
Date: Wed, 09 Aug 2006 11:10:43 +0200
Links: << >>  << T >>  << A >>
I agree to many of the suggestions, but they are all from a
user/implementor view. I would like to add:
- André DeHon
   for real innovative thinking about architectures of FPGAs
   what an FPGA realy is when compared to a processor
- Jason Cong et al. for the Flow Map Algorithm
- Tom Kean & Co. from Algotronix for the CAL architecture (later XC6200)
- Ross Freeman for the integrated CMOS FPGA
- The people (don't know the names) that build FPGAs from seas of
discrete muxes with wire wrap interconnect in the 60s and therefor
really are the inventors of FPGAs.

Kolja Sulimma

Article: 106208
Subject: Re: 100 Mbit manchester coded signal in FPGA
From: "Symon" <symon_brewer@hotmail.com>
Date: 9 Aug 2006 11:40:56 +0200
Links: << >>  << T >>  << A >>
"Antti Lukats" <antti@openchip.org> wrote in message 
news:ebbtvs$dpr$1@online.de...
> "Phil Hays" <spampostmaster@comcast.net> schrieb im Newsbeitrag
> and CPLD osc about the same as from above should work.
> sure it has to tested to work properly on the correct freq and not 
> harmonics
>
I'm sure you meant this, but I'll post it anyway. I'd rather say it has to 
be _designed_ to work properly. Trial and error is, as I've found through 
trial and error, a terribly inefficient way to do projects.
Cheers, Syms. 



Article: 106209
Subject: A Newbie question
From: "santanu" <thisissantanu@gmail.com>
Date: 9 Aug 2006 03:11:35 -0700
Links: << >>  << T >>  << A >>
Hi Everybody,

I am just starting with the Xilinx Multimedia Board (Virtex II).

I have written a trivial verilog program using ISE 6.3:
-------------------------------------
module mult(c_upper, c_lower);
  output [31:0] c_upper;
  output [31:0] c_lower;

  reg [31:0] ia;
  reg [31:0] ib;
  reg [63:0] c;

  initial begin
    ia=32'h10000001;
    ib=32'h00000002;
    c=ia*ib;
  end

  assign c_lower=c[31:0];
  assign c_upper=c[63:32];

endmodule
---------------------------------------

As for assigning pins, I have used BANK0
for storing the c_upper and c_lower.

The program compiled fine, and the bitstream was generated
and downloaded successfully. But the problem is now, how
do I see the memory where the result is supposed to be present?

It is possible that I am asking a stupid question, but at our
place, nobody has any experience with this board, and I am
having to figure this out on my own.

I would be grateful if you could point me to any suitable document
that might answer my question, or provide a solution.

Thaks in advance.

-Santanu Chatterjee


Article: 106210
Subject: Re: Newcomer question
From: Johannes Hausensteiner <johannes.hausensteiner@pcl.at>
Date: Wed, 09 Aug 2006 12:56:43 +0200
Links: << >>  << T >>  << A >>
Hi,

For some reason my first post ended up in a complete different thread
(XPower: Post-Place and Route Simulation model). Thanks to all of you
answered there.
Being (in my age still) impatient I sent this post a second time -
I apologize for that.

Johannes


Johannes Hausensteiner wrote:
> Hi there,
> 
> I am doing my first FPGA/VHDL design. Previously I did CPLD designs
> utilizing Altera's AHDL.
> I coded the VHDL source files and simulated it successfully with
> Modelsim. Then I made the I/O pin assignments and made the .bit
> file and loaded it to the FPGA. To my disappointment only some of
> the signals are correct; the functionality of the system does not
> work.
> I am using ispLEVER and a Lattice LFEC33 FPGA.
> There is a "Post Place and Route Simulation" action available within
> ispLEVER (actually it starts Modelsim), but this does not work.
> Modelsim always complains "Error loading design".
> What possibilities do I have to debug my design?
> 
> Thanks a lot,
> 
> Johannes

Article: 106211
Subject: Re: 100 Mbit manchester coded signal in FPGA
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 09 Aug 2006 23:14:14 +1200
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> gosh the 7404 and 7414 are totally different chips (in the context of making 
> oscillators).
> it wasnt much of an engineer who tried crystal osc with 7414.
> 7414 is good for making RC oscillator with 1 R and 1C (7404 is not)
> 
> http://focus.ti.com/lit/ds/symlink/sn74lvc1404.pdf

and also the very similar
http://www.standardics.philips.com/products/aup/pdf/74aup1z04.pdf

> and CPLD osc about the same as from above should work.

problem is, cpld osc is not 'about the same', as these devices use 
unbuffered inverters for the Xtal osc, and Schmitt post buffers.
- no presently available CPLD's offer unbuffered inverters, they
have loop gains even higher than buffered cmos gates which tyically
chain 3 inverters.

> sure it has to tested to work properly on the correct freq and not harmonics

still leaves edge effects, which are not ideal on a clock source :)

-jg


Article: 106212
Subject: ISE software bug???
From: "Jozsef" <bit_vector@tvn.hu>
Date: 9 Aug 2006 04:36:45 -0700
Links: << >>  << T >>  << A >>
Hi,

 I'm confused over two days for the sollution of the next problem:

environment:
software : WP8.1.03i & WP8.2.01i (tried with both)
HW: XC3S400PQG208

I have a board which requires some clock forwarding. Input and output
locations are constrained, input clock located at P76 and output
located at
P165. The problem is with the forwarding. I've tried with DCM, or a
simple

 out<=input;

row in the source, but the clock haven't found on output pin (inspected
with
oscilloscope). Unfortunately, Xilinx's webcase page is unreachable by
several reasons.

And the reason why I think this to software bug: forwarding works at
yesterday for several synthesizing & config stram generation cycle
after 30
hours hard error finding. I don't know, how...  But I've confused, when
I
added a simple counter to testing the sychronous network inside the
FPGA.
Counter wouldn't want to work. I've catched some warnings on the .ncd
or
.ngd file from the PAR process (maybe corrupt?), I haven't remember,
sorry:-/    This occoured to cleanup project files, and after, the
forwarding isn't works :(((

best regards


Article: 106213
Subject: Re: ISE software bug???
From: Aurelian Lazarut <aurash@xilinx.com>
Date: Wed, 09 Aug 2006 13:48:29 +0100
Links: << >>  << T >>  << A >>
Jozsef,
after 30 hours of debuging this wire maybe you should rest. After taking 
a nap, please check map report for trimmed signals, or post some 
files/reports/error messages to see how we can help you.
Aurash

Jozsef wrote:

>Hi,
>
> I'm confused over two days for the sollution of the next problem:
>
>environment:
>software : WP8.1.03i & WP8.2.01i (tried with both)
>HW: XC3S400PQG208
>
>I have a board which requires some clock forwarding. Input and output
>locations are constrained, input clock located at P76 and output
>located at
>P165. The problem is with the forwarding. I've tried with DCM, or a
>simple
>
> out<=input;
>
>row in the source, but the clock haven't found on output pin (inspected
>with
>oscilloscope). Unfortunately, Xilinx's webcase page is unreachable by
>several reasons.
>
>And the reason why I think this to software bug: forwarding works at
>yesterday for several synthesizing & config stram generation cycle
>after 30
>hours hard error finding. I don't know, how...  But I've confused, when
>I
>added a simple counter to testing the sychronous network inside the
>FPGA.
>Counter wouldn't want to work. I've catched some warnings on the .ncd
>or
>.ngd file from the PAR process (maybe corrupt?), I haven't remember,
>sorry:-/    This occoured to cleanup project files, and after, the
>forwarding isn't works :(((
>
>best regards
>
>  
>


-- 
 __
/ /\/\ Aurelian Lazarut
\ \  / System Verification Engineer
/ /  \ Xilinx Ireland
\_\/\/
 
phone:	353 01 4032639
fax:	353 01 4640324
    
     

Article: 106214
Subject: DSP core, use of real type signals (Altera Stratix)
From: "Erik Verhagen" <Erik.Verhagen@cern.ch>
Date: Wed, 9 Aug 2006 14:48:59 +0200
Links: << >>  << T >>  << A >>
Hello,
I have a little problem, it is about real values in VHDL, and the way =
Quartus is managing them.
I am describing a simple DSP function (filter) in VHDL to implement on a =
Stratix device. As you probabely know, these functions need to shift =
input values in a register bank (declared as "signal" in VHDL), applying =
coefficients (reals) to them. These signals must therefor be of real =
type.
Quartus returns this error on compilation : <snip> Error (10414): VHDL =
error at iir_butterworth_3.vhd(49), at object "X": a real cannot be =
non-constant </snip> ("X" is such a register) Of course the filter =
coefficients (reals) are hardcoded as constants in a package, but these =
shift registers containing reals *are not* constants, they of course =
have to be signals to enable shifting.=20
I have read about obscure floating point units implemented on Stratix =
devices, so I suppose it should be possible to manage real signals =
(floating/fixed point representation ?) in it.=20
Does anyone have an idea about how I can use non-constant reals to =
create a DSP core on Stratix ? I think it is only a synthesis tool =
issue.

Here is the code (no comment on the casts, I *AM* aware this is not the =
most elegant)
A, B, C and D are the filter coefficients.
This description simulates PERFECTLY with Modelsim...

architecture testing of iir_butterworth_3 is

  type register_bank is array (0 to 2) of real;
  signal X : register_bank;
  signal Y : register_bank;

begin

  DSP : process(clock, reset, data_in)

  begin

    if reset =3D '1' then	         -- initialise registers to 0
      for i in 0 to 2 loop
        X(i) <=3D 0.0;
        Y(i) <=3D 0.0;
      end loop;		=09

    elsif clock'event AND clock =3D '1' then
      X(0) <=3D real(conv_integer(data_in));
      X(1 to 2) <=3D X(0 to 1);              shift X's
=09
      Y(0) <=3D ( real(conv_integer(data_in)) + 3.0*X(0) + 3.0*X(1) + =
X(2) - B*Y(0) - C*Y(1) - D*Y(2)) / A;
      Y(1 to 2) <=3D Y(0 to 1);              shift Y's
    end if;

  end process DSP;

  data_out <=3D conv_std_logic_vector(integer(Y(0)), data_width);

  end architecture;


Thanks in advance for the help
Regards,


----------------------------------------------
- Erik Verhagen                 (div: AB-BI) -
-                CERN, Geneva                -
- European Organisation for Nuclear Research -
----------------------------------------------



Article: 106215
Subject: Re: ISE software bug???
From: Aurelian Lazarut <aurash@xilinx.com>
Date: Wed, 09 Aug 2006 13:52:23 +0100
Links: << >>  << T >>  << A >>
or better, just add a BUFG in between and make sure you'll use a 
dedicated clock pin for this input.
Aurash

Aurelian Lazarut wrote:

> Jozsef,
> after 30 hours of debuging this wire maybe you should rest. After 
> taking a nap, please check map report for trimmed signals, or post 
> some files/reports/error messages to see how we can help you.
> Aurash
>
> Jozsef wrote:
>
>> Hi,
>>
>> I'm confused over two days for the sollution of the next problem:
>>
>> environment:
>> software : WP8.1.03i & WP8.2.01i (tried with both)
>> HW: XC3S400PQG208
>>
>> I have a board which requires some clock forwarding. Input and output
>> locations are constrained, input clock located at P76 and output
>> located at
>> P165. The problem is with the forwarding. I've tried with DCM, or a
>> simple
>>
>> out<=input;
>>
>> row in the source, but the clock haven't found on output pin (inspected
>> with
>> oscilloscope). Unfortunately, Xilinx's webcase page is unreachable by
>> several reasons.
>>
>> And the reason why I think this to software bug: forwarding works at
>> yesterday for several synthesizing & config stram generation cycle
>> after 30
>> hours hard error finding. I don't know, how...  But I've confused, when
>> I
>> added a simple counter to testing the sychronous network inside the
>> FPGA.
>> Counter wouldn't want to work. I've catched some warnings on the .ncd
>> or
>> .ngd file from the PAR process (maybe corrupt?), I haven't remember,
>> sorry:-/    This occoured to cleanup project files, and after, the
>> forwarding isn't works :(((
>>
>> best regards
>>
>>  
>>
>
>


-- 
 __
/ /\/\ Aurelian Lazarut
\ \  / System Verification Engineer
/ /  \ Xilinx Ireland
\_\/\/
 
phone:	353 01 4032639
fax:	353 01 4640324
    
     

Article: 106216
Subject: Xilinx PCI Core & CardBus
From: "Weltraumbaer" <info@presser24.de>
Date: 9 Aug 2006 06:09:21 -0700
Links: << >>  << T >>  << A >>
Hi everybody,

I have designed a Cardbus Card with Spartan 3 and Xilinx PCI Core,
which works very well in all kind of notebooks, but when I try to use
the card within a PC (with a PCI CardBus adapter card - TI PCI-1520
chipset) nothing happens not even the new hardware window comes up. But
the PCI CardBus adapter seems to be OK, because if I use a bought 3COM
Ethernet Card the new hardware window appears and the driver will be
installed. The PCI Cardbus adapter card has exactly the same chipset as
one of my test notebook, where the card is working very well. I have
also tried to set the boot clock (CCLK) to maximum speed - but the
result did not change. I do not really see the difference between a
chipset mounted directly on the motherboard and the adapter card.

I hope somebody has an idea to solve this problem.

With kind regards
Nico Presser


Article: 106217
Subject: Re: Xilinx PCI Core & CardBus
From: "Gabor" <gabor@alacron.com>
Date: 9 Aug 2006 06:21:13 -0700
Links: << >>  << T >>  << A >>
Are you sure you're getting your required voltage(s) from the
cardbus adapter?  If your requested voltages are not available
you normally don't get powered up at all.  I've found that 3.3v
is the only voltage you can reliably expect on a cardbus adapter.

HTH,
Gabor

Weltraumbaer wrote:
> Hi everybody,
>
> I have designed a Cardbus Card with Spartan 3 and Xilinx PCI Core,
> which works very well in all kind of notebooks, but when I try to use
> the card within a PC (with a PCI CardBus adapter card - TI PCI-1520
> chipset) nothing happens not even the new hardware window comes up. But
> the PCI CardBus adapter seems to be OK, because if I use a bought 3COM
> Ethernet Card the new hardware window appears and the driver will be
> installed. The PCI Cardbus adapter card has exactly the same chipset as
> one of my test notebook, where the card is working very well. I have
> also tried to set the boot clock (CCLK) to maximum speed - but the
> result did not change. I do not really see the difference between a
> chipset mounted directly on the motherboard and the adapter card.
>
> I hope somebody has an idea to solve this problem.
> 
> With kind regards
> Nico Presser


Article: 106218
Subject: Re: Xilinx PCI Core burst problem
From: "Weltraumbaer" <info@presser24.de>
Date: 9 Aug 2006 06:23:12 -0700
Links: << >>  << T >>  << A >>
Hi all,

Thank you for your fast response. Meanwhile I have tried another
notebook with a different CardBus chipset (TI PCI-1520) and I did not
believe what I have seen. Everything was working as it should be. With
master read command 1 DW was transferred, with master read line command
8 DW's were transferred and with master read multiple command 4kB in a
row were transferred with the maximum of 1 retry after initial
request!!!

Nico Presser


Article: 106219
Subject: Re: Xilinx PCI Core & CardBus
From: "Weltraumbaer" <info@presser24.de>
Date: 9 Aug 2006 06:28:30 -0700
Links: << >>  << T >>  << A >>
Hi Gabor,

As far as I know CardBus does only support 3,3V. In older PCMCIA
systems you could choose between 5V and 3,3V. Nevertheless my card is
based on 3,3V.

Nico


Article: 106220
Subject: Re: Xilinx PCI Core burst problem
From: "Antti" <Antti.Lukats@xilant.com>
Date: 9 Aug 2006 06:52:36 -0700
Links: << >>  << T >>  << A >>
Kolja Sulimma schrieb:

> John_H wrote:
> > Weltraumbaer wrote:
> >> Hello,
> >>
> >> I have designed a CardBus Design, which is very similar to pci with
> >> full master functionality. The main aim of this card is to transfer a
> >> huge amount of data to and from PC RAM to the CardBus card. But in
> >> master read mode I very often get a target retry. The fact of an target
> >> retry (in this case the pc is the target) is not abnormal but I have
> >> scanned the pci bus and I have seen a lot of target retries in series
> >> -> sometimes more then 100 in a row. This is absolute unacceptable due
> >> to the poor bus performance -> so my fifo's run out of data. The common
> >> pc memory (ram) is locked from driver and is set as non cacheable.
> >>
> >> I hope that somebody can help me in this issue. I am not really sure if
> >> this is a hardware or a software (driver) problem.
>
> We learned the hard way that PCI is just not intended to read at high data rates.
> Some chipset will even split a single 128-bit read (SSE2 move) of the CPU into
> two PCI accesses. You can't really expect the chipset to be nicer to your expansion
> board than it is to the CPU.
>
> I would not really on getting any read bursts larger than a cache line to work without
> tuning chipset specific registers.
>
> Kolja Sulimma

Hi Kolja,

do you know if SSE2 moves would be normally translated to 64 bit PCI(X)
transfers or not? I am working with PCI-X ipcore where backend is
always 64bits so sometimes I would like the PC host software todo
atomic 64 bit read writes but I found no way. It should be doable only
with 64 bit OS as the Intel 64 bit extensions are not accessible in 32
bit OSes (so I have understood it at least). I have been reading intel
specs, but as far as I understand on 32 bit OS there is no almost no
way to force a programatic 64 bit access from the CPU - maybe I missed
something. I only looked at CPU commands not the SSE2

--

as of burst - sometimes it works like magic, as example I see an PCI 64
bit master to transfer 4KB blocks to PC main memory as almost continous
stream, eg 512 clocks for 4kbyte, then after a few clocks next block,
etc.. not a single retry!

sure master reads would yield more retries

Antti


Article: 106221
Subject: Re: Newbie question
From: Johannes Hausensteiner <johannes.hausensteiner@pcl.at>
Date: Wed, 09 Aug 2006 16:16:27 +0200
Links: << >>  << T >>  << A >>
Hi Bart,

Thanks for the link.

bart wrote:
> Johannes Hausensteiner wrote:
> 
>> What possibilities do I have to debug my design?
> 
> Hi Johannes,
> besides comp.arch.fpga and other usenet groups, you could post your
> questions on Lattice's support forum:
> 
> http://www.latticesemi.com/support/forums.cfm
> 
> hope this helps.
> regards,
> bart borosky, lattice
> 

Article: 106222
Subject: Re: Newbie question
From: Johannes Hausensteiner <johannes.hausensteiner@pcl.at>
Date: Wed, 09 Aug 2006 16:16:42 +0200
Links: << >>  << T >>  << A >>
Hi André,

Thanks for your answer; yes I added my testbench to the ispLEVER
project and assosiated it to the FPGA chip. I get three entries in
right pane of the ispLEVER ProjectNavigator:
- VHDL Functional Simulation
- VHDL Post-Route Functional Simulation
- VHDL Post-Route Timing Simulation
When I double-click on any of them Modelsim is started and it compiles
and tries to load the design. In all three of them there are following
error messages in Modelsim:
-- snip ---
# ** Error: (vsim-3170) Could not find 'work.StimModule_Unknown'.
# Error loading design
# Error: Error loading design
#        Pausing macro execution
-- snip ---
The name "work.StimModule_Unknown" is used for each and every design
I tried up to now.
When I replace this in the (by ispLEVER generated) do-files
(test_bench.fdo, test_bench.xdo, test_bench.tdo) with the name of the
testbench then the "Functional Simulation" will work.
The "Post-Route Functional Simulation" and the "Post-Route Timing
Simulation" will still refuse to load in Modelsim with the following
error:
-- snip ---
# Loading work.tb_counter(test_counter)
# ** Error: (vsim-13) Recompile work.counter(everything) because
work.counter has changed.
# Error loading design
# Error: Error loading design
-- snip ---
This does not change when I actually recompile "counter",
"work.counter", or the whole design.

While once more double-checking I found out the following:
for the "Post-Route ... Simulation" ispLEVER decompiles what it has
routed to a VHDL file named "design.vho". This uses the architecture
name "Structure". For the testbench to be loaded correctly within
Modelsim is has (of course) to be of architecture "Structure", too
(which was in the case in my design). - OK, this one is clear; I can
live with the "work.StimModule_Unknown" thing.


So thank you for your replies!

Johannes



ALuPin@web.de wrote:
> Hi Johannes,
> 
> did you import the testbench file and associate it to the device in
> ispLEVER?
> By doing that you can start functional and timing simulation when
> marking
> the device.
> 
> Besides are you using VHDL packages ?
> 
> Rgds
> André
> 
> 
>> There is a "Post Place and Route Simulation" action available within
>> ispLEVER (actually it starts Modelsim), but this does not work.
>> Modelsim always complains "Error loading design".
>> What possibilities do I have to debug my design?
>>
>> Thanks a lot,
>>
>> Johannes
> 


Article: 106223
Subject: Re: ISE software bug???
From: "Jozsef" <bit_vector@tvn.hu>
Date: 9 Aug 2006 07:34:34 -0700
Links: << >>  << T >>  << A >>
Aurash,

Now changes the situation, but I stand with incomprehension. Now, the
clock are forwarded, but and significantly but, synchronous upcounter
isn't work.
The design & report files attached below.

-------------- c.vhd ---------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
library UNISIM;
use UNISIM.VComponents.all;

entity c is
    Port ( clk : in  STD_LOGIC;
	        sys_clk_out: out std_logic;
           q : out  STD_LOGIC
          );
end c;

architecture Behavioral of c is
signal aaaa : std_logic_vector(6 downto 0);
signal i_clk: std_logic;
    port (I: in  STD_LOGIC;
          O: out STD_LOGIC);
end component;
begin
  internalclock: bufg port map(clk,i_clk);
  process(i_clk)            ----this counter is not work, why????
  begin
    if rising_edge(i_clk) then
	   aaaa<=aaaa+"0000001";
	 end if;
  end process;
	Sys_Clk_out<=clk;
	q<=aaaa(6);
end Behavioral;

--------------end  of c.vhd ---------
-------------- c.ucf ----------

#PACE: Start of Constraints generated by PACE

#PACE: Start of PACE I/O Pin Assignments
NET "clk"  LOC = "P76" | IOSTANDARD = LVCMOS33 ; #           gclk2
NET "q"  LOC = "P95" | IOSTANDARD = LVCMOS33  | SLEW = FAST  | DRIVE =
12 ; #IO
NET "sys_clk_out"  LOC = "P165" | IOSTANDARD = LVCMOS33  | SLEW = FAST
; # IO

#PACE: Start of PACE Area Constraints

#PACE: Start of PACE Prohibit Constraints

#PACE: End of Constraints generated by PACE

------------end of c.ucf--------------------

-----------------SYNTHESIZE REPORT---------------------
Release 8.2.01i - xst I.32
Copyright (c) 1995-2006 Xilinx, Inc.  All rights reserved.
--> Parameter TMPDIR set to ./xst/projnav.tmp
CPU : 0.00 / 1.51 s | Elapsed : 0.00 / 1.00 s

--> Parameter xsthdpdir set to ./xst
CPU : 0.00 / 1.51 s | Elapsed : 0.00 / 1.00 s

--> Reading design: c.prj

TABLE OF CONTENTS
  1) Synthesis Options Summary
  2) HDL Compilation
  3) Design Hierarchy Analysis
  4) HDL Analysis
  5) HDL Synthesis
     5.1) HDL Synthesis Report
  6) Advanced HDL Synthesis
     6.1) Advanced HDL Synthesis Report
  7) Low Level Synthesis
  8) Partition Report
  9) Final Report
     9.1) Device utilization summary
     9.2) TIMING REPORT


=========================================================================
*                      Synthesis Options Summary
*
=========================================================================
---- Source Parameters
Input File Name                    : "c.prj"
Input Format                       : mixed
Ignore Synthesis Constraint File   : NO

---- Target Parameters
Output File Name                   : "c"
Output Format                      : NGC
Target Device                      : xc3s400-4-pq208

---- Source Options
Top Module Name                    : c
Automatic FSM Extraction           : YES
FSM Encoding Algorithm             : Auto
FSM Style                          : lut
RAM Extraction                     : Yes
RAM Style                          : Auto
ROM Extraction                     : Yes
Mux Style                          : Auto
Decoder Extraction                 : YES
Priority Encoder Extraction        : YES
Shift Register Extraction          : YES
Logical Shifter Extraction         : YES
XOR Collapsing                     : YES
ROM Style                          : Auto
Mux Extraction                     : YES
Resource Sharing                   : YES
Multiplier Style                   : auto
Automatic Register Balancing       : No

---- Target Options
Add IO Buffers                     : YES
Global Maximum Fanout              : 500
Add Generic Clock Buffer(BUFG)     : 8
Register Duplication               : YES
Slice Packing                      : YES
Pack IO Registers into IOBs        : auto
Equivalent register Removal        : YES

---- General Options
Optimization Goal                  : Speed
Optimization Effort                : 1
Keep Hierarchy                     : NO
RTL Output                         : Yes
Global Optimization                : AllClockNets
Write Timing Constraints           : NO
Hierarchy Separator                : /
Bus Delimiter                      : <>
Case Specifier                     : maintain
Slice Utilization Ratio            : 100
Slice Utilization Ratio Delta      : 5

---- Other Options
lso                                : c.lso
Read Cores                         : YES
cross_clock_analysis               : NO
verilog2001                        : YES
safe_implementation                : No
Optimize Instantiated Primitives   : NO
use_clock_enable                   : Yes
use_sync_set                       : Yes
use_sync_reset                     : Yes

=========================================================================


=========================================================================
*                          HDL Compilation
*
=========================================================================
Compiling vhdl file "C:/XilinxProjects/Dummy1/c.vhd" in Library work.
Entity <c> compiled.
Entity <c> (Architecture <behavioral>) compiled.

=========================================================================
*                     Design Hierarchy Analysis
*
=========================================================================
Analyzing hierarchy for entity <c> in library <work> (architecture
<behavioral>).

Building hierarchy successfully finished.

=========================================================================
*                            HDL Analysis
*
=========================================================================
Analyzing Entity <c> in library <work> (Architecture <behavioral>).
WARNING:Xst:2211 - "C:/XilinxProjects/Dummy1/c.vhd" line 58:
Instantiating black box module <BUFG>.
Entity <c> analyzed. Unit <c> generated.


=========================================================================
*                           HDL Synthesis
*
=========================================================================

Performing bidirectional port resolution...

Synthesizing Unit <c>.
    Related source file is "C:/XilinxProjects/Dummy1/c.vhd".
    Found 7-bit up counter for signal <aaaa>.
    Summary:
	inferred   1 Counter(s).
Unit <c> synthesized.


=========================================================================
HDL Synthesis Report

Macro Statistics
# Counters                                             : 1
 7-bit up counter                                      : 1

=========================================================================

=========================================================================
*                       Advanced HDL Synthesis
*
=========================================================================

Loading device for application Rf_Device from file '3s400.nph' in
environment C:\Xilinx.

=========================================================================
Advanced HDL Synthesis Report

Macro Statistics
# Counters                                             : 1
 7-bit up counter                                      : 1

=========================================================================

=========================================================================
*                         Low Level Synthesis
*
=========================================================================

Optimizing unit <c> ...

Mapping all equations...
Building and optimizing final netlist ...
Found area constraint ratio of 100 (+ 5) on block c, actual ratio is 0.

Final Macro Processing ...

=========================================================================
Final Register Report

Macro Statistics
# Registers                                            : 7
 Flip-Flops                                            : 7

=========================================================================

=========================================================================
*                          Partition Report
*
=========================================================================

Partition Implementation Status
-------------------------------

  No Partitions were found in this design.

-------------------------------

=========================================================================
*                            Final Report
*
=========================================================================
Final Results
RTL Top Level Output File Name     : c.ngr
Top Level Output File Name         : c
Output Format                      : NGC
Optimization Goal                  : Speed
Keep Hierarchy                     : NO

Design Statistics
# IOs                              : 3

Cell Usage :
# BELS                             : 8
#      LUT2                        : 2
#      LUT3                        : 2
#      LUT4                        : 2
#      LUT4_D                      : 1
#      VCC                         : 1
# FlipFlops/Latches                : 7
#      FD                          : 6
#      FDR                         : 1
# Clock Buffers                    : 1
#      BUFG                        : 1
# IO Buffers                       : 3
#      IBUFG                       : 1
#      OBUF                        : 2
=========================================================================

Device utilization summary:
---------------------------

Selected Device : 3s400pq208-4

 Number of Slices:                       4  out of   3584     0%
 Number of Slice Flip Flops:             7  out of   7168     0%
 Number of 4 input LUTs:                 7  out of   7168     0%
 Number of IOs:                          3
 Number of bonded IOBs:                  3  out of    141     2%
 Number of GCLKs:                        1  out of      8    12%


=========================================================================
TIMING REPORT

NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE.
      FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT
      GENERATED AFTER PLACE-and-ROUTE.

Clock Information:
------------------
-----------------------------------+------------------------+-------+
Clock Signal                       | Clock buffer(FF name)  | Load  |
-----------------------------------+------------------------+-------+
clk                                | IBUFG+BUFG             | 7     |
-----------------------------------+------------------------+-------+

Asynchronous Control Signals Information:
----------------------------------------
No asynchronous control signals found in this design

Timing Summary:
---------------
Speed Grade: -4

   Minimum period: 4.186ns (Maximum Frequency: 238.892MHz)
   Minimum input arrival time before clock: No path found
   Maximum output required time after clock: 7.241ns
   Maximum combinational path delay: 7.743ns

Timing Detail:
--------------
All values displayed in nanoseconds (ns)

=========================================================================
Timing constraint: Default period analysis for Clock 'clk'
  Clock period: 4.186ns (frequency: 238.892MHz)
  Total number of paths / destination ports: 28 / 7
-------------------------------------------------------------------------
Delay:               4.186ns (Levels of Logic = 2)
  Source:            aaaa_3 (FF)
  Destination:       aaaa_5 (FF)
  Source Clock:      clk rising
  Destination Clock: clk rising

  Data Path: aaaa_3 to aaaa_5
                                Gate     Net
    Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
    ----------------------------------------  ------------
     FD:C->Q               2   0.720   1.216  aaaa_3 (aaaa_3)
     LUT4_D:I0->O          2   0.551   0.945  Mcount_aaaa_cy<3>11
(Mcount_aaaa_cy<3>)
     LUT3:I2->O            1   0.551   0.000  Mcount_aaaa_xor<5>11
(Result<5>)
     FD:D                      0.203          aaaa_5
    ----------------------------------------
    Total                      4.186ns (2.025ns logic, 2.161ns route)
                                       (48.4% logic, 51.6% route)

=========================================================================
Timing constraint: Default OFFSET OUT AFTER for Clock 'clk'
  Total number of paths / destination ports: 1 / 1
-------------------------------------------------------------------------
Offset:              7.241ns (Levels of Logic = 1)
  Source:            aaaa_6 (FF)
  Destination:       q (PAD)
  Source Clock:      clk rising

  Data Path: aaaa_6 to q
                                Gate     Net
    Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
    ----------------------------------------  ------------
     FD:C->Q               2   0.720   0.877  aaaa_6 (aaaa_6)
     OBUF:I->O                 5.644          q_OBUF (q)
    ----------------------------------------
    Total                      7.241ns (6.364ns logic, 0.877ns route)
                                       (87.9% logic, 12.1% route)

=========================================================================
Timing constraint: Default path analysis
  Total number of paths / destination ports: 1 / 1
-------------------------------------------------------------------------
Delay:               7.743ns (Levels of Logic = 2)
  Source:            clk (PAD)
  Destination:       sys_clk_out (PAD)

  Data Path: clk to sys_clk_out
                                Gate     Net
    Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
    ----------------------------------------  ------------
     IBUFG:I->O            2   1.222   0.877  clk_IBUFG
(sys_clk_out_OBUF)
     OBUF:I->O                 5.644          sys_clk_out_OBUF
(sys_clk_out)
    ----------------------------------------
    Total                      7.743ns (6.866ns logic, 0.877ns route)
                                       (88.7% logic, 11.3% route)

=========================================================================
CPU : 12.40 / 13.98 s | Elapsed : 13.00 / 14.00 s

-->

Total memory usage is 137084 kilobytes

Number of errors   :    0 (   0 filtered)
Number of warnings :    1 (   0 filtered)
Number of infos    :    0 (   0 filtered)
-------------------END OF SYNTHESIZE REPORT------------------------
-------------------TRANSLATE REPORT---------------------------------
Release 8.2.01i ngdbuild I.32
Copyright (c) 1995-2006 Xilinx, Inc.  All rights reserved.

Command Line: C:\Xilinx\bin\nt\ngdbuild.exe -ise
C:/XilinxProjects/Dummy1/Dummy1.ise -intstyle ise -dd _ngo -nt
timestamp -uc
c.ucf -p xc3s400-pq208-4 c.ngc c.ngd

Reading NGO file 'C:/XilinxProjects/Dummy1/c.ngc' ...

Applying constraints in "c.ucf" to the design...

Checking timing specifications ...
Checking Partitions ...
Checking expanded design ...

Partition Implementation Status
-------------------------------

  No Partitions were found in this design.

-------------------------------

NGDBUILD Design Results Summary:
  Number of errors:     0
  Number of warnings:   0

Total memory usage is 65956 kilobytes

Writing NGD file "c.ngd" ...

Writing NGDBUILD log file "c.bld"...
--------------------END OF TRANSLATION REPORT-----------------
-------------------MAP REPORT----------------------------------------
elease 8.2.01i Map I.32
Xilinx Mapping Report File for Design 'c'

Design Information
------------------
Command Line   : C:\Xilinx\bin\nt\map.exe -ise
C:/XilinxProjects/Dummy1/Dummy1.ise -intstyle ise -p xc3s400-pq208-4
-cm
balanced -detail -ignore_keep_hierarchy -pr b -k 4 -c 100 -bp -o
c_map.ncd c.ngd
c.pcf
Target Device  : xc3s400
Target Package : pq208
Target Speed   : -4
Mapper Version : spartan3 -- $Revision: 1.34.32.1 $
Mapped Date    : Wed Aug 09 16:00:49 2006

Design Summary
--------------
Number of errors:      0
Number of warnings:    1
Logic Utilization:
  Number of Slice Flip Flops:           7 out of   7,168    1%
  Number of 4 input LUTs:               7 out of   7,168    1%
Logic Distribution:
  Number of occupied Slices:                            5 out of
3,584    1%
    Number of Slices containing only related logic:       5 out of
 5  100%
    Number of Slices containing unrelated logic:          0 out of
 5    0%
      *See NOTES below for an explanation of the effects of unrelated
logic
Total Number of 4 input LUTs:           7 out of   7,168    1%
  Number of bonded IOBs:                3 out of     141    2%
  Number of GCLKs:                     1 out of       8   12%

Total equivalent gate count for design:  101
Additional JTAG gate count for IOBs:  144
Peak Memory Usage:  138 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 and Partition Summary
Section 10 - Modular Design Summary
Section 11 - Timing Report
Section 12 - Configuration String Information

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

Section 2 - Warnings
--------------------
WARNING:LIT:243 - Logical network N9 has no load.

Section 3 - Informational
-------------------------
INFO:MapLib:562 - No environment variables are currently set.
INFO:MapLib:535 - The following Virtex BUFG(s) is/are being retargetted
to
   Virtex2 BUFGMUX(s) with input tied to I0 and Select pin tied to
constant 0:
   BUFG symbol "internalclock" (output signal=i_clk)
INFO:MapLib:331 - Block RAM optimization summary:
INFO:MapLib:333 - No optimization performed

Section 4 - Removed Logic Summary
---------------------------------
   1 block(s) removed
   1 block(s) optimized away
   1 signal(s) removed
   1 Block(s) redundant

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

The trimmed logic report below shows the logic removed from your design
due to
sourceless or loadless signals, and VCC or ground connections.  If the
removal
of a signal or symbol results in the subsequent removal of an
additional signal
or symbol, the message explaining that second removal will be indented.
 This
indentation will be repeated as a chain of related logic is removed.

To quickly locate the original cause for the removal of a chain of
logic, look
above the place where that logic is listed in the trimming report, then
locate
the lines that are least indented (begin at the leftmost edge).

The signal "N9" is loadless and has been removed.
 Loadless block "XST_GND" (ZERO) removed.

Optimized Block(s):
TYPE 		BLOCK
VCC 		XST_VCC

Redundant Block(s):
TYPE 		BLOCK
LOCALBUF 		Mcount_aaaa_cy<3>11/LUT4_D_BUF

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

+------------------------------------------------------------------------------------------------------------------------+
| IOB Name                           | Type    | Direction | IO
Standard | Drive    | Slew | Reg (s)  | Resistor | IOB   |
|                                    |         |           |
 | Strength | Rate |          |          | Delay |
+------------------------------------------------------------------------------------------------------------------------+
| clk                                | IOB     | INPUT     | LVCMOS33
 |          |      |          |          |       |
| q                                  | IOB     | OUTPUT    | LVCMOS33
 | 12       | FAST |          |          |       |
| sys_clk_out                        | IOB     | OUTPUT    | LVCMOS33
 | 12       | FAST |          |          |       |
+------------------------------------------------------------------------------------------------------------------------+

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

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

Section 9 - Area Group and Partition Summary
--------------------------------------------

Partition Implementation Status
-------------------------------

  No Partitions were found in this design.

-------------------------------

Area Group Information
----------------------

  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
-----------------------------------------
BUFGMUX "internalclock": Configuration String is:
   "DISABLE_ATTR:LOW I0_USED:0 SINV:S_B"

-----------------END OF MAP REPORT ------------------------------
------------------PAR REPORT--------------------------------------
Release 8.2.01i par I.32
Copyright (c) 1995-2006 Xilinx, Inc.  All rights reserved.

JOZSEF::  Wed Aug 09 16:00:57 2006

par -w -intstyle ise -ol std -t 1 c_map.ncd c.ncd c.pcf


Constraints file: c.pcf.
Loading device for application Rf_Device from file '3s400.nph' in
environment C:\Xilinx.
   "c" is an NCD, version 3.1, device xc3s400, package pq208, speed -4

Initializing temperature to 85.000 Celsius. (default - Range: 0.000 to
85.000 Celsius)
Initializing voltage to 1.140 Volts. (default - Range: 1.140 to 1.260
Volts)

INFO:Par:282 - No user timing constraints were detected or you have set
the option to ignore timing constraints ("par
   -x"). Place and Route will run in "Performance Evaluation Mode" to
automatically improve the performance of all
   internal clocks in this design. The PAR timing summary will list the
performance achieved for each clock. Note: For
   the fastest runtime, set the effort level to "std".  For best
performance, set the effort level to "high". For a
   balance between the fastest runtime and best performance, set the
effort level to "med".

Device speed data version:  "PRODUCTION 1.39 2006-06-02".


Device Utilization Summary:

   Number of BUFGMUXs                  1 out of 8      12%
   Number of External IOBs             3 out of 141     2%
      Number of LOCed IOBs             3 out of 3     100%

   Number of Slices                    5 out of 3584    1%
      Number of SLICEMs                0 out of 1792    0%



Overall effort level (-ol):   Standard
Placer effort level (-pl):    High
Placer cost table entry (-t): 1
Router effort level (-rl):    Standard


Starting Placer

Phase 1.1
Phase 1.1 (Checksum:98969a) REAL time: 4 secs

Phase 2.7
Phase 2.7 (Checksum:1312cfe) REAL time: 5 secs

Phase 3.31
Phase 3.31 (Checksum:1c9c37d) REAL time: 5 secs

Phase 4.2
.


Phase 4.2 (Checksum:26259fc) REAL time: 8 secs

Phase 5.8
.
.
.
.
.
Phase 5.8 (Checksum:98c4fb) REAL time: 8 secs

Phase 6.5
Phase 6.5 (Checksum:39386fa) REAL time: 8 secs

Phase 7.18
Phase 7.18 (Checksum:42c1d79) REAL time: 8 secs

Phase 8.5
Phase 8.5 (Checksum:4c4b3f8) REAL time: 8 secs

Writing design to file c.ncd


Total REAL time to Placer completion: 8 secs
Total CPU time to Placer completion: 6 secs

Starting Router

Phase 1: 33 unrouted;       REAL time: 8 secs

Phase 2: 27 unrouted;       REAL time: 8 secs

Phase 3: 6 unrouted;       REAL time: 9 secs

Phase 4: 6 unrouted; (197)      REAL time: 9 secs

Phase 5: 10 unrouted; (0)      REAL time: 9 secs

Phase 6: 0 unrouted; (0)      REAL time: 9 secs

Phase 7: 0 unrouted; (0)      REAL time: 9 secs


Total REAL time to Router completion: 9 secs
Total CPU time to Router completion: 6 secs

Partition Implementation Status
-------------------------------

  No Partitions were found in this design.

-------------------------------

Generating "PAR" statistics.

**************************
Generating Clock Report
**************************

+---------------------+--------------+------+------+------------+-------------+
|        Clock Net    |   Resource   |Locked|Fanout|Net Skew(ns)|Max
Delay(ns)|
+---------------------+--------------+------+------+------------+-------------+
|               i_clk |      BUFGMUX2| No   |    5 |  0.000     |
1.034      |
+---------------------+--------------+------+------+------------+-------------+

* Net Skew is the difference between the minimum and maximum routing
only delays for the net. Note this is different from Clock Skew which
is reported in TRCE timing report. Clock Skew is the difference between
the minimum and maximum path delays which includes logic delays.


   The Delay Summary Report


The NUMBER OF SIGNALS NOT COMPLETELY ROUTED for this design is: 0

   The AVERAGE CONNECTION DELAY for this design is:        0.772
   The MAXIMUM PIN DELAY IS:                               4.295
   The AVERAGE CONNECTION DELAY on the 10 WORST NETS is:   1.116

   Listing Pin Delays by value: (nsec)

    d < 1.00   < d < 2.00  < d < 3.00  < d < 4.00  < d < 5.00  d >=
5.00
   ---------   ---------   ---------   ---------   ---------
---------
          24           6           0           0           1
0

Timing Score: 0

Asterisk (*) preceding a constraint indicates it was not met.
   This may be due to a setup or hold violation.

------------------------------------------------------------------------------------------------------
  Constraint                                | Requested  | Actual     |
Logic  | Absolute   |Number of
                                            |            |            |
Levels | Slack      |errors
------------------------------------------------------------------------------------------------------
  Autotimespec constraint for clock net i_c | N/A        | 2.842ns    |
2      | N/A        | N/A
  lk                                        |            |            |
       |            |
------------------------------------------------------------------------------------------------------


All constraints were met.
INFO:Timing:2761 - N/A entries in the Constraints list may indicate
that the
   constraint does not cover any paths or that it has no requested
value.


Generating Pad Report.

All signals are completely routed.

Total REAL time to PAR completion: 10 secs
Total CPU time to PAR completion: 7 secs

Peak Memory Usage:  126 MB

Placement: Completed - No errors found.
Routing: Completed - No errors found.

Number of error messages: 0
Number of warning messages: 0
Number of info messages: 1

Writing design to file c.ncd



PAR done!
---------------------END OF PAR REPORT---------------------------



Aurelian Lazarut wrote:
> or better, just add a BUFG in between and make sure you'll use a
> dedicated clock pin for this input.
> Aurash
>
> Aurelian Lazarut wrote:
>
> > Jozsef,
> > after 30 hours of debuging this wire maybe you should rest. After
> > taking a nap, please check map report for trimmed signals, or post
> > some files/reports/error messages to see how we can help you.
> > Aurash
> >
> > Jozsef wrote:
> >
> >> Hi,
> >>
> >> I'm confused over two days for the sollution of the next problem:
> >>
> >> environment:
> >> software : WP8.1.03i & WP8.2.01i (tried with both)
> >> HW: XC3S400PQG208
> >>
> >> I have a board which requires some clock forwarding. Input and output
> >> locations are constrained, input clock located at P76 and output
> >> located at
> >> P165. The problem is with the forwarding. I've tried with DCM, or a
> >> simple
> >>
> >> out<=input;
> >>
> >> row in the source, but the clock haven't found on output pin (inspected
> >> with
> >> oscilloscope). Unfortunately, Xilinx's webcase page is unreachable by
> >> several reasons.
> >>
> >> And the reason why I think this to software bug: forwarding works at
> >> yesterday for several synthesizing & config stram generation cycle
> >> after 30
> >> hours hard error finding. I don't know, how...  But I've confused, when
> >> I
> >> added a simple counter to testing the sychronous network inside the
> >> FPGA.
> >> Counter wouldn't want to work. I've catched some warnings on the .ncd
> >> or
> >> .ngd file from the PAR process (maybe corrupt?), I haven't remember,
> >> sorry:-/    This occoured to cleanup project files, and after, the
> >> forwarding isn't works :(((
> >>
> >> best regards
> >>
> >>
> >>
> >
> >
>
>
> --
>  __
> / /\/\ Aurelian Lazarut
> \ \  / System Verification Engineer
> / /  \ Xilinx Ireland
> \_\/\/
>  
> phone:	353 01 4032639
> fax:	353 01 4640324


Article: 106224
Subject: Re: ISE software bug???
From: "Jozsef" <bit_vector@tvn.hu>
Date: 9 Aug 2006 07:38:34 -0700
Links: << >>  << T >>  << A >>

oops,
c.vhd incorrect in my last post.

the correct c.vhd is:

---------- c.vhd ------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
library UNISIM;
use UNISIM.VComponents.all;

entity c is
    Port ( clk : in  STD_LOGIC;
	        sys_clk_out: out std_logic;
           q : out  STD_LOGIC
          );
end c;

architecture Behavioral of c is
signal aaaa : std_logic_vector(6 downto 0);
signal i_clk: std_logic;
component BUFG
    port (I: in  STD_LOGIC;
          O: out STD_LOGIC);
end component;
begin
  internalclock: bufg port map(clk,i_clk);
  process(i_clk)
  begin
    if rising_edge(i_clk) then
	   aaaa<=aaaa+"0000001";
	 end if;
  end process;
	Sys_Clk_out<=clk;
	q<=aaaa(6);
end Behavioral;

----------end of c.vhd---------------




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