CLKDIV support about apicula HOT 13 OPEN

Not so fast in the end, lol. I ended up tripping over myself, and behaviour from fuse_h4x.parse_tile that may or may not be a bug.

First, to the stuff that matters most:

CLKDIV

I was targeting GW2A, so everything written here is from that perspective. CLKDIV has two parameters (DIV_MODE and GSREN), three inputs (HCLKIN, RESETN, and CALIB), and one output(CLKOUT).

Parameters

For the first HCLK on a side (going clockwise round the chip), DIV_MODE is controlled by feature codes (15,0) - (18,0) in shortval table 50. For the second HCLK on the side, it is controlled by features (20,0) - (23,0). In my experiments, feature (29,0) and (30,0) were activated occasionally, but I haven't been able to identify what they do. The other features in table 50 seem to control other behaviour/functions in the HCLK tiles, like DHCEN, CLKDIV2, inputs from other HCLKs, etc.

I don't know how to handle the GSREN parameter yet. Enabling or disabling it does not seem to flip any fuses, so it might be implemented purely via routing. Feature (19,0) which I suspect to be some kind of parameter gets enabled sometimes, and I have no idea why.

Input

HCLKIN is routed to the input of the HCLK on the appropriate bank, as one would expect.
The connections for the RESETN and CALIB inputs are a bit more interesting: These connections are always made to the HCLK tile that is closest to the (0,0) coordinate. For example, RESETN and CALIB inputs for both CLKDIVS on the top-side are made to the HCLK on Bank 0; while for the bottom side, they both connect to the HCLK on bank 5.

For the first HCLK on a side (in this case, the first one is the one closest to the (0,0) coordinate), RESETN and CALIB connect to B0 and C0 respectively; for the second HCLK, they connect to B5 and C5.

Output

When CLKOUT goes back to the logic tiles on the fabric, it is routed via the table 38 connections, which I think should work out of the box. Features (29,0) and (30,0) seem to control whether the output of CLKDIV gets routed to the primary (HCLK_OUT0/HCLK_OUT2) or alternate (HCLK_OUT1/HCLK_OUT3) output node of HCLK.

Observations and Suggestions

In fuse_h4x.parse_tile, the "negative wires" get overwritten by the "positive wires" -- the fuses for an entry like (-1, 2) get overwritten by fuses for the (1,2) entry, where a (1,2) entry exists. The implication of this is that parse_tile never checks if the fuses associated with the (-1,2) entry are in the state prescribed by the (-1,2) row. If this is not intended behaviour, I'll be happy to submit a PR to fix it.

Curiously enough, the fuses associated with the negative wires that are not overwritten still seem to 'cover' for all the ones that do get overwritten. I have no idea if this is by design or just a nice coincidence.

Speaking about covers, I found that solving for a minimum cover can be useful for cutting out 'noise' in the report from parse_tile. Consider a somewhat trivial example like this, where parse_tile reports the following wires:

['HCLK_IN2', 'HCLK_OUT3']             [4, 13, 5098, 5113, -1, -1, -1, -1]
['HCLK_IN3', 'HCLK_OUT3']             [5, 13, 5098, -1, -1, -1, -1, -1]
['HCLK_UNK9', 'HCLK_OUT3']            [9, 13, 5113, -1, -1, -1, -1, -1]
['TLPLL0CLK0', 'HCLK_IN2']            [81, 4, 5126, 5141, 5216, -1, -1, -1]
['TLPLL0CLK1', 'HCLK_IN2']            [82, 4, 5111, -1, -1, -1, -1, -1]
['BLPLL0CLK0', 'HCLK_IN2']            [89, 4, 5111, 5126, -1, -1, -1, -1]
['BLPLL0CLK1', 'HCLK_IN2']            [90, 4, 5111, 5141, -1, -1, -1, -1]
['PCLKL0', 'HCLK_IN2']                [125, 4, 5111, 5126, 5216, -1, -1, -1]
['PCLKL1', 'HCLK_IN2']                [126, 4, 5111, 5126, 5141, 5216, -1, -1]
['LBDHCLK1', 'HCLK_IN2']              [179, 4, 5111, 5141, 5216, -1, -1, -1]
['VSS', 'HCLK_IN2']                   [278, 4, 5111, 5126, 5141, 5216, -1, -1]

After solving for a minimum cover, this is what we get: the smallest set of wires that account for all the fuses :).

['HCLK_IN2', 'HCLK_OUT3']              [4, 13, 5098, 5113, -1, -1, -1, -1]
['PCLKL1', 'HCLK_IN2']                 [126, 4, 5111, 5126, 5141, 5216, -1, -1]

It's not perfect, and has the potential to hide connections that are useful, but I think it can be quite useful regardless. I found two solvers -- one optimal one without any dependencies, but with bad runtime for long lists; and an approximate one that performs better on long lists but has a numpy dependency. I can submit a PR for this too.

from apicula.

Great job!
Let's start from the end: minimum cover for wires is a cool thing that I dreamed of :) Considering the nature of the application, I vote for the slow option - it’s still faster than what I’m looking for with my eyes, but subconsciously I won’t trust the “approximate” ;)

Regarding the “negative” wires and their fuse, there are many mysterious places in the Gowin IDE tables and this is one of them.
I'm reading lines like "if a given source is connected to a given sink, then the following fuses must NOT be set."
If this is true, then in most cases there is no point in paying attention to the absence of these fuses - the only exception is a line for which there is no “positive pair” - this is a connection when all fuses are cleared, that is, roughly speaking, an empty chip, the default connection.

And now the main thing: you have identified a sufficient number of features to look for candidates for the table from dat['header']['logicinfo'], when you find it, then we can look at the attributes.

from apicula.

@Seyviour are you on our matrix channel? We're discussing plans for the coming year, in case you would like to be more actively involved.

from apicula.

Hello @pepijndevos. Yes, I'm on the chat. I'm following the conversation but I haven't had much to say so far.

from apicula.

Do you mean DVI? Because any implementation of HDMI without a license invites legal action. Almost a joke.

About the primitive: for CLKDIV it is a very heavy primitive, BSRAM is a child's walk in comparison. Because the input for it is HCLK - the same two wires that run along the sides of the chip.

But, since I don’t know your experience (what if you just need an evening to implement this thing?), the approximate plan of action is as follows:

• learn to compare images with each other in order to isolate changing places;
• find the fuses responsible for the division coefficient (it's easy);
• find MUXes that connect the input of this primitive to HCLK (hard, since these MUXes are scattered throughout the chip);
• find MUXs that connect the CLKDIV output to consumers (this can be simple if the consumer can be simple logic and may turn out to be hemorrhoids if the consumers are only IO).

And yes, it’s better to immediately forget about nextpnr-gowin: of course, you can do anything, but if something doesn’t work, then dealing with the non-himbaechel option... I’ll say for myself - there’s no point.

from apicula.

Do you mean DVI? Because any implementation of HDMI without a license invites legal action. Almost a joke.

For my use-case, I am happy with DVI-D to LVDS over the pins. This is for learning purposes.
By saying HDMI I am describing the port on the tangnano device which Sipeed describe as a HDMI connector.
https://wiki.sipeed.com/hardware/en/tang/Tang-Nano-9K/Nano-9K.html

I'll start with the first two steps before I even get to the latter ones.

learn to compare images with each other in order to isolate changing places

I'm not sure what you mean by this.
Does this mean the images of the fpga under a microscope of looking at the gates ?

find the fuses responsible for the division coefficient (it's easy);

I thought one could create some simple verilog examples of CLKDIV and change values to see how it behaves.
I presume that is this part ?

himbaechel

I see commits for this in the nextpnr repo it seems to be something about a newer api to the nextpnr framework for FPGAS with larger LUT counts. I don't know how much of this works atm.

from apicula.

learn to compare images with each other in order to isolate changing places

I'm not sure what you mean by this. Does this mean the images of the fpga under a microscope of looking at the gates ?

I meant to compare the images that you flash into the FPGA. To avoid repetition:
#185

find the fuses responsible for the division coefficient (it's easy);

I thought one could create some simple verilog examples of CLKDIV and change values to see how it behaves. I presume that is this part ?

Almost. You already KNOW how it behaves, at least in theory, but the bits that make this piece of FPGA behave are unknown (and interesting).

himbaechel

I see commits for this in the nextpnr repo it seems to be something about a newer api to the nextpnr framework for FPGAS with larger LUT counts. I don't know how much of this works atm.

Look in the examples directory. In short, everything that works in legacy gowin works, plus attosoc works on Tangnano9k, Tangnano20k and TangPrimer20k.

https://github.com/YosysHQ/apicula/tree/master/examples/himbaechel

from apicula.

Do you mean DVI? Because any implementation of HDMI without a license invites legal action. Almost a joke.

About the primitive: for CLKDIV it is a very heavy primitive, BSRAM is a child's walk in comparison. Because the input for it is HCLK - the same two wires that run along the sides of the chip.

But, since I don’t know your experience (what if you just need an evening to implement this thing?), the approximate plan of action is as follows:

* learn to compare images with each other in order to isolate changing places;

* find the fuses responsible for the division coefficient (it's easy);

* find MUXes that connect the input of this primitive to HCLK (hard, since these MUXes are scattered throughout the chip);

* find MUXs that connect the CLKDIV output to consumers (this can be simple if the consumer can be simple logic and may turn out to be hemorrhoids if the consumers are only IO).

And yes, it’s better to immediately forget about nextpnr-gowin: of course, you can do anything, but if something doesn’t work, then dealing with the non-himbaechel option... I’ll say for myself - there’s no point.

Hello :)

I'm currently working on this.

I believe I've identified the fuses that configure the DIV_MODE, and I've confirmed that the output of CLKDIV can be consumed by simple logic (the use case I have an interest in). All that to say that I've done the easy part, lol. Finding the muxes will be more tasking, and there's the extra complication that the output of CLKDIV in one bank can be routed to other banks.

I have two questions, if you'll be kind enough to answer:

• How much is currently known about HCLK itself?
• Why do you expect that finding the muxes for CLKDIV input will be hard, given that CLKDIV seems to be in the same rows/columns that the other IO tiles are on? If we already know how to use HCLK in other IO tiles, maybe this won't be so different 🤞

TIA

from apicula.

Wow, that was fast! Congratulations.

In addition to what is written in the Gowin documentation, we have the locations of cells with HCLK MUXes for supported chips, as well as the ranges of cells served by each of the 4 HCLK outputs. If the signal from the CLKDIV output is supplied via HCLK, then there may not be any particular difficulties even with switching to another bank - this may have already been decided inside the MUX.

My assumptions about possible difficulties are probably related to memories of research on these same HCLKs - that the wire numbers coincide with the numbers of the watch spines, but are not connected to them, then that in 9C some HCLK wires have different numbers, but in fact one wire , then in some IO cells the CLK2 wire is actually HCLK - there was a lot of fun there.

But it’s possible that you won’t have to deal with this anymore.

from apicula.

Thank you!

Haha. Yes, lots of weird stuff, like the alonenode table :). About the wires, the core reason why I think it'll be a good idea to report the negative wires is so that someone like me doesn't get confused in the future. Maybe we can add an argument to the function that determines if it considers the negative wires or not?

I agree with you that the exact solver is better in this case. It might also be a good idea for it to return the top-n solutions rather than just the best one. 🤔

About 'logicinfo', I'd be grateful if you could kindly clarify as myy understanding of that table might be wrong.

Given that the following entries associated with DIVMODE are in 'shortval':

[15, 0, fuse1, -1, -1, -1 ... -1]
[16, 0, fuse1, -1, -1, -1 ... -1]
[17, 0, fuse1, -1, -1, -1 ... -1]
[18, 0, fuse1, -1, -1, -1 ... -1]
etc. 

Is my task to find a 'logicinfo' table that has entries like

(x, 15)
(x, 16)
(x, 17)
(x, 18) 

from apicula.

Well, now you remember that there is no point in paying attention to the “negative” wires except for one single one, so maybe it will be enough to just describe it in the documentation? ;)
And besides, the flag is only half the battle - you understand that fuses in “negative” lines should be cleared, not set - I think the function will turn into mush :)

If you need the "alonenode" table, then you're already doing those complex things so I can retire :)

Now about logicinfo. Its structure is described in the documentation (I think), but I’ll repeat it anyway. Now it is more convenient to work not with raw tables from a dat file, but from db.logicinfo.
We look at the rows of each table as follows:

row_number (attribute, value)

that is, your numbers 15, 16, 17, 18 in the shortval table are line_number in logicinfo:

...
row 15 [attr_0, val_0]
row 16 [attr_0, val_1]
row 17 [attr_2, val_4]
row 18 [attr_3, val_0]
...

attr is the numeric code of the primitive parameter, val is the parameter value. val can be either the direct value of the parameter (if you write inst.SOME_PARAM=4 in verilog, then val is also 4), or a code (inst.SOME_OTHER_PARAM=DISABLE, then val = some_number)

Although there are few tables (25 or so), searching there by boolean parameters is a very “creative” process, but if the parameter has several values, then the situation improves significantly. You're lucky: the DIV_MODE (?) parameter has several values, which means you just need to find those tables where lines 15-18 look like:

15: (x, val0)
16: (x, val1)
17: (x, val2)
18: (x, val3)

that is, where x is the same and val is different.

from apicula.

Okay, then I'll add updating the documentation to my todo list. parse_tile reporting some negative wires and not others was confusing to me, and someone that doesn't know what's going on might have a similar experience.

Haha. I'm leaving the "alonenode" table alone for now. Maybe that's what it means -- "Leave this table alone" :) :)

Thanks a lot for explaining the 'logicinfo' table.

If the row-numbers start from 0, then it seems "unknown_49" is the table:
These are lines 15 - 24. Lines 20-24 match up with the fuses for the second HCLK on a side, so I'm pretty confident.

(14, 13),
 (14, 14),
 (14, 15),
 (14, 16),
 (15, 4),
 (16, 13),
 (16, 14),
 (16, 15),
 (16, 16),
 (17, 5)

from apicula.

Great!
Now that you have the logicinfo table number and attribute numbers, I would advise you to do... synthesis.

With a high probability, yosys understands the primitive itself and passes it through itself, but you will have to work with nextpnr.
It needs databases and you will generate the databases :)

You need to place Bels in the right cells. Candidates will be cells with a type that has a table of 49. There may be too many of them, then you will need to experiment and determine the fuses in which cells react to changes in the divisor - there, with a high probability, it will be possible to create Bels.

The goal is to create the entire chain necessary to obtain the image using apicula and then compare the images with the vendor ones in order to achieve a match.

from apicula.