An other Microchip screwup on teh 18F14K22
in [Design]
|
From: krw on 9 May 2010 23:37 On Sun, 09 May 2010 16:06:33 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: >On Fri, 07 May 2010 17:57:31 -0500, "krw(a)att.bizzzzzzzzzzzz" ><krw(a)att.bizzzzzzzzzzzz> wrote: > >>On Fri, 07 May 2010 14:16:26 -0400, Spehro Pefhany >><speffSNIP(a)interlogDOTyou.knowwhat> wrote: >> >>>On Fri, 07 May 2010 09:27:35 -0700, John Larkin >>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>> >>>> >>>>That's pretty bad. But uPs are getting so complex, so overloaded with >>>>features, that the designers are sort of shoveling hunks of home-made >>>>or purchased IP into compilers and hoping for the best. And, >>>>apparently, not taking much time to simulate and verify. Or document! >>>>We had to do a bunch of experiments on the SPI interface on our NXP >>>>ARMs; even high-level support people couldn't answer some fundamental >>>>timing/framing questions. The SPI and ADC documentation is awful. >>>> >>>>We use ARM chips that have 30-character pin names, the pin functions >>>>are so overloaded. >>> >>>Who's are you using now? We're getting going with the Luminary parts. >>> >>>>What would be nice would be if things like SPI were small RAM-driven >>>>microengines. Then the functionality would be in loadable code, not >>>>hard-wired silicon. Sort of like Motorola's TPU blocks. They could be >>>>repurposed, too. >>>> >>>>John >>> >>>You'd think it would be relatively simple to put a thin FPGA or CPLD >>>fabric around the core, perhaps preloaded from ROM with some useful >>>defaults. >> >>That's a lot easier said than done. First, X, A, and A have most of the IP >>locked up for FPGA sorts of things. Second, the development software for such >>things is non-trivial. Great idea, but not likely to fly. > >PALs and small FPGAs have been around over 30 years. If you limit to not >much more tech, all the patents should be expired. A lot of the simple stuff, sure. Not sure about all the RAM and other special functions. >Atmel, Freescale, >Microchip, etc., all have nice multiplexing tech for the multifunction >pins. How does this apply?
From: krw on 9 May 2010 23:48 On Sun, 9 May 2010 15:26:46 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: >"Jan Panteltje" <pNaonStpealmtje(a)yahoo.com> wrote in message >news:hs3ioh$tr7$1(a)news.albasani.net... >> Do you not think it is strange that it took 8 revisions for it to work (IF >> it works in A8)? > >Seems like it's not that uncommon anymore. > >> What does a new mask cost these days? Must be very expensive, especially >> if after 7 silicon versions with the same problem not a single customer will >> buy these chips. > >It's apparently not expensive relative to the predicted lost sales of delaying >the part by, e.g., a year. :-( > >Unfortunately it's very unlikely that the bugs in your 18F14K22 would have >stopped anyone who was planning to buy a million of the things per year from >continuing to use the part... > >> When I bought the Z80, in the 19 eighties, a chip that has a much >> more complicated instruction set, but much easier to use, it worked on all >> advertised issues. > >I don't know if Microchip is doing it yet, but many microcontrollers today are >designed in Verilog or VHDL, and this seems to have brought with it the >mindset of "all designs have bugs" that permeates the software industry today. >(Note that an x86-compatible CPU today from AMD or Intel often has dozens or >even hundreds of errata... also note that for years now Intel and AMD have >make some of their CPUs "soft" so that microcode updates applied at boot by >the BIOS can fix some of the problems...) The whole idea behind Verilog and in particular, VHDL, is design correctness and verification. It's *not* software, though I've seen enough managers who believe it is (and assign C programmers to logic design <shudder>). The issue is not one of "mindset" that all designs have bugs, rather that all designs are so complicated that it becomes impossible to test every combination of features. All of our designs were in VHDL and the simulation environment (architecture models, simulator, and "test benches") was C++. Much of the verification started out with random settings of registers and random sequences of instructions. This works well for CPU sorts of things, where pretty much any sequence of instructions and data will produce "interesting" results. It tends to get messy when working with I/O, where many settings and data combinations will cause failures (It hurts when I do that => don't do that). Verification is not a simple problem. It's also often seen as a necessary evil and swept under the carpet.
From: JosephKK on 10 May 2010 03:01 On Sun, 09 May 2010 22:37:35 -0500, "krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote: >On Sun, 09 May 2010 16:06:33 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: > >>On Fri, 07 May 2010 17:57:31 -0500, "krw(a)att.bizzzzzzzzzzzz" >><krw(a)att.bizzzzzzzzzzzz> wrote: >> >>>On Fri, 07 May 2010 14:16:26 -0400, Spehro Pefhany >>><speffSNIP(a)interlogDOTyou.knowwhat> wrote: >>> >>>>On Fri, 07 May 2010 09:27:35 -0700, John Larkin >>>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>> >>>>> >>>>>That's pretty bad. But uPs are getting so complex, so overloaded with >>>>>features, that the designers are sort of shoveling hunks of home-made >>>>>or purchased IP into compilers and hoping for the best. And, >>>>>apparently, not taking much time to simulate and verify. Or document! >>>>>We had to do a bunch of experiments on the SPI interface on our NXP >>>>>ARMs; even high-level support people couldn't answer some fundamental >>>>>timing/framing questions. The SPI and ADC documentation is awful. >>>>> >>>>>We use ARM chips that have 30-character pin names, the pin functions >>>>>are so overloaded. >>>> >>>>Who's are you using now? We're getting going with the Luminary parts. >>>> >>>>>What would be nice would be if things like SPI were small RAM-driven >>>>>microengines. Then the functionality would be in loadable code, not >>>>>hard-wired silicon. Sort of like Motorola's TPU blocks. They could be >>>>>repurposed, too. >>>>> >>>>>John >>>> >>>>You'd think it would be relatively simple to put a thin FPGA or CPLD >>>>fabric around the core, perhaps preloaded from ROM with some useful >>>>defaults. >>> >>>That's a lot easier said than done. First, X, A, and A have most of the IP >>>locked up for FPGA sorts of things. Second, the development software for such >>>things is non-trivial. Great idea, but not likely to fly. >> >>PALs and small FPGAs have been around over 30 years. If you limit to not >>much more tech, all the patents should be expired. > >A lot of the simple stuff, sure. Not sure about all the RAM and other special >functions. > >>Atmel, Freescale, >>Microchip, etc., all have nice multiplexing tech for the multifunction >>pins. > >How does this apply? The underlying idea of using some programmable logic rather than Special Function registers to select or even perform the various pin functions. It could even be in a separate program space. This could really help with all of the various serial busses that are popular now. It may even allow better allocation of ADC/DAC I/O.
From: krw on 10 May 2010 18:30 On Mon, 10 May 2010 00:01:26 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: >On Sun, 09 May 2010 22:37:35 -0500, "krw(a)att.bizzzzzzzzzzzz" ><krw(a)att.bizzzzzzzzzzzz> wrote: > >>On Sun, 09 May 2010 16:06:33 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: >> >>>On Fri, 07 May 2010 17:57:31 -0500, "krw(a)att.bizzzzzzzzzzzz" >>><krw(a)att.bizzzzzzzzzzzz> wrote: >>> >>>>On Fri, 07 May 2010 14:16:26 -0400, Spehro Pefhany >>>><speffSNIP(a)interlogDOTyou.knowwhat> wrote: >>>> >>>>>On Fri, 07 May 2010 09:27:35 -0700, John Larkin >>>>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>>> >>>>>> >>>>>>That's pretty bad. But uPs are getting so complex, so overloaded with >>>>>>features, that the designers are sort of shoveling hunks of home-made >>>>>>or purchased IP into compilers and hoping for the best. And, >>>>>>apparently, not taking much time to simulate and verify. Or document! >>>>>>We had to do a bunch of experiments on the SPI interface on our NXP >>>>>>ARMs; even high-level support people couldn't answer some fundamental >>>>>>timing/framing questions. The SPI and ADC documentation is awful. >>>>>> >>>>>>We use ARM chips that have 30-character pin names, the pin functions >>>>>>are so overloaded. >>>>> >>>>>Who's are you using now? We're getting going with the Luminary parts. >>>>> >>>>>>What would be nice would be if things like SPI were small RAM-driven >>>>>>microengines. Then the functionality would be in loadable code, not >>>>>>hard-wired silicon. Sort of like Motorola's TPU blocks. They could be >>>>>>repurposed, too. >>>>>> >>>>>>John >>>>> >>>>>You'd think it would be relatively simple to put a thin FPGA or CPLD >>>>>fabric around the core, perhaps preloaded from ROM with some useful >>>>>defaults. >>>> >>>>That's a lot easier said than done. First, X, A, and A have most of the IP >>>>locked up for FPGA sorts of things. Second, the development software for such >>>>things is non-trivial. Great idea, but not likely to fly. >>> >>>PALs and small FPGAs have been around over 30 years. If you limit to not >>>much more tech, all the patents should be expired. >> >>A lot of the simple stuff, sure. Not sure about all the RAM and other special >>functions. >> >>>Atmel, Freescale, >>>Microchip, etc., all have nice multiplexing tech for the multifunction >>>pins. >> >>How does this apply? > >The underlying idea of using some programmable logic rather than Special >Function registers to select or even perform the various pin functions. >It could even be in a separate program space. This could really help >with all of the various serial busses that are popular now. I don't see how Muxes are all that big of a deal, particularly after you have FPGA fabric connected to the I/O. >It may even allow better allocation of ADC/DAC I/O. Some have routable analogs, most restrict the pins these functions are on very tightly.
From: JosephKK on 11 May 2010 00:31
On Mon, 10 May 2010 17:30:21 -0500, "krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote: >On Mon, 10 May 2010 00:01:26 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: > >>On Sun, 09 May 2010 22:37:35 -0500, "krw(a)att.bizzzzzzzzzzzz" >><krw(a)att.bizzzzzzzzzzzz> wrote: >> >>>On Sun, 09 May 2010 16:06:33 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: >>> >>>>On Fri, 07 May 2010 17:57:31 -0500, "krw(a)att.bizzzzzzzzzzzz" >>>><krw(a)att.bizzzzzzzzzzzz> wrote: >>>> >>>>>On Fri, 07 May 2010 14:16:26 -0400, Spehro Pefhany >>>>><speffSNIP(a)interlogDOTyou.knowwhat> wrote: >>>>> >>>>>>On Fri, 07 May 2010 09:27:35 -0700, John Larkin >>>>>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>>>> >>>>>>> >>>>>>>That's pretty bad. But uPs are getting so complex, so overloaded with >>>>>>>features, that the designers are sort of shoveling hunks of home-made >>>>>>>or purchased IP into compilers and hoping for the best. And, >>>>>>>apparently, not taking much time to simulate and verify. Or document! >>>>>>>We had to do a bunch of experiments on the SPI interface on our NXP >>>>>>>ARMs; even high-level support people couldn't answer some fundamental >>>>>>>timing/framing questions. The SPI and ADC documentation is awful. >>>>>>> >>>>>>>We use ARM chips that have 30-character pin names, the pin functions >>>>>>>are so overloaded. >>>>>> >>>>>>Who's are you using now? We're getting going with the Luminary parts. >>>>>> >>>>>>>What would be nice would be if things like SPI were small RAM-driven >>>>>>>microengines. Then the functionality would be in loadable code, not >>>>>>>hard-wired silicon. Sort of like Motorola's TPU blocks. They could be >>>>>>>repurposed, too. >>>>>>> >>>>>>>John >>>>>> >>>>>>You'd think it would be relatively simple to put a thin FPGA or CPLD >>>>>>fabric around the core, perhaps preloaded from ROM with some useful >>>>>>defaults. >>>>> >>>>>That's a lot easier said than done. First, X, A, and A have most of the IP >>>>>locked up for FPGA sorts of things. Second, the development software for such >>>>>things is non-trivial. Great idea, but not likely to fly. >>>> >>>>PALs and small FPGAs have been around over 30 years. If you limit to not >>>>much more tech, all the patents should be expired. >>> >>>A lot of the simple stuff, sure. Not sure about all the RAM and other special >>>functions. >>> >>>>Atmel, Freescale, >>>>Microchip, etc., all have nice multiplexing tech for the multifunction >>>>pins. >>> >>>How does this apply? >> >>The underlying idea of using some programmable logic rather than Special >>Function registers to select or even perform the various pin functions. >>It could even be in a separate program space. This could really help >>with all of the various serial busses that are popular now. > >I don't see how Muxes are all that big of a deal, particularly after you have >FPGA fabric connected to the I/O. To maintain any analog capability it would have to be at least one transmission gate (analog switch) remove. > >>It may even allow better allocation of ADC/DAC I/O. > >Some have routable analogs, most restrict the pins these functions are on very >tightly. The CPLD layer could allow lesser restrictions, which may then allow more convenient routing of the board. |