Found: an FPGA with internal tri-states

In has been mentioned here a few times that there are no FPGAs with 
internal tristates. However, surfing around somewhat aimlessly, I 
stumbled upon a device series which has them and obviously had to share 
my find:

The Atmel AT40K and AT40KAL series.

OTOH, their gate delay is pretty big: around 1.2 ns, and their SRAM read 
times aren't much better at about 10 ns. I didn't dig much deeper into 
the datasheets so far.

On 10/24/2015 10:38 AM, Aleksandar Kuktin wrote:
> In has been mentioned here a few times that there are no FPGAs with
> internal tristates. However, surfing around somewhat aimlessly, I
> stumbled upon a device series which has them and obviously had to share
> my find:
>
> The Atmel AT40K and AT40KAL series.
>
> OTOH, their gate delay is pretty big: around 1.2 ns, and their SRAM read
> times aren't much better at about 10 ns. I didn't dig much deeper into
> the datasheets so far.

This is a truly ancient FPGA family and you would use them at your own 
risk.  I'd be very surprised if they didn't come with a caution: Not for 
New Designs.  I think they are at least 15 years old, no?  I haven't 
looked them up, but I bet they are pretty expensive too.

-- 

Rick

On 10/24/2015 10:55 AM, rickman wrote:
> On 10/24/2015 10:38 AM, Aleksandar Kuktin wrote:
>> In has been mentioned here a few times that there are no FPGAs with
>> internal tristates. However, surfing around somewhat aimlessly, I
>> stumbled upon a device series which has them and obviously had to share
>> my find:
>>
>> The Atmel AT40K and AT40KAL series.
>>
>> OTOH, their gate delay is pretty big: around 1.2 ns, and their SRAM read
>> times aren't much better at about 10 ns. I didn't dig much deeper into
>> the datasheets so far.
>
> This is a truly ancient FPGA family and you would use them at your own
> risk.  I'd be very surprised if they didn't come with a caution: Not for
> New Designs.  I think they are at least 15 years old, no?  I haven't
> looked them up, but I bet they are pretty expensive too.
>

If you want another old FPGA with internal tristate that is still in
production, check out Xilinx Spartan 2.  It's also 5V tolerant...

-- 
Gabor

On 10/24/2015 04:38 PM, Aleksandar Kuktin wrote:
> In has been mentioned here a few times that there are no FPGAs with 
> internal tristates. However, surfing around somewhat aimlessly, I 
> stumbled upon a device series which has them and obviously had to share 
> my find:
> 
> The Atmel AT40K and AT40KAL series.
> 
> OTOH, their gate delay is pretty big: around 1.2 ns, and their SRAM read 
> times aren't much better at about 10 ns. I didn't dig much deeper into 
> the datasheets so far.
> 
A while back i tried verifying the available documentation 
against the bitstreams their IDS software produces. 
Got most of the details figured out.

there it is:
<https://github.com/klammerj/iverilog/tree/master/tgt-slick/util/wigglepuppy>

Aleksandar Kuktin <akuktin@gmail.com> wrote:

> In has been mentioned here a few times that there are no FPGAs with 
> internal tristates. However, surfing around somewhat aimlessly, I 
> stumbled upon a device series which has them and obviously had to share 
> my find:
 
> The Atmel AT40K and AT40KAL series.
 
> OTOH, their gate delay is pretty big: around 1.2 ns, and their SRAM read 
> times aren't much better at about 10 ns. I didn't dig much deeper into 
> the datasheets so far.

Internal tristates don't scale properly. As the chips get bigger,
and wires get smaller, the delay increases too much.

For unidirectional wires, there are buffers along the way, but you
can't buffer lines with tristates. 

But you don't need to worry.  The usual synthesis tools will
generate wire-AND (or maybe wire-OR) logic if you write tri-state
logic.

If you are implementing existing logic designs, it is easy enough
to allow the synthesis tools to process them. If not, it is easy
enough to write wire-AND logic.  (At least is is in verilog,
I haven't tried in VHDL yet.)

-- glen

Gabor Szakacs wrote:


> 
> If you want another old FPGA with internal tristate that is still in
> production, check out Xilinx Spartan 2.  It's also 5V tolerant...
> 
These were officially discontinued some years back, but some big customers 
must have squealed VERY loudly!  Digi-key even has stock of straight Spartan 
2, but no stock or prices on Spartan 2E, which I did use in a product.
I've moved on the Spartan 3A, which works nicely, and as long as they keep 
making those, they are a VERY good price for an FPGA.

Spartan 2 and 2E have not been supported by their tools in a long time.  I 
think Ise 10.1 is the last to support them.  Fortunately, Xilinx does make 
their legacy tools available!

Jon

Jon Elson wrote:
> Gabor Szakacs wrote:
> 
> 
>> If you want another old FPGA with internal tristate that is still in
>> production, check out Xilinx Spartan 2.  It's also 5V tolerant...
>>
> These were officially discontinued some years back, but some big customers 
> must have squealed VERY loudly!  Digi-key even has stock of straight Spartan 
> 2, but no stock or prices on Spartan 2E, which I did use in a product.
> I've moved on the Spartan 3A, which works nicely, and as long as they keep 
> making those, they are a VERY good price for an FPGA.
> 
> Spartan 2 and 2E have not been supported by their tools in a long time.  I 
> think Ise 10.1 is the last to support them.  Fortunately, Xilinx does make 
> their legacy tools available!
> 
> Jon

EOL was announced for Spartan-2 some years back and then it was
retracted.  Spartan 2E is no longer manufactured.  My guess is that it
was easier to migrate from 2E to newer parts since 2E was already not
5V tolerant.  In any case, Xilinx is generally happy to continue to
supply old parts as long as there is enough demand and as long as the
fab partners still have the process used to build the parts.  Xilinx
has never migrated an existing part to a different process node, and
probably never will.

-- 
Gabor

GaborSzakacs wrote:

  Xilinx
> has never migrated an existing part to a different process node, and
> probably never will.
> 
The engineering of the LUTs is pretty difficult, and probably requires a 
number of prototypes to get all the paths time-equalized so that under all 
cases the LUT is glitchless.  Also, getting the skew-free clock lines just 
right is probably difficult.  if they scaled the chip, the timing 
simulations would all be off.

So, it seems to me that scaling the chip would be essentially the same 
effort as designing a whole new chip from scratch.  I think this is where 
FPGAs are just a little bit different from typical logic parts.

Jon

On 10/26/2015 11:49 PM, Jon Elson wrote:
> GaborSzakacs wrote:
>
>    Xilinx
>> has never migrated an existing part to a different process node, and
>> probably never will.
>>
> The engineering of the LUTs is pretty difficult, and probably requires a
> number of prototypes to get all the paths time-equalized so that under all
> cases the LUT is glitchless.  Also, getting the skew-free clock lines just
> right is probably difficult.  if they scaled the chip, the timing
> simulations would all be off.

I've never heard anyone say LUTs are glitch free because they are timing 
controlled.  They are glitchless because they use pass transistor 
switches rather than gates for the mux.  But I can't say I am 
knowledgeable about this.  I just recall the description by the Xilinx 
guys who used to post here and they didn't talk about balancing timing 
in the LUTs.


> So, it seems to me that scaling the chip would be essentially the same
> effort as designing a whole new chip from scratch.  I think this is where
> FPGAs are just a little bit different from typical logic parts.

I won't argue that this isn't true for the newer generations.  I don't 
know it is for the same reasons.

-- 

Rick

rickman <gnuarm@gmail.com> wrote:
> On 10/26/2015 11:49 PM, Jon Elson wrote:

(snip)
>> The engineering of the LUTs is pretty difficult, and probably requires a
>> number of prototypes to get all the paths time-equalized so that under all
>> cases the LUT is glitchless.  Also, getting the skew-free clock lines just
>> right is probably difficult.  if they scaled the chip, the timing
>> simulations would all be off.
 
> I've never heard anyone say LUTs are glitch free because they are timing 
> controlled.  They are glitchless because they use pass transistor 
> switches rather than gates for the mux.  But I can't say I am 
> knowledgeable about this.  I just recall the description by the Xilinx 
> guys who used to post here and they didn't talk about balancing timing 
> in the LUTs.

Yes, but you have to time the pass transistors right.

Well, mostly you have to be sure not to go into any other state
on the way to the right one. 
 
>> So, it seems to me that scaling the chip would be essentially the same
>> effort as designing a whole new chip from scratch.  I think this is where
>> FPGAs are just a little bit different from typical logic parts.
 
> I won't argue that this isn't true for the newer generations.  
> I don't know it is for the same reasons.

Seems to me that retiming an existing design has to be easier than
completely designing a new one, but maybe not all that much easier.

-- glen