Virtex 4 released today

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

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

> 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

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

This is a multi-part message in MIME format.
--------------F8A44375B4C9D82F7C90A15D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

--------------F8A44375B4C9D82F7C90A15D
Content-Type: text/x-vcard; charset=us-ascii;
 name="vic.vadi.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Vic Vadi
Content-Disposition: attachment;
 filename="vic.vadi.vcf"

begin:vcard 
n:Vadi;Vic
tel;fax:408-626-6499
tel;work:x6303 (408-626-6303)
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:vicv@xilinx.com
fn:Vic Vadi
end:vcard

--------------F8A44375B4C9D82F7C90A15D--

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

This is a multi-part message in MIME format.
--------------76654E55B9D356EB34130712
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> 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

--------------76654E55B9D356EB34130712
Content-Type: text/x-vcard; charset=us-ascii;
 name="vic.vadi.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Vic Vadi
Content-Disposition: attachment;
 filename="vic.vadi.vcf"

begin:vcard 
n:Vadi;Vic
tel;fax:408-626-6499
tel;work:x6303 (408-626-6303)
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:vicv@xilinx.com
fn:Vic Vadi
end:vcard

--------------76654E55B9D356EB34130712--

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.

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
>

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