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 73125

Article: 73125
Subject: Re: Virtex 4 released today
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 14 Sep 2004 10:15:01 -0700
Links: << >>  << T >>  << A >>
Antti,

The MGT's are designed to address the same standards as V2 Pro and V2 Pro X.

That said, the ppm frequency shift of SATA when using spread spectrum 
clocking (0 to -5000 ppm)is not addressed.

Austin

Antti Lukats wrote:
> "Austin Lesea" <austin@xilinx.com> wrote in message
> news:ci4p3r$imf1@cliff.xsj.xilinx.com...
> 
>>All,
>>
>>As Peter would say, the teasing is over:  V4 is ALIVE.
>>
>>http://www.xilinx.com for all of the details.
>>
>>Now I can finally talk about it.
>>
>>Austin
> 
> 
> Any ideas if the V2 rocket MGTs are any better ?
> int terms of tolerance to lock freq ppm window and to be able to support
> more standards?
> 
> Antti
> 
> 

Article: 73126
Subject: Re: Need some help with some technical claims...
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 14 Sep 2004 10:30:58 -0700
Links: << >>  << T >>  << A >>


Dan K wrote:

> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message

(snip)

> A while back I was deposed for a patent infringement law suit.
 >   The opposition lawyer were trying to prove that my
 > "hardware search engine"  built in an FPGA was really a
 > "software search engine"  because anything in an FPGA was
> really software.  Don't know how that one turned out as I'm no
 >  longer with that company,

> but:  Lawyers - ya gotta love em!

In the days when software wasn't patentable and hardware was,
the distinction was important.   There were stories about the
patent for virtual memory, being both hardware and software
and the problems trying to patent it.

Yes, the distinction is only important to lawyers.

-- glen


Article: 73127
Subject: Re: spartan-3 I/O timing
From: "Channing Wen" <channing@pldsupport.com>
Date: Wed, 15 Sep 2004 01:33:31 +0800
Links: << >>  << T >>  << A >>
Is seems the TIOPI only 1.20 - 0.31 = 0.89ns for LVTTL input described in
SP-3 datasheet v1.3, and the TIOOP for LVTTL F12 is 3.42-0.12 = 3.2ns.


"Robert Sefton" <rsefton@abc.net> дʼ
news:2qn4qtF111ef9U1@uni-berlin.de...
> Can someone explain this to me?
>
> Here's the LVTTL I/O timing for Virtex-2 -4 and Spartan-3 -4 (Fast 12mA
> drive for the outputs):
>
>                 Virtex-2    Spartan-3
>                 --------     ----------
> TIOPI       0.88ns        2.15ns   (pad to IOB .I output)
> TIOOP     1.74ns         0.48ns  (IOB ,O input to pad)
>
> According to these numbers the Spartan-3 input buffer got 1.27ns slower
and
> the output buffer got 1.26ns faster. Is this possible?
>
> I have a Virtex-2 1000 design that fits perfectly in a Spartan-3 1000, but
I
> just routed it and got a ton of input path timing errors. So much for
saving
> $125 per chip with S3.
>
> Thanks,
> Rob
> (email is bogus, please reply to group)
>
>



Article: 73128
Subject: Re: spartan-3 I/O timing
From: "Robert Sefton" <rsefton@abc.net>
Date: Tue, 14 Sep 2004 10:53:59 -0700
Links: << >>  << T >>  << A >>
"Channing Wen" <channing@pldsupport.com> wrote in message 
news:ci7a1g$1o0i$1@mail.cn99.com...
> Is seems the TIOPI only 1.20 - 0.31 = 0.89ns for LVTTL input described in
> SP-3 datasheet v1.3, and the TIOOP for LVTTL F12 is 3.42-0.12 = 3.2ns.
>

Channing -

Are you looking at Tables 16 and 17 for the input delay and Tables 18 and 20 
for the output delay? I still get 2.15ns for the input delay (1.94 + 0.21), 
but I had the output delay wrong. 0.48ns is just the correction factor for 
LVTTL F12. The complete output delay is 1.46 - 0.48 = 0.98ns. Where did you 
get your numbers?

Thanks,
Rob





Article: 73129
Subject: Re: spartan-3 I/O timing
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Tue, 14 Sep 2004 10:54:31 -0700
Links: << >>  << T >>  << A >>

"Robert Sefton" <rsefton@abc.net> wrote in message
news:2qn4qtF111ef9U1@uni-berlin.de...
> Can someone explain this to me?
>
> Here's the LVTTL I/O timing for Virtex-2 -4 and Spartan-3 -4 (Fast 12mA
> drive for the outputs):
>
>                 Virtex-2    Spartan-3
>                 --------     ----------
> TIOPI       0.88ns        2.15ns   (pad to IOB .I output)
> TIOOP     1.74ns         0.48ns  (IOB ,O input to pad)
>
> According to these numbers the Spartan-3 input buffer got 1.27ns slower
and
> the output buffer got 1.26ns faster. Is this possible?
>
> I have a Virtex-2 1000 design that fits perfectly in a Spartan-3 1000, but
I
> just routed it and got a ton of input path timing errors. So much for
saving
> $125 per chip with S3.

Do you know which version of the speeds file you are using?  It should be
listed in the timing report.  Alternately, you can type the following on the
command line or in a DOS box.

   speedprint 3s1000 > timing.txt

The "version id" is listed toward the top of the file.  You want v1.32 or
later.  The numbers in your posting don't seem to match up completely with
the v1.32 speeds file or the Spartan-3 data sheet, even with the relevant
adjustments to LVTTL.  Here are the values from the Spartan-3 data sheet.
http://www.xilinx.com/bvdocs/publications/ds099-3.pdf

Tiopi = 1.94 ns (measured for LVCMOS, 2.5V, 12 mA output drive, Fast slew
rate)
LVTTL input adjustment = 0.21 ns
Tiopi (LVTLL) = 1.94 + 0.21 = 2.15 ns

Tioop = 1.46 ns
LVTTL output adjustment = 0.48 ns
Tioop (LVTTL) = 1.46 + 0.48 = 1.94 ns

There is a physical reason for some I/O timing differences between Virtex-II
and Spartan-3.  Spartan-3 uses lower cost wire-bonded packages and has a
dual I/O ring.

What is the nature of you input path timing errors?  What timing do you
need?  Perhaps there is a relatively easy work-around.  The Digital Clock
Managers (DCMs) on a Spartan-3 FPGA allow you to adjust I/O timing if you
have a monotonic clock.  If the clock is not monotonic, you can also use a
technique that Xilinx calls "local clocking".  We use this on a number of
high-speed memory interfaces.

"Saving $125 per chip with S3", I hope, justifies a little further analysis.
;-)
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3:  Make it Your ASIC





Article: 73130
Subject: Re: Xilinx EDK and plb master
From: Paul Hartke <phartke@Stanford.EDU>
Date: Tue, 14 Sep 2004 11:13:29 -0700
Links: << >>  << T >>  << A >>
I'll suggest again the latest EDK service pack.  Paul

Mancini Stephane wrote:
> 
> Thanks a lot,
> Yes but my version allow me only to have PLB slave.
> What I'm wondering is if the IPIF PLB master is OK despite the fact that
> the EDK IP Import Wizard doesn't have the feature.
> The problem is that it will be long until we have the new version...
> 
> Can I use the IPIF PLB master with EDK 6.2 with no problem ?
> 
> I can hack the slave only version to use a master but it would be easier
> if someone could give me a VHDL wrapper with a single master.
> Thanks a lot for your help.
> 
> Stephane
> 
> On Mon, 13 Sep 2004 11:44:15 -0700, Paul Hartke wrote:
> 
> > Have you considered the EDK IP Import Wizard?
> >
> > I see that you are are not using the latest EDK service pack.  There are
> > more features in this area in EDK 6.2.2
> >
> > EDK 6.3 should be coming out shortly, and I figure there will be more
> > additions in there as well.
> >
> > Paul
> >

Article: 73131
Subject: Xilinx S3 Serial Port Code
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 14 Sep 2004 12:03:44 -0700
Links: << >>  << T >>  << A >>
Hello Every1,

I am looking for VHDL code for a serial port.  Small. Fixed Baud rate.
Perhaps only output, don't know that for sure yet. I look at XAPP699
and started to think that the real code isn't really there, just an IP core
with various wrappers and test benches. Not sure about this.

Could anybody point the way here?

Much obliged,

Brad

b r a d @ a i v i s i o n . c o m



Article: 73132
Subject: Re: spartan-3 I/O timing
From: "Robert Sefton" <rsefton@abc.net>
Date: Tue, 14 Sep 2004 12:08:12 -0700
Links: << >>  << T >>  << A >>
"Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com> wrote in message 
news:ci7b93$9rd1@cliff.xsj.xilinx.com...
>
> Do you know which version of the speeds file you are using?  It should be
> listed in the timing report.  Alternately, you can type the following on 
> the
> command line or in a DOS box.
>
>   speedprint 3s1000 > timing.txt
>
> The "version id" is listed toward the top of the file.  You want v1.32 or
> later.

Steve -

Thanks for the reply. Here's the speed file version from the timing report:

Device,speed:             xc3s1000,-4 (ADVANCED 1.32 2004-06-09)

> The numbers in your posting don't seem to match up completely with
> the v1.32 speeds file or the Spartan-3 data sheet, even with the relevant
> adjustments to LVTTL.  Here are the values from the Spartan-3 data sheet.
> http://www.xilinx.com/bvdocs/publications/ds099-3.pdf
>
> Tiopi = 1.94 ns (measured for LVCMOS, 2.5V, 12 mA output drive, Fast slew
> rate)
> LVTTL input adjustment = 0.21 ns
> Tiopi (LVTLL) = 1.94 + 0.21 = 2.15 ns
>
> Tioop = 1.46 ns
> LVTTL output adjustment = 0.48 ns
> Tioop (LVTTL) = 1.46 + 0.48 = 1.94 ns
>

I was working from the data sheet. I got Tiopi right but butchered Tioop
twice. When I use the tables correctly I get 1.94ns. So the S-3/V-2 (-4)
comparison looks like this now for LVTTL F12:

                Virtex-2    Spartan-3
                --------     ----------
TIOPI       0.88ns        2.15ns   (pad to IOB .I output)
TIOOP     1.74ns         1.94ns  (IOB .O input to pad)

This is a huge hit to take on the input path. My Virtex-2 design interfaces
to a PowerPC and SDRAM on a 66MHz 60X bus, and there's also flash
and a couple of peripherals on the bus. The FPGA is a bus master for SDRAM
DMAs, and the I/O timing for the ciritcal arbitration and control signals is
extremely tight. They can't be registered in the IOB. I'm already using the 
DCM.

> There is a physical reason for some I/O timing differences between 
> Virtex-II
> and Spartan-3.  Spartan-3 uses lower cost wire-bonded packages and has a
> dual I/O ring.
>
> What is the nature of you input path timing errors?  What timing do you
> need?  Perhaps there is a relatively easy work-around.  The Digital Clock
> Managers (DCMs) on a Spartan-3 FPGA allow you to adjust I/O timing if you
> have a monotonic clock.  If the clock is not monotonic, you can also use a
> technique that Xilinx calls "local clocking".  We use this on a number of
> high-speed memory interfaces.
>

Here's one of my input timing constraints:

NET "abb_n_pad" OFFSET = IN 7.1 ns AFTER "clk66_pad"; (7.1ns is the PowerPC 
derated output delay + trace delay + fudge for clock skew)

Here's the result in Virtex-2:

================================================================================
Timing constraint: COMP "abb_n_pad" OFFSET = IN 7.100 nS  AFTER COMP 
"clk66_pad" ;

 50 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold 
errors)
 Maximum allowable offset is   7.380ns.
--------------------------------------------------------------------------------

So Virtex-2 makes the constraint with 280ps margin.

Here's the Spartan-3 result:

================================================================================
Timing constraint: COMP "abb2_n_pad" OFFSET = IN 7.100 nS  AFTER COMP 
"clk66_pad" ;

 13 items analyzed, 7 timing errors detected. (7 setup errors, 0 hold 
errors)
 Maximum allowable offset is   5.637ns.
--------------------------------------------------------------------------------

So the Spartan-3 misses by 7.1 - 5.637 = 1.463ns. That's pretty close to the 
1.27ns
increase in the input buffer delay. The rest is lost in the internal logic, 
which is also slower
in Spartan-3. Here are the internal 66MHz timing results:

Virtex-2:

================================================================================
Timing constraint: TS_clk66_dll_clk0 = PERIOD TIMEGRP "clk66_dll_clk0" 
TS_CLK66 * 1.000000 HIGH
50.000 % ;

 59785 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold 
errors)
 Minimum period is  11.770ns.
--------------------------------------------------------------------------------

Spartan-3:

================================================================================
Timing constraint: TS_clk66_dll_clk0 = PERIOD TIMEGRP "clk66_dll_clk0" 
TS_CLK66 * 1.000000 HIGH
50.000 % ;

 59860 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold 
errors)
 Minimum period is  13.694ns.
--------------------------------------------------------------------------------

So the Spartan-3 is about 15% slower than Virtex-2 internally. I'm pretty 
bummed with
these results. The Spartan-3 pricing is compelling, but just a tease if it 
can't make timing.
And I need the industrial temp range, so I can currently only use -4 parts.

I'm open to any and all ideas, but I can't speed up the PowerPC so Spartan-3 
looks like
a no-go on this one.

Thanks,
Rob







Article: 73133
Subject: Help with Coregen ROM in ISE 6.2.03i
From: jmkerwin@yahoo.com (Jon)
Date: 14 Sep 2004 12:10:08 -0700
Links: << >>  << T >>  << A >>
I'm very new to working with Xilinx tools so I may be overlooking
something obvious.  I'm able to synthesize with XST and simulate using
Modelsim without any problems.  But I am unable to implement my design
because a Coregen ROM generates errors in the translate step.  The
ERROR messages don't seem to be indicative of the problem.  I've tried
referring to the Xilinx online help but it has been most unhelpful. 
Has anyone run into these ERRORS before?

1) ERROR:NgdBuild:76 - File "c:\xilinx\rtc2/ro256x8pre.ngc" cannot be
merged into block "rom0_rom0" (TYPE="ro256x8pre") because one or more
pins on the block, including pin "CLK", were not found in the file. 
Please make sure that all pins on the instantiated component match
pins in the lower-level design block (irrespective of case).  If there
are bussed pins on this block, make sure that the upper-level and
lower-level netlists use the same bus-naming convention.

The Xilinx Answer Record #14848 says to change the bus delimiter style
of the synthesis tool to match the bus macro style.  But they already
agree, so I shouldn't have to change anything.  Also, I've made sure
that all port names match.

2) ERROR:NgdBuild:604 - logical block 'rom0_rom0' with type
'ro256x8pre' could not be resolved. A pin name misspelling can cause
this, a missing edif or ngc file, or the misspelling of a type name.
Symbol 'ro256x8pre' is not supported in target 'virtex2'.

This one has me at a loss.  These files are auto-generated by Coregen
so it leaves very little room (or so I thought) for me to screw things
up.  Any help would be greatly appreciated.

thanks,
Jon

Article: 73134
Subject: Re: Xilinx S3 Serial Port Code
From: Shalin Sheth <Shalin.Sheth@xilinx.com>
Date: Tue, 14 Sep 2004 12:23:01 -0700
Links: << >>  << T >>  << A >>
Brad,

The PicoBlaze reference design comes with VHDL code to implement a 
serial port.  You can download the PicoBlaze design with the serial port 
code after registering at:

http://www.xilinx.com/picoblaze

Cheers,
Shalin-

Brad Smallridge wrote:
> Hello Every1,
> 
> I am looking for VHDL code for a serial port.  Small. Fixed Baud rate.
> Perhaps only output, don't know that for sure yet. I look at XAPP699
> and started to think that the real code isn't really there, just an IP core
> with various wrappers and test benches. Not sure about this.
> 
> Could anybody point the way here?
> 
> Much obliged,
> 
> Brad
> 
> b r a d @ a i v i s i o n . c o m
> 
> 


Article: 73135
Subject: Re: AHB-Slave
From: Joe <joe_y@invalid_address.nospam.com>
Date: Tue, 14 Sep 2004 20:38:30 +0100
Links: << >>  << T >>  << A >>
mack wrote:

> Hi,
>   When the current AHB slave is busy (hready low) servicing the
> Master,but if the master drives IDLE transfer in the next cycle , then
> according to the protocol slave should give a zero wait state OKAY
> response,but by seeing the hready high for this IDLE response ,master
> will drive it's address and data.Later the slave will drive hready for
> the pending(previous transfer) service.This is malfuntion the current
> transfer...so it is alwayas nessacary to give a zero wait state OKAY
> response for an IDLE transfer??
> 
> Regards,
> M.M.Kumar

Hi there,

A few things you need to know:
- An AHB slave don't have to worry what is on HTRANS when HREADY is low
- An AHB master should not change HTRANS, HADDR, HWRITE, etc when HREADY 
is low (except when it detected error/retry/split responses).

So for the following waveform is perfectly fine:

           T0      T1      T2      T3     T4     T5
         _______ _____________________________ ______
HADDR   ___A___X___B_________________________X______
         _______ _____________________________ ______
HTRANS  ___2___X___IDLE______________________X______
         _______                       _______  _____
HREADY         \_____________________/       \/     \
         _______                        ______ ______
HRDATA/ _______XXXXXXXXXXXXXXXXXXXXXXXX__A___X______X
HWDATA
         _______ _____________________________ ______
HRESP   ___2___X___OKAY______________________X_OKAY_X


In T0, AHB master issue transfer (note that HREADY is high)
In T1, AHB slave start doing the work (putting HREADY to low)
In T2 and T3, despite HTRANS is IDLE in previous cycle, AHB slaves
can ignore it because HREADY is low.
In T4, AHB slave set HREADY to high, so all AHB slave will have to
check what is on HTRANS, HADDR (also HSEL,HWRITE etc).
In T5, AHB slave output a zero wait state OKAY response for the IDLE in T4.

Hope this answered your question.  In addition, question about AHB might 
be better be posted on comp.sys.arm newsgroup. (I know, you might not be 
using ARM stuffs but I guess more people on that newsgroup can answer 
questions on AMBA stuffs).

Regards,
Joe


Article: 73136
Subject: Re: Xilinx S3 Serial Port Code
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 14 Sep 2004 13:05:34 -0700
Links: << >>  << T >>  << A >>
Yes, that's quite helpful.



Article: 73137
Subject: Xilinx RocketPHY Development Kit (HWK-RPHY-DVLP)
From: onenanometer@yahoo.com (FPGA geek)
Date: 14 Sep 2004 13:09:32 -0700
Links: << >>  << T >>  << A >>
Hello everyone:

I am design engineer and in the process of evaluating the

Xilinx RocketPHY Development Kit (HWK-RPHY-DVLP)
http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HWK-RPHY-DVLP&iLanguageID=1

If anyone has had the opportunity to evaluate this board, can you
please give me some feedback on the designs implemented and the
problems faced.

Thanks for the help.
FPGAgeek

Article: 73138
Subject: EDK OPB Uart 16550
From: wpiman@aol.com (MS)
Date: 14 Sep 2004 13:10:56 -0700
Links: << >>  << T >>  << A >>
We are using the trial version of the OPB Uart 16550 in one of our
designs.  We are running this at 19200,8,N,1, no flow control.  We are
using Hyperterminal- and we are able to access the UART ok for generic
stuff.  Print/scan.

We then run a test where we send a bunch of checksum frames (Srecords)
to the UART and check them on the PPC.  This is done via Hyperterm-
send text file.  The program makes it thru a couple of hundred of
these checksumed Srecords and then reports an error.  Seems a piece of
one of the Srecords gets lost.

We then try the same test with the OPB UART lite and it works
flawlessly.  All the records are reported correctly.

We then tried the same test with another terminal program- Tera Term-
and the problems go away for the 550.  We are able to send the text
file to both the Uart Lite and Uart 550 with no problems.

Has anyone seen anything similar to this?  It seems the 550 and
Hyperterminal do not jive well together.  Very odd.  We want to buy
this core because our OS comes with a 16550 driver- and do not want to
write our own.

Article: 73139
Subject: Re: New to FpGa ; At configuring the device error cmes
From: Neil Glenn Jacobson <n.e.i.l.j.a.c.o.b.s.o.n.a.t.x.i.l.i.n.x.c.o.m.>
Date: Tue, 14 Sep 2004 14:03:32 -0700
Links: << >>  << T >>  << A >>
senthil wrote:
> If the LED is NOT green on your 4 then you have not 
> 
>>powered it correctly.
>>
> 
> 
> Hi ..
> I plugged the cable correctly. . the led also blown ie., power came up
> from the usb port.. 

I suppose you mean parallel port?  If not - that's your problem :-)

> all things i made perfectly. but i didn't detect
> the fpga..

What does "the led also blown" mean?

> 
> give some suggestion..

Is you BIOS setting for your parallel port set to "ECP"?

> 
> Regards
> Senthil.R


-- 

     You've *read the email* - now *buy the book*


Article: 73140
Subject: Re: Virtex 4 released today
From: "IgI" <igorsath@hotmail.com>
Date: Tue, 14 Sep 2004 23:03:57 +0200
Links: << >>  << T >>  << A >>
Hi!

A Xilinx representative came today to the company where I work and he had a
short but very informative Virtex4 presentation. What I find very useful is
that Xilinx finally put a FIFO control logic on BRAMs and significantly
increase their performance. Feature to cascade FIFOs will also be very
useful for me. I was also hoping to see a 256 deep and 64bit wide BRAMs, but
I guess we'll have to wait for that feature for a while?

Several times in the past I bumped into the 8 global clocks limitation on
Virtex II. That's why I was very exited to hear that I can use up to 32
global clocks, but after reading the Virtex 4 User's guide (page 21) my
excitement cooled down a bit. There is a statement: "However, only eight
different clocks can be driven in a single clock region. A clock region is a
branch of the clock tree consisting of eight CLB rows up and eight CLB rows
down. A clock region only spans halfway across the device."
If I understand this correctly, there is still a limitation of 8 global
clocks per device, that means max. of 8 different and completely unrelated
clocks can be used in all regions of the chip? Please, tell me I'm wrong? ;)

While further reading documentation, I found there are several new variable
phase-shifting modes available. What's got me worried (about my last
Virtex-II design) is the following sentence: "Using the variable-positive
and variable-center modes the phase can be dynamically and repetitively
moved forward and backwards by 1/256 of the clock period.". In my last
Virtex-II design I used 2 variable phase shifted clocks and I'm adjusting
the phase dynamically all the time. So far the design is working, but can I
expect for example that after one million adjustments (for the sake of
simplicity let's say each adjustment increases the phase for 100 steps and
then decreases the phase for the same amount of steps) the clock phase will
still be 0. I know there are many parameters that can have influence on the
stability of phase adjusted clock, but have you measured how repetitively
accurate is fine phase adjustment in Virtex-II compared to Virtex-4?

I believe most of the new features will be very useful, just bring us the
productions chips (not ES) as soon as possible, so we won't have to wait too
long as it was the case with Virtex-II.

I will probably come up with some new questions tomorrow, because I first
have to go over the docs/app notes I downloaded today...

Regards,
Igor Bizjak


"Austin Lesea" <austin@xilinx.com> wrote in message
news:ci4p3r$imf1@cliff.xsj.xilinx.com...
> All,
>
> As Peter would say, the teasing is over:  V4 is ALIVE.
>
> http://www.xilinx.com for all of the details.
>
> Now I can finally talk about it.
>
> Austin



Article: 73141
Subject: Re: Adding a Delay2
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Tue, 14 Sep 2004 16:11:19 -0500
Links: << >>  << T >>  << A >>


Victor Schutte wrote:

>Adding 800ns is quite heavy, possibly done with a counter 800ns/ 20ns period
>after which the signal is asserted. The same can be done for 80ns (only 4
>periods).
>
>The compilers are usually intelligent when it comes to optimizing. You add
>more time wasting gates and it removes it to increase speed. The one option
>is to route a signal to a pin and back through another but that is usually
>ineffective and ugly, and ony adds a few ns to the signal.
>  
>
I used a version of this in a CPLD application where there was no continuous
frequency clock.  I put a 5.1 K resistor between an output pin and an input
pin, using the parasitic capacitance of the input pin as the C for the 
RC delay.
This worked quite well to clock a counter after the removal of a bus strobe
signal.  I doubt you could make this work reliably for 800 ns, but 80 ns 
might
be doable.  For 800 ns, assuming you don't have enough CLBs for the 
requisite
counter, you would need an external one shot or counter.

>  
>
Jon


Article: 73142
Subject: Re: Virtex 4 released today
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 14 Sep 2004 14:30:53 -0700
Links: << >>  << T >>  << A >>
IgI,

See below,

Austin

IgI wrote:
> Hi!
> 
> A Xilinx representative came today to the company where I work and he had a
> short but very informative Virtex4 presentation. What I find very useful is
> that Xilinx finally put a FIFO control logic on BRAMs and significantly
> increase their performance. Feature to cascade FIFOs will also be very
> useful for me. I was also hoping to see a 256 deep and 64bit wide BRAMs, but
> I guess we'll have to wait for that feature for a while?

Yup.  Not his time.  Aside, do we have enough BRAM?
> 

> Several times in the past I bumped into the 8 global clocks limitation on
> Virtex II. That's why I was very exited to hear that I can use up to 32
> global clocks, but after reading the Virtex 4 User's guide (page 21) my
> excitement cooled down a bit. There is a statement: "However, only eight
> different clocks can be driven in a single clock region. A clock region is a
> branch of the clock tree consisting of eight CLB rows up and eight CLB rows
> down. A clock region only spans halfway across the device."
> If I understand this correctly, there is still a limitation of 8 global
> clocks per device, that means max. of 8 different and completely unrelated
> clocks can be used in all regions of the chip? Please, tell me I'm wrong? ;)

Sorry, you are correct.  Eight clocks per region.  I don't understand 
why folks want so many different clocks-- ever heard of synchronous 
design?  Regions are smaller than they used to be (smaller than 
quadrants) so having different clocks for different regions still allows 
a real nightmare of asynchonous clock designs.

That combined with the additional local clocks for IOs gives you even 
more opportunities to cross asynchronous clock domains.........

> 
> While further reading documentation, I found there are several new variable
> phase-shifting modes available. What's got me worried (about my last
> Virtex-II design) is the following sentence: "Using the variable-positive
> and variable-center modes the phase can be dynamically and repetitively
> moved forward and backwards by 1/256 of the clock period.". In my last
> Virtex-II design I used 2 variable phase shifted clocks and I'm adjusting
> the phase dynamically all the time. So far the design is working, but can I
> expect for example that after one million adjustments (for the sake of
> simplicity let's say each adjustment increases the phase for 100 steps and
> then decreases the phase for the same amount of steps) the clock phase will
> still be 0. I know there are many parameters that can have influence on the
> stability of phase adjusted clock, but have you measured how repetitively
> accurate is fine phase adjustment in Virtex-II compared to Virtex-4?

Yes we have.

V4 has even finer steps than V2P, and comes back to the same place +/- 
12 ps.  With V2p it was +/- 25 ps.  Absolute.  You worry about the 
oddest things......the DCM is all digital and a state machine, so it has 
no choice when it comes to where it should be....

One million or one trillion clocks, a flip flop doesn't care, and 
neither does the DCM.

> 
> I believe most of the new features will be very useful, just bring us the
> productions chips (not ES) as soon as possible, so we won't have to wait too
> long as it was the case with Virtex-II.

Virtex II went cleanly into production with no delays.  It was Virtex II 
Pro, and the issue of low K dielectrics that delayed that product 
family.  We don't care to use low-K anymore unless it gets production 
qualified on someone else's dime.

> 
> I will probably come up with some new questions tomorrow, because I first
> have to go over the docs/app notes I downloaded today...

Happy reading!

> 
> Regards,
> Igor Bizjak
> 
> 
> "Austin Lesea" <austin@xilinx.com> wrote in message
> news:ci4p3r$imf1@cliff.xsj.xilinx.com...
> 
>>All,
>>
>>As Peter would say, the teasing is over:  V4 is ALIVE.
>>
>>http://www.xilinx.com for all of the details.
>>
>>Now I can finally talk about it.
>>
>>Austin
> 
> 
> 

Article: 73143
Subject: Synthesis issues in Modelsim 5,7g SE for a simple ROM
From: sridharh@gmail.com (Sridhar Hegde)
Date: 14 Sep 2004 14:36:55 -0700
Links: << >>  << T >>  << A >>
Hi,

I am designing a simple ROM in VHDL and following is the code for
it.Xilinx ISE 6.2i doesn't seem to have any issues synthesizing the
design to a Virtex 2 chip(xc2v4000) or translating/mapping/routing the
design(Implementation process).

When I use the test bench created by HDL bencher to see the results,
in Modelsim, a behavioral simulation shows be proper results but a
post translate simulation or anything beyond that like a Post Map or a
Post place and route simulation show a U on all output pins and
Modelsim gives me a number of warnings about "Unbound components"
shown below..

Im stuck at this design phase and would appreciate any help from the
VHDL gurus out there...Heres the code:-

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

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
--  Uncomment the following lines to use the declarations that are
--  provided for instantiating Xilinx primitive components.
--library UNISIM;
--use UNISIM.VComponents.all;

entity inrom is
    Port ( en 	: in std_logic;
           clk  : in std_logic;
	   dout : out std_logic_vector( 15 downto 0);
	  valid : out std_logic; --valid data is present on output when 1
	  reset : in std_logic
	     );
end inrom;

architecture rtl of inrom is

type array_rom is array (15 downto 0) of std_logic_vector( 15 downto
0);
signal myarray : array_rom;
signal valid_sig:std_logic;
signal dout_sig : std_logic_vector(15 downto 0);
signal clk2: std_logic;

begin



myarray(0) <= x"0000";
myarray(1) <= x"0000";
myarray(2) <= x"0000";
myarray(3) <= x"003C";
myarray(4) <= x"0000";
myarray(5) <= x"0000";
myarray(6) <= x"0064";
myarray(7) <= x"0000";
myarray(8) <= x"0000";
myarray(9) <= x"000A";
myarray(10) <= x"0000";
myarray(11) <= x"0000";
myarray(12) <= x"003C";
myarray(13) <= x"0000";
myarray(14) <= x"0000";
myarray(15) <= x"0064";

process( reset,clk)
variable romvar:natural range 0 to 15;

begin
		if reset = '1' then
			dout_sig <= (others=>'0');
			valid_sig <='0';
			romvar :=0;
	
		elsif (clk'event and clk='1') then 
			if  en='1' then 
			  	dout_sig <= myarray (romvar);
		   		valid_sig<='1';
			        romvar :=romvar + 1;
			else
				dout_sig <= myarray (romvar);
		   		valid_sig<='0';
			end if; 
	        end if;
	end process;
	
dout <= dout_sig;
valid <=valid_sig;
end rtl;
-------------------------------------------------------------------------
Warnings given by Modelsim:

 do inromtbw.ndo 
# ** Warning: (vlib-34) Library already exists at "work".
###### inrom_translate.vhd(443):     );
# WARNING[1]: inrom_translate.vhd(443): No default binding for
component: "x_mux2". (No entity named "x_mux2" was found)
###### inrom_translate.vhd(455):     );
# WARNING[1]: inrom_translate.vhd(455): No default binding for
component: "x_ff". (No entity named "x_ff" was found)
###### inrom_translate.vhd(468):     );
# WARNING[1]: inrom_translate.vhd(468): No default binding for
component: "x_xor2". (No entity named "x_xor2" was found)
###### inrom_translate.vhd(472):     );
# WARNING[1]: inrom_translate.vhd(472): No default binding for
component: "x_zero". (No entity named "x_zero" was found)
###### inrom_translate.vhd(476):     );
# WARNING[1]: inrom_translate.vhd(476): No default binding for
component: "x_one". (No entity named "x_one" was found)
###### inrom_translate.vhd(714):     );
# WARNING[1]: inrom_translate.vhd(714): No default binding for
component: "x_lut2". (No entity named "x_lut2" was found)
###### inrom_translate.vhd(2994):     );
# WARNING[1]: inrom_translate.vhd(2994): No default binding for
component: "x_lut3". (No entity named "x_lut3" was found)
###### inrom_translate.vhd(3128):     );
# WARNING[1]: inrom_translate.vhd(3128): No default binding for
component: "x_lut4". (No entity named "x_lut4" was found)
###### inrom_translate.vhd(3203):     );
# WARNING[1]: inrom_translate.vhd(3203): No default binding for
component: "x_or2". (No entity named "x_or2" was found)
###### inrom_translate.vhd(3341):     );
# WARNING[1]: inrom_translate.vhd(3341): No default binding for
component: "x_tri". (No entity named "x_tri" was found)
###### inrom_translate.vhd(3450):     );
# WARNING[1]: inrom_translate.vhd(3450): No default binding for
component: "x_inv". (No entity named "x_inv" was found)
###### inrom_translate.vhd(3533):     port map (O => GSR);
# WARNING[1]: inrom_translate.vhd(3533): No default binding for
component: "x_roc". (No entity named "x_roc" was found)
###### inrom_translate.vhd(3535):     port map (O => GTS);
# WARNING[1]: inrom_translate.vhd(3535): No default binding for
component: "x_toc". (No entity named "x_toc" was found)
# vsim -lib work -t 1ps inromtbw 
# Loading C:/Modeltech_5.7g/win32/../std.standard
# Loading C:/Modeltech_5.7g/win32/../ieee.std_logic_1164(body)
# Loading C:/Modeltech_5.7g/win32/../ieee.std_logic_arith(body)
# Loading C:/Modeltech_5.7g/win32/../std.textio(body)
# Loading C:/Modeltech_5.7g/win32/../ieee.std_logic_textio(body)
# Loading C:/Modeltech_5.7g/win32/../vital2000.vital_timing(body)
# Loading C:\Xilinx6\vhdl\mti_se\simprim.vcomponents
# Loading C:/Modeltech_5.7g/win32/../vital2000.vital_primitives(body)
# Loading C:\Xilinx6\vhdl\mti_se\simprim.vpackage(body)
# Loading work.inromtbw(testbench_arch)
# Loading work.inrom(structure)
# ** Warning: (vsim-3473) Component 'romvar_madd_n0000_inst_cy_5_0' is
not bound.
#    Time: 0 ps  Iteration: 0  Region: /inromtbw/uut  File:
inrom_translate.vhd
# ** Warning: (vsim-3473) Component 'valid_sig_1' is not bound.
#    Time: 0 ps  Iteration: 0  Region: /inromtbw/uut  File:
inrom_translate.vhd
# ** Warning: (vsim-3473) Component 'mmux_n0001_inst_mux_f5_130' is
not bound.


I can not use a Core generated ROM for this design due to some
restrictions I have in my other codes..Sorry for a rather long mail
and thanks in advance for any help!!

Article: 73144
Subject: constraints coverage
From: "Brannon King" <bking@starbridgesystems.com>
Date: 14 Sep 2004 17:47:17 EDT
Links: << >>  << T >>  << A >>
Once upon a time I saw a number that told me what percentage of my project 
was unconstrained. I can't seem to get TRCE (Xilinx ISE) to show me that 
number again. Can someone point me in the right direction?

-- 
Prepend a 'b' to email me. Thanks. 



Article: 73145
Subject: Re: Virtex 4 released today
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 14 Sep 2004 17:12:49 -0500
Links: << >>  << T >>  << A >>
>Sorry, you are correct.  Eight clocks per region.  I don't understand 
>why folks want so many different clocks-- ever heard of synchronous 
>design?  Regions are smaller than they used to be (smaller than 
>quadrants) so having different clocks for different regions still allows 
>a real nightmare of asynchonous clock designs.
>
>That combined with the additional local clocks for IOs gives you even 
>more opportunities to cross asynchronous clock domains.........

How good is current software at identifying signals/paths that
cross clock domains?

It seems as though there should be some mechanism where you can
tag a signal as asynchronous and/or tag the first FF as a synchronizer
and specify how much extra time you need.  Anything that crosses clock
domains without being tagged should get flagged as an error.
(Or something like that.)

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 73146
Subject: Re: Virtex 4 released today
From: jon@beniston.com (Jon Beniston)
Date: 14 Sep 2004 15:16:20 -0700
Links: << >>  << T >>  << A >>
> I think it's better that I answer that.
> MicroBlaze will run about 185 MHz in speedgrade -12.
> With the new architecture Virtex4, I will need to create a different 
> aspect ratio on the RPM block since this architecture is smaller and higher.
> VII and V2Pro was more rectangular in the shape.
> With the new floorplan I achieves 165 MHz in -11 and this will give us 
> around 185 MHz in -12.

So that's only 10% faster that a vIIp then?

Don't get me wrong, a 185 MHz CPU is pretty fantasic, it just doesn't
seem that the v4 is giving it that much of a kick.
 
Cheers,
JonB

Article: 73147
Subject: Re: Virtex 4 released today
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 14 Sep 2004 15:20:27 -0700
Links: << >>  << T >>  << A >>

"Austin Lesea" <austin@xilinx.com> wrote in message
news:ci7nuk$imf5@cliff.xsj.xilinx.com...
> IgI,
>
> > Several times in the past I bumped into the 8 global clocks limitation
on
> > Virtex II. That's why I was very exited to hear that I can use up to 32
> > global clocks, but after reading the Virtex 4 User's guide (page 21) my
> > excitement cooled down a bit. There is a statement: "However, only eight
> > different clocks can be driven in a single clock region. A clock region
is a
> > branch of the clock tree consisting of eight CLB rows up and eight CLB
rows
> > down. A clock region only spans halfway across the device."
> > If I understand this correctly, there is still a limitation of 8 global
> > clocks per device, that means max. of 8 different and completely
unrelated
> > clocks can be used in all regions of the chip? Please, tell me I'm
wrong? ;)
>
> Sorry, you are correct.  Eight clocks per region.  I don't understand
> why folks want so many different clocks-- ever heard of synchronous
> design?  Regions are smaller than they used to be (smaller than
> quadrants) so having different clocks for different regions still allows
> a real nightmare of asynchonous clock designs.
>
> That combined with the additional local clocks for IOs gives you even
> more opportunities to cross asynchronous clock domains.........
>
Indeed, when I saw that there are 32 global clocks in V4, my heart sank.
Unlike Igor, I'm sick and tired of fixing shoddy designs that are the result
of inexperienced designers throwing as many clocks as possible at their
designs. Go synchronous, young man!
Cheers, Syms.



Article: 73148
Subject: Re: EDK OPB Uart 16550
From: Mark McDougall <msmcdoug@no.spam.iinet>
Date: Wed, 15 Sep 2004 08:27:38 +1000
Links: << >>  << T >>  << A >>
MS wrote:

> Has anyone seen anything similar to this?  It seems the 550 and
> Hyperterminal do not jive well together.  Very odd.  We want to buy
> this core because our OS comes with a 16550 driver- and do not want to
> write our own.

IMHO Hyperterm is an absolute piece of garbage! I've had no end of troubles 
over the years with it on various different applications, usually involving 
flow control but also dropped chars etc.

For years, the 'standard' test I used for serial comms was the DOS-based 
Telix. These days I find Tera Term Pro does the job quite well. More 
recently I've used PuTTY, but haven't used it extensively.

If I were you, I'd try 1 or 2 *other* terminal programs (is a DOS-based one 
pratical just for the sake of piece-of-mind testing, or even Minicom on 
Linux?) and if none of those have problems, curse Micro$oft and vow never to 
touch Hyperterm again!

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|         <http://to be announced>           |   with less resistance!"

Article: 73149
Subject: Re: Xpower - Clock Power
From: mukesh.chugh@gmail.com (Mukesh Chugh)
Date: 14 Sep 2004 15:57:45 -0700
Links: << >>  << T >>  << A >>
Hi Brendon,

Thanks Brendon for the response.
Yes, I am using 6.2.03i of xpower. Can I get web updates? Also, do we
need to get update for xpower alone or we have to get for complete
ISE. I also saw on xilinx web site that ISE 6.3i is released too on
9/13. Pls clarify what all i need to upgrade if I have ISE 6.2 and
xpower 6.2.03i

--
Mukesh

Brendan Cullen <bcullen@xilinx.com> wrote in message news:<41404E30.47F20BF8@xilinx.com>...
> 
> This does indeed look similar to another problem which we've been working
> on.  We have a fix for that problem (the one we've been working on) and
> the fix will be available in the next service pack - 6.3.01i  - which
> should be available to you next week.  However, you might be experiencing
> a diferent symptiom.  One option would be for you to zip up the NCD & VCD
> file and send them to us ?  Or are they huge ?  The other option is for
> you to try the service pack next week.  Note - in order for you to use
> 6.3.01i you'll need to have the underlying 6.3i.  (From your other e-mail
> to the newsgroup it appears you are using 6.2.03i.)
> 
> Brendan



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