Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 160600

Article: 160600
Subject: Re: Very low pin count FPGA
From: Jon Elson <elson@pico-systems.com>
Date: Mon, 21 May 2018 12:46:06 -0500
Links: << >>  << T >>  << A >>
On Sun, 20 May 2018 08:46:24 -0700, gnuarm.deletethisbit wrote:

> On Sunday, April 1, 2018 at 4:49:58 PM UTC-4, mctuv...@gmail.com wrote:
>> On Sunday, April 20, 2003 at 6:30:57 AM UTC-4, Ian Hickey wrote:
>> > Does any manufacturer make a very small programmable logic device
>> > (with FLASH storage) is say a SOIC-8 or similar.
>> > 
>> > It's for a small home project that only has one output and only one
>> > input (plus CLK)
>> > 
>> > Thanks in advance.
>> > 
>> > Ian
>> 
>> I know this is many years since the original question, but...
>> ...Times, they are a changin'...
>> Here is an under $2 FPGA that sports 11 I/O pins in a tiny 4x4 BGA
>> package (16 pins total).
>> https://www.digikey.com/product-detail/en/lattice-semiconductor-
corporation/ICE40UL1K-SWG16ITR50/220-1960-1-ND/5129490
> 
> Yes, Lattice has been introducing a number of low pin count and medium
> pin count devices, but they are all in very fine pitch BGA packaging. 
> Great for high volume manufacturing, but sometimes difficult for medium
> volume work and near impossible for low volume, hand assembly.
Xilinx has the XC95xxXL series of CPLDs, starting at 44 pins quad flat 
pack with leads.  Very easy to hand solder.  These have an internal 
architecture based on the old PLD devices, ie. 36-wide and gates, and are 
non-volatile.  They are also single-voltage (3.3 V).

They also have the CoolRunner II series of CPLDs which are similar in 
architecture to FPGAs, non-volatile, available down to 44 pins, same 
package as above.  These do need dual power supplies (I think 3.3 and 1.2 
V).

Jon

Article: 160601
Subject: Re: CPLD 1.8V to 3.3V bidirectional SDA
From: Richard Damon <Richard@Damon-Family.org>
Date: Mon, 21 May 2018 22:21:17 -0400
Links: << >>  << T >>  << A >>
On 5/21/18 10:19 AM, gnuarm.deletethisbit@gmail.com wrote:
> On Sunday, May 20, 2018 at 12:21:28 PM UTC-4, Mike Perkins wrote:
>> On 08/05/2018 15:59, nobody wrote:
>>> I have a small design flaw with a new sensor, ICM20948, into a PI device. I need to make the SDA bidirectional and level shift SCL, int, and fsync. Voltage level on the sensor board is 1.8V the PI is 3.3V. I have CPLD hardware that I would like to use to make the bidirectional level shifted SDA as well as level shift the other three.
>>>
>>> The VHDL behavior is as simple as:
>>>
>>> begin
>>>
>>> enable <= '1' when DIR = '1' else '0';
>>> I2C(0) <= SCL;
>>> I2C(1) <= SDA when enable = '0' else 'Z';
>>> SDA <= I2C(1) when enable = '1' else 'Z';
>>>
>>> end Behavioral;
>>>
>>> I have used this before in another I2C without failure. The hardware seems to be performing the bidirectional communication, but all logic is a ~3.3V level.
>>>
>>> The CPLD is a Xilinx XC2CA64 with the 1.8V I2C pins on 11 and 13 and the 3.3V I2C and ancillary pins on 15, 16 and 17. The UCF is as follows:
>>>
>>> NET "I2C(0)" LOC = "11" ;     #SCL1V8
>>> NET "I2C(0)" IOSTANDARD = "LVCMOS18" ;
>>> NET "I2C(1)" LOC = "13" ;
>>> NET "I2C(1)" IOSTANDARD = "LVCMOS18" ; 	#SDA1V8
>>>
>>> NET "SCL"  LOC = "17" ;							#PI side
>>> NET "SCL" IOSTANDARD = "LVCMOS33" ; 	#
>>> NET "SDA"  LOC = "15" ;							#PI side
>>> NET "SDA" IOSTANDARD = "LVCMOS33" ; 	#
>>> NET "DIR"  LOC = "16" ;							#PI side
>>> NET "DIR" IOSTANDARD = "LVCMOS33" ; 	#
>>
>> Level shifting bidirectional signals is not a trivial thing to do.
>>
>> Agree with Rick's post where the output should either be pulled low of Hi-Z.
>>
>> What is wrong with the classic way of doing it as per:
>>    https://www.nxp.com/docs/en/application-note/AN10441.pdf
>>
>> The SCL may also need to be truly bidirectional if there is any device 
>> clock-stretching.
> 
> Your point is well taken.  There isn't much chance of clock stretching being used though as some number of I2C masters don't implement it.  I would be more concerned with proper management of the direction control signal.  
> 
> In the app note you point to they don't seem to compensate for the loss in voltage across the source to gate.  So while there are pullups on both side, the active drive from either side won't drive the full range and in fact may be very cramped by the 1.8 volt power supply.  If this bus isn't using the fast bit rate I guess that won't be a problem. 
> 
> Rick C.
> 

'active drive'? I2C (at least at base speeds) is a purely pull up
protocal. The only time logic is supposed to actually drive signal high
is if you transition into 'High Speed' (above the 400KHz fast mode)
mode. The App note specifically says it is for full / fast ((not High
Speed), so the bus is designed to be just restive pulled up.



Article: 160602
Subject: Re: CPLD 1.8V to 3.3V bidirectional SDA
From: gnuarm.deletethisbit@gmail.com
Date: Tue, 22 May 2018 00:48:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, May 21, 2018 at 10:21:21 PM UTC-4, Richard Damon wrote:
> On 5/21/18 10:19 AM, gnuarm.deletethisbit@gmail.com wrote:
> > On Sunday, May 20, 2018 at 12:21:28 PM UTC-4, Mike Perkins wrote:
> >> On 08/05/2018 15:59, nobody wrote:
> >>> I have a small design flaw with a new sensor, ICM20948, into a PI dev=
ice. I need to make the SDA bidirectional and level shift SCL, int, and fsy=
nc. Voltage level on the sensor board is 1.8V the PI is 3.3V. I have CPLD h=
ardware that I would like to use to make the bidirectional level shifted SD=
A as well as level shift the other three.
> >>>
> >>> The VHDL behavior is as simple as:
> >>>
> >>> begin
> >>>
> >>> enable <=3D '1' when DIR =3D '1' else '0';
> >>> I2C(0) <=3D SCL;
> >>> I2C(1) <=3D SDA when enable =3D '0' else 'Z';
> >>> SDA <=3D I2C(1) when enable =3D '1' else 'Z';
> >>>
> >>> end Behavioral;
> >>>
> >>> I have used this before in another I2C without failure. The hardware =
seems to be performing the bidirectional communication, but all logic is a =
~3.3V level.
> >>>
> >>> The CPLD is a Xilinx XC2CA64 with the 1.8V I2C pins on 11 and 13 and =
the 3.3V I2C and ancillary pins on 15, 16 and 17. The UCF is as follows:
> >>>
> >>> NET "I2C(0)" LOC =3D "11" ;     #SCL1V8
> >>> NET "I2C(0)" IOSTANDARD =3D "LVCMOS18" ;
> >>> NET "I2C(1)" LOC =3D "13" ;
> >>> NET "I2C(1)" IOSTANDARD =3D "LVCMOS18" ; 	#SDA1V8
> >>>
> >>> NET "SCL"  LOC =3D "17" ;							#PI side
> >>> NET "SCL" IOSTANDARD =3D "LVCMOS33" ; 	#
> >>> NET "SDA"  LOC =3D "15" ;							#PI side
> >>> NET "SDA" IOSTANDARD =3D "LVCMOS33" ; 	#
> >>> NET "DIR"  LOC =3D "16" ;							#PI side
> >>> NET "DIR" IOSTANDARD =3D "LVCMOS33" ; 	#
> >>
> >> Level shifting bidirectional signals is not a trivial thing to do.
> >>
> >> Agree with Rick's post where the output should either be pulled low of=
 Hi-Z.
> >>
> >> What is wrong with the classic way of doing it as per:
> >>    https://www.nxp.com/docs/en/application-note/AN10441.pdf
> >>
> >> The SCL may also need to be truly bidirectional if there is any device=
=20
> >> clock-stretching.
> >=20
> > Your point is well taken.  There isn't much chance of clock stretching =
being used though as some number of I2C masters don't implement it.  I woul=
d be more concerned with proper management of the direction control signal.=
 =20
> >=20
> > In the app note you point to they don't seem to compensate for the loss=
 in voltage across the source to gate.  So while there are pullups on both =
side, the active drive from either side won't drive the full range and in f=
act may be very cramped by the 1.8 volt power supply.  If this bus isn't us=
ing the fast bit rate I guess that won't be a problem.=20
> >=20
> > Rick C.
> >=20
>=20
> 'active drive'? I2C (at least at base speeds) is a purely pull up
> protocal. The only time logic is supposed to actually drive signal high
> is if you transition into 'High Speed' (above the 400KHz fast mode)
> mode. The App note specifically says it is for full / fast ((not High
> Speed), so the bus is designed to be just restive pulled up.

That's why I said if they weren't running fast it won't matter.  I didn't m=
emorize the names they use for the various modes, so "fast" was descriptive=
 rather than nominal.=20

The real issue is using a device that will actually be turned on with only =
a 1.8 volt gate drive which will potentially be even less since the driving=
 signal may not pull fully to ground.=20

I don't recall the details of the I2C interface timing, but it might be mor=
e realistic to implement a repeater that receives and retransmits the I2C s=
ignals rather than just level shifts.  The devil is in the details so it is=
 hard to say without at least simulating this circuit.=20

Rick Collins

Article: 160603
Subject: Re: FPGA selection recommendation
From: gnuarm.deletethisbit@gmail.com
Date: Tue, 22 May 2018 01:08:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, April 14, 2018 at 11:06:42 AM UTC-4, Piotr Wyderski wrote:
> I need an FPGA chip with about 100 GPIO pins and capable of hosting a=20
> CPU with an existing Linux port, mainly to run a web server. I would
> like to connect it to a 16-bit 	DRAM, so there should exist a memory=20
> controller with this feature, either a hard macro or a soft IP core.
> There should also be a fast ethernet MAC. Nothing fancy, but:
>=20
> 1. This is for a small non-profit project, so the IP cores must be free.
> Paying O(500) bucks for a Nios/MicroBlaze license is out of the=20
> question. Ditto about the MAC. As far as I know, neither Xiling nor
> Altera have a free/very cheap licensing option for non-profit=20
> applications, so the most obvious way is a no-go. Are there any
> *reasonable* open CPU/MAC/memory controller cores to use instead?
> $1000 per year is extremely cheap for commercial purposes, but
> a showstopper for hobby applications, where you can buy a bucket
> of STM32-class chips.
>=20
> 2. The chip must be hand-solderable and introduce no thermal strain=20
> problems. This excludes the BGA/chip scale packages and leaves only
> the QFP variants on the table. I don't care about the superior
> signal integrity benefits of the leadless packages, 50MHz is more
> than needed. But this requirement kills Zynq/Cyclone V, otherwise
> a perfect choice for this application. The PCB must be manufacturable
> in a cheap PCB shop and they can often do at most 4 layers.
>=20
> 3. The FPGA must be SRAM-based.
>=20
> 4. I don't want the SOM modules.
>=20
> The older Spartan 3Es (3S500E) or equivalent Cyclone 3 in PQFP208
> would have been aa good choice here, but I seem to be blocked by
> the licenseing issues. I'd gladly stick to these platforms, but
> could you please recommend me any robust open-source IP cores
> which fit inside this class of FPGAs?

I read much of the thread but not all.  I don't think I have anything meani=
ngful to add to the discussion as asked by the OP.  I do feel his pain abou=
t the available packages for FPGAs.  My desire is to have FPGA devices that=
 are similar in package and utility to smaller MCUs including price competi=
tiveness.  I don't care about hand soldering since that is of no economic v=
alue and I am in business.  My interest in using leaded or no-lead devices =
rather than BGA type packages is convenience and the cost of PWBs.  While t=
he larger BGAs often have wider pin pitches and so are not difficult to rou=
te with relaxed design rules, they are big and expensive mitigating the poi=
nt of using low cost PWBs.  Smaller pin count packages at a lower unit pric=
e use much finer ball pitches and require the most expensive PWB processing=
.  As a result there are no $10 FPGA boards available much less $5 FPGA boa=
rds even though there are a number of FPGAs well below this price.=20

I recall having conversations here with Xilinx representatives about the co=
st basis for FPGAs and often the die size was pin count limited.  So the sm=
allest devices were fairly large by some standards.  Lattice is the only FP=
GA company I am aware of that makes devices that only have a couple dozen I=
/Os or less across all packages.  Because of the market for these devices t=
hey end up in microscopic packages that are not practical for low cost prod=
uction unless very high volumes are produced.=20

Rick C.

Article: 160604
Subject: Re: CPLD 1.8V to 3.3V bidirectional SDA
From: Mike Perkins <spam@spam.com>
Date: Wed, 23 May 2018 03:26:24 +0100
Links: << >>  << T >>  << A >>
On 21/05/2018 15:19, gnuarm.deletethisbit@gmail.com wrote:
> On Sunday, May 20, 2018 at 12:21:28 PM UTC-4, Mike Perkins wrote:
>> On 08/05/2018 15:59, nobody wrote:
>>> I have a small design flaw with a new sensor, ICM20948, into a PI
>>> device. I need to make the SDA bidirectional and level shift SCL,
>>> int, and fsync. Voltage level on the sensor board is 1.8V the PI
>>> is 3.3V. I have CPLD hardware that I would like to use to make
>>> the bidirectional level shifted SDA as well as level shift the
>>> other three.
>>> 
>>> The VHDL behavior is as simple as:
>>> 
>>> begin
>>> 
>>> enable <= '1' when DIR = '1' else '0'; I2C(0) <= SCL; I2C(1) <=
>>> SDA when enable = '0' else 'Z'; SDA <= I2C(1) when enable = '1'
>>> else 'Z';
>>> 
>>> end Behavioral;
>>> 
>>> I have used this before in another I2C without failure. The
>>> hardware seems to be performing the bidirectional communication,
>>> but all logic is a ~3.3V level.
>>> 
>>> The CPLD is a Xilinx XC2CA64 with the 1.8V I2C pins on 11 and 13
>>> and the 3.3V I2C and ancillary pins on 15, 16 and 17. The UCF is
>>> as follows:
>>> 
>>> NET "I2C(0)" LOC = "11" ;     #SCL1V8 NET "I2C(0)" IOSTANDARD =
>>> "LVCMOS18" ; NET "I2C(1)" LOC = "13" ; NET "I2C(1)" IOSTANDARD =
>>> "LVCMOS18" ; 	#SDA1V8
>>> 
>>> NET "SCL"  LOC = "17" ;							#PI side NET "SCL" IOSTANDARD =
>>> "LVCMOS33" ; 	# NET "SDA"  LOC = "15" ;							#PI side NET "SDA"
>>> IOSTANDARD = "LVCMOS33" ; 	# NET "DIR"  LOC = "16" ;							#PI
>>> side NET "DIR" IOSTANDARD = "LVCMOS33" ; 	#
>> 
>> Level shifting bidirectional signals is not a trivial thing to do.
>> 
>> Agree with Rick's post where the output should either be pulled low
>> of Hi-Z.
>> 
>> What is wrong with the classic way of doing it as per: 
>> https://www.nxp.com/docs/en/application-note/AN10441.pdf
>> 
>> The SCL may also need to be truly bidirectional if there is any
>> device clock-stretching.
> 
> Your point is well taken.  There isn't much chance of clock
> stretching being used though as some number of I2C masters don't
> implement it.

Is it not the slave that holds the clock low, not the master?
   https://www.i2c-bus.org/clock-stretching/

Not all devices do this.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 160605
Subject: Re: CPLD 1.8V to 3.3V bidirectional SDA
From: Richard Damon <Richard@Damon-Family.org>
Date: Tue, 22 May 2018 23:37:41 -0400
Links: << >>  << T >>  << A >>
On 5/22/18 3:48 AM, gnuarm.deletethisbit@gmail.com wrote:
> On Monday, May 21, 2018 at 10:21:21 PM UTC-4, Richard Damon wrote:
>> On 5/21/18 10:19 AM, gnuarm.deletethisbit@gmail.com wrote:
>>> On Sunday, May 20, 2018 at 12:21:28 PM UTC-4, Mike Perkins wrote:
>>>> On 08/05/2018 15:59, nobody wrote:
>>>>> I have a small design flaw with a new sensor, ICM20948, into a PI device. I need to make the SDA bidirectional and level shift SCL, int, and fsync. Voltage level on the sensor board is 1.8V the PI is 3.3V. I have CPLD hardware that I would like to use to make the bidirectional level shifted SDA as well as level shift the other three.
>>>>>
>>>>> The VHDL behavior is as simple as:
>>>>>
>>>>> begin
>>>>>
>>>>> enable <= '1' when DIR = '1' else '0';
>>>>> I2C(0) <= SCL;
>>>>> I2C(1) <= SDA when enable = '0' else 'Z';
>>>>> SDA <= I2C(1) when enable = '1' else 'Z';
>>>>>
>>>>> end Behavioral;
>>>>>
>>>>> I have used this before in another I2C without failure. The hardware seems to be performing the bidirectional communication, but all logic is a ~3.3V level.
>>>>>
>>>>> The CPLD is a Xilinx XC2CA64 with the 1.8V I2C pins on 11 and 13 and the 3.3V I2C and ancillary pins on 15, 16 and 17. The UCF is as follows:
>>>>>
>>>>> NET "I2C(0)" LOC = "11" ;     #SCL1V8
>>>>> NET "I2C(0)" IOSTANDARD = "LVCMOS18" ;
>>>>> NET "I2C(1)" LOC = "13" ;
>>>>> NET "I2C(1)" IOSTANDARD = "LVCMOS18" ; 	#SDA1V8
>>>>>
>>>>> NET "SCL"  LOC = "17" ;							#PI side
>>>>> NET "SCL" IOSTANDARD = "LVCMOS33" ; 	#
>>>>> NET "SDA"  LOC = "15" ;							#PI side
>>>>> NET "SDA" IOSTANDARD = "LVCMOS33" ; 	#
>>>>> NET "DIR"  LOC = "16" ;							#PI side
>>>>> NET "DIR" IOSTANDARD = "LVCMOS33" ; 	#
>>>>
>>>> Level shifting bidirectional signals is not a trivial thing to do.
>>>>
>>>> Agree with Rick's post where the output should either be pulled low of Hi-Z.
>>>>
>>>> What is wrong with the classic way of doing it as per:
>>>>    https://www.nxp.com/docs/en/application-note/AN10441.pdf
>>>>
>>>> The SCL may also need to be truly bidirectional if there is any device 
>>>> clock-stretching.
>>>
>>> Your point is well taken.  There isn't much chance of clock stretching being used though as some number of I2C masters don't implement it.  I would be more concerned with proper management of the direction control signal.  
>>>
>>> In the app note you point to they don't seem to compensate for the loss in voltage across the source to gate.  So while there are pullups on both side, the active drive from either side won't drive the full range and in fact may be very cramped by the 1.8 volt power supply.  If this bus isn't using the fast bit rate I guess that won't be a problem. 
>>>
>>> Rick C.
>>>
>>
>> 'active drive'? I2C (at least at base speeds) is a purely pull up
>> protocal. The only time logic is supposed to actually drive signal high
>> is if you transition into 'High Speed' (above the 400KHz fast mode)
>> mode. The App note specifically says it is for full / fast ((not High
>> Speed), so the bus is designed to be just restive pulled up.
> 
> That's why I said if they weren't running fast it won't matter.  I didn't memorize the names they use for the various modes, so "fast" was descriptive rather than nominal. 
> 
> The real issue is using a device that will actually be turned on with only a 1.8 volt gate drive which will potentially be even less since the driving signal may not pull fully to ground. 
> 
> I don't recall the details of the I2C interface timing, but it might be more realistic to implement a repeater that receives and retransmits the I2C signals rather than just level shifts.  The devil is in the details so it is hard to say without at least simulating this circuit. 
> 
> Rick Collins
> 

The big point is that the High Speed I2C bus is very much a different
beast than the Full / Fast speed bus, with very different requirements.
The notes on implementing High Speed mode often talk about the need to
isolate High Speed devices from 'Normal' speed devices because they
might not tolerate the bus suddenly running faster than they were
designed for, even if they aren't being talked to.

As I mentioned, the App Note specifically limited its applicability to
the modes with the passive pull ups.

Also, High Speed I2C devices are fairly rare.

Geting Fets that turn on at 1-1.2 volts isn't that hard (and the current
needed isn't that high which makes the lower threshold easier to implement).

If by an I2C Repeater, you mean something that receives an I2C message
on one side and then send it to the other, this is basically impossible
if you want it to be transparent due to acks and reads. You basically
need to be re transmitting bit by bit.

There are devices that are a bit more complicated that can do this task,
and even handle High Speed, which operate by assuming that the signal
driving to them drive low with better than required margins, and then
the repeater drives a weaker low so it can detect which sides are being
driven (something like if Ain < 0.3V then pull Bout to 0.5V) with the
disadvantage that you can't repeat a repeated signal.

Article: 160606
Subject: Re: CPLD 1.8V to 3.3V bidirectional SDA
From: gnuarm.deletethisbit@gmail.com
Date: Thu, 24 May 2018 10:19:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, May 22, 2018 at 10:26:26 PM UTC-4, Mike Perkins wrote:
> On 21/05/2018 15:19, gnuarm.deletethisbit@gmail.com wrote:
> > On Sunday, May 20, 2018 at 12:21:28 PM UTC-4, Mike Perkins wrote:
> >> On 08/05/2018 15:59, nobody wrote:
> >>> I have a small design flaw with a new sensor, ICM20948, into a PI
> >>> device. I need to make the SDA bidirectional and level shift SCL,
> >>> int, and fsync. Voltage level on the sensor board is 1.8V the PI
> >>> is 3.3V. I have CPLD hardware that I would like to use to make
> >>> the bidirectional level shifted SDA as well as level shift the
> >>> other three.
> >>> 
> >>> The VHDL behavior is as simple as:
> >>> 
> >>> begin
> >>> 
> >>> enable <= '1' when DIR = '1' else '0'; I2C(0) <= SCL; I2C(1) <=
> >>> SDA when enable = '0' else 'Z'; SDA <= I2C(1) when enable = '1'
> >>> else 'Z';
> >>> 
> >>> end Behavioral;
> >>> 
> >>> I have used this before in another I2C without failure. The
> >>> hardware seems to be performing the bidirectional communication,
> >>> but all logic is a ~3.3V level.
> >>> 
> >>> The CPLD is a Xilinx XC2CA64 with the 1.8V I2C pins on 11 and 13
> >>> and the 3.3V I2C and ancillary pins on 15, 16 and 17. The UCF is
> >>> as follows:
> >>> 
> >>> NET "I2C(0)" LOC = "11" ;     #SCL1V8 NET "I2C(0)" IOSTANDARD =
> >>> "LVCMOS18" ; NET "I2C(1)" LOC = "13" ; NET "I2C(1)" IOSTANDARD =
> >>> "LVCMOS18" ; 	#SDA1V8
> >>> 
> >>> NET "SCL"  LOC = "17" ;							#PI side NET "SCL" IOSTANDARD =
> >>> "LVCMOS33" ; 	# NET "SDA"  LOC = "15" ;							#PI side NET "SDA"
> >>> IOSTANDARD = "LVCMOS33" ; 	# NET "DIR"  LOC = "16" ;							#PI
> >>> side NET "DIR" IOSTANDARD = "LVCMOS33" ; 	#
> >> 
> >> Level shifting bidirectional signals is not a trivial thing to do.
> >> 
> >> Agree with Rick's post where the output should either be pulled low
> >> of Hi-Z.
> >> 
> >> What is wrong with the classic way of doing it as per: 
> >> https://www.nxp.com/docs/en/application-note/AN10441.pdf
> >> 
> >> The SCL may also need to be truly bidirectional if there is any
> >> device clock-stretching.
> > 
> > Your point is well taken.  There isn't much chance of clock
> > stretching being used though as some number of I2C masters don't
> > implement it.
> 
> Is it not the slave that holds the clock low, not the master?
>    https://www.i2c-bus.org/clock-stretching/
> 
> Not all devices do this.

Yes, the slave holds the clock low, but the master has to be paying attention.  If not the network screws up. 

Rick C. 

Article: 160607
Subject: Re: Very low pin count FPGA
From: gnuarm.deletethisbit@gmail.com
Date: Thu, 24 May 2018 10:26:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, May 21, 2018 at 1:46:15 PM UTC-4, Jon Elson wrote:
> On Sun, 20 May 2018 08:46:24 -0700, gnuarm.deletethisbit wrote:
>=20
> > On Sunday, April 1, 2018 at 4:49:58 PM UTC-4, mctuv...@gmail.com wrote:
> >> On Sunday, April 20, 2003 at 6:30:57 AM UTC-4, Ian Hickey wrote:
> >> > Does any manufacturer make a very small programmable logic device
> >> > (with FLASH storage) is say a SOIC-8 or similar.
> >> >=20
> >> > It's for a small home project that only has one output and only one
> >> > input (plus CLK)
> >> >=20
> >> > Thanks in advance.
> >> >=20
> >> > Ian
> >>=20
> >> I know this is many years since the original question, but...
> >> ...Times, they are a changin'...
> >> Here is an under $2 FPGA that sports 11 I/O pins in a tiny 4x4 BGA
> >> package (16 pins total).
> >> https://www.digikey.com/product-detail/en/lattice-semiconductor-
> corporation/ICE40UL1K-SWG16ITR50/220-1960-1-ND/5129490
> >=20
> > Yes, Lattice has been introducing a number of low pin count and medium
> > pin count devices, but they are all in very fine pitch BGA packaging.=
=20
> > Great for high volume manufacturing, but sometimes difficult for medium
> > volume work and near impossible for low volume, hand assembly.
> Xilinx has the XC95xxXL series of CPLDs, starting at 44 pins quad flat=20
> pack with leads.  Very easy to hand solder.  These have an internal=20
> architecture based on the old PLD devices, ie. 36-wide and gates, and are=
=20
> non-volatile.  They are also single-voltage (3.3 V).
>=20
> They also have the CoolRunner II series of CPLDs which are similar in=20
> architecture to FPGAs, non-volatile, available down to 44 pins, same=20
> package as above.  These do need dual power supplies (I think 3.3 and 1.2=
=20
> V).

Both the Coolrunner II and the 9500 series are very limited in capability a=
nd in the case of the Coolrunner II can be rather expensive for the larger =
devices.  They also only package the smallest devices in the smallest packa=
ges.  They just aren't useful for much other than simple CPLD type applicat=
ions.  Maybe that's because they are simple CPLDs?=20

Rick C.=20

Article: 160608
Subject: Re: Very low pin count FPGA
From: Jon Elson <elson@pico-systems.com>
Date: Thu, 24 May 2018 14:23:34 -0500
Links: << >>  << T >>  << A >>
On Thu, 24 May 2018 10:26:58 -0700, gnuarm.deletethisbit wrote:

> On Monday, May 21, 2018 at 1:46:15 PM UTC-4, Jon Elson wrote:
>> On Sun, 20 May 2018 08:46:24 -0700, gnuarm.deletethisbit wrote:
>> 
>> > On Sunday, April 1, 2018 at 4:49:58 PM UTC-4, mctuv...@gmail.com
>> > wrote:
>> >> On Sunday, April 20, 2003 at 6:30:57 AM UTC-4, Ian Hickey wrote:
>> >> > Does any manufacturer make a very small programmable logic device
>> >> > (with FLASH storage) is say a SOIC-8 or similar.
>> >> > 
>> >> > It's for a small home project that only has one output and only
>> >> > one input (plus CLK)
>> >> > 
<snip>
> 
> Both the Coolrunner II and the 9500 series are very limited in
> capability and in the case of the Coolrunner II can be rather expensive
> for the larger devices.  They also only package the smallest devices in
> the smallest packages.  They just aren't useful for much other than
> simple CPLD type applications.  Maybe that's because they are simple
> CPLDs?
Well, the OP did say he had ONE input and ONE output (plus clock) so that 
seems like it could be a pretty small circuit.  I have a case where I 
needed 3 sequential reset pulses to put an Analog Devices chip in the 
proper state upon power-up.  The smallest XC9536 (now upgraded to 
XC9536XL) was perfect, and smaller than I could have done it with 2 
74HC4538s plus R & C.

Since the OP didn't give much info, I had to make assumptions on how much 
logic he needed.

Jon

Article: 160609
Subject: Re: Very low pin count FPGA
From: gnuarm.deletethisbit@gmail.com
Date: Thu, 24 May 2018 13:37:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, May 24, 2018 at 3:23:44 PM UTC-4, Jon Elson wrote:
> On Thu, 24 May 2018 10:26:58 -0700, gnuarm.deletethisbit wrote:
>=20
> > On Monday, May 21, 2018 at 1:46:15 PM UTC-4, Jon Elson wrote:
> >> On Sun, 20 May 2018 08:46:24 -0700, gnuarm.deletethisbit wrote:
> >>=20
> >> > On Sunday, April 1, 2018 at 4:49:58 PM UTC-4, mctuv...@gmail.com
> >> > wrote:
> >> >> On Sunday, April 20, 2003 at 6:30:57 AM UTC-4, Ian Hickey wrote:
> >> >> > Does any manufacturer make a very small programmable logic device
> >> >> > (with FLASH storage) is say a SOIC-8 or similar.
> >> >> >=20
> >> >> > It's for a small home project that only has one output and only
> >> >> > one input (plus CLK)
> >> >> >=20
> <snip>
> >=20
> > Both the Coolrunner II and the 9500 series are very limited in
> > capability and in the case of the Coolrunner II can be rather expensive
> > for the larger devices.  They also only package the smallest devices in
> > the smallest packages.  They just aren't useful for much other than
> > simple CPLD type applications.  Maybe that's because they are simple
> > CPLDs?
> Well, the OP did say he had ONE input and ONE output (plus clock) so that=
=20
> seems like it could be a pretty small circuit.  I have a case where I=20
> needed 3 sequential reset pulses to put an Analog Devices chip in the=20
> proper state upon power-up.  The smallest XC9536 (now upgraded to=20
> XC9536XL) was perfect, and smaller than I could have done it with 2=20
> 74HC4538s plus R & C.
>=20
> Since the OP didn't give much info, I had to make assumptions on how much=
=20
> logic he needed.

Yeah, but if you are still working on the OPs needs he said he wanted a dev=
ice in an "SOIC-8 or similar". =20

That is the crux of the problem.  There are some number of applications whi=
ch require more logic than a 22V10 but in a similar size package.  Just as =
there is a wide range of MCU sizes in capability and packages it would be u=
seful to have a similar range of capacities and packages for FPGAs.  Not al=
l MCUs in a 20 pin package are limited to 8 kB of Flash, some go well beyon=
d that.  But in FPGAs they seem to be less interested in a proliferation of=
 die types so when they plan their devices a die with this must logic has t=
his many I/O pins and they try to make as many as possible in the packages.=
 =20

I was once told the die sizes in low end FPGAs are I/O bound.  So the highe=
r pin counts become a self fulfilling prophesy so they can charge more.  I'=
ve also been told the FPGA makers have no interest in competing in the same=
 application space as MCUs since the margins are much narrower.  The big tw=
o FPGA makers are in the same mindset that their primary market is to suppl=
y the larger devices to the large communications vendors.  Everything else =
is picking up bread crumbs. =20

If it weren't for that FPGAs would support many of the same interfaces that=
 MCUs do and be available in similar packaging - able to compete head to he=
ad for applications that don't take a quarter MB of program to implement.  =
Lattice presently has a 384 LUT device for just a couple of bucks, but it i=
s in a package with 0.4 mm ball pitch which is not so easy to work with wit=
hout a very fine PWB process and micro vias.=20

Rick C.

Article: 160610
Subject: Re: Very low pin count FPGA
From: Jon Elson <elson@pico-systems.com>
Date: Fri, 25 May 2018 14:01:47 -0500
Links: << >>  << T >>  << A >>
On Thu, 24 May 2018 13:37:46 -0700, gnuarm.deletethisbit wrote:

>
> 
> Yeah, but if you are still working on the OPs needs he said he wanted a
> device in an "SOIC-8 or similar".
> 
Yup, that makes the problem harder.  Really, the 44-pin QFP isn't a WHOLE 
bunch bigger than an SOIC-8.  And, maybe there are some devices I don't 
know about that are in such a small package.

Jon

Article: 160611
Subject: Re: Very low pin count FPGA
From: gnuarm.deletethisbit@gmail.com
Date: Fri, 25 May 2018 13:29:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, May 25, 2018 at 3:01:56 PM UTC-4, Jon Elson wrote:
> On Thu, 24 May 2018 13:37:46 -0700, gnuarm.deletethisbit wrote:
>=20
> >
> >=20
> > Yeah, but if you are still working on the OPs needs he said he wanted a
> > device in an "SOIC-8 or similar".
> >=20
> Yup, that makes the problem harder.  Really, the 44-pin QFP isn't a WHOLE=
=20
> bunch bigger than an SOIC-8.  And, maybe there are some devices I don't=
=20
> know about that are in such a small package.

I've never seen anything in an 8 pin package, not even a PLD.  There are co=
mpanies that make "programmable" logic in very pin limited packages.  But t=
hey aren't "programmable" in the same way as PLDs.  More like a 2 input mux=
 (I don't recall the exact details) intended so you can wire it into your c=
ircuit to be a number of different types of 2 or 3 input gates.  The goal i=
s to replace multiple part numbers with a single line item in the BOM.  Her=
e is one just emailed to me recently.=20

https://www.digikey.com/en/product-highlight/n/nxp-semi/dual-pcb-configurab=
le-logic

Rick C.

Article: 160612
Subject: Re: Very low pin count FPGA
From: jim.brakefield@ieee.org
Date: Fri, 25 May 2018 16:42:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, April 22, 2003 at 12:01:26 AM UTC-5, Jim Granville wrote:
> Ian Hickey wrote:
> > 
> > Yes there are many small 8-pin micros out there which are very cheap sub $1.
> > The project does have some medium speed requirement but probably could be
> > achieved with PIC12C508 or MSP430F1101A.
> > 
> > My main reason for looking for a CPLD or similar was I have years of micro
> > work and was looking for a challenge.
> > 
> > Is no one aware of a third tier manufacturer specialising in medium speed
> > 10MHz to 30MHz logic with small pin count?
> 
> Currently you have SPLD and (smaller) CPLD to choose from.
> 
> SPLD come in TSSOP packages, so are quite small, but have quite low
> register counts.
> Lattice have just released a MLF package ispGAL22V10.
> 
> In CPLD, TQFP44 (10mm) is the most common small package.
> Some offer BGA, but these have problems on single sided PCBs :)
> TQFP48 (7mm) is appearing 'selectively'.
> 
>  MLF packages are obvious for (smaller) CPLDs, as they have 
> high density and low electrical and thermal impedances, and can
> be used right down to single sided PCBs.
>  The PLD industry is rather slower at seeing this, than the
> uC industry.
> 
> -jg

It should be mentioned that the Cypress PSOC family has a modest CPLD fabric and is available in QFN-24+ and SOIC-8+ packages.  Get a free Cortex M1.

Article: 160613
Subject: Re: Very low pin count FPGA
From: gnuarm.deletethisbit@gmail.com
Date: Sat, 26 May 2018 00:03:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, May 25, 2018 at 7:42:54 PM UTC-4, jim.bra...@ieee.org wrote:
> On Tuesday, April 22, 2003 at 12:01:26 AM UTC-5, Jim Granville wrote:
> > Ian Hickey wrote:
> > >=20
> > > Yes there are many small 8-pin micros out there which are very cheap =
sub $1.
> > > The project does have some medium speed requirement but probably coul=
d be
> > > achieved with PIC12C508 or MSP430F1101A.
> > >=20
> > > My main reason for looking for a CPLD or similar was I have years of =
micro
> > > work and was looking for a challenge.
> > >=20
> > > Is no one aware of a third tier manufacturer specialising in medium s=
peed
> > > 10MHz to 30MHz logic with small pin count?
> >=20
> > Currently you have SPLD and (smaller) CPLD to choose from.
> >=20
> > SPLD come in TSSOP packages, so are quite small, but have quite low
> > register counts.
> > Lattice have just released a MLF package ispGAL22V10.
> >=20
> > In CPLD, TQFP44 (10mm) is the most common small package.
> > Some offer BGA, but these have problems on single sided PCBs :)
> > TQFP48 (7mm) is appearing 'selectively'.
> >=20
> >  MLF packages are obvious for (smaller) CPLDs, as they have=20
> > high density and low electrical and thermal impedances, and can
> > be used right down to single sided PCBs.
> >  The PLD industry is rather slower at seeing this, than the
> > uC industry.
> >=20
> > -jg
>=20
> It should be mentioned that the Cypress PSOC family has a modest CPLD fab=
ric and is available in QFN-24+ and SOIC-8+ packages.  Get a free Cortex M1=
.

I have worked with the PSOC and I don't really consider it to contain FPGA =
capability.  The blocks they provide are much higher level than LUTs and FF=
s.  They have function units with a degree of programmability.  I believe t=
hey offer some support for programming in Verilog, but I have no idea how c=
onstrained that is.  The device I worked with most recently really didn't h=
ave the general blocks at all, it had some highly configurable serial port =
units that could be UART, USART, SPI, etc.  Not at all PLD like.=20

I think I read something about their newer devices, but I don't recall what=
 was new.  Here it is, PSOC6 dual core ARM, CM4, CM0+.  I believe there is =
a version with a BLE stack on the CM0+.  They have versions with 12 UDBs (u=
niversal digital blocks) or none.  I guess that is PLD like, but I recall t=
hey didn't let you in on the details.  Rather they have software that lets =
you chain preconfigured functions graphically. =20

Rick C.

Article: 160614
Subject: Communication between HDL simulation and user software via ZMQ
From: wzab01@gmail.com
Date: Sun, 27 May 2018 03:45:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
I develop systems were the FPGA-based hardware will use message-based commu=
nication (via Ethernet, USB or another communication channel) with remote s=
oftware. Those systems require thorough testing in simulations.

Therefore I needed to create a mechanism for communication between the simu=
lation and software using the remote message-passing library like ZeroMQ.

The first version was implemented for GHDL, using VHPI, and it was very sim=
ple:

https://groups.google.com/d/msg/alt.sources/R5cKBbRrUJM/ZGIj9wzWAAAJ
https://github.com/wzab/wzab-hdl-library/tree/master/vzmq/ghdl_proc

Unfortunately, sometimes my systems have to use proprietary Xilinx IP block=
s, that can't be simulated with GHDL.
(Especially now, when Xilinx decided to postpone support for VHLD models fo=
r IP cores https://forums.xilinx.com/t5/Simulation-and-Verification/no-VHDL=
-simulation-models-for-XPM-s/td-p/813397 )
The only option to interface simulation with the external C library in Viva=
do XSIM is now DPI via SystemVerilog.
(Well, it is possible to communicate via named pipes and sockets, but it re=
quires reimplementation of ZeroMQ in HDL, which quite complex)

Because it is not possible to directly communicate with SystemVerilog funct=
ions in tasks from VHDL, I had to create a simple module (entity), that pro=
vides a standard signal-based interface for VHDL. There are two equivalent =
versions. One for GHDL and another one for XSIM. The sources are also avail=
able at https://github.com/wzab/wzab-hdl-library/tree/master/vzmq/ghdl
https://github.com/wzab/wzab-hdl-library/tree/master/vzmq/dpi
https://groups.google.com/d/msg/alt.sources/R5cKBbRrUJM/eoe9D0ydDAAJ

The code is just "proof of the concept", so it is not very clean. However, =
I hope that it may be useful or at least inspiring for somebody,

The code is published as Public Domain or under Creative Commons CC0 licens=
e, so it may be widely reused.

I'll appreciate any suggestions for improvements or bugs fixes.

Regards,
Wojtek




Article: 160615
Subject: Searching for info about very old FPGA devices
From: Rodrigo Melo <rodrigomelo9@gmail.com>
Date: Sun, 27 May 2018 09:38:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello. My name is Rodrigo and I am from Argentina. I was looking for very o=
ld datasheets without success :-( (I searched a lot in google, archive.org,=
 alldatasheets, and more places...). I obtained name from old papers and pa=
tents:

* Plessey (1989). ERA60100 Preliminary Datasheet. Plessey Semiconductor, Sw=
indon, England.
* GEC Plessey Semiconductors, ERA60100 Electrically Reconfigurable Array Da=
ta Sheet, GEC Plessey Semiconductors Ltd., Swindon, Wiltshire SN2 2QW, UK, =
1991

* Plus Logic FPGA2020 Preliminary Data Sheet, 1990
* Plus Logic, FPSL5110 Product Brief , October 1989
* FPGA 2010, Field Programmable Gate Array, Plus Logic, San Jose, Calif., n=
o date, pp. 1-4.
* FPGA 2020, Field Programmable Gate Array, Plus Logic, San Jose, Calif., n=
o date, pp. 1-37.
* FPGA 2040, Field Programmable Gate Array, Plus Logic, San Jose, Calif., n=
o date, pp. 1-4.
* FPGA 5110, Intelligent Data Buffer, Plus Logic, San Jose, Calif., no date=
, pp. 1-6.

* Concurrent Logic, Inc. Data Sheet CFA6006 Field Programmable Gate Array; =
Advanced Info.; Mar. 15, 1991, Rev. 2.2.
* Concurrent Logic, Inc., "CLi6000 Series Field Programmable Gate Array," R=
ev. 1.3, May 1992.

* National Semiconductor, "Configurable Logic Array (CLAy) Data Sheet", 199=
3
* Configurable Logic Array (CLAy=E2=84=A2); Preliminary. Datasheet, Nationa=
l Semiconductors, Santa Clara, CA, Dec. 1993

I am studyng their architectures and the datasheet could be useful.

Some doubts which maybe somebody knows:
* Did Plus Logic FPGAs? I know, their devices are called FPGA20xx... Howeve=
r, Plus Logic was acquired by Xilinx in 1991 to became the EPLD/CPLD divisi=
on... And the FPGA2020 became the XC7272 (which is a CPLD).
* Has the Clay from National some relation with the CLI6000 from Concurrent=
? or the AT6000 from Atmel? (which acquired Concurrent Logic and CLI6000).

I read some very old posts with people speaking about some of them, so, may=
be theses people is still around and have some ideas :-D

Thanks in advance.

Article: 160616
Subject: Re: Searching for info about very old FPGA devices
From: gnuarm.deletethisbit@gmail.com
Date: Sun, 27 May 2018 11:59:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, May 27, 2018 at 12:39:02 PM UTC-4, Rodrigo Melo wrote:
> Hello. My name is Rodrigo and I am from Argentina. I was looking for very=
 old datasheets without success :-( (I searched a lot in google, archive.or=
g, alldatasheets, and more places...). I obtained name from old papers and =
patents:
>=20
> * Plessey (1989). ERA60100 Preliminary Datasheet. Plessey Semiconductor, =
Swindon, England.
> * GEC Plessey Semiconductors, ERA60100 Electrically Reconfigurable Array =
Data Sheet, GEC Plessey Semiconductors Ltd., Swindon, Wiltshire SN2 2QW, UK=
, 1991
>=20
> * Plus Logic FPGA2020 Preliminary Data Sheet, 1990
> * Plus Logic, FPSL5110 Product Brief , October 1989
> * FPGA 2010, Field Programmable Gate Array, Plus Logic, San Jose, Calif.,=
 no date, pp. 1-4.
> * FPGA 2020, Field Programmable Gate Array, Plus Logic, San Jose, Calif.,=
 no date, pp. 1-37.
> * FPGA 2040, Field Programmable Gate Array, Plus Logic, San Jose, Calif.,=
 no date, pp. 1-4.
> * FPGA 5110, Intelligent Data Buffer, Plus Logic, San Jose, Calif., no da=
te, pp. 1-6.
>=20
> * Concurrent Logic, Inc. Data Sheet CFA6006 Field Programmable Gate Array=
; Advanced Info.; Mar. 15, 1991, Rev. 2.2.
> * Concurrent Logic, Inc., "CLi6000 Series Field Programmable Gate Array,"=
 Rev. 1.3, May 1992.
>=20
> * National Semiconductor, "Configurable Logic Array (CLAy) Data Sheet", 1=
993
> * Configurable Logic Array (CLAy=E2=84=A2); Preliminary. Datasheet, Natio=
nal Semiconductors, Santa Clara, CA, Dec. 1993
>=20
> I am studyng their architectures and the datasheet could be useful.
>=20
> Some doubts which maybe somebody knows:
> * Did Plus Logic FPGAs? I know, their devices are called FPGA20xx... Howe=
ver, Plus Logic was acquired by Xilinx in 1991 to became the EPLD/CPLD divi=
sion... And the FPGA2020 became the XC7272 (which is a CPLD).
> * Has the Clay from National some relation with the CLI6000 from Concurre=
nt? or the AT6000 from Atmel? (which acquired Concurrent Logic and CLI6000)=
.
>=20
> I read some very old posts with people speaking about some of them, so, m=
aybe theses people is still around and have some ideas :-D
>=20
> Thanks in advance.

I worked with the Concurrent chips, but I think the data sheets are on an o=
ld desktop that doesn't work anymore.  I did find this on the Internet.=20

www.datasheet5.com/download/CLI6006-4PL084C/252501

Hope that helps.=20

Rick C.

Article: 160617
Subject: Re: Searching for info about very old FPGA devices
From: driverram@gmail.com
Date: Sun, 27 May 2018 14:02:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
> I worked with the Concurrent chips, but I think the data sheets are on an old desktop that doesn't work anymore.  I did find this on the Internet. 
> 
> www.datasheet5.com/download/CLI6006-4PL084C/252501
> 
> Hope that helps. 
> 
> Rick C.

Hi Rick. Thanks. In fact, is the only one that I already have XD I copy and paste my list of missing datasheets where I didn't update that I found it the last week.

I know that they are very old datasheet and if I didn't found in internet, old desktops are the only opportunity! I think that the worst cases are Plus Logic products, due that I think that were not marketed and there is very little information.

Thanks

Article: 160618
Subject: Re: Searching for info about very old FPGA devices
From: Tim <tim@bugblat.invalid>
Date: Mon, 28 May 2018 03:41:24 +0100
Links: << >>  << T >>  << A >>
Some of the old parts (Motorola, Toshiba, and others) were licensed from 
Pilkington - that gives you another search term :)

See if you can track down someone from Lattice Logic in Edinburgh. They 
were gurus and were very well connected.

More parts for your list: Xilinx 5200 and Xilinx 8100.

I expect you've read this and checked the references:
https://ieeexplore.ieee.org/document/7086413/

--
Tim


On 27/05/2018 17:38, Rodrigo Melo wrote:
> Hello. My name is Rodrigo and I am from Argentina. I was looking for very old datasheets without success :-( (I searched a lot in google, archive.org, alldatasheets, and more places...). I obtained name from old papers and patents:
> 
> * Plessey (1989). ERA60100 Preliminary Datasheet. Plessey Semiconductor, Swindon, England.
> * GEC Plessey Semiconductors, ERA60100 Electrically Reconfigurable Array Data Sheet, GEC Plessey Semiconductors Ltd., Swindon, Wiltshire SN2 2QW, UK, 1991
> 
> * Plus Logic FPGA2020 Preliminary Data Sheet, 1990
> * Plus Logic, FPSL5110 Product Brief , October 1989
> * FPGA 2010, Field Programmable Gate Array, Plus Logic, San Jose, Calif., no date, pp. 1-4.
> * FPGA 2020, Field Programmable Gate Array, Plus Logic, San Jose, Calif., no date, pp. 1-37.
> * FPGA 2040, Field Programmable Gate Array, Plus Logic, San Jose, Calif., no date, pp. 1-4.
> * FPGA 5110, Intelligent Data Buffer, Plus Logic, San Jose, Calif., no date, pp. 1-6.
> 
> * Concurrent Logic, Inc. Data Sheet CFA6006 Field Programmable Gate Array; Advanced Info.; Mar. 15, 1991, Rev. 2.2.
> * Concurrent Logic, Inc., "CLi6000 Series Field Programmable Gate Array," Rev. 1.3, May 1992.
> 
> * National Semiconductor, "Configurable Logic Array (CLAy) Data Sheet", 1993
> * Configurable Logic Array (CLAy™); Preliminary. Datasheet, National Semiconductors, Santa Clara, CA, Dec. 1993
> 
> I am studyng their architectures and the datasheet could be useful.
> 
> Some doubts which maybe somebody knows:
> * Did Plus Logic FPGAs? I know, their devices are called FPGA20xx... However, Plus Logic was acquired by Xilinx in 1991 to became the EPLD/CPLD division... And the FPGA2020 became the XC7272 (which is a CPLD).
> * Has the Clay from National some relation with the CLI6000 from Concurrent? or the AT6000 from Atmel? (which acquired Concurrent Logic and CLI6000).
> 
> I read some very old posts with people speaking about some of them, so, maybe theses people is still around and have some ideas :-D
> 
> Thanks in advance.
> 

Article: 160619
Subject: Re: Searching for info about very old FPGA devices
From: Rodrigo Melo <rodrigomelo9@gmail.com>
Date: Sun, 27 May 2018 20:41:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
> Some of the old parts (Motorola, Toshiba, and others) were licensed from 
> Pilkington - that gives you another search term :)
Yes, I know. Pilkington licensee Plessey (ERA), Toshiba (TC? somebody know about datasheets? I only have a paper) and Motorola (MAP1000). Somebody know others? I read it "others" a lot of times, but no more names.

> See if you can track down someone from Lattice Logic in Edinburgh. They 
> were gurus and were very well connected.
Ok, I will search about they.


> More parts for your list: Xilinx 5200 and Xilinx 8100.
Yes, I know all about Xilinx since the xc2064 :-D I also know that Xilinx acquired Plus Logic (CPLD business) and Algotronix (which derived in the xc6200). Also the coolrunner CPLDs from Philips.

> I expect you've read this and checked the references:
> https://ieeexplore.ieee.org/document/7086413/
Yes, I read it and a lot more of paper. Any idea about Prizm? I found nothing about.

I also know about IBM10016 (an AT6000 variation), Crosspoint's CP20K and Plasma from HP.

My main doubts know are:
* What about Prizm?
* Was Plus Logic a FPGA vendor, or only CPLDs?
* What about the Clay from Nationals? were originals or licensed?
* What about others Pilkington based?
* Is there a datasheet from TC series of Toshiba? I found other things from Toshiba called TC XD

See you.

Article: 160620
Subject: Re: Can a glitch-free mux be designed in an FPGA?
From: Thing241 <bob.comml@verizon.net>
Date: Tue, 29 May 2018 04:50:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
> Actually, there is no reason for a LUT to glitch where logic wouldn't

I agree, based on the structure of the N-input LUT (2^N flops feeding N lev=
els of glitchless muxes).  But Xilinx won't admit it.  The official line fr=
om Xilinx is that a single input change won't glitch the output (which cove=
rs the 2-input mux case in question), but multiple inputs changing might gl=
itch.  After looking into the LUT structure I have concluded that any colle=
ction of inputs that cannot change the output cannot glitch the output, but=
 again, Xilinx won't confirm this.

Article: 160621
Subject: Re: Can a glitch-free mux be designed in an FPGA?
From: gnuarm.deletethisbit@gmail.com
Date: Tue, 29 May 2018 22:46:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, May 21, 2011 at 12:18:07 AM UTC-4, Mr.CRC wrote:
> Hi:
>=20
> The simplest incarnation of a 2-to-1 multiplexer can be described by the
> equation:
>=20
> y =3D ~s & a | s & b
>=20
> where 'y' is the output, 's' is the select input, with 'a' and 'b' the
> data inputs.
>=20
> Of course, this multiplexer is broken because a practical implementation
>  glitches in a if 'a' and 'b' are true, and the select line toggles.
> Such as this example from the book (1):
> -----------------------------------------
> module mux21g (
>     input wire a,
>     input wire b,
>     input wire s,
>     output wire y
> );
>=20
> wire _s;
> wire c, d;
>=20
> assign #10 _s =3D ~s;
> assign #10 c =3D _s & a;
> assign #10 d =3D s & b;
> assign #10 y =3D c | d;
> ------------------------------------
>=20
> The fix for the glitching is of course to implement an extra term
> (Verilog not shown, but I think we can all handle it):
>=20
> y =3D ~s & a | s & b | a & b
>=20
>=20
> So the big questions are:
>=20
> 1.  What happens (ie., synthesizes) when you implement these equations
> in an FPGA?

I can't say for all FPGA brands, but for Xilinx and most Lattice devices th=
e design of the LUTs use transmission gates with the turn off faster than t=
he turn on time.  There is also a small amount of capacitance on the switch=
ing node resulting in the previous value being held until the new value is =
forced onto the switching node.  In other words, no glitch.=20


> 1a.  What synthesizes if you do:
>=20
> assign y =3D ~s & a | s & b; // ???
>=20
> 1b.  What synthesizes if you code the corrected mux equation:
>=20
> assign y =3D ~s & a | s & b | a & b; // ???

Both cases result in a LUT being filled in the same way.  There are no gate=
s at this level in most FPGAs, just a table being set to the output values =
for the various minterms of a set of input signals.  So in both cases it wo=
uld set the appropriate table values to ones to implement, a & ~b & ~s | a =
& b & ~s | ~a & b & s | a & b & s. =20


> 1c.  Is there any difference in the synthesis if you code it one bitwise
> operation at a time, like the module above, vs. all in one equation?

No.=20


> 1d. If you "infer" a mux using the code shown in the vendor's device
> library, then do you get a good mux, or a glitchy mux?

Every vendor I am aware of will give you a "good" mux.=20


> In the case of a CPLD, I would expect that I could implement the fixed
> mux if I selected suitable synthesis properties, such as "mux
> extraction" (which I think recognizes my intent to create a mux, perhaps
> whether I code it glitch free or not, and implements a correct mux--can
> any tool experts clarify?) and/or "wysiwyg" which will probably even
> implement the bad mux if I so choose.

Huh?  Tools can only implement what you describe using the HDL logic.  How =
can they possibly know your "intent"?=20


> But the FPGA with its LUTs is a different ball of wax.

Huh?=20


> I will be extremely interested to hear what the experts make of these
> questions.

I would too.=20


> I think that it is possible, though I don't yet know how, to see the
> "RTL" output by the synth?  Are the answers to my questions to be found
> there?

Most synthesis tools I have used can produce an RTL logic diagram for you t=
o look at. =20


> Then there are pre-synthesis and post-synthesis (or is it pre and post
> fitting?) simulation models, etc., and whew!  There are quite a few
> things I haven't delved into yet.

Pre and post synthesis *simulation*.  That is simply the synthesis tool pro=
viding delay information for use in simulation or not. =20

Rick C.

Article: 160622
Subject: Re: Can a glitch-free mux be designed in an FPGA?
From: gnuarm.deletethisbit@gmail.com
Date: Tue, 29 May 2018 23:58:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, May 29, 2018 at 7:50:51 AM UTC-4, Thing241 wrote:
> > Actually, there is no reason for a LUT to glitch where logic wouldn't
>=20
> I agree, based on the structure of the N-input LUT (2^N flops feeding N l=
evels of glitchless muxes).  But Xilinx won't admit it.  The official line =
from Xilinx is that a single input change won't glitch the output (which co=
vers the 2-input mux case in question), but multiple inputs changing might =
glitch.  After looking into the LUT structure I have concluded that any col=
lection of inputs that cannot change the output cannot glitch the output, b=
ut again, Xilinx won't confirm this.

I'm not sure you can say this.  No, that's wrong.  I *am* sure you *can't* =
say this. =20

The LUTs in most FPGAs are specifically constructed to prevent changing a s=
ingle control signal causing a glitch.  This is possible because the contro=
l signals drive 2 input muxes made of a pair of transmission gates.  They a=
re constructed so the turn on time is always longer than the turn off time.=
  This leaves the output node in a high impedance allowing the capacitance =
to hold the previous value until the new value is driven by the other gate =
in the pair. =20

When more than one control signal is changing, the state of different pairs=
 of transmission gates which have not been designed to match can not be gua=
ranteed to be switching in the same manner.  The glitchless behavior comes =
from careful design at a low level.  It would appear this glitchless behavi=
or is too hard to create across the entire LUT.=20

But maybe I don't understand you premise.  I am assuming we are talking abo=
ut something like A & ~C | B & C with both A and C changing at the same tim=
e.  C goes from 1 to zero and A goes from 0 to 1 while B stays at 1.  In th=
is case the output depends on the relative speeds withing the LUT.  Maybe y=
ou are talking about something like A | B | C where A and B transition whil=
e C is always a 1?  I am pretty sure in this case there would be no glitch =
since there are no intermediate states that will output a 0.=20

Rick C.

Article: 160623
Subject: Re: Can a glitch-free mux be designed in an FPGA?
From: thing241 <bob.comml@verizon.net>
Date: Wed, 30 May 2018 02:54:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
> Maybe you are talking about something like A | B | C where A and B transi=
tion while C is always a 1?  I am pretty sure in this case there would be n=
o glitch since there are no intermediate states that will output a 0.=20
>=20
Exactly.  LUTs don't glitch "where logic wouldn't" (as rickman said).
In a recent exchange with a Xilinx engineer on one of their forums I propos=
ed that if a LUT were implementing an AND gate, and one of the inputs was l=
ow, the other inputs could not glitch the output regardless of how they swi=
tched (collectively).  He would not agree, again quoting the Xilinx mantra =
that only "single" inputs are guaranteed not to cause a glitch.

Article: 160624
Subject: Re: Can a glitch-free mux be designed in an FPGA?
From: gnuarm.deletethisbit@gmail.com
Date: Wed, 30 May 2018 11:48:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, May 30, 2018 at 5:54:51 AM UTC-4, thing241 wrote:
> > Maybe you are talking about something like A | B | C where A and B tran=
sition while C is always a 1?  I am pretty sure in this case there would be=
 no glitch since there are no intermediate states that will output a 0.=20
> >=20
> Exactly.  LUTs don't glitch "where logic wouldn't" (as rickman said).
> In a recent exchange with a Xilinx engineer on one of their forums I prop=
osed that if a LUT were implementing an AND gate, and one of the inputs was=
 low, the other inputs could not glitch the output regardless of how they s=
witched (collectively).  He would not agree, again quoting the Xilinx mantr=
a that only "single" inputs are guaranteed not to cause a glitch.

There is what the chip will do and what the company guarantees...  Sort of =
a Forest Gump distinction I think.  Box of chocolates and all that...=20

Rick C.



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search