Would be interesting to see how the definition of the simple Blinky will look like with your 'language'.
https://github.com/zapta/GreenPAKs/tree/main/blinkyBTW, the design tool can create a project (including schematic) from the 256 configuration bytes it reads from a device. You can use it for example to run the Renesas validation rules on the configurations that you generate, or to run simulation over it. I find the simulations helpful in understanding the various blocks with very fast exploration cycles.
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.
Be interesting to follow that.
The smaller CPLD from Philips/ atmel / altera used fitters, that swallow Berkley TT2 files, and create a fit report and a JED fuse image file.
The abstraction in the Dialog design tool is minimal and is limited to a cell boundary. You chose a specific cell, select one of its variant configurations (e.g. LATCH vs LUT) and it shows you just the that subset of the cell functionality.
With your own definition language, in addition to fitting you can add cross cell abstractions, such as a LUT with more than one output, or a register with more than one bits. It all depends how much smart you want to add to the tool.
BTW, i managed today to program with a generic I2C interface. I plan to expand it to a more useful API and tool that support automation of multiple devices in-circuit programming.
https://github.com/zapta/GreenPAKs/blob/main/tool/test.pyhttps://github.com/zapta/GreenPAKs/blob/main/tool/greenpack_i2c_driver.py
Hello,
I designed FPGA board based on Gowin FPA (GW1N-LV9LQ144). This device has a 8640 LUts and 6480 Flip-Flops. The development board is well quipped with peripheral circuit. Below is image of this board
There are 64 pins of GPIOs leaded out on headers (16 differential pairs). High speed and differential signals traces are designed with length matching.
This board is cheap.
It has:
1) 8 LEDs
2) 5 switches
3) 8 DIP-Switches
4) VGA output
5) uSD card socket
6) Audio output
7) 3 Golpin headers - 64 pins
8 MB of PSRAM
9) USB FTDI built-in programmer
10) 32 Mbit external Flash
Regards
With your own definition language, in addition to fitting you can add cross cell abstractions, such as a LUT with more than one output, or a register with more than one bits. It all depends how much smart you want to add to the tool.
I don't think you can make anything useful. Only just for the sake of "hacking"
I definitely don't plan on doing anything advanced, just give you the ability to configure things in a better way than calculating the register values directly. There is no point in trying to be smart for a device with 20 LUT+FFs.
I started looking in details at the configuration, and the datasheet is not fully complete. For the LUT/DFF + CNT/DLY blocks, they list a fixed set of "supported" bit configurations, but they don't fully breakout the logic of mapping from the set of bits to the mux/demux control signals. Some of that is possible to guess, but other parts are not obvious. It would be easy enough to guess or figure out in practice, but it is strange that they did not document it, given the amount of information already provided.
For a few reasons
1. It reduces the SPI bus load. Especially if it you build a hierarchical tree.
2. It's nicer to debug a device this way.
3. It's optional since the user can use the original CLK and MOSI.
I consider to route also MISO signal. Especially for reason #1.
I started looking in details at the configuration, and the datasheet is not fully complete. For the LUT/DFF + CNT/DLY blocks, they list a fixed set of "supported" bit configurations, but they don't fully breakout the logic of mapping from the set of bits to the mux/demux control signals. Some of that is possible to guess, but other parts are not obvious. It would be easy enough to guess or figure out in practice, but it is strange that they did not document it, given the amount of information already provided.
Did you look at both logic diagrams and register definitions?
They probably expected everyone to to use the GUI tool
I definitely don't plan on doing anything advanced, just give you the ability to configure things in a better way than calculating the register values directly. There is no point in trying to be smart for a device with 20 LUT+FFs.
Would be nice if someone wrote a Verilog/VHDL compiler
Or even something simple like CUPL
Did you look at both logic diagrams and register definitions?
Yes, I did. And it is not like documentation missing, it is all there is you just use specified bit patterns. You just can get more flexibility by treating things as separate controls.
The diagrams are not entirely representative of the full logic. If you look at Figure 31, for example, the first column of multiplexers has two input per mux and one control signal. But this signal is not a specific single bit, it is not even a common signal for all of them. It is a separate signal for each mux, which is derived from registers [1341:1340] and [1338:1337].
It would be a very Verilog limited compiler. To the point of being useless. It is a lot of work for absolutely no benefit. The interconnecting logic is very simple, so all you will have is just instantiations of those 20 modules with direct writes between them.
Did you look at both logic diagrams and register definitions?
The diagrams are not entirely representative of the full logic. If you look at Figure 31, for example, the first column of multiplexers has two input per mux and one control signal. But this signal is not a specific single bit, it is not even a common signal for all of them. It is a separate signal for each mux, which is derived from registers [1341:1340] and [1338:1337].
Yes you are right. There is another hidden LUT between [1341,1340,1338,1337] and control signals. To save few bits of NVM I guess.
It looks like the first mistake found. In the description of "Single 4-bit LUT" and "Single DFF w RST and SET" (bits 1280 - 1286), the enumerated values are not correct. The first one is "0000000", the second one is shown as "0010000". The exact order of the bits is not well documented, but the rest of the table shows third bit from the right to select LUT vs DFF (bit 1282), which also matches the diagram. In this case it looks like the value "0010000" is bit reversed. In practice "0000100" selects DFF, which matches the reset of the table.
Also, this thing is somewhat easy to debug. It has a virtual 8-bit port that can be written from I2C and it can be routed to any inputs of the blocks. And outputs of all blocks are also available. So, there is not even a need to connect anything to the pins to test functionality, I just provide inputs from the Python script.
It looks like the first mistake found. In the description of "Single 4-bit LUT" and "Single DFF w RST and SET" (bits 1280 - 1286), the enumerated values are not correct. The first one is "0000000", the second one is shown as "0010000". The exact order of the bits is not well documented, but the rest of the table shows third bit from the right to select LUT vs DFF (bit 1282), which also matches the diagram. In this case it looks like the value "0010000" is bit reversed. In practice "0000100" selects DFF, which matches the reset of the table.
Can you select this exact option from GUI?
I don't want to. I don't want to download that IDE unless I absolutely have to.
There is a clear structure to those bits, and this one is absolutely swapped. The bits in the table are in order 1286-1280. This way it makes sense for the diagram. But it does not looks like there is a lot more functionality that can be extracted from arbitrary configurations. I don't know why they needed it to be that convoluted. Arbitrary and uniform selection of inputs would be so much better.
It looks like the first mistake found. In the description of "Single 4-bit LUT" and "Single DFF w RST and SET" (bits 1280 - 1286), the enumerated values are not correct. The first one is "0000000", the second one is shown as "0010000". The exact order of the bits is not well documented, but the rest of the table shows third bit from the right to select LUT vs DFF (bit 1282), which also matches the diagram. In this case it looks like the value "0010000" is bit reversed. In practice "0000100" selects DFF, which matches the reset of the table.
Order of bits is specified in the table as below, so 1282 supposed to be third bit from the
left1286
1285
1282
1284
1283
1281
1280
This order is entirely incorrect. Here is a more combined (LUT/DFF is marked with *) and better arranged table.The pairs (1286 1285) (1284 1283) (1281 1280) make a lot of sense and match the diagrams. There is not a lot of extra decoding going on, just some reuse of bits.
# 1286 1285 1284 1283 1282 1281 1280
# 00 00 0 00 - 4-bit LUT : DLY_IN - LOW In3 - A In2 - B In1 - C In0 - D
# 00 10 0 00 - DFF : DLY_IN - LOW Di - A nSET - B nRST - C CLK - D
# 00 00 0 01 - CNT/DLY : DLY_IN - D UP - A KEEP - B EXT_CLK - C DLY_OUT - L/D
# Di nSET nRST CLK
# 00 00 * 10 - CNT/DLY -> L/D : DLY_IN - A In3 - DLY_OUT In2 - B In1 - C In0 - D
# 01 00 * 10 - CNT/DLY -> L/D : DLY_IN - A In3 - DLY_OUT In2 - [1282] In1 - C In0 - D EXT_CLK - B
# 10 00 * 10 - CNT/DLY -> L/D : DLY_IN - A In3 - DLY_OUT In2 - B In1 - [1282] In0 - D EXT_CLK - C
# 00 01 * 10 - CNT/DLY -> L/D : DLY_IN - B In3 - A In2 - DLY_OUT In1 - C In0 - D
# 10 01 * 10 - CNT/DLY -> L/D : DLY_IN - B In3 - A In2 - DLY_OUT In1 - [1282] In0 - D EXT_CLK - C
# 00 10 * 10 - CNT/DLY -> L/D : DLY_IN - C In3 - A In2 - B In1 - DLY_OUT In0 - D
# 01 10 * 10 - CNT/DLY -> L/D : DLY_IN - C In3 - A In2 - [1282] In1 - DLY_OUT In0 - D EXT_CLK - B
# 00 11 * 10 - CNT/DLY -> L/D : DLY_IN - D In3 - A In2 - B In1 - C In0 - DLY_OUT
# 01 11 * 10 - CNT/DLY -> L/D : DLY_IN - D In3 - A In2 - [1282] In1 - C In0 - DLY_OUT EXT_CLK - B
# 10 11 * 10 - CNT/DLY -> L/D : DLY_IN - D In3 - A In2 - B In1 - [1282] In0 - DLY_OUT EXT_CLK - C
# 00 00 * 11 - L/D -> CNT/DLY : DLY_IN - L/D_O In3 - A In2 - B In1 - C In0 - D
# 01 00 * 11 - L/D -> CNT/DLY : DLY_IN - L/D_O In3 - A In2 - [1282] In1 - C In0 - D EXT_CLK - B
# 10 00 * 11 - L/D -> CNT/DLY : DLY_IN - L/D_O In3 - A In2 - B In1 - [1282] In0 - D EXT_CLK - C
In all cases bit 1282 is third from the right, except for the second line.
Which IC are you using?
Also, why don't you want to load the design tool, for security reasons? It can be very useful to what you are doing, showing the bits interactively as you configure the cells.
Which IC are you using?
SLG46826.
Also, why don't you want to load the design tool, for security reasons? It can be very useful to what you are doing, showing the bits interactively as you configure the cells.
There is no fun in doing that. I have no practical use for this device other than to have fun figuring it out on a low level.
It will be useful for the community if you can document what you find. Adding insight on top of the official documents.
This order is entirely incorrect. Here is a more combined (LUT/DFF is marked with *) and better arranged table.The pairs (1286 1285) (1284 1283) (1281 1280) make a lot of sense and match the diagrams. There is not a lot of extra decoding going on, just some reuse of bits.
I checked with whatever GUI generates. Looks like whoever made this table, first few entries they documented correctly, and for the rest they forgot about bit 1282, and documented as if all bits are in descending order. Or maybe it was two different persons
What is the moral of this story? When you document this kind of stuff, it must be generated automatically, and from the same data as the software.
I've been working though the document, describing this thing as a huge Python dictionary. It is actually quite hilarious, and I wonder if it is intentional. Not a single description of those multi-function blocks is correct. Most have binary values moved around. One has them correct, but the bit indexes are wrong.
The other digital blocks are more or less ok, but the analog blocks are mental. There are bits that are mentioned in the table and never in the rest of the datasheet. And overall descriptions do not match the diagrams.
The datasheet is really bad all around. For such a simple thing, it is one of the worst I read in a long time.
If you like, you can report the errors here
https://community.renesas.com/analog-products/f/greenpak-greenfet . They do expose the bits in the designer and even provide a tool to compare two sets of configuration bits, which means that the bits are exposed to the user and are expected to be correct.
The datasheet is indeed not clear, even if not getting into the configuration bits. I explore through trial and error in the design tool, using simulations. I presume that most of their users use the design tool, don't get into the bits, and get hand holding from the vendor when needed.