Why the second flip-flop in Virtex-6?

"glen herrmannsfeldt":
> Jan Bruns <testzugang_janbruns@arcor.de> wrote:

>> Will that Spartan6 have internal tristatable interconnects,
 
> As far as I know, that will never happen again.  It is part
> of the scaling laws for MOS circuits that as the circuitry
> gets smaller the RC time constant of wires increases.  
> R increases faster than C decreases, resulting in slower
> circuits.  The fix is to add buffers on longer lines,
> but those are directional.

That's probably not 100% fpga related, but why would R and C
change with smaller devices? Shouldn't R be constant for wires
(halfed length and width), and C shrink with either the
wire's surface or at most be constant shorter distance to 
other lines, but shorter)? 

BTW.: I mean a way to get wired a AND/OR, using some 
driver enable (to avoid MUXing many lines).

>> and/or better capabilites to build large MUXes?
 
> This should be possible.  As far as I know, AND/OR logic,
> where the signal and its enable drive an AND gate, then
> all the AND outputs drive an OR gate to generate the
> result.  That can be distributed back to where it is needed.

Sure, but there are only two options for an input to a mux:
register or combinatorial. If it is combinatorial, there might 
be a chance to absorb the AND with enable. If it's a register,
we have a "wasted" LUT per MUX-input.
The large OR at the end also adds levels of logic.
 
>> In Spartan3, a usual way to make a 32:1 MUX requires 16 LUT4
>> (8 Slices, 2 CLBs) + F5MUX + 3 levels of FXMUXes and because
>> both CLBs won't absorb much of any logic following the mux32,
>> the result has to be routed far away.
> 
> Can you replace that with AND/OR logic?  

That could probably mean 
32 LUT4s for (en & src & a0 & a1)
11 LUT4s to OR the 32 signals
 8 LUT4s for a a2..a4 3->8 decoder 
========
61 LUT4s (much more then the 16 LUTs using a standard spartan3 MUX32)

>> It seems obvious to me that giving the spartan3 CLB additional full mux32
>> logic wasn't a theoretical problem nor would it blow up required routing
>> resources (since a CLB already has enough external interconnects), and
>> the remaining logic would still be theoretically usable without any
>> external routing blow up (maybe non-registered adders or registered
>> counters; not sure if these would mean exactly no blowup, but nearly).

Or what about a minimal hardwired (yet impossible) modification to the F5MUX:

module new_f5mux(f,g,f4,g4,f3,g3,bx,ce, o);
  parameter static_fsel = 1'b0;
  parameter static_gsel = 1'b0;
  input g,g,f3,f4,g3,g4,bx,ce;
  output o;
  wire mf = (ce) ? f3 : f4;  // hardwired, but
  wire mg = (ce) ? g3 : g4;  // dynamic
  wire fq = (static_fsel) ? f : mf;  // config-time
  wire gq = (static_gsel) ? g : mg;  // static
  assign o = (bx) ? fq : gq;
endmodule

This would still allow a MUX16 per CLB or MUX32 per 2 CLBs,
but would free many other resources in the CLBs (carrychains,
LUT2, FlipFlops driven local, without ce, but still with reset 
option).

How does this compare to "dualport-ram option" the SLICEMs have.

Gruss

Jan Bruns

On Feb 4, 4:12=A0am, jhal...@TheWorld.com (Joseph H Allen) wrote:
> I'm surprised that the Spartan-6 integrated memory controller does not su=
pport
> DIMMs. =A0Also surprised that there are no integrated memory controllers =
in
> Virtex-6.
>
> Note the Virtex-6 Select-IO voltage range: only up to 2.5V! =A02.5V is th=
e
> new 5V...

The Spartan 6 Guide says Standards up to 3.3V ?
Where is the 2.5V limit given ?

-jg

-jg <Jim.Granville@gmail.com> writes:
> The Spartan 6 Guide says Standards up to 3.3V ?
> Where is the 2.5V limit given ?

In the Virtex 6 guide.

Jan Bruns wrote:

> That's probably not 100% fpga related, but why would R and C
> change with smaller devices? Shouldn't R be constant for wires
> (halfed length and width), and C shrink with either the
> wire's surface or at most be constant shorter distance to 
> other lines, but shorter)? 

The problem is that with smaller nodes the geometry of the wires
is changed. They have become very narrow but tall compared to the
old more rectangular ones. Also the length might not be halved,
because the chip has more logic. The die sizes have been quite
constant all the time (io-pads create the first limit how small
the die can become).

Also the propagation delay in the metal wire is proportional to the
square of the wire length, with repeaters that can be changed to linear
dependency. That is one big reason to remove tristate busses inside the
chips, they would not work very fast.

--Kim

Joseph H Allen wrote:
> No, 3.3V was the old new 5V.  The new new 5V is 2.5V.  Altera Straitx-IV
> also does not support 3.3V I/O.

Also in some of the new chips that still support the 3.3v volt the drive
strength might be very low, even so low that is is almost unusable.

--Kim

Jan Bruns <testzugang_janbruns@arcor.de> wrote:
 
> "glen herrmannsfeldt":
>> Jan Bruns <testzugang_janbruns@arcor.de> wrote:
>>> Will that Spartan6 have internal tristatable interconnects,
 
>> As far as I know, that will never happen again.  It is part
>> of the scaling laws for MOS circuits that as the circuitry
>> gets smaller the RC time constant of wires increases.  
>> R increases faster than C decreases, resulting in slower
>> circuits.  The fix is to add buffers on longer lines,
>> but those are directional.
 
> That's probably not 100% fpga related, but why would R and C
> change with smaller devices? Shouldn't R be constant for wires
> (halfed length and width), and C shrink with either the
> wire's surface or at most be constant shorter distance to 
> other lines, but shorter)? 

Wires shrink in width and height, both of which change
the resistance, C depends (mostly) just on width. 
Shrink by a factor of 2, R increases by a factor
of (about) 4, C decreases by a factor of 2.

If you actually shrink the die then the length would
also decrease, but it is more usual to keep the die size
and put more CLBs on.
 
> BTW.: I mean a way to get wired a AND/OR, using some 
> driver enable (to avoid MUXing many lines).
 
>>> and/or better capabilites to build large MUXes?
 
>> This should be possible.  As far as I know, AND/OR logic,
(snip)
 
> Sure, but there are only two options for an input to a mux:
> register or combinatorial. If it is combinatorial, there might 
> be a chance to absorb the AND with enable. If it's a register,
> we have a "wasted" LUT per MUX-input.
> The large OR at the end also adds levels of logic.

When you did have tristate devices on the chip interior
they were in special places, complicating routing.
 
>>> In Spartan3, a usual way to make a 32:1 MUX requires 16 LUT4
>>> (8 Slices, 2 CLBs) + F5MUX + 3 levels of FXMUXes and because
>>> both CLBs won't absorb much of any logic following the mux32,
>>> the result has to be routed far away.
 
>> Can you replace that with AND/OR logic?  
 
> That could probably mean 
> 32 LUT4s for (en & src & a0 & a1)
> 11 LUT4s to OR the 32 signals
> 8 LUT4s for a a2..a4 3->8 decoder 
> ========
> 61 LUT4s (much more then the 16 LUTs using a standard spartan3 MUX32)

Plus the priority encoder to use for the MUX inputs?

As I understand it, some tools will convert a wide (bus)
MUX into a decode and AND/OR logic.  For a single MUX
that doesn't seem to help.

-- glen

On Feb 4, 5:58=A0pm, Eric Smith <e...@brouhaha.com> wrote:
> -jg <Jim.Granvi...@gmail.com> writes:
> > The Spartan 6 Guide says Standards up to 3.3V ?
> > Where is the 2.5V limit given ?
>
> In the Virtex 6 guide.

So it seems they made a deliberate process decision, for Virtex 6 to
be
2.5V, and Spartan 6 to be 3.3V ?

That's  a large market to isolate your devices from - one hopes the
few picoseconds of speed that might have gained, turn out to be wrth
it!! :)

-jg
.

-jg wrote:
> So it seems they made a deliberate process decision, for Virtex 6 to
> be
> 2.5V, and Spartan 6 to be 3.3V ?

One decision maker might be, that usually new expensive designs are
not interfacing very old chips. But on the other hand cheap chips
can be used to cost reduce old designs or replace old ASICs.


> That's  a large market to isolate your devices from - one hopes the
> few picoseconds of speed that might have gained, turn out to be wrth
> it!! :)

It more a question of die space. 3.3v tolerant IO is huge in 40/45nm.
In V6 they are trying to reach the high end of IO and LUT counts. On
the other hand with S6 the LUT counts are not that high and also the IO
count is lower than in V6 so they can waste space for the IO.

--Kim

On Feb 4, 11:15=A0pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
> -jg wrote:
> > That's =A0a large market to isolate your devices from - one hopes the
> > few picoseconds of speed that might have gained, turn out to be wrth
> > it!! :)
>
> It more a question of die space. 3.3v tolerant IO is huge in 40/45nm.
> In V6 they are trying to reach the high end of IO and LUT counts. On
> the other hand with S6 the LUT counts are not that high and also the IO
> count is lower than in V6 so they can waste space for the IO.

Die Size, are you sure ?
- My understanding is Oxide thickness is what primarily determines IO
Voltage Specs.

Die area (PAD IO area) more determines drive current.

-jg

On Tue, 3 Feb 2009 15:12:41 +0000 (UTC), jhallen@TheWorld.com (Joseph H Allen)
wrote:

>I'm surprised that the Spartan-6 integrated memory controller does not support
>DIMMs.  Also surprised that there are no integrated memory controllers in
>Virtex-6.
>
>Note the Virtex-6 Select-IO voltage range: only up to 2.5V!  2.5V is the
>new 5V...

Reading between the lines here...

At a guess the V6 I/O blocks are fast enough to support DDR memory quite well
without special support - and that way you have the flexibility to support any
configuration you need (modulo SSO limitations; the tools will handle those)

But the S6 would struggle without special support... which would explain why it
has blocks the V6 doesn't. It is targetted at lower cost apps where you rarely
need DIMMs. But at a guess you may be able to support DIMMs with some speed
limitations; maybe you can tap into the memory controllers for all except the
datapath.

- Brian