Found: an FPGA with internal tri-states

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

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.







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

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