Help finding a small and low cost programable logic IC.

[zapta]

That's a good point. Some devices do stretch. I searched the SLG46826's datasheet for 'stretch' and didn't find any reference. Still trying to understand this device.

It's similar to using a ISO1541 where the SCL is unidirectional.

[zapta]

But you would have to program them outside of the board, or figure out some way to power only one device at a time.

The in-circuit programming doc mentions explicitly the possibility of using these 4 bit code to program multiple devices connected to the same I2C bus "This gives the User flexibility on the chip level addressing of this device and other devices on the same I2C bus"   https://www.renesas.com/us/en/document/mat/system-programming-guide-slg468246

Let's say that there are N <= 16 devices, each hard wired on the PCB for a different code (via IO2,3,4,5). If each of the devices is programed to use the code from the IO pins then the rest is solved.  Let's say that we just assembled the board and the devices are at factory default, using the 0001 code from the register. The master can send a write command that will flip those 4 bits to use the code from IO pins. All devices will ack in parallel (open drain) and will flip those bits. From this point, each has a unique code.

BTW, the master can be the on-board MCU or an external I2c adapter via a programming connector.

I haven't tried it yet, just speculating based on the documentation.

[ataradov]

This might work, assuming devices operate with the same timing and don't clock stretch. It is probably better to program the SRAM registers first, then program the EEPROM individually.

[zapta]

I can not find any programmers for GreenPak SPLD. Everywhere no stock. Can NVM be programmed over i2c? Or is where any clones or open source programmers?

Digikey has one in stock. Even if it will got away, the lead time is only two weeks, so you can order now.

https://www.digikey.com/en/products/detail/renesas-electronics-corporation/SLG4DVKGSD/16254311?s=N4IgTCBcDaIMoBkDiAWAIgNQNJLmkAugL5A

[zapta]

This might work, assuming devices operate with the same timing and don't clock stretch. It is probably better to program the SRAM registers first, then program the EEPROM individually.

I asked about it in the Renesas forums. The answer I got so far from a use is that the SCL multi programming devices is input only and thus no stretching. I haven't verified it yet with the datasheet.

Any use of I2C clock stretching should be mentioned explicitly IMO since they require the master(s) and any bus interface to support it.

https://community.renesas.com/analog-products/f/greenpak-greenfet/32620/do-greenpak-devices-use-i2c-clock-stretching?ReplySortBy=CreatedDate&ReplySortOrder=Ascending

[ataradov]

Clock stretching is a natural feature of the I2C. It is unfortunate that people still keep making broken hardware that does not support it, even though it is easy to implement. And most masters do support it, since it comes free with the collision detection. If your master does not do that, well, it is very broken.

But this is fine. For hobby use nobody cares.

[PCB.Wiz]

It would be rare for a memory  interface to use clock stretching, that’s usually only seen in small MCU’s that handle one byte as slaves.
Some use fixed times, and others use ACK polling, for the ‘some ms’ pgm/ erase times.

[ataradov]

Just to clarify, I meant that it is natural for the masters. Slaves are perfectly fine with input-only behavior. Obviously, it i better to get it documented, since it would allow parallel operation like it required here.

In this case, it looks like for programming operations you have to introduce delays yourself. The page programming takes 20 ms, and there are no status bits for that. Erase also takes 20 ms, but there is a status bit. Not sure if device would allow reading of that bit wile operation is ongoing though.

I have boards on a way SLG46824, we'll see how all that works.

[zapta]

If anybody is interested, I designed these SMD adapters for breadboarding. Ordered them from JLCPCB but haven't tested them yet.  I order 0.8mm boards and cut with aviation snips, or strong scissors. It costs as low as $3.5 for 5 boards shipped to the US.


https://github.com/zapta/GreenPAKs/tree/main/smd_adapters/JLCPCB

[zapta]

Some devices such as the ADS1261 just require to master to clock an extra dummy byte to have sufficient time to prepare the response.

[SiliconWizard]

It would be rare for a memory  interface to use clock stretching, that’s usually only seen in small MCU’s that handle one byte as slaves.
Some use fixed times, and others use ACK polling, for the ‘some ms’ pgm/ erase times.

Well, while clock stretching can be done without in a lot of cases indeed - not a big fan of the principle myself for reasons I explained before, namely that holding the bus to wait for some operation to complete is not a great idea if the bus is shared by a number of devices, but can be efficient in some specific cases - any master implementation not handling clock stretching properly is a borked implementation. So, I agree with ataradov here.

[c64]

Not related to i2c discussion, but. I'm looking at the SLG46824 datasheet... For timing characteristics they only specify typicals at 25°C. How can you design anything like this?

[zapta]

Clock stretching is a natural feature of the I2C.

Ok, let's assume worst case where (1) the GreenPAKs use clock stretching while programming and (2) each one may stretch for a different period. What will happen if we write to a few of them in parallel, to initialize the 'use I2C address from external pins' settings, such that each gets its own unique address? 

I would think that the master will send 8 bits, some devices will stretch, and when the longest one ends the stretching, the master will send the 9th clock and everything will resume as normal. In other words, the parallel write will succeed even with stretching.

Am I missing something?

(I don't think that they use stretching but this is a just-in-case mental excersize).

[woofy]

Writing to multiple slaves in parallel is not part of the I2C specification. How could you ever know if one of the devices NAK'd out?

[zapta]

The context here is a very specific use case of initializing virgin greenpaks to have them switching to the individual addresses assigned to them by the PCB wiring. If one failed to write, it will not be found at its designated address.

[SiliconWizard]

I understand, but clearly this is an out-of-spec use. How will you assign them individual addresses in this way?

[ataradov]

I expect that to work. Those devices have configuration bits where they would take part of the address from the pins. So you have to upload the same firmware on all of them. That firmware would enable individual address assignment from the pins. Then on the board strap the pins to different values.

Even writing to the EEPROM should work, since it looks like it just takes 16 byte page at a time and the write starts after the stop bit. And it is on you to wait for the write time, since there are no flags you can poll for. So, they are write-only device when it comes to programming anyway.

The downside, you are going to lose use of pins, which are already pretty limited.

[zapta]

I had today the my first program, a 1Hz blinky, running on an actual chip.  ;-)

[c64]

How did you program it?

[zapta]

I got a 1695-SLG4DVKGSD-ND from Digikey this week. They had two in stock and I ordered one. They say that the lead time is two weeks if you order now. Also ordered this https://www.amazon.com/dp/B0844Z6M83 so I can write my own flasher in Python.


https://www.digikey.com/en/products/detail/renesas-electronics-corporation/SLG4DVKGSD/16254311?s=N4IgTCBcDaIIwDYCcBWAtAZQDIHEAsAIgGoDSOGBaAcgSALoC%2BQA

[ataradov]

I've just assembled my board. I have an on-board MCU for programming/interfacing. But I want to go hard mode and not use vendor tools and make a Python script to configure the registers. This will likely be a project for the holidays though.

I want to prepare to the time when ForgeFPGA are released. It would be cool to play with their independent configuration too.

[zapta]

I've just assembled my board. I have an on-board MCU for programming/interfacing. But I want to go hard mode and not use vendor tools and make a Python script to configure the registers.

Can this be done with an of the shelf board such as Pi Pico?  If so, with a compatible python API on pypi.org, this can be a great open source tool for the community. People just buy a Pico board, flush the binary (no tools require) and have GreenPAK programmer with high level python library that can be pip installed.

[ataradov]

The Python script would generate 256 bytes of the firmware. It will not do any of the actual programing. I assume it would end up portable enough to run on the Pico.

But this workflow does not make sense. It is easier to generate the binary and then separately program it using whatever tools. In my case I don't even care to program it into the EEPROM, I just want dynamically configurable device.

My initial though was to actually just make a C header with all the defines for the device. The firmware is then easily generated in run-time. And I still might do that, but Python first for simplicity.

[zapta]

I see, I thought you are talking about the programming aspect.

How do you plan to generate the 256 configuration bytes. What will be the input to that program or how will the desired behavior will be defined?

[ataradov]

The same way you configure regular peripherals in the MCUs - a bunch of definitions for the configuration options and their possible values. With Python you can organize HDL-like structure, but I don't know if it is really necessary. There is not a whole lot of logic to configure there.

Literally half the configuration bits are I/O settings and matrix interconnect. There are a lot of bits, but once you know what you want, a lot of them don't matter, so the actual functional part of the configuration is pretty small.