Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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). JonArticle: 160601
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
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 CollinsArticle: 160603
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
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.ukArticle: 160605
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
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
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.=20Article: 160608
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. JonArticle: 160609
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
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. JonArticle: 160611
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
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
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
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, WojtekArticle: 160615
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
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
> 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. ThanksArticle: 160618
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
> 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
> 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
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
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
> 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
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:
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