Found: an FPGA with internal tri-states

[Aleksandar Kuktin]

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.

 

[rickman]

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

 

[Gabor Szakacs]

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

 

[Johann Klammer]

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>

 

[glen herrmannsfeldt]

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

 

[Jon Elson]

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

 

[GaborSzakacs]

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

 

[Jon Elson]

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

 

[rickman]

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

 

[glen herrmannsfeldt]

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

 

[rickman]

On 10/27/2015 2:17 PM, glen herrmannsfeldt wrote:

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.

I believe this only requires that the switching time for on time is
longer than the off time. Then none of the pass transistors short
different value memory cells together and invalid states and glitches
are prevented, just a smooth transition between states.

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.

I believe there is a *lot* of footwork that goes into designing the
logic cells for a new process if you want optimum results. That is
where the work is and where the risk of respin is. The logical
structure is fairly cut and dried. Porting a logic cell design to a new
process should be a lot less work if you are not trying to optimize it.
The question is, why would anyone want to port an older generation
FPGA architecture to a new process when they are already designing a new
family? The only reason would be to save customers the trouble of
porting their designs to the new family. This would also require
compatible pin outs which seem to be anathema in the FPGA world unlike
the MCU world where they try very hard to share as much commonality in
pinouts as possible.

I would really like to see an MCU maker come out with FPGA enabled
products. I know the bulk of the work would be in ramping up the FPGA
side development software. Patents would not be a serious issue as most
of the basic ones have run out. A low end FPGA/CPU design wouldn't need
to be state of the art as most designs don't push the envelope for
FPGAs. Mostly designers just want something that works.

Cypress has some devices with "configurable" logic blocks, but they are
more like programmable I/O devices than they are generic logic and very
limited.

--

Rick

 

[carstenherr]

In german microcontroller Forum, there was a discussion recently regardin
this Topic. An expert for algorithms and optimization explained this i
detail that signals and busses in FPGAs cannot efficiently be optiomize
when they are bidictional. So this is not just an electrical issue.







--------------------------------------
Posted through http://www.FPGARelated.com

 

[rickman]

On 12/1/2015 10:37 AM, carstenherr wrote:

In german microcontroller Forum, there was a discussion recently regarding
this Topic. An expert for algorithms and optimization explained this in
detail that signals and busses in FPGAs cannot efficiently be optiomized
when they are bidictional. So this is not just an electrical issue.

I'm not sure what that means really. How are other buses optimized?

--

Rick