EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

Replaceme EPROM by CPLD/FPGA

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - Replaceme EPROM by CPLD/FPGA

Goto page 1, 2, 3  Next

Stef
Guest

Thu Mar 28, 2019 1:45 pm   



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.


--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

It's better to burn out than it is to rust.


Guest

Thu Mar 28, 2019 2:45 pm   



On Thursday, March 28, 2019 at 8:43:07 AM UTC-4, Stef wrote:
Quote:
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.


You could program it as a constant array. Then let the logic generate as appropriate. In a device like the ispMACH 4000 which has no memory, this might not fit well and would require the full tool set to be used.

If you pick a device that has internal memory, you can use a part that can be placed and routed once and the contents of the memory loaded in one of the final steps using a lot less of the tools.

That said, I have not done this myself. I have only seen it described by others. For a data point, our production testing programs an FPGA and it takes around 20 seconds for the smallish device we use. Any compilation portion would change that to minutes, but maybe not too many for such a simple HDL file. I don't know how long it would take to load the memory. That might even be doable as a separate step after the programming.

The most affordable devices I am familiar with are the iCE40 line. There are a number of flavors so you could shop around to find the cheapest. Like many FPGAs they come in an array of packages which may or may not suit your design. A chip scale package with 0.25 spaced balls might not suit your assembly process.

Another alternative, if the memory speed can be slow, would be to use a serial PROM device as your in circuit programmable memory and use an ispMACH 4000 to turn it into a parallel device. If your calibration data is read sequentially this becomes very simple indeed and can be pretty fast once started.

Just kicking around some ideas.

--

Rick C.

- Get a 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

Theo
Guest

Thu Mar 28, 2019 3:45 pm   



Stef <stef33d_at_yahooi-n-v-a-l-i-d.com.invalid> wrote:
Quote:
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?

Theo

Stef
Guest

Thu Mar 28, 2019 3:45 pm   



On 2019-03-28 gnuarm.deletethisbit_at_gmail.com wrote in comp.arch.fpga:
Quote:
On Thursday, March 28, 2019 at 8:43:07 AM UTC-4, 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.

You could program it as a constant array. Then let the logic generate as appropriate. In a device like the ispMACH 4000 which has no memory, this might not fit well and would require the full tool set to be used.

If you pick a device that has internal memory, you can use a part that can be placed and routed once and the contents of the memory loaded in one of the final steps using a lot less of the tools.

That said, I have not done this myself. I have only seen it described by others. For a data point, our production testing programs an FPGA and it takes around 20 seconds for the smallish device we use. Any compilation portion would change that to minutes, but maybe not too many for such a simple HDL file. I don't know how long it would take to load the memory. That might even be doable as a separate step after the programming.

The most affordable devices I am familiar with are the iCE40 line. There are a number of flavors so you could shop around to find the cheapest. Like many FPGAs they come in an array of packages which may or may not suit your design. A chip scale package with 0.25 spaced balls might not suit your assembly process.

Another alternative, if the memory speed can be slow, would be to use a serial PROM device as your in circuit programmable memory and use an ispMACH 4000 to turn it into a parallel device. If your calibration data is read sequentially this becomes very simple indeed and can be pretty fast once started.

Just kicking around some ideas.


Thanks for the input.
Data is read sequentially, so approaches like that are doable. Access is
rather slow, so if we go that route, MCU solutions (with internal EEPROM)
may be possible too.


--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

It's better to burn out than it is to rust.

Stef
Guest

Thu Mar 28, 2019 4:24 pm   



On 2019-03-28 Theo wrote in comp.arch.fpga:
Quote:
Stef <stef33d_at_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 (Cool, 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?)

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

It's better to burn out than it is to rust.


Guest

Thu Mar 28, 2019 4:45 pm   



On Thursday, March 28, 2019 at 10:28:54 AM UTC-4, Stef wrote:
Quote:
On 2019-03-28 gnuarm.deletethisbit_at_gmail.com wrote in comp.arch.fpga:
On Thursday, March 28, 2019 at 8:43:07 AM UTC-4, 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.

You could program it as a constant array. Then let the logic generate as appropriate. In a device like the ispMACH 4000 which has no memory, this might not fit well and would require the full tool set to be used.

If you pick a device that has internal memory, you can use a part that can be placed and routed once and the contents of the memory loaded in one of the final steps using a lot less of the tools.

That said, I have not done this myself. I have only seen it described by others. For a data point, our production testing programs an FPGA and it takes around 20 seconds for the smallish device we use. Any compilation portion would change that to minutes, but maybe not too many for such a simple HDL file. I don't know how long it would take to load the memory. That might even be doable as a separate step after the programming.

The most affordable devices I am familiar with are the iCE40 line. There are a number of flavors so you could shop around to find the cheapest. Like many FPGAs they come in an array of packages which may or may not suit your design. A chip scale package with 0.25 spaced balls might not suit your assembly process.

Another alternative, if the memory speed can be slow, would be to use a serial PROM device as your in circuit programmable memory and use an ispMACH 4000 to turn it into a parallel device. If your calibration data is read sequentially this becomes very simple indeed and can be pretty fast once started.

Just kicking around some ideas.

Thanks for the input.
Data is read sequentially, so approaches like that are doable. Access is
rather slow, so if we go that route, MCU solutions (with internal EEPROM)
may be possible too.


I had forgotten that the Lattice XO2 and XO3 devices have User Flash Memory (UFM) for just this sort of application (configuration data). The XO2-640 part (smallest with UFM) in a 48 pin QFN is just $3.12 qty 100. The XO3 can be even lower cost, but only available in BGA style packaging. I found a couple of app notes on using it, one specifically for making it into a parallel interface RAM.

Reference Design RD1126

--

Rick C.

+ Get a 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

Anssi Saari
Guest

Thu Mar 28, 2019 4:45 pm   



Stef <stef33d_at_yahooI-N-V-A-L-I-D.com.invalid> writes:

Quote:
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.


The HDL for this would be pretty short, maybe just an array declaration
with the calibration data and then a single assignment to the output
from the array based on the address input. So very easy to generate with
a little software.

Most vendor tools have automation possibilities so the tool flow can be
done with a single command. Might take longer than a few seconds though.
On the other hand, if there's a limited number of bitstreams then it
could be possible to generate and store all of them beforehand.

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.

Tim
Guest

Thu Mar 28, 2019 4:45 pm   



On 28/03/2019 12:28, Stef wrote:
Quote:
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.

Stef
Guest

Thu Mar 28, 2019 6:45 pm   



On 2019-03-28 Tim wrote in comp.arch.fpga:
Quote:
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.

Stef
Guest

Thu Mar 28, 2019 6:45 pm   



On 2019-03-28 Anssi Saari wrote in comp.arch.fpga:
Quote:
Stef <stef33d_at_yahooI-N-V-A-L-I-D.com.invalid> writes:

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.

The HDL for this would be pretty short, maybe just an array declaration
with the calibration data and then a single assignment to the output
from the array based on the address input. So very easy to generate with
a little software.

Most vendor tools have automation possibilities so the tool flow can be
done with a single command. Might take longer than a few seconds though.
On the other hand, if there's a limited number of bitstreams then it
could be possible to generate and store all of them beforehand.


In theory there are 1024 bits, but not all will be used/changed. But
even then, the number of posibilities is rather high. A few seconds is
a wide range, but not into the minutes. Wink We will see...


Quote:
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.


Ah, similar to Ricks' approach, but then with intel. Thanks.

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

A lot of people I know believe in positive thinking, and so do I.
I believe everything positively stinks.
-- Lew Col

Stef
Guest

Thu Mar 28, 2019 6:45 pm   



On 2019-03-28 gnuarm.deletethisbit_at_gmail.com wrote in comp.arch.fpga:
Quote:
On Thursday, March 28, 2019 at 10:28:54 AM UTC-4, Stef wrote:
On 2019-03-28 gnuarm.deletethisbit_at_gmail.com wrote in comp.arch.fpga:
On Thursday, March 28, 2019 at 8:43:07 AM UTC-4, 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.

You could program it as a constant array. Then let the logic generate as appropriate. In a device like the ispMACH 4000 which has no memory, this might not fit well and would require the full tool set to be used.

If you pick a device that has internal memory, you can use a part that can be placed and routed once and the contents of the memory loaded in one of the final steps using a lot less of the tools.

That said, I have not done this myself. I have only seen it described by others. For a data point, our production testing programs an FPGA and it takes around 20 seconds for the smallish device we use. Any compilation portion would change that to minutes, but maybe not too many for such a simple HDL file. I don't know how long it would take to load the memory. That might even be doable as a separate step after the programming.

The most affordable devices I am familiar with are the iCE40 line. There are a number of flavors so you could shop around to find the cheapest. Like many FPGAs they come in an array of packages which may or may not suit your design. A chip scale package with 0.25 spaced balls might not suit your assembly process.

Another alternative, if the memory speed can be slow, would be to use a serial PROM device as your in circuit programmable memory and use an ispMACH 4000 to turn it into a parallel device. If your calibration data is read sequentially this becomes very simple indeed and can be pretty fast once started.

Just kicking around some ideas.

Thanks for the input.
Data is read sequentially, so approaches like that are doable. Access is
rather slow, so if we go that route, MCU solutions (with internal EEPROM)
may be possible too.

I had forgotten that the Lattice XO2 and XO3 devices have User Flash Memory (UFM) for just this sort of application (configuration data). The XO2-640 part (smallest with UFM) in a 48 pin QFN is just $3.12 qty 100. The XO3 can be even lower cost, but only available in BGA style packaging. I found a couple of app notes on using it, one specifically for making it into a parallel interface RAM.

Reference Design RD1126


Nice reference, thanks.

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

It takes less time to do a thing right than it does to explain why you
did it wrong.
-- H.W. Longfellow

A.P.Richelieu
Guest

Thu Mar 28, 2019 10:45 pm   



Den 2019-03-28 kl. 15:24, skrev Stef:
Quote:
On 2019-03-28 Theo wrote in comp.arch.fpga:
Stef <stef33d_at_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 (Cool, 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


Guest

Thu Mar 28, 2019 10:45 pm   



On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote:
Quote:
Den 2019-03-28 kl. 15:24, skrev Stef:
On 2019-03-28 Theo wrote in comp.arch.fpga:
Stef <stef33d_at_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 (Cool, 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.

--

Rick C.

-- Get a 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209


Guest

Thu Mar 28, 2019 11:45 pm   



torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev gnuarm.de...@gmail.com:
Quote:
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_at_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 (Cool, 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


Guest

Fri Mar 29, 2019 12:45 am   



On Thursday, March 28, 2019 at 6:16:28 PM UTC-4, lasselangwad...@gmail.com wrote:
Quote:
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_at_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 (Cool, 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.

"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

Goto page 1, 2, 3  Next

elektroda.net NewsGroups Forum Index - FPGA - Replaceme EPROM by CPLD/FPGA

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map