Replaceme EPROM by CPLD/FPGA

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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.

Re: Replaceme EPROM by CPLD/FPGA
On Thursday, March 28, 2019 at 8:43:07 AM UTC-4, Stef wrote:
Quoted text here. Click to load it
s
e

You could program it as a constant array.  Then let the logic generate as a
ppropriate.  In a device like the ispMACH 4000 which has no memory, this mi
ght 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 t
he final steps using a lot less of the tools.  

That said, I have not done this myself.  I have only seen it described by o
thers.  For a data point, our production testing programs an FPGA and it ta
kes around 20 seconds for the smallish device we use.  Any compilation port
ion 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 mi
ght even be doable as a separate step after the programming.  

The most affordable devices I am familiar with are the iCE40 line.  There a
re 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 you
r 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 ser
ial PROM device as your in circuit programmable memory and use an ispMACH 4
000 to turn it into a parallel device.  If your calibration data is read se
quentially this becomes very simple indeed and can be pretty fast once star
ted.  

Just kicking around some ideas.  

--  

  Rick C.

  - Get a 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Replaceme EPROM by CPLD/FPGA
On 2019-03-28 snipped-for-privacy@gmail.com wrote in comp.arch.fpga:
Quoted text here. Click to load it

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.

Re: Replaceme EPROM by CPLD/FPGA
On Thursday, March 28, 2019 at 10:28:54 AM UTC-4, Stef wrote:
Quoted text here. Click to load it
ices
 the
Quoted text here. Click to load it
d
is
as appropriate.  In a device like the ispMACH 4000 which has no memory, thi
s might not fit well and would require the full tool set to be used.  
Quoted text here. Click to load it
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.  
Quoted text here. Click to load it
by others.  For a data point, our production testing programs an FPGA and i
t 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 sim
ple HDL file.  I don't know how long it would take to load the memory.  Tha
t might even be doable as a separate step after the programming.  
Quoted text here. Click to load it
re 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 y
our assembly process.  
Quoted text here. Click to load it
 serial PROM device as your in circuit programmable memory and use an ispMA
CH 4000 to turn it into a parallel device.  If your calibration data is rea
d sequentially this becomes very simple indeed and can be pretty fast once  
started.  
Quoted text here. Click to load it

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 c
an 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 pa
rallel interface RAM.  

Reference Design RD1126

--  

  Rick C.

  + Get a 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Replaceme EPROM by CPLD/FPGA
On 2019-03-28 snipped-for-privacy@gmail.com wrote in comp.arch.fpga:
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Replaceme EPROM by CPLD/FPGA
Quoted text here. Click to load it

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_id39%086

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)

Quoted text here. Click to load it

Does your old design have voltage requirements like 5V capability?

Theo

Re: Replaceme EPROM by CPLD/FPGA
On 2019-03-28 Theo wrote in comp.arch.fpga:
Quoted text here. Click to load it

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?)

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

Re: Replaceme EPROM by CPLD/FPGA
Den 2019-03-28 kl. 15:24, skrev Stef:
Quoted text here. Click to load it
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

Re: Replaceme EPROM by CPLD/FPGA
On Thursday, March 28, 2019 at 4:49:25 PM UTC-4, A.P.Richelieu wrote:
Quoted text here. Click to load it
=
Quoted text here. Click to load it
u can
  I
Quoted text here. Click to load it
run
ou can
r a
't
tes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.ashx
?document_id39%086
Quoted text here. Click to load it
 reads
Quoted text here. Click to load it
ires -
Quoted text here. Click to load it
V
ould
ming
free

I find it interesting that people often feel MCUs are simpler than programm
able logic.  What your program in particular lacks is the important part, a
llowing 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, the
re is setup code that either needs to be written from scratch by reading th
e MCU data sheet (starting clocks, initialize I/O banks, brown out detector
s, etc., etc...) or by starting with the standard startup code and paring o
ut what is not needed or appropriate.  

To me, this is inordinately complex compared to the relatively trivial exer
cise 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 cod
e 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
We've slightly trimmed the long signature. Click to see the full one.
Re: Replaceme EPROM by CPLD/FPGA
torsdag den 28. marts 2019 kl. 22.37.18 UTC+1 skrev snipped-for-privacy@gmail.com:
Quoted text here. Click to load it
L
he
=
Quoted text here. Click to load it
you can
g.  I
Quoted text here. Click to load it
o run
 you can
Quoted text here. Click to load it
for a
en't
Notes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.as
hx?document_id39%086
Quoted text here. Click to load it
at reads
m
 wires -
Quoted text here. Click to load it
r
 5V
Quoted text here. Click to load it
k.
s
+
 could
Quoted text here. Click to load it
amming
e free
mmable logic.  What your program in particular lacks is the important part,
 allowing the contents of "memory[]" to be set at manufacturing time.  I do
n't see the use of an MCU to be at all simple.  In addition to the above, t
here 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 detect
ors, etc., etc...) or by starting with the standard startup code and paring
 out what is not needed or appropriate.  
Quoted text here. Click to load it
ercise of creating an HDL ROM which is about as complex as the code above a
nd setting the details of the chosen I/O pins to be used.  The only remaini
ng issue is to use the vendor tool to initialize this ROM in the compiled c
ode or even in the same way it is done now which I think is done by the boa
rd itself.  
Quoted text here. Click to load it
  

if the only thing in your toolbox it hammers, nailing things together alway
s  
seem like the obvious choice

at slow speed an mcu could be just as viable, and customizing the array cou
ld  
be as simple as patching the bin or hex file programmed into the part



Re: Replaceme EPROM by CPLD/FPGA
On Thursday, March 28, 2019 at 6:16:28 PM UTC-4, snipped-for-privacy@gmail.com  
wrote:
Quoted text here. Click to load it
m:
Quoted text here. Click to load it
HDL
 the
Quoted text here. Click to load it
A =
Quoted text here. Click to load it
e you can
Quoted text here. Click to load it
ing.  I
Quoted text here. Click to load it
 to run
Quoted text here. Click to load it
nk you can
Quoted text here. Click to load it
s for a
Quoted text here. Click to load it
aven't
onNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devices.
ashx?document_id39%086
Quoted text here. Click to load it
that reads
ram
ol wires -
Quoted text here. Click to load it
for
.
th 5V
ork.
 is
Quoted text here. Click to load it
1 +
at could
e
gramming
the free
rammable logic.  What your program in particular lacks is the important par
t, 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 readin
g the MCU data sheet (starting clocks, initialize I/O banks, brown out dete
ctors, etc., etc...) or by starting with the standard startup code and pari
ng out what is not needed or appropriate.  
Quoted text here. Click to load it
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 remai
ning 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 b
oard itself.  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
ays  
Quoted text here. Click to load it
ould  
Quoted text here. Click to load it

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 u
p 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
We've slightly trimmed the long signature. Click to see the full one.
Re: Replaceme EPROM by CPLD/FPGA
fredag den 29. marts 2019 kl. 00.03.22 UTC+1 skrev snipped-for-privacy@gmail.com:
Quoted text here. Click to load it
m wrote:
Quoted text here. Click to load it
com:
Quoted text here. Click to load it
n HDL
ng the
ATA =
Quoted text here. Click to load it
ere you can
Quoted text here. Click to load it
iling.  I
Quoted text here. Click to load it
ed to run
Quoted text here. Click to load it
hink you can
Quoted text here. Click to load it
nds for a
Quoted text here. Click to load it
 haven't
Quoted text here. Click to load it
tionNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Device
s.ashx?document_id39%086
Quoted text here. Click to load it
D that reads
Quoted text here. Click to load it
ogram
trol wires -
Quoted text here. Click to load it
r for
te.
y?
Quoted text here. Click to load it
with 5V
 work.
Quoted text here. Click to load it
ce is
 (1 +
Quoted text here. Click to load it
that could
ose
rogramming
f the free
Quoted text here. Click to load it
ge
ogrammable logic.  What your program in particular lacks is the important p
art, 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 abov
e, there is setup code that either needs to be written from scratch by read
ing the MCU data sheet (starting clocks, initialize I/O banks, brown out de
tectors, etc., etc...) or by starting with the standard startup code and pa
ring out what is not needed or appropriate.  
Quoted text here. Click to load it
l exercise of creating an HDL ROM which is about as complex as the code abo
ve and setting the details of the chosen I/O pins to be used.  The only rem
aining issue is to use the vendor tool to initialize this ROM in the compil
ed code or even in the same way it is done now which I think is done by the
 board itself.  
Quoted text here. Click to load it
y.  
Quoted text here. Click to load it
lways  
Quoted text here. Click to load it
 could  
Quoted text here. Click to load it
r 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 desi
gn with than HDL in my experience.  


so you have only used big MCUs with piles of peripherals and advanced featu
res, small 8bitters are usually nothing like that  

Quoted text here. Click to load it
  The PLD tools have already dealt with this issue.  
Quoted text here. Click to load it

doing exactly the same thing, replacing the data

Re: Replaceme EPROM by CPLD/FPGA
On Thursday, March 28, 2019 at 7:27:58 PM UTC-4, snipped-for-privacy@gmail.com  
wrote:
Quoted text here. Click to load it
:
Quoted text here. Click to load it
com wrote:
Quoted text here. Click to load it
l.com:
Quoted text here. Click to load it
e:
Quoted text here. Click to load it
 an HDL
Quoted text here. Click to load it
ring the
 DATA =
Quoted text here. Click to load it
.
where you can
Quoted text here. Click to load it
mpiling.  I
Quoted text here. Click to load it
need to run
Quoted text here. Click to load it
 think you can
Quoted text here. Click to load it
conds for a
Quoted text here. Click to load it
 I haven't
Quoted text here. Click to load it
cationNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devi
ces.ashx?document_id39%086
Quoted text here. Click to load it
PLD that reads
Quoted text here. Click to load it
program
ontrol wires -
Quoted text here. Click to load it
der for
date.
ity?
Quoted text here. Click to load it
3 with 5V
Quoted text here. Click to load it
ld work.
face is
ol (1 +
Quoted text here. Click to load it
s that could
Quoted text here. Click to load it
Those
 programming
Quoted text here. Click to load it
 of the free
Quoted text here. Click to load it
  
Quoted text here. Click to load it
kage
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 ab
ove, there is setup code that either needs to be written from scratch by re
ading 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.  
Quoted text here. Click to load it
ial exercise of creating an HDL ROM which is about as complex as the code a
bove and setting the details of the chosen I/O pins to be used.  The only r
emaining issue is to use the vendor tool to initialize this ROM in the comp
iled code or even in the same way it is done now which I think is done by t
he board itself.  
Quoted text here. Click to load it
ity.  
Quoted text here. Click to load it
 always  
Quoted text here. Click to load it
ay could  
Quoted text here. Click to load it
for the MCU.  The ones I've used have a *lot* of features that need to be s
et up for the MCU to even run.  MCU code is always a lot more complex to de
sign with than HDL in my experience.  
Quoted text here. Click to load it
tures, small 8bitters are usually nothing like that  
Quoted text here. Click to load it
a.  The PLD tools have already dealt with this issue.  
Quoted text here. Click to load it

So there is a tool for patching the hex data?  You don't need any startup c
ode 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 i
n binary code.  

--  

  Rick C.

  +- Get a 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Replaceme EPROM by CPLD/FPGA
On 2019-03-29 snipped-for-privacy@gmail.com wrote in comp.arch.fpga:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it
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.

Quoted text here. Click to load it

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.

Re: Replaceme EPROM by CPLD/FPGA
Den 2019-03-29 kl. 01:17, skrev snipped-for-privacy@gmail.com:
Quoted text here. Click to load it
If you never used a micro, you may have a problem.
If you have used a specific micro, then you are likely to have setup code.

The ROM code is best expressed in C.
const uint8_t memory[256] = {
    0x00, 0x01, 0x02, 0x03, ...
};

You get a state of the art C compiler/debugger from IAR free of charge
for these types of applications.

If you are not in a hurry, you can implement a bitbanged USART in three  
pins in the micro.
You send an address, as an 8 bit byte, and the micro responds with the data.

The Micro is going to be way cheaper than a programmable logic device
if there is any volume at all behind such a request.

You can also get much much smaller packages with micros than with  
programmable logic.

AP

Re: Replaceme EPROM by CPLD/FPGA
On Friday, March 29, 2019 at 6:52:14 PM UTC-4, A.P.Richelieu wrote:
Quoted text here. Click to load it
com wrote:
Quoted text here. Click to load it
com:
Quoted text here. Click to load it
l.com wrote:
Quoted text here. Click to load it
il.com:
Quoted text here. Click to load it
e:
Quoted text here. Click to load it
n HDL
ng the
ATA =
Quoted text here. Click to load it
ere you can
Quoted text here. Click to load it
iling.  I
Quoted text here. Click to load it
ed to run
Quoted text here. Click to load it
hink you can
Quoted text here. Click to load it
nds for a
Quoted text here. Click to load it
 haven't
Quoted text here. Click to load it
tionNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Device
s.ashx?document_id39%086
Quoted text here. Click to load it
D that reads
Quoted text here. Click to load it
ogram
trol wires -
Quoted text here. Click to load it
r for
te.
y?
Quoted text here. Click to load it
with 5V
 work.
Quoted text here. Click to load it
ce is
 (1 +
Quoted text here. Click to load it
that could
ose
rogramming
f the free
Quoted text here. Click to load it
age
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 ab
ove, there is setup code that either needs to be written from scratch by re
ading 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.
Quoted text here. Click to load it
ial exercise of creating an HDL ROM which is about as complex as the code a
bove and setting the details of the chosen I/O pins to be used.  The only r
emaining issue is to use the vendor tool to initialize this ROM in the comp
iled code or even in the same way it is done now which I think is done by t
he board itself.
Quoted text here. Click to load it
ity.
r always
ray could
t
e 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.
Quoted text here. Click to load it
features, small 8bitters are usually nothing like that
Quoted text here. Click to load it
ata.  The PLD tools have already dealt with this issue.
Quoted text here. Click to load it
up code on your small 8 bitter?
Quoted text here. Click to load it
 MCU tools I've worked with would require quite a bit of work to replace da
ta in binary code.
Quoted text here. Click to load it
.
  
Quoted text here. Click to load it
ta.

Not if the design is pin defined.  This design can't be done with an 8 pin  
package.  

Cost depends on many things and some FPGAs are very inexpensive.  Having th
e simplest production solution is a great start.  So far FPGAs are the only
 solution that actually provides a clear and simple method of being program
med with the configuration data in production without issues.  But I should
n't say that because I don't truly understand all the issues the OP has.  I
 do know that the FPGA will handle them all as presently understood.  The M
CU will require some work to make that happen I believe.  

--  

  Rick C.

  --- Get a 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Replaceme EPROM by CPLD/FPGA
Den 2019-03-30 kl. 02:48, skrev snipped-for-privacy@gmail.com:
Quoted text here. Click to load it

The configuration file is a simple text file which gets included in the  
build. It is easily generated from a hex file, if that is a need.
You can program the microcontroller and the FPGA before you mount it to  
the PCB. Otherwise you program both using JTAG.
There is ZERO issues in programming a micro. It is well known thing.
There will be some fallout with BOTH.

If there is a need to update the contents in the field, you can do so  
using a serial port = 2 pin.

With a need for 13 I/Os, for the ROM interface, a 24 pin QFN package (4  
x 4 mm) should do. Smallest FPGA is 3 x the price.

It is going to cost around $1.25 @ 1 piece @ Digikey.
The smallest FPGA is 3 x the price.
The power consumption is going to be a fraction of that of an FPGA.

The only thing that needs to be checked if the solution is fast enough.

AP

Re: Replaceme EPROM by CPLD/FPGA
On Saturday, March 30, 2019 at 12:54:36 AM UTC-4, A.P.Richelieu wrote:
Quoted text here. Click to load it
l.com wrote:
Quoted text here. Click to load it
l.com:
Quoted text here. Click to load it
ail.com wrote:
Quoted text here. Click to load it
mail.com:
Quoted text here. Click to load it
ote:
Quoted text here. Click to load it
 an HDL
Quoted text here. Click to load it
ring the
 DATA =
Quoted text here. Click to load it
.
where you can
Quoted text here. Click to load it
mpiling.  I
Quoted text here. Click to load it
need to run
Quoted text here. Click to load it
 think you can
Quoted text here. Click to load it
conds for a
Quoted text here. Click to load it
 I haven't
Quoted text here. Click to load it
cationNotes/UZ/UsingUserFlashMemoryandHardenedControlFunctionsinMachXO2Devi
ces.ashx?document_id39%086
Quoted text here. Click to load it
PLD that reads
Quoted text here. Click to load it
program
ontrol wires -
Quoted text here. Click to load it
der for
date.
ity?
Quoted text here. Click to load it
3 with 5V
Quoted text here. Click to load it
ld work.
face is
ol (1 +
Quoted text here. Click to load it
s that could
Quoted text here. Click to load it
Those
 programming
Quoted text here. Click to load it
 of the free
Quoted text here. Click to load it
ckage
n programmable logic.  What your program in particular lacks is the importa
nt part, allowing the contents of "memory[]" to be set at manufacturing tim
e.  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 ou
t detectors, etc., etc...) or by starting with the standard startup code an
d paring out what is not needed or appropriate.
Quoted text here. Click to load it
ivial 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 co
mpiled code or even in the same way it is done now which I think is done by
 the board itself.
Quoted text here. Click to load it
ility.
her always
array could
art
ode 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 t
o design with than HDL in my experience.
Quoted text here. Click to load it
d features, small 8bitters are usually nothing like that
Quoted text here. Click to load it
 data.  The PLD tools have already dealt with this issue.
Quoted text here. Click to load it
rtup code on your small 8 bitter?
Quoted text here. Click to load it
he MCU tools I've worked with would require quite a bit of work to replace  
data in binary code.
Quoted text here. Click to load it
ode.
e
 data.
Quoted text here. Click to load it
pin package.
g the simplest production solution is a great start.  So far FPGAs are the  
only solution that actually provides a clear and simple method of being pro
grammed with the configuration data in production without issues.  But I sh
ouldn't say that because I don't truly understand all the issues the OP has
.  I do know that the FPGA will handle them all as presently understood.  T
he MCU will require some work to make that happen I believe.
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

The issue is that the programming file needs to be modified with calibratio
n data for each device being programmed.  This process is well defined for  
FPGAs since it is common to need to load block rams or in this case User Fl
ash.  In addition there are particular methods of loading the User Flash.  
  

The point is the loading of configuration data can be easily integrated int
o the typical programming process for the FPGA.  This is not as straightfor
ward for the MCU where you need to perform a build rather than just loading
 the configuration data.  

Your information about FPGAs is not so current, especially the power consum
ption.  You clearly have not worked with the lower power devices which are  
available.  There are devices that have double digit microamp power levels  
if not being clocked at high rates.  The devices I have pointed to are avai
lable in QFN packages in addition to very tiny chip scale packages.  

FPGA packaging is one of my pet peaves.  The focus in smaller FPGAs seems t
o be package size to fit mobile apps.  So while there are very tiny package
s available, they don't suit my apps.  But you can't say small packages are
n't available.  

--  

  Rick C.

  --+ Get a 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Replaceme EPROM by CPLD/FPGA
Den 2019-03-30 kl. 08:12, skrev snipped-for-privacy@gmail.com:
Quoted text here. Click to load it

Once you have programmed the microcontroller, you use a write pin to  
program the part, and a read pin to read out the part.
These things can be connected to DMA, for quite high speed.
Since the reads were "slow", I bet this is good enough.
Piece of cake.

The build to add an additional memory array of 128 bytes takes a  
fraction of a second. It is not complex. It is well known technology.
To say that this is not straightforward shows that you know little about  
MCUs.

AP

Re: Replaceme EPROM by CPLD/FPGA
Quoted text here. Click to load it

The first thing that went through my mind when I saw the original post
was "microchip PIC" - the size of a full stop.
I just assumed I'd missunderstood since this was an FPGA group.

I'd concur with the other posters - microprocessor is the way to go.  
I'd recommend a download of their parts selector software (free) and have a  
browse.
FPGA's require far too much work for everyday tasks such as this.

--  

john

=========================
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline