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.
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.
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.
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.
features, small 8bitters are usually nothing like that
ata. The PLD tools have already dealt with this issue.
up code on your small 8 bitter?
MCU tools I've worked with would require quite a bit of work to replace da ta in binary code.
.
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
--- Tesla referral code - https://ts.la/richard11209
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.
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.
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.
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.
d features, small 8bitters are usually nothing like that
data. The PLD tools have already dealt with this issue.
rtup code on your small 8 bitter?
he MCU tools I've worked with would require quite a bit of work to replace data in binary code.
ode.
e
data.
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.
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
--+ Tesla referral code - https://ts.la/richard11209
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.
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
=========================
http://johntech.co.uk
=========================
The Event System originally implemented in the AVR is probably quite useful for this application. It is available in some Cortex-M parts as well where the NMI can be used for almost no delay response.
Many FPGAs require an external EEPROM for storing the Bitfile. All those wi ll be no choice for you.
Whats left is in fact some old CPLDs, Lattice and Microsemi which all use i nternal Flash. The CPLDs would be in many occasions too small to store 1024 bits random content.
I understand it is something like 256 times 4 bit. This means you have 8 bi t address for 4 bit result. A function calculating 4 bits result from 8 bit address can be either very simple (eg: Bit0=not Adress(0), bit1=Address(0), bit2=address(1) xor address(2), bit3 = address(3) and address(4)) or very complex (example le ft to you).
Due to Fan-In/Fan-Out constraints a function looking simple can simple expl ode in size, my experience says you cannot say on first glance how easy or complex a table transfers into a combinatorical circuit. So the question if you have 10 different tables which of those require what size of combinatoric is hard to answer before implementing it.
On the other hand most FPGAs packages might be too large in size for your b oard design, if a simple EEPROM is allready too large. No idea what cou can accept.
You might want to check out the Microsemi ProAsic3 technology which provide s an 1k EEPROM for user access. The smallest package would be the A3PN010 i n QN48 (6x6 mm)
internal Flash. The CPLDs would be in many occasions too small to store 10
24 bits random content.
bit address for 4 bit result.
y simple (eg: Bit0=not Adress(0), bit1=Address(0), bit2=address(1) xo r address(2), bit3 = address(3) and address(4)) or very complex (example left to you).
plode in size, my experience says you cannot say on first glance how easy o r complex a table transfers into a combinatorical circuit.
at size of combinatoric is hard to answer before implementing it.
board design, if a simple EEPROM is allready too large. No idea what cou c an accept.
des an 1k EEPROM for user access. The smallest package would be the A3PN010 in QN48 (6x6 mm)
You seem to have not read most of the posts in this thread. There have bee n specific FPGAs mentioned which will do the job the OP needs. He seems to prefer an MCU approach because he is more familiar with MCUs than FPGAs.
--
Rick C.
-+- Get a 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209
A dual package solution is not prefered, but if the packages are small enough, it might fit. Double sided placement could be a last resort as long as the bottom components are >
A TSOP EEPROM would be a good mechanical fit, but unfortunately it is electrically unsuitable as you need access to all address and data pins for programming. I managed to get an SOIC28 (17.9 x 10.3 mm) on the board after reducing some clearances and pad sizes, but that relies on the connector and memory pins 'interleaving' a little (pitch 2.54 and 1.27 mm). So generically I would say the maximum size is 18 x 9 mm
That would fit mechanically.
It is not that I prefer an MCU approach, but I am indeed more comfortable with MCU's. And if I go that way and need help, I think it's best not to ask in an FPGA group. ;-)
There are other issues against the MCU approach. One of them is that it may (this is not sure) be harder for certification than a CPLD solution.
For now I am still trying to find all possible solutions (and still hoping for a suitable memory device to pop up :-( ) so I can come up with a good overview of solutions. The overview should include all costs and effort for components, development, tools, certification, in-line programming, etc.
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
Every man takes the limits of his own field of vision for the limits
of the world.
-- Schopenhauer
U?ytkownik "Stef" napisa? w wiadomo?ci news:nnd$093f4a46$3b21e82e@963e990d8e91a0cc... | 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.
You seem to be right. I tried a random pattern in a Lattice 4064 part, and in one of the small Xilinx parts, both fitted, but more testing is needed to see what proportion of possible patterns would fit. Part size from 4x4mm BGA to 7x7mm TQFP. Six connections are needed for flashing, could be pins, holes, or pads.
If it is a microprocessor system, and you have firmware build access, I would use a 1kx8 I2C eeprom in SOT23-5 package.
As others have noted, perhaps there is not enough detail in your spec to suggest optimum solutions. Perhaps you are just doing re- calibration and need to build a pin-compatible solution?
I've done a 27xxx EPROM emulator by simply using a cheap Ebay board with a Cyclone IV and some 74HC buffers. The HDL code can be generated simply by u sing Octave reading a file and compiling a synthesize-able VHDL file from i t's contents. I'm sure it could be possible to create a simple statemachine to fill upp RAM via some UART for dynamic update of contents. Just my 2 ce nt.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.