Den 2019-03-30 kl. 08:12, skrev gnuarm.deletethisbit@gmail.com:
> On Saturday, March 30, 2019 at 12:54:36 AM UTC-4, A.P.Richelieu wrote:
>> Den 2019-03-30 kl. 02:48, skrev gnuarm.deletethisbit@gmail.com:
>>> On Friday, March 29, 2019 at 6:52:14 PM UTC-4, A.P.Richelieu wrote:
>>>> Den 2019-03-29 kl. 01:17, skrev gnuarm.deletethisbit@gmail.com:
>>>>> 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 data
>>>>>
>>>>> So 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.
>>>>>
>>>> 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.
>>>
>>> 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 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 programmed with the configuration data in production without issues. But I shouldn'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 MCU will require some work to make that happen I believe.
>>>
>>
>> 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.
>
> The issue is that the programming file needs to be modified with calibration 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 Flash. In addition there are particular methods of loading the User Flash.
>
> The point is the loading of configuration data can be easily integrated into the typical programming process for the FPGA. This is not as straightforward 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 consumption. 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 available 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 to be package size to fit mobile apps. So while there are very tiny packages available, they don't suit my apps. But you can't say small packages aren't available.
>
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