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 73150

Article: 73150
Subject: Re: spartan-3 I/O timing
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 14 Sep 2004 23:11:25 GMT
Links: << >>  << T >>  << A >>
"Robert Sefton" <rsefton@abc.net> wrote in message
news:2qott4F12cbadU1@uni-berlin.de...

[snip]

> 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

My 133MHz PowerPC interface hasn't been in a Spartan-3 yet but was readily
implemented in the Spartan-IIE.  Being the second of 2 masters interfacing
to a bridge (the first is the processor), the timing was aggressive
considering the complexity in a qualified bus grant.  To get around the need
to come in, go through logic, and go out with only one register in the path,
I leveraged the FDSE primitives in the IOBs to turn the tristates on and off
with the exceptionally low delays.  I had the advantage of DMAs going only
into the chip - I'm thinking DMAs back out would be troublesome for the 133
MHz speeds.

A reconfiguration of the interface might get your bus control to behave much
better with the Spartan-3 I/O timings.

Another trick that I've used... if delaying the clock would help but the DCM
is unavailable, add another clock buffer in the clock path.  Controlling the
routing to the same or opposite sides of the chip will give slightly
different times.  Since routing delays tend to track faster/slower with the
rest of the chip, I wasn't too concerned about just "adding delays" to
improve my timing.



Article: 73151
Subject: Re: Xilinx Xpower Issues - Help from xilinx team please
From: mukesh.chugh@gmail.com (Mukesh Chugh)
Date: 14 Sep 2004 16:38:42 -0700
Links: << >>  << T >>  << A >>
"Arthur" <arthuryang42spam@yahoo.com> wrote in message news:<chlf2p$rdm@odak26.prod.google.com>...
> Mukesh,
> 
> Try running 'clean up project files' from ISE then delete any .XML
> files that may be remaining in that project directory. The .XML file
> contains toggle and frequency data and can conflict with the VCD
> simulation file if they don't happen to target the same device. (For
> example, you target a Spartan-IIe then save the settings file and then
> retarget to Virtex-II and accidentally load the .XML file for the
> Spartan-IIe design)
> 
> If that doesn't help, send the design into Xilinx for analysis. They
> can take a look at it and let you know what the problem is.
> Regards,
> Arthur

Hi Arthur,

Thanks for the response,
I tried cleaning up as per your suggestion but that didnt help. 

--
Mukesh

Article: 73152
Subject: Re: Virtex 4 released today
From: Vic Vadi <vic.vadi@xilinx.com>
Date: Tue, 14 Sep 2004 16:49:44 -0700
Links: << >>  << T >>  << A >>


>
> > 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? ;)

Actually you are wrong. Virtex 4 has several different clock regions.
An LX25 for example has 12 different clock regions. Each of those
12 clock regions can only get 8 global clocks, but those 8 clocks
in each of those 12 regions can come from any of the 32
global clock buffers. Plus you also get 2 regional clocks in each
clock region for Source-Synchronous type applications.

Enjoy,
- Vic



Article: 73153
Subject: Re: Virtex 4 released today
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 14 Sep 2004 16:52:17 -0700
Links: << >>  << T >>  << A >>

Austin Lesea wrote:

(snip regarding 32 global clocks in four regions)

> 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.

A large number of clocks doesn't preclude a synchronous design, but
I have to agree that more than eight should be pretty unusual.

(There were some designs discussed recently that used multiple
phase clocks, all from the same clock generator.  That could still
qualify as a synchronous design.)

It would be interesting, though, similar to the way register
windows work on the SPARC processor, to have some clock inputs
global across the chip, some overlap in different combinations,
and the rest local to a region.

-- glen


Article: 73154
Subject: Re: Virtex 4 released today
From: Vic Vadi <vic.vadi@xilinx.com>
Date: Tue, 14 Sep 2004 16:58:06 -0700
Links: << >>  << T >>  << A >>


> 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.

Part of the reasoning behind having 32 global clock buffers is that
customers may want to route other high fanout nets such as resets
and clock enables on global clock buffers. (The value of this
depends on your design style ofcourse)

- Vic



Article: 73155
Subject: Re: Virtex 4 released today
From: General Schvantzkoph <schvantzkoph@yahoo.com>
Date: Tue, 14 Sep 2004 20:25:30 -0400
Links: << >>  << T >>  << A >>
There are lots of situations where you need multiple clocks. If you
are interfacing to a number of devices that each have their own clock you
need a separate clock for each of them. Even if the devices are all using
the same source clock their output clocks (for clock forwarded interfaces)
are all phase shifted by an indeterminate amount so they have to be
treated as asynchronous. I typically capture each device's data in an
async FIFO and then transfer it into a primary clock domain. The great
majority of the slices are in the primary domain so the device is mostly
synchronous but there is still a need for a large number of clocks.


Article: 73156
Subject: Re: Virtex 4 released today
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 14 Sep 2004 17:29:46 -0700
Links: << >>  << T >>  << A >>
Hi Vic,
So you can route clock enables on these V4 global nets? That'd be good. As
for resets, fair enough, provided you're not talking about asynchronous
ones!
cheers, Syms.
"Vic Vadi" <vic.vadi@xilinx.com> wrote in message
news:4147858D.C40A8281@xilinx.com...
> > 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.
>
> Part of the reasoning behind having 32 global clock buffers is that
> customers may want to route other high fanout nets such as resets
> and clock enables on global clock buffers. (The value of this
> depends on your design style ofcourse)
>
> - Vic
>



Article: 73157
Subject: Re: New to Xilinx Software - help with downlaod
From: digvijaymr@yahoo.com (Digvijay Raghavan)
Date: 14 Sep 2004 17:45:12 -0700
Links: << >>  << T >>  << A >>
Hi Kranthi,
       I have used the student edition (a prior version) a long time
ago and in my opinion webpack seems better. It does support some
devices even upto Virtex II, some of the Spartan and all of the CPLD
devices. You can simulate your design (ships with Modelsim from
Mentor), sythesize your design, perform post synthesys simulations
(similar to back-annotation), floorplan and come out with the
configuration bit files. One good feature with this is that you can
generate simulation vectors graphically and internally it generates
the test bench for you. Try it!!

Good luck,
Digvijay.

kranthi_q@graffiti.net (Kranthi Q) wrote in message news:<ecef0ac4.0409131011.4243433@posting.google.com>...
> Hi,
> 
> I want to learn to use the Xilinx Software and was wondering which one to download..
> 
> What is the difference between Xilinx Student Edition 4.2i and Xilinx webpack??
> 
> which is better to download???  and How are they and what do they offer??
> 
> I am new to this and would appreciate the help!!!
> 
> Thank you.
> 
> Kranthi.

Article: 73158
Subject: Re: Virtex 4 released today
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 15 Sep 2004 13:14:35 +1200
Links: << >>  << T >>  << A >>
Vic Vadi wrote:
>>>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? ;)
> 
> 
> Actually you are wrong. Virtex 4 has several different clock regions.
> An LX25 for example has 12 different clock regions. Each of those
> 12 clock regions can only get 8 global clocks, but those 8 clocks
> in each of those 12 regions can come from any of the 32
> global clock buffers. Plus you also get 2 regional clocks in each
> clock region for Source-Synchronous type applications.

  So, supposing someone wants to create a 'phased array' of clocks,
to push their time-resolution well below the 1/clock, ( as in other 
threads ) what is the practical limit in Virtex-4, for the number of DCM 
controled phases that can be generated, AND dispersed thru the chip ?
( IIRC earlier DCM's had just 4 phases ).
  Can each of the 32 global clock buffers be driven to +1/32 phase 
advance, for example ?

-jg


Article: 73159
Subject: Re: Virtex 4 released today
From: "Antti Lukats" <antti@case2000.com>
Date: Tue, 14 Sep 2004 18:49:09 -0700
Links: << >>  << T >>  << A >>

"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: 73160
Subject: Re: spartan-3 I/O timing
From: "Robert Sefton" <rsefton@abc.net>
Date: Tue, 14 Sep 2004 19:09:01 -0700
Links: << >>  << T >>  << A >>
"John_H" <johnhandwork@mail.com> wrote in message 
news:xUK1d.9$l1.933@news-west.eli.net...
>
> My 133MHz PowerPC interface hasn't been in a Spartan-3 yet but was readily
> implemented in the Spartan-IIE.  Being the second of 2 masters interfacing
> to a bridge (the first is the processor), the timing was aggressive
> considering the complexity in a qualified bus grant.  To get around the 
> need
> to come in, go through logic, and go out with only one register in the 
> path,
> I leveraged the FDSE primitives in the IOBs to turn the tristates on and 
> off
> with the exceptionally low delays.  I had the advantage of DMAs going only
> into the chip - I'm thinking DMAs back out would be troublesome for the 
> 133
> MHz speeds.
>
> A reconfiguration of the interface might get your bus control to behave 
> much
> better with the Spartan-3 I/O timings.
>
> Another trick that I've used... if delaying the clock would help but the 
> DCM
> is unavailable, add another clock buffer in the clock path.  Controlling 
> the
> routing to the same or opposite sides of the chip will give slightly
> different times.  Since routing delays tend to track faster/slower with 
> the
> rest of the chip, I wasn't too concerned about just "adding delays" to
> improve my timing.
>

Thanks for the ideas. I have three masters in the FPGA, and each master
supports four DMA functions, so there are a total of 12 DMA channels. Plus 
the
MPC8250 uses GPCM accesses on the 60X bus to access internal FPGA registers.
Lot's of logic hanging off the critical nets. The MPC8250 has dedicated 
br-/bg-/dbg-
lines for each master, but abb-, dbb-, psdval-, etc., are shared.

I am using the DCM, but shifting the clock won't help because there are 
output
paths that are just as critical. One upside with the Spartan-3 is that the
S-3 1000 has almost 50% more logic (LUTs and FFs) than the V-2 1000. So
I have more headroom there. Now that I've accepted the I/O timing situation
and stopped being pissed about it maybe I can find a way to make it work. 



Article: 73161
Subject: Re: why systemc?
From: alexg@ottawa.com (Alexander Gnusin)
Date: 14 Sep 2004 19:30:05 -0700
Links: << >>  << T >>  << A >>
Javier Castillo <jcastillo@opensocdesign.com> wrote in message news:<Xns95647797DF637jcastilloopensocdesi@193.147.184.15>...

Hi Javier,
please see by comments below.
 
>   I dont want to have a discussion about what is better, because is obvious 
> that actually Verilog or VHDL are more mature HDLs and SystemC is a newbie. 
> The thing I want to transmit is that systemC can be used for RT design with 
> its current limitations. I say current because the SystemC Synthesis 
> Working Group is working in improve the SystemC capabilities in order to 
> make SystemC a RT solution as Verilog is.

I am convinced that it is possible to develop RTL using SystemC. More
than that, I am also convinced that, with some efforts, it will be
possible to develop RTL using Perl or any other language. The question
will be: how easy will be to sell it to designers.
Working Group effors are not sufficient to make SystemC a RTL Solution
as Verilog is. It is about the whole chip design infrastructure. It
took decades of common effort to bring Verilog-based design
infrastructure to the current level.  Then, the trend as I see is to
reduce, but not increase the number of RTL languages. SystemVerilog is
targeting this goal, inheriting most of useful RTL constructs from
VHDL. In fact, there is no value to express the same design intent in
different languages. As long as single language allows designers to
express all he/she needs, there is no need for another one.

> About your comments, I am agree in some of them because is obvious that 
> tools have a Verilog input and doesnt support SystemC. This Verilog input 
> is the reason to make a translation of the SystemC code, but I expect the 
> EDA suppliers will add SystemC support in their products. 

EDA suppliers will add SystemC support only if there will be business
case for it. Business case will be developed if designers will be
willing to pay money for the ability to develop RTL with SystemC. It
may not happen in the nearest feature.


> But I am not agree in other things, for example when you said:
> 
> > In addition to design, I also doubt that SystemC is a good choise for
> > the whole verification environment. For the system-level verification,
> > it is a good choise since it allows seamless interoperability with the
> > software. For the functional verification, verification-specific
> > languages (HVL)or SystemVerilog would be much better choise.
> > Functional verification requires advanced coverage, random generation,
> > assertion support as well as may other items such as random stability
> > etc. I doubt that SystemC has similar capabilities comparing to HVLs
> > or SV.
> 
> One of the strongest features of SystemC is the verification capabilities. 
> The SystemC Verification Library provides random generation, transaction 
> recording and many other features. Assertion or advance coverage is not 
> possible, the only thing you can do is a line coverage metric using GNU 
> gcov program. But as I said I expect EDA vendors will supply a SystemC 
> front end in their products. 

SystemC has good enough support for transaction-based, system-level
verification. It does not have almost any support for cycle-precised
verification, such as sequences, properties, assertions, coverage
constructs etc. This is natural, since SystemC, according to it's
name, targets system-level modeling and verification.


Regards,
Alexander Gnusin

Article: 73162
Subject: Re: Need some help with some technical claims...
From: "Austin Franklin" <austin@dark99room.com>
Date: Tue, 14 Sep 2004 23:34:26 -0400
Links: << >>  << T >>  << A >>
Hi Philip,

"Philip Freidin" <philip@fliptronics.com> wrote in message
news:givdk0te05fhs3jaoet64tfqv2edeul24q@4ax.com...
> Hi Austin,
> As I shake my head in wonderment reading your post, I think to myself
> (and not for the first time :-)
>
> "Self, isn't it great that all the really crazy clients end up in
>  Austin's bucket"

It's not a client, it's a physicist who used an FPGA once (or twice)...and
knows more than I do about electrical engineering and FPGAs.  If that is
true, perhaps I ought to open a hot dog stand ;-)

> >Any input appreciated ;-)
>
> Enjoy your argument  :-)

Well, it's not really an argument if you aready know the right answers.
Yours were pretty much the same as mine.  No surprise there ;-)

 I think you missed this "interesting" statement though:

>#1> Programming FPGAs...changes bits of non-volatile memory that is [are]
>#1> used as inputs to these [logic gates in the silicon wafer] gates...

The "are used as inputs to these logic gates in the silicon wafer" part...

and one comment on this:

"Since the devices are volatile, and infinitely re-programmable, just like
a CPU, no physical modification of the internal wires occurs."

Though true, there is a logical modification to the "internal wires", as in,
the PIPs get programmed to route the internal signals.

Regards,

Austin



Article: 73163
Subject: Re: EDK OPB Uart 16550
From: Dan Henry <dhenry@sprynet.com>
Date: Tue, 14 Sep 2004 21:46:40 -0600
Links: << >>  << T >>  << A >>
wpiman@aol.com (MS) wrote:

>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-

Yikes!  Everything else snipped.

Do your utmost to remove HyperTerminal as a variable.  The vast
majority of the time when I've thought I had a serial I/O problem,
when boiling it all down to a low gravy, what was left as a problem
source, was HyperTerminal.

Summary: If you observe a serial I/O problem and you a using
HyperTerminal, the likely cause is HyperTerminal!

You've been warned!

--
Dan Henry

Article: 73164
Subject: Re: Virtex 4 released today
From: Goran Bilski <goran@xilinx.com>
Date: Wed, 15 Sep 2004 08:11:16 +0200
Links: << >>  << T >>  << A >>
No

MicroBlaze runs at 150 MHz in a V2PRo and 185 MHz in V4.
That is a 23% improvement.

Göran


Jon Beniston wrote:

>>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: 73165
Subject: Re: Virtex 4 released today
From: "IgI" <igorsath@hotmail.com>
Date: Wed, 15 Sep 2004 08:47:58 +0200
Links: << >>  << T >>  << A >>
Hi!

My points exatly General Schvantzkoph. In a majority of designs 8 is more
than enought, but in cases, when you have to interface with 4 different CPUs
each running in it's own clock domain, you have 4 independent DDR channels
(1-2 variable shifted clocks per channel), 2 ZBTs, USB and Ethernet
interface, 1 or 2 ChipscopePro cores for debugging. Then you also have a
system clock (which is used in 80% of the design) all that on the same
chip,... then you are running out of IOs, out of BRAMs, out of clocks, out
of everything. That's why you need to cross the regions... And on top of
this, SI issues, different IO standards and voltage levels sometimes forces
you use IOs in other banks... And at the end location of other devices on
PCB, which are connected to FPGA also forces you to use IOs you normaly
wouldn't. Some would say use bigger chip. Of course this could be a
solution, but a very expensive one, because price is also a major factor. By
using bigger chip (with more IOs) I would have to use 12 layer PCB instead
of 10, PCB would be bigger, I had to redesign the cooling solution. All this
would result in a more expensive product.

Austin, It was not my intension to criticize your desicions, I just wanted
to clear this matter. And If I had ISE 6.3 installed on my machine, I
wouldn't ask this, instead I would try to figure this out by myself. Anyway,
when can we expect CDs with ISE 6.3 to arrive?

Regards,
Igor Bizjak

"General Schvantzkoph" <schvantzkoph@yahoo.com> wrote in message
news:pan.2004.09.15.00.25.27.975530@yahoo.com...
> There are lots of situations where you need multiple clocks. If you
> are interfacing to a number of devices that each have their own clock you
> need a separate clock for each of them. Even if the devices are all using
> the same source clock their output clocks (for clock forwarded interfaces)
> are all phase shifted by an indeterminate amount so they have to be
> treated as asynchronous. I typically capture each device's data in an
> async FIFO and then transfer it into a primary clock domain. The great
> majority of the slices are in the primary domain so the device is mostly
> synchronous but there is still a need for a large number of clocks.
>



Article: 73166
Subject: New VHDL (Xilinx) Website
From: j.matrix@ukonline.co.uk (John Matrix)
Date: 15 Sep 2004 01:19:55 -0700
Links: << >>  << T >>  << A >>
Hello everybody,

I would just like to take this opportunity to tell you about a new
VHDL IP website that is now up and running at...

http://www.spacewire.co.uk

There are some interesting bits of IP to download including a full
CISC micro that comes complete with an assembler and Xilinx RAM
generator.

Well worth a look ;-)

All the best,
John

Article: 73167
Subject: Re: Virtex 4 released today
From: Juergen Fuhrmann <juergen.fuhrmann@xilinx.com>
Date: Wed, 15 Sep 2004 11:01:17 +0200
Links: << >>  << T >>  << A >>
Please have a look at the new ChipSync Interface, which is available in 
all I/Os and takes care of the issue that you describe.

It makes the design of all source synchronous interfaces much easier. 
Instead of using a global clock signal for the received clock, it uses a 
dedicated local clock to capture the data. The clock AND the data can be 
delay adjusted, so that board delays and skew can be compensated.

Within the FPGA you have the option to run the FIFO of your example at 
"line speed" or reduce the clock frequency and increase the bit-width by 
using the built-in SERDES. As an example, if you have data coming into 
the device at 1Gbps (500 MHz DDR) you may want to set the SERDES up with 
a divide by 4 (the value 4 is just an example that makes sense in this 
case) so that you get 4 bits with every clock of 250 MHz. This can 
easily be transferred to a BRAM / FIFO. Only when you read the FIFO, you 
may want to use a global clock, as this is your "real" system clock 
(primary domain).

There are 2 local clocks per clock region. The number of clock regions 
depends on the device size - there are between 8 and 24 of these clock 
regions.

A detailed description of these resources can be found in the "Virtex-4 
User Guide". I can not describe all the features and capabilities in 
this message. There are also a couple of Application Notes available 
that take advantage of this technology.

--Jürgen

General Schvantzkoph wrote:

> There are lots of situations where you need multiple clocks. If you
> are interfacing to a number of devices that each have their own clock you
> need a separate clock for each of them. Even if the devices are all using
> the same source clock their output clocks (for clock forwarded interfaces)
> are all phase shifted by an indeterminate amount so they have to be
> treated as asynchronous. I typically capture each device's data in an
> async FIFO and then transfer it into a primary clock domain. The great
> majority of the slices are in the primary domain so the device is mostly
> synchronous but there is still a need for a large number of clocks.
> 

Article: 73168
Subject: Re: Virtex 4 released today
From: jon@beniston.com (Jon Beniston)
Date: 15 Sep 2004 03:37:12 -0700
Links: << >>  << T >>  << A >>
Goran Bilski <goran@xilinx.com> wrote in message news:<4147DCBB.2020409@xilinx.com>...
> No
> 
> MicroBlaze runs at 150 MHz in a V2PRo and 185 MHz in V4.
> That is a 23% improvement.

The Xilinx web site (http://www.xilinx.com/ipcenter/processor_central/microblaze/performance.htm)
says 150 MHz for a -6 device. I was assuming the -7 would be a bit
faster.

Cheers,
JonB

Article: 73169
Subject: Re: Virtex 4 released today
From: Goran Bilski <goran@xilinx.com>
Date: Wed, 15 Sep 2004 14:18:53 +0200
Links: << >>  << T >>  << A >>
Hi,

If I remember my test was with the -7 speed grade for V2Pro.
So I don't think that the website is correct. It should be a -7 device.
I will contact the person who is responsible for the webpage.

Thanks for finding this
Göran

Jon Beniston wrote:

>Goran Bilski <goran@xilinx.com> wrote in message news:<4147DCBB.2020409@xilinx.com>...
>  
>
>>No
>>
>>MicroBlaze runs at 150 MHz in a V2PRo and 185 MHz in V4.
>>That is a 23% improvement.
>>    
>>
>
>The Xilinx web site (http://www.xilinx.com/ipcenter/processor_central/microblaze/performance.htm)
>says 150 MHz for a -6 device. I was assuming the -7 would be a bit
>faster.
>
>Cheers,
>JonB
>  
>


Article: 73170
Subject: Xilinx Core Gen Question
From: Laurent Gauch <laurent.gauch@DELETEALLCAPSamontec.com>
Date: Wed, 15 Sep 2004 14:43:56 +0200
Links: << >>  << T >>  << A >>
Hi all,

Can I insert my own IP core in the Xilinx Core Gen?
Can I use Xilinx Core Gen to manage my OWN VHDL IP core?
If not, why Xilinx does not allow that feature.

Larry,
www.amontec.com

Article: 73171
Subject: CLK2X
From: Vivek <>
Date: Wed, 15 Sep 2004 06:16:34 -0700
Links: << >>  << T >>  << A >>
Hi,

I was wondering how accurate the clock2x of the VIRTEX 2 FPGA was. I wanted to multiply 60 MHz by two using the clock2x in order to generate a 120 MHz clk for my logic. Has anyone had experience using this and has it worked well?

Article: 73172
Subject: Re: Xpower - Clock Power
From: Brendan Cullen <bcullen@xilinx.com>
Date: Wed, 15 Sep 2004 14:44:55 +0100
Links: << >>  << T >>  << A >>
Hi Mukesh,

Mukesh Chugh wrote:

> Hi Brendon,
>
> Thanks Brendon for the response.
> Yes, I am using 6.2.03i of xpower. Can I get web updates?

You can.  Our service packs are available on the web.

> Also, do we
> need to get update for xpower alone or we have to get for complete
> ISE.

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

There are two steps :
- Firstly you need to upgrade to 6.3i.  That is not a web release.  That is a CD-based release.

- Then you need to download (from the web) 6.3.01i

Regards,

Brendan

>
>
> --
> 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


Article: 73173
Subject: Simulation Warning
From: "Naimesh" <naimesh.thakkar@gmail.com>
Date: 15 Sep 2004 06:46:45 -0700
Links: << >>  << T >>  << A >>
Hello

I am getting following warning during simulation in ModelSim


* Warning: *DFE3C RECOVERY High VIOLATION ON CLR WITH RESPECT TO CLK;
#   Expected := 1 ns; Observed := 0 ns; At : 61005 ns
#    Time: 61005 ns  Iteration: 1

Can any one tell what is RECOVERY High VIOLATION.
Thank for any help

Naimesh


Article: 73174
Subject: altera quartus II handbook is wrong??
From: malaka@email.it (sebastian)
Date: 15 Sep 2004 06:56:03 -0700
Links: << >>  << T >>  << A >>
hi,

im supposed to evaluate the same design in both altera and xilinx
devices, the problem is that altera's software seems a bit "unusual"
and doesnt understand code that all others synthetisers i've tried
recognise.

first i was having trouble with RAMs, but i solved that following
quartus II handbook coding guidelines (though i had to change several
files...and i dont like when that happens...specially because i'll
have three versions, one for each fpga family and then another for
asic!!)

now, im having trouble with ROMs, specially because the handbook has
an error...it says

***   "VHDL Synchronous ROM"   ***
.
.
.

architecture ...
begin

  process(clock) <- note this!
  begin
    case address is  <- note this! no if rising_edge!!!
      when "000" => data_out <= "010";
      when others => blah blah;
    end case;
  end process;
end;

now, i've tried both ways, the right one with the "if rising_edge..."
and the wrong one, and still i cant get quartus II to infer a ROM
without using LEs, it always makes the ROM out of LEs!. Could somebody
explain it to me?. Or is it that it just cant implement a ROM in a
RAM?? and it will always use LEs??

thanks a lot in advance



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