On 2019-03-28 Tim wrote in comp.arch.fpga:> On 28/03/2019 12:28, Stef wrote: >> We have a product that includes a small parallel OTP memory. These devices >> get very hard to get and no easy alternative is available that fits in the >> very small available space. A PLCC32 EPROM will not fit unfortunately. >> Since the memory array is small (256x4 bits), I was thinking this could >> easily fit into a CPLD or FPGA. But how to program this? >> >> The memory is used for calibration data. So in production, the device is >> characterized, data block is calculated and programmed. >> >> Usually you use the vendor tools to generate a bitstream from an HDL >> design. But are there options to generate these bitstreams during the >> production cycle, in only a few seconds? Something like HDL + DATA = >> BITSTREAM. And then burn the resulting bitsream in the device. >> >> A device like the Lattice ispMACH 4000 seems a possible candidate. >> > > CAT34C02? 2Kb I2C EEPROM, small, cheap, commodity, can be locked by > software, OK at 3.3V and 5V. Not as amusing as a CPLD.This is a serial interface EEPROM, plenty of those around. The required parallel interface is harder to find unfortunately. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Murphy was an optimist.
Replaceme EPROM by CPLD/FPGA
Started by ●March 28, 2019
Reply by ●March 28, 20192019-03-28
Reply by ●March 28, 20192019-03-28
Den 2019-03-28 kl. 15:24, skrev Stef:> On 2019-03-28 Theo wrote in comp.arch.fpga: >> Stef <stef33d@yahooi-n-v-a-l-i-d.com.invalid> wrote: >>> Usually you use the vendor tools to generate a bitstream from an HDL >>> design. But are there options to generate these bitstreams during the >>> production cycle, in only a few seconds? Something like HDL + DATA = >>> BITSTREAM. And then burn the resulting bitsream in the device. >> >> Intel Quartus has an 'Update Memory Initialization File' step where you can >> change the memory contents of an existing project without recompiling. I >> don't know how much project scaffolding you'd need (you still need to run >> the Assembler step to generate bitfiles afterwards, so I don't think you can >> edit an existing bitfile). It's not super quick (maybe ten seconds for a >> Cyclone V) but better than a recompile. >> >> I think some of the Lattice parts have a user flash memory but I haven't >> used those: >> http://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.ashx?document_id=39086 >> >> I suppose another option is a small SPI/I2C flash chip and a CPLD that reads >> the contents in at powerup time. Or a NOR flash that you can program >> externally (but programming header with 8 address, 4 data, 3 control wires - >> might be too big) or another chip to drive them (I2C I/O expander for >> instance and a 3/4 pin header) >> >>> A device like the Lattice ispMACH 4000 seems a possible candidate. >> >> Does your old design have voltage requirements like 5V capability? > > The supply is 5V, but the interface on the reading device is 3V3 with 5V > tolerant IO. So adding 3V3 regulation for the memory power should work. > > Another limitation is that that the preferred programming interface is > through the available connections: Address (8), data (4), control (1 + > 1 tied to GND, and VCC rising to VPP). And there are 2 free pins that could > be used as well. > > This is a reason why parallel EEPROM (FLASH) is not an option. Those > devices all require access to all address and data to enter the programming > sequence. (or do you know a flash that does not require this?) > Or use a CPLD to generate those sequences? (based on the states of the free > pins?) >What is reading from the EPROM? What is the bus speed of the access? I would not be surprised, if you could not implement this with a microcontroller running at a decent clock frequency. A small Cortex-M0 chip like the ATSAMD10xxxx in a 20 - 32 pin package should be small The program will look like this: while (1) { port = memory[pins & 0xff]; oe = (pins & 0x100) ? ON : OFF; } AP
Reply by ●March 28, 20192019-03-28
On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote:> Den 2019-03-28 kl. 15:24, skrev Stef: > > On 2019-03-28 Theo wrote in comp.arch.fpga: > >> Stef <stef33d@yahooi-n-v-a-l-i-d.com.invalid> wrote: > >>> Usually you use the vendor tools to generate a bitstream from an HDL > >>> design. But are there options to generate these bitstreams during the > >>> production cycle, in only a few seconds? Something like HDL + DATA = > >>> BITSTREAM. And then burn the resulting bitsream in the device. > >> > >> Intel Quartus has an 'Update Memory Initialization File' step where you can > >> change the memory contents of an existing project without recompiling. I > >> don't know how much project scaffolding you'd need (you still need to run > >> the Assembler step to generate bitfiles afterwards, so I don't think you can > >> edit an existing bitfile). It's not super quick (maybe ten seconds for a > >> Cyclone V) but better than a recompile. > >> > >> I think some of the Lattice parts have a user flash memory but I haven't > >> used those: > >> http://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.ashx?document_id=39086 > >> > >> I suppose another option is a small SPI/I2C flash chip and a CPLD that reads > >> the contents in at powerup time. Or a NOR flash that you can program > >> externally (but programming header with 8 address, 4 data, 3 control wires - > >> might be too big) or another chip to drive them (I2C I/O expander for > >> instance and a 3/4 pin header) > >> > >>> A device like the Lattice ispMACH 4000 seems a possible candidate. > >> > >> Does your old design have voltage requirements like 5V capability? > > > > The supply is 5V, but the interface on the reading device is 3V3 with 5V > > tolerant IO. So adding 3V3 regulation for the memory power should work. > > > > Another limitation is that that the preferred programming interface is > > through the available connections: Address (8), data (4), control (1 + > > 1 tied to GND, and VCC rising to VPP). And there are 2 free pins that could > > be used as well. > > > > This is a reason why parallel EEPROM (FLASH) is not an option. Those > > devices all require access to all address and data to enter the programming > > sequence. (or do you know a flash that does not require this?) > > Or use a CPLD to generate those sequences? (based on the states of the free > > pins?) > > > What is reading from the EPROM? > What is the bus speed of the access? > > I would not be surprised, if you could not implement this with a > microcontroller running at a decent clock frequency. > > A small Cortex-M0 chip like the ATSAMD10xxxx in a 20 - 32 pin package > should be small > > The program will look like this: > while (1) { > port = memory[pins & 0xff]; > oe = (pins & 0x100) ? ON : OFF; > } > > API find it interesting that people often feel MCUs are simpler than programmable logic. What your program in particular lacks is the important part, allowing the contents of "memory[]" to be set at manufacturing time. I don't see the use of an MCU to be at all simple. In addition to the above, there is setup code that either needs to be written from scratch by reading the MCU data sheet (starting clocks, initialize I/O banks, brown out detectors, etc., etc...) or by starting with the standard startup code and paring out what is not needed or appropriate. To me, this is inordinately complex compared to the relatively trivial exercise of creating an HDL ROM which is about as complex as the code above and setting the details of the chosen I/O pins to be used. The only remaining issue is to use the vendor tool to initialize this ROM in the compiled code or even in the same way it is done now which I think is done by the board itself. Not only is the PLD method simpler, it provides a lot more flexibility. -- Rick C. -- Get a 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209
Reply by ●March 28, 20192019-03-28
torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gmail.com:> On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote: > > Den 2019-03-28 kl. 15:24, skrev Stef: > > > On 2019-03-28 Theo wrote in comp.arch.fpga: > > >> Stef <stef33d@yahooi-n-v-a-l-i-d.com.invalid> wrote: > > >>> Usually you use the vendor tools to generate a bitstream from an HDL > > >>> design. But are there options to generate these bitstreams during the > > >>> production cycle, in only a few seconds? Something like HDL + DATA = > > >>> BITSTREAM. And then burn the resulting bitsream in the device. > > >> > > >> Intel Quartus has an 'Update Memory Initialization File' step where you can > > >> change the memory contents of an existing project without recompiling. I > > >> don't know how much project scaffolding you'd need (you still need to run > > >> the Assembler step to generate bitfiles afterwards, so I don't think you can > > >> edit an existing bitfile). It's not super quick (maybe ten seconds for a > > >> Cyclone V) but better than a recompile. > > >> > > >> I think some of the Lattice parts have a user flash memory but I haven't > > >> used those: > > >> http://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.ashx?document_id=39086 > > >> > > >> I suppose another option is a small SPI/I2C flash chip and a CPLD that reads > > >> the contents in at powerup time. Or a NOR flash that you can program > > >> externally (but programming header with 8 address, 4 data, 3 control wires - > > >> might be too big) or another chip to drive them (I2C I/O expander for > > >> instance and a 3/4 pin header) > > >> > > >>> A device like the Lattice ispMACH 4000 seems a possible candidate. > > >> > > >> Does your old design have voltage requirements like 5V capability? > > > > > > The supply is 5V, but the interface on the reading device is 3V3 with 5V > > > tolerant IO. So adding 3V3 regulation for the memory power should work. > > > > > > Another limitation is that that the preferred programming interface is > > > through the available connections: Address (8), data (4), control (1 + > > > 1 tied to GND, and VCC rising to VPP). And there are 2 free pins that could > > > be used as well. > > > > > > This is a reason why parallel EEPROM (FLASH) is not an option. Those > > > devices all require access to all address and data to enter the programming > > > sequence. (or do you know a flash that does not require this?) > > > Or use a CPLD to generate those sequences? (based on the states of the free > > > pins?) > > > > > What is reading from the EPROM? > > What is the bus speed of the access? > > > > I would not be surprised, if you could not implement this with a > > microcontroller running at a decent clock frequency. > > > > A small Cortex-M0 chip like the ATSAMD10xxxx in a 20 - 32 pin package > > should be small > > > > The program will look like this: > > while (1) { > > port = memory[pins & 0xff]; > > oe = (pins & 0x100) ? ON : OFF; > > } > > > > AP > > I find it interesting that people often feel MCUs are simpler than programmable logic. What your program in particular lacks is the important part, allowing the contents of "memory[]" to be set at manufacturing time. I don't see the use of an MCU to be at all simple. In addition to the above, there is setup code that either needs to be written from scratch by reading the MCU data sheet (starting clocks, initialize I/O banks, brown out detectors, etc., etc...) or by starting with the standard startup code and paring out what is not needed or appropriate. > > To me, this is inordinately complex compared to the relatively trivial exercise of creating an HDL ROM which is about as complex as the code above and setting the details of the chosen I/O pins to be used. The only remaining issue is to use the vendor tool to initialize this ROM in the compiled code or even in the same way it is done now which I think is done by the board itself. > > Not only is the PLD method simpler, it provides a lot more flexibility.if the only thing in your toolbox it hammers, nailing things together always seem like the obvious choice at slow speed an mcu could be just as viable, and customizing the array could be as simple as patching the bin or hex file programmed into the part
Reply by ●March 28, 20192019-03-28
On Thursday, March 28, 2019 at 6:16:28 PM UTC-4, lasselangwad...@gmail.com wrote:> torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gmail.com: > > On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote: > > > Den 2019-03-28 kl. 15:24, skrev Stef: > > > > On 2019-03-28 Theo wrote in comp.arch.fpga: > > > >> Stef <stef33d@yahooi-n-v-a-l-i-d.com.invalid> wrote: > > > >>> Usually you use the vendor tools to generate a bitstream from an HDL > > > >>> design. But are there options to generate these bitstreams during the > > > >>> production cycle, in only a few seconds? Something like HDL + DATA = > > > >>> BITSTREAM. And then burn the resulting bitsream in the device. > > > >> > > > >> Intel Quartus has an 'Update Memory Initialization File' step where you can > > > >> change the memory contents of an existing project without recompiling. I > > > >> don't know how much project scaffolding you'd need (you still need to run > > > >> the Assembler step to generate bitfiles afterwards, so I don't think you can > > > >> edit an existing bitfile). It's not super quick (maybe ten seconds for a > > > >> Cyclone V) but better than a recompile. > > > >> > > > >> I think some of the Lattice parts have a user flash memory but I haven't > > > >> used those: > > > >> http://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.ashx?document_id=39086 > > > >> > > > >> I suppose another option is a small SPI/I2C flash chip and a CPLD that reads > > > >> the contents in at powerup time. Or a NOR flash that you can program > > > >> externally (but programming header with 8 address, 4 data, 3 control wires - > > > >> might be too big) or another chip to drive them (I2C I/O expander for > > > >> instance and a 3/4 pin header) > > > >> > > > >>> A device like the Lattice ispMACH 4000 seems a possible candidate. > > > >> > > > >> Does your old design have voltage requirements like 5V capability? > > > > > > > > The supply is 5V, but the interface on the reading device is 3V3 with 5V > > > > tolerant IO. So adding 3V3 regulation for the memory power should work. > > > > > > > > Another limitation is that that the preferred programming interface is > > > > through the available connections: Address (8), data (4), control (1 + > > > > 1 tied to GND, and VCC rising to VPP). And there are 2 free pins that could > > > > be used as well. > > > > > > > > This is a reason why parallel EEPROM (FLASH) is not an option. Those > > > > devices all require access to all address and data to enter the programming > > > > sequence. (or do you know a flash that does not require this?) > > > > Or use a CPLD to generate those sequences? (based on the states of the free > > > > pins?) > > > > > > > What is reading from the EPROM? > > > What is the bus speed of the access? > > > > > > I would not be surprised, if you could not implement this with a > > > microcontroller running at a decent clock frequency. > > > > > > A small Cortex-M0 chip like the ATSAMD10xxxx in a 20 - 32 pin package > > > should be small > > > > > > The program will look like this: > > > while (1) { > > > port = memory[pins & 0xff]; > > > oe = (pins & 0x100) ? ON : OFF; > > > } > > > > > > AP > > > > I find it interesting that people often feel MCUs are simpler than programmable logic. What your program in particular lacks is the important part, allowing the contents of "memory[]" to be set at manufacturing time. I don't see the use of an MCU to be at all simple. In addition to the above, there is setup code that either needs to be written from scratch by reading the MCU data sheet (starting clocks, initialize I/O banks, brown out detectors, etc., etc...) or by starting with the standard startup code and paring out what is not needed or appropriate. > > > > To me, this is inordinately complex compared to the relatively trivial exercise of creating an HDL ROM which is about as complex as the code above and setting the details of the chosen I/O pins to be used. The only remaining issue is to use the vendor tool to initialize this ROM in the compiled code or even in the same way it is done now which I think is done by the board itself. > > > > Not only is the PLD method simpler, it provides a lot more flexibility. > > if the only thing in your toolbox it hammers, nailing things together always > seem like the obvious choice > > at slow speed an mcu could be just as viable, and customizing the array could > be as simple as patching the bin or hex file programmed into the partBut you didn't address the additional setup required to write the code for the MCU. The ones I've used have a *lot* of features that need to be set up for the MCU to even run. MCU code is always a lot more complex to design with than HDL in my experience. "Patching" a hex file is not the way I want to manage configuration data. The PLD tools have already dealt with this issue. -- Rick C. -+ Get a 1,000 miles of free Supercharging -+ Tesla referral code - https://ts.la/richard11209
Reply by ●March 28, 20192019-03-28
fredag den 29. marts 2019 kl. 00.03.22 UTC+1 skrev gnuarm.de...@gmail.com:> On Thursday, March 28, 2019 at 6:16:28 PM UTC-4, lasselangwad...@gmail.com wrote: > > torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gmail.com: > > > On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote: > > > > Den 2019-03-28 kl. 15:24, skrev Stef: > > > > > On 2019-03-28 Theo wrote in comp.arch.fpga: > > > > >> Stef <stef33d@yahooi-n-v-a-l-i-d.com.invalid> wrote: > > > > >>> Usually you use the vendor tools to generate a bitstream from an HDL > > > > >>> design. But are there options to generate these bitstreams during the > > > > >>> production cycle, in only a few seconds? Something like HDL + DATA = > > > > >>> BITSTREAM. And then burn the resulting bitsream in the device. > > > > >> > > > > >> Intel Quartus has an 'Update Memory Initialization File' step where you can > > > > >> change the memory contents of an existing project without recompiling. I > > > > >> don't know how much project scaffolding you'd need (you still need to run > > > > >> the Assembler step to generate bitfiles afterwards, so I don't think you can > > > > >> edit an existing bitfile). It's not super quick (maybe ten seconds for a > > > > >> Cyclone V) but better than a recompile. > > > > >> > > > > >> I think some of the Lattice parts have a user flash memory but I haven't > > > > >> used those: > > > > >> http://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.ashx?document_id=39086 > > > > >> > > > > >> I suppose another option is a small SPI/I2C flash chip and a CPLD that reads > > > > >> the contents in at powerup time. Or a NOR flash that you can program > > > > >> externally (but programming header with 8 address, 4 data, 3 control wires - > > > > >> might be too big) or another chip to drive them (I2C I/O expander for > > > > >> instance and a 3/4 pin header) > > > > >> > > > > >>> A device like the Lattice ispMACH 4000 seems a possible candidate. > > > > >> > > > > >> Does your old design have voltage requirements like 5V capability? > > > > > > > > > > The supply is 5V, but the interface on the reading device is 3V3 with 5V > > > > > tolerant IO. So adding 3V3 regulation for the memory power should work. > > > > > > > > > > Another limitation is that that the preferred programming interface is > > > > > through the available connections: Address (8), data (4), control (1 + > > > > > 1 tied to GND, and VCC rising to VPP). And there are 2 free pins that could > > > > > be used as well. > > > > > > > > > > This is a reason why parallel EEPROM (FLASH) is not an option. Those > > > > > devices all require access to all address and data to enter the programming > > > > > sequence. (or do you know a flash that does not require this?) > > > > > Or use a CPLD to generate those sequences? (based on the states of the free > > > > > pins?) > > > > > > > > > What is reading from the EPROM? > > > > What is the bus speed of the access? > > > > > > > > I would not be surprised, if you could not implement this with a > > > > microcontroller running at a decent clock frequency. > > > > > > > > A small Cortex-M0 chip like the ATSAMD10xxxx in a 20 - 32 pin package > > > > should be small > > > > > > > > The program will look like this: > > > > while (1) { > > > > port = memory[pins & 0xff]; > > > > oe = (pins & 0x100) ? ON : OFF; > > > > } > > > > > > > > AP > > > > > > I find it interesting that people often feel MCUs are simpler than programmable logic. What your program in particular lacks is the important part, allowing the contents of "memory[]" to be set at manufacturing time. I don't see the use of an MCU to be at all simple. In addition to the above, there is setup code that either needs to be written from scratch by reading the MCU data sheet (starting clocks, initialize I/O banks, brown out detectors, etc., etc...) or by starting with the standard startup code and paring out what is not needed or appropriate. > > > > > > To me, this is inordinately complex compared to the relatively trivial exercise of creating an HDL ROM which is about as complex as the code above and setting the details of the chosen I/O pins to be used. The only remaining issue is to use the vendor tool to initialize this ROM in the compiled code or even in the same way it is done now which I think is done by the board itself. > > > > > > Not only is the PLD method simpler, it provides a lot more flexibility. > > > > if the only thing in your toolbox it hammers, nailing things together always > > seem like the obvious choice > > > > at slow speed an mcu could be just as viable, and customizing the array could > > be as simple as patching the bin or hex file programmed into the part > > But you didn't address the additional setup required to write the code for the MCU. The ones I've used have a *lot* of features that need to be set up for the MCU to even run. MCU code is always a lot more complex to design with than HDL in my experience.so you have only used big MCUs with piles of peripherals and advanced features, small 8bitters are usually nothing like that> > "Patching" a hex file is not the way I want to manage configuration data. The PLD tools have already dealt with this issue. >doing exactly the same thing, replacing the data
Reply by ●March 28, 20192019-03-28
On Thursday, March 28, 2019 at 7:27:58 PM UTC-4, lasselangwad...@gmail.com wrote:> fredag den 29. marts 2019 kl. 00.03.22 UTC+1 skrev gnuarm.de...@gmail.com: > > On Thursday, March 28, 2019 at 6:16:28 PM UTC-4, lasselangwad...@gmail.com wrote: > > > torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gmail.com: > > > > On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote: > > > > > Den 2019-03-28 kl. 15:24, skrev Stef: > > > > > > On 2019-03-28 Theo wrote in comp.arch.fpga: > > > > > >> Stef <stef33d@yahooi-n-v-a-l-i-d.com.invalid> wrote: > > > > > >>> Usually you use the vendor tools to generate a bitstream from an HDL > > > > > >>> design. But are there options to generate these bitstreams during the > > > > > >>> production cycle, in only a few seconds? Something like HDL + DATA = > > > > > >>> BITSTREAM. And then burn the resulting bitsream in the device. > > > > > >> > > > > > >> Intel Quartus has an 'Update Memory Initialization File' step where you can > > > > > >> change the memory contents of an existing project without recompiling. I > > > > > >> don't know how much project scaffolding you'd need (you still need to run > > > > > >> the Assembler step to generate bitfiles afterwards, so I don't think you can > > > > > >> edit an existing bitfile). It's not super quick (maybe ten seconds for a > > > > > >> Cyclone V) but better than a recompile. > > > > > >> > > > > > >> I think some of the Lattice parts have a user flash memory but I haven't > > > > > >> used those: > > > > > >> http://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.ashx?document_id=39086 > > > > > >> > > > > > >> I suppose another option is a small SPI/I2C flash chip and a CPLD that reads > > > > > >> the contents in at powerup time. Or a NOR flash that you can program > > > > > >> externally (but programming header with 8 address, 4 data, 3 control wires - > > > > > >> might be too big) or another chip to drive them (I2C I/O expander for > > > > > >> instance and a 3/4 pin header) > > > > > >> > > > > > >>> A device like the Lattice ispMACH 4000 seems a possible candidate. > > > > > >> > > > > > >> Does your old design have voltage requirements like 5V capability? > > > > > > > > > > > > The supply is 5V, but the interface on the reading device is 3V3 with 5V > > > > > > tolerant IO. So adding 3V3 regulation for the memory power should work. > > > > > > > > > > > > Another limitation is that that the preferred programming interface is > > > > > > through the available connections: Address (8), data (4), control (1 + > > > > > > 1 tied to GND, and VCC rising to VPP). And there are 2 free pins that could > > > > > > be used as well. > > > > > > > > > > > > This is a reason why parallel EEPROM (FLASH) is not an option. Those > > > > > > devices all require access to all address and data to enter the programming > > > > > > sequence. (or do you know a flash that does not require this?) > > > > > > Or use a CPLD to generate those sequences? (based on the states of the free > > > > > > pins?) > > > > > > > > > > > What is reading from the EPROM? > > > > > What is the bus speed of the access? > > > > > > > > > > I would not be surprised, if you could not implement this with a > > > > > microcontroller running at a decent clock frequency. > > > > > > > > > > A small Cortex-M0 chip like the ATSAMD10xxxx in a 20 - 32 pin package > > > > > should be small > > > > > > > > > > The program will look like this: > > > > > while (1) { > > > > > port = memory[pins & 0xff]; > > > > > oe = (pins & 0x100) ? ON : OFF; > > > > > } > > > > > > > > > > AP > > > > > > > > I find it interesting that people often feel MCUs are simpler than programmable logic. What your program in particular lacks is the important part, allowing the contents of "memory[]" to be set at manufacturing time. I don't see the use of an MCU to be at all simple. In addition to the above, there is setup code that either needs to be written from scratch by reading the MCU data sheet (starting clocks, initialize I/O banks, brown out detectors, etc., etc...) or by starting with the standard startup code and paring out what is not needed or appropriate. > > > > > > > > To me, this is inordinately complex compared to the relatively trivial exercise of creating an HDL ROM which is about as complex as the code above and setting the details of the chosen I/O pins to be used. The only remaining issue is to use the vendor tool to initialize this ROM in the compiled code or even in the same way it is done now which I think is done by the board itself. > > > > > > > > Not only is the PLD method simpler, it provides a lot more flexibility. > > > > > > if the only thing in your toolbox it hammers, nailing things together always > > > seem like the obvious choice > > > > > > at slow speed an mcu could be just as viable, and customizing the array could > > > be as simple as patching the bin or hex file programmed into the part > > > > But you didn't address the additional setup required to write the code for the MCU. The ones I've used have a *lot* of features that need to be set up for the MCU to even run. MCU code is always a lot more complex to design with than HDL in my experience. > > > so you have only used big MCUs with piles of peripherals and advanced features, small 8bitters are usually nothing like that > > > > > "Patching" a hex file is not the way I want to manage configuration data. The PLD tools have already dealt with this issue. > > > > doing exactly the same thing, replacing the dataSo there is a tool for patching the hex data? You don't need any startup code on your small 8 bitter? I think you are being a bit disingenuous about the patching issue. The MCU tools I've worked with would require quite a bit of work to replace data in binary code. -- Rick C. +- Get a 1,000 miles of free Supercharging +- Tesla referral code - https://ts.la/richard11209
Reply by ●March 29, 20192019-03-29
On 2019-03-29 gnuarm.deletethisbit@gmail.com wrote in comp.arch.fpga:> On Thursday, March 28, 2019 at 7:27:58 PM UTC-4, lasselangwad...@gmail.com wrote: >> fredag den 29. marts 2019 kl. 00.03.22 UTC+1 skrev gnuarm.de...@gmail.com: >> > On Thursday, March 28, 2019 at 6:16:28 PM UTC-4, lasselangwad...@gmail.com wrote: >> > > torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gmail.com: >> > > > On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote: >> > > > > Den 2019-03-28 kl. 15:24, skrev Stef: >> > > > > > On 2019-03-28 Theo wrote in comp.arch.fpga: >> > > > > >> Stef <stef33d@yahooi-n-v-a-l-i-d.com.invalid> wrote: >> > > > > >>> Usually you use the vendor tools to generate a bitstream from an HDL >> > > > > >>> design. But are there options to generate these bitstreams during the >> > > > > >>> production cycle, in only a few seconds? Something like HDL + DATA = >> > > > > >>> BITSTREAM. And then burn the resulting bitsream in the device. >> > > > > >> >> > > > > >> Intel Quartus has an 'Update Memory Initialization File' step where you can >> > > > > >> change the memory contents of an existing project without recompiling. I >> > > > > >> don't know how much project scaffolding you'd need (you still need to run >> > > > > >> the Assembler step to generate bitfiles afterwards, so I don't think you can >> > > > > >> edit an existing bitfile). It's not super quick (maybe ten seconds for a >> > > > > >> Cyclone V) but better than a recompile. >> > > > > >> >> > > > > >> I think some of the Lattice parts have a user flash memory but I haven't >> > > > > >> used those: >> > > > > >> http://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.ashx?document_id=39086 >> > > > > >> >> > > > > >> I suppose another option is a small SPI/I2C flash chip and a CPLD that reads >> > > > > >> the contents in at powerup time. Or a NOR flash that you can program >> > > > > >> externally (but programming header with 8 address, 4 data, 3 control wires - >> > > > > >> might be too big) or another chip to drive them (I2C I/O expander for >> > > > > >> instance and a 3/4 pin header) >> > > > > >> >> > > > > >>> A device like the Lattice ispMACH 4000 seems a possible candidate. >> > > > > >> >> > > > > >> Does your old design have voltage requirements like 5V capability? >> > > > > > >> > > > > > The supply is 5V, but the interface on the reading device is 3V3 with 5V >> > > > > > tolerant IO. So adding 3V3 regulation for the memory power should work. >> > > > > > >> > > > > > Another limitation is that that the preferred programming interface is >> > > > > > through the available connections: Address (8), data (4), control (1 + >> > > > > > 1 tied to GND, and VCC rising to VPP). And there are 2 free pins that could >> > > > > > be used as well. >> > > > > > >> > > > > > This is a reason why parallel EEPROM (FLASH) is not an option. Those >> > > > > > devices all require access to all address and data to enter the programming >> > > > > > sequence. (or do you know a flash that does not require this?) >> > > > > > Or use a CPLD to generate those sequences? (based on the states of the free >> > > > > > pins?) >> > > > > > >> > > > > What is reading from the EPROM? >> > > > > What is the bus speed of the access? >> > > > > >> > > > > I would not be surprised, if you could not implement this with a >> > > > > microcontroller running at a decent clock frequency. >> > > > > >> > > > > A small Cortex-M0 chip like the ATSAMD10xxxx in a 20 - 32 pin package >> > > > > should be small >> > > > > >> > > > > The program will look like this: >> > > > > while (1) { >> > > > > port = memory[pins & 0xff]; >> > > > > oe = (pins & 0x100) ? ON : OFF; >> > > > > } >> > > > > >> > > > > AP >> > > > >> > > > I find it interesting that people often feel MCUs are simpler than programmable logic. What your program in particular lacks is the important part, allowing the contents of "memory[]" to be set at manufacturing time. I don't see the use of an MCU to be at all simple. In addition to the above, there is setup code that either needs to be written from scratch by reading the MCU data sheet (starting clocks, initialize I/O banks, brown out detectors, etc., etc...) or by starting with the standard startup code and paring out what is not needed or appropriate. >> > > > >> > > > To me, this is inordinately complex compared to the relatively trivial exercise of creating an HDL ROM which is about as complex as the code above and setting the details of the chosen I/O pins to be used. The only remaining issue is to use the vendor tool to initialize this ROM in the compiled code or even in the same way it is done now which I think is done by the board itself.No, 'the board' is connector + PROM on a very small piece of FR4, programmed in a universal programmer. There is already software generating the data to be programmed. And yes, an MCU is a possibility as well. And as I am much more comfortable in programming MCU's, I think I can handle the software involved for MCU and data generation. ;-) But I see a CPLD (or FPGA) as a solution as well and was wondering how I would approach such a solution. That why I asked in an FPGA group.>> > > > >> > > > Not only is the PLD method simpler, it provides a lot more flexibility. >> > > >> > > if the only thing in your toolbox it hammers, nailing things together always >> > > seem like the obvious choice >> > > >> > > at slow speed an mcu could be just as viable, and customizing the array could >> > > be as simple as patching the bin or hex file programmed into the part >> > >> > But you didn't address the additional setup required to write the code for the MCU. The ones I've used have a *lot* of features that need to be set up for the MCU to even run. MCU code is always a lot more complex to design with than HDL in my experience. >> >> >> so you have only used big MCUs with piles of peripherals and advanced features, small 8bitters are usually nothing like that >> >> > >> > "Patching" a hex file is not the way I want to manage configuration data. The PLD tools have already dealt with this issue. >> > >> >> doing exactly the same thing, replacing the data > > So there is a tool for patching the hex data? You don't need any startup code on your small 8 bitter?Startup usually comes with the tools. Just start a new project for the specific controller and everything is set up to defaults and you just have to write your main() and set the peripherals (which would only be GPIO in this case). You may want to check the oscillator setup in the startup. And if you use a higer level tool (like STM32CubeMX for ST controllers), you can let it generate most of the peripheral init code.> > I think you are being a bit disingenuous about the patching issue. The MCU tools I've worked with would require quite a bit of work to replace data in binary code. >I think this could be done with the linker. Just add a section with the calibration data at a fixed address. Or maybe even better (does not require linker during production), there are plenty of hex file tools and I would be suprised if there is not one that allow adding a bit of data. And if there's nothing, writing something like that in C (or Python or Perl or ...) is not too complex (and I think I even have hex file code in C from old projects somewhere). But all this is not so relevant for an FPGA group, I suppose. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Pound for pound, the amoeba is the most vicious animal on earth.
Reply by ●March 29, 20192019-03-29
Anssi Saari <as@sci.fi> wrote:> Another way could be to use the user flash memory which is included in > Intel's MaxII and MaxV CPLDs. The size is 8192 bits so big enough. You'd > program the CPLD with the same design and only the UFM part of the flash > would need to be programmed in production.It appears there's a core for making a MAX CPLD look like an I2C EEPROM: https://www.intel.com/content/www/us/en/programmable/documentation/eis1406081952758.html I haven't used these cores, but assume a mux could be interposed between this core and the flash, to allow access to the flash in a parallel manner in addition to via I2C. The OP could put a MAX part on their module, and use the spare two pins on their module to provide an I2C programming interface. The bitfile is programmed at manufacture time (some JTAG pads on the module or pre-program the chips) and the memory can then be field-programmed via the I2C pins on the connector. Theo
Reply by ●March 29, 20192019-03-29
On Friday, March 29, 2019 at 12:12:00 PM UTC-4, Theo wrote:> Anssi Saari <as@sci.fi> wrote: > > Another way could be to use the user flash memory which is included in > > Intel's MaxII and MaxV CPLDs. The size is 8192 bits so big enough. You'd > > program the CPLD with the same design and only the UFM part of the flash > > would need to be programmed in production. > > It appears there's a core for making a MAX CPLD look like an I2C EEPROM: > https://www.intel.com/content/www/us/en/programmable/documentation/eis1406081952758.html > I haven't used these cores, but assume a mux could be interposed between > this core and the flash, to allow access to the flash in a parallel manner > in addition to via I2C. > > The OP could put a MAX part on their module, and use the spare two pins on > their module to provide an I2C programming interface. The bitfile is > programmed at manufacture time (some JTAG pads on the module or pre-program > the chips) and the memory can then be field-programmed via the I2C pins on > the connector.I don't know about others, but I prefer easy to work with packaging. I find most FPGAs come in hard (for me) to use chip scale or BGA packages (very large pin counts). The Lattice parts at least are available in QFN packages. -- Rick C. ++ Get a 1,000 miles of free Supercharging ++ Tesla referral code - https://ts.la/richard11209
