Help finding a small and low cost programable logic IC.

[ataradov]

Ok, I'm done with this for now. I'm attaching the files in case anyone interested. The working blinky example:

Code: [Select]

i2c.addr = 1 # default

osc0.power   = always
osc0.matrix  = off
osc0.pre_div = 8
osc0.div1    = 1
osc0.out1    = enable

cnt_dly_1.clk_src = osc0
cnt_dly_1.dly_in  = low
cnt_dly_1.data    = 128
cnt_dly_1.fn_edge = rising_edge_reset
cnt_dly_1.sync    = 2dff

lut2_0.in0 = dff_1
lut2_0.in1 = dff_1
lut2_0.lut = nand

dff_1.clk = cnt_dly_1
dff_1.d   = lut2_0

io14.input_mode = digital_schmitt
io14.pull_value = 10K
io14.pull_mode  = up

lut2_3.in0 = dff_1
lut2_3.in1 = io14
lut2_3.lut = and

io6.output_mode = push_pull_2x
io6.output      = lut2_3
io6.output_oe   = enable

io3.output_mode = push_pull_2x
io3.output      = osc0_1
io3.output_oe   = enable
The source clock is 2048 Hz OSC0 pre-divided by 8. It then further divided by cnt_dly_1 by 128. It then goes to the DFF_1 clock and the data input is the inverted output. Note that the same could have been achieved by specifying "dff_1.dff_output = qb" and connecting the output to the input directly. I used lut2_0 as an inverter to show more logic. The output is IO6. It is further gated by IO14 input, again to show more stuff. The 2048 Hz is also output on IO3.

I have not verified all the bit values, so there are likely some mistakes. And it is also likely that some bits can be better grouped/described. But this all will be obvious with use. At least now there is a computer-readable description of the part, which can be used to generate C defines, for example to allow run-time dynamic configuration from the host MCU.

Error checking is very minimal. Conflicting resource use is detected on the bit/register level. If two blocks demand the same bit to be set to different values, then something is conflicting. I have no doubt it is possible to intentionally create situation that is not detected by this system.

But for now I've had my fun and I want to work on other stuff. Now that I know how this part works, I'll keep it in mind and may be it will come in handy in some project.

Also, can anyone attach any generated binary from the IDE? The last 16 bytes on the blank part seem to contain some information. I wonder what IDE puts there. In my experiments I have not tried to reprogram those bits and just left them as is. They are reserved in the datasheet.

[zapta]

Very elegant code.  What USB/I2C adapter are you using?

I loaded the bits your test generates to the design tool and got the view below. The rules checks went well except for comments about the comparators which are not connected by included in the design. Not sure what this means in the SPLD, maybe they are powered on, even though they are not used?

When I disabled the comparators in the design tool and exported the NVM bits, I god the diff shown in the second screenshot below. The last page of the NVM is not user writeable so not sure what the design tool put in those bits and what bits the SPLD returns when reading these bits.

[zapta]

...

The second screenshot below is the diagram from your bits after hiding the comparators and rearranging blocks.

The first one is after converting the NAND to an INVERTER.

[ataradov]

Those bits are entirely undocumented. The whole last part of the memory map is reserved. A blank device has this in the last 16 bytes "40 16 11 27 22 18 10 10 10 00 b8 00 00 00 00 a5". I have no idea what that is, so I can't meaningfully generate this value. In my experiments I just left those bytes as is. In my experiments I saw no issues with those comparators being "enabled". It might affect power consumption or something like that, but I don't think it matters for functionality.

I use a custom adapter based on SAM D11. I just hacked up an existing VCP project to interpret the commands and translate them to I2C. I have it mounted on the same breakout board, so I don't have to worry about separate adapters.

[zapta]

According to the in-circuit programming guide, the last 16 bytes are also not user writable, so it doesn't matter what you put there. It's possible that the design tools uses it for its own purpose.  I just write pages 0-14 and verify them by reading back.

[ataradov]

Ok, but the bits in your diff are in that page. So, it looks like the tool uses them to store project settings rather than actual data. So you can import the binary back and get correct things enabled, but the programming tool will ignore that.

[zapta]

I changed the USB/I2C adapter and hit this errata where writing to the erase register doesn't ack. Added code to clear the error and continue.

https://www.renesas.com/us/en/document/dve/slg46824-errata?language=en

I am now programming with a plain Raspberry Pi PICO that acts as a USB/I2C adapter, instead of the of the shelf I2cDriver Mini.

[zapta]

Posted my code as two pypi packages here:

https://pypi.org/project/greenpak      // An API do read/write/program greenpak devices via I2C.
https://pypi.org/project/i2c-adapter   // Rasberry Pico based USB to I2C adapter.

In the future will extend the greenpak driver to support also other USB/I2C adapters.

[zapta]

Here is an example with the in-circuit initial address assignment. The control codes page may be at different NVM addresses in different device type,  hence the programming is done for each device type independently.. Writing the control code page for one type creates a side affect on the other types that were not assigned yet, but this is fixed once they move to their real address and are reprogrammed from scratch.

https://greenpak.readthedocs.io/en/latest/#assigning-initial-addresses