Adapting the packer to the alternative P&R

[yrabbit]

nextpnr with gowin as the Himbaechel architecture mainly affects gowin_pack.

At this experimental stage, I think it is wise not to mimic the old input format, but to support both for now.

The new nextpnr output file has a format flag in the header, so it's easy to distinguish between the two.

• new cell numbering, new wire naming, pips and bels are used.
• LUT and DFF come separately, not as SLICE - I'm interested to see what comes out of this and how it affects all sorts of ALU and RAM
• IO is purely nominal for now, just to make the LEDs and buttons work during the experiments.

[yrabbit]

gihub somehow doesn't pull new commits from my branch, but that's okay - just know that ALUs are added and tested:)

[pepijndevos]

I'm sliiiightly concerned that in the process of replacing fuzzing fuzzing will introduce more and more hardcoded constants with unclear origin that will make it harder to add new FPGAs maybe? Would at least be good to leave some pointers where all these constants came from.

And as you said there is indeed a lot of duplication during the transition, but that's fine. I'd even be fine with being a bit more radical and merging this without the duplication.

Here is an idea: set up CI to detect an alpha release and push those to test.pypi.org, and make nextpnr CI use that. That way we can make an alpha release with only himbachel, without people installing that and ending up with broken builds. It's always been the case that current Apicula only works with current Nextpnr, but we've recently found out that people will install alpha builds and complain they are broken.

[yrabbit]

Like this?

--- a/apycula/chipdb.py
+++ b/apycula/chipdb.py
@@ -687,8 +687,25 @@ def fse_create_hclk_aliases(db, device, dat):
             db.aliases[(row, col, 'HCLK1')] = (row, db.cols - 1, 'SPINE13')

 # HCLK for Himbaechel
-# hclk - locs of hclk control this side
-# edges - how cells along this side can connect to hclk
+#
+# hclk - locs of hclk control this side. The location of the HCLK is determined
+# by the presence of table 48 in the 'wire' table of the cell. If there is
+# such a table, then there are fuses for managing HCLK muxes. HCLK affiliation
+# is determined empirically by comparing an empty image and an image with one
+# OSER4 located on the side of the chip of interest.
+#
+# edges - how cells along this side can connect to hclk.
+# Usually a specific HCLK is responsible for the nearest half side of the chip,
+# but sometimes the IDE refuses to put IOLOGIC in one or two cells in the
+# middle of the side, do not specify such cells as controlled by HCLK.
+#
+# CLK2/HCLK_OUT# - These are determined by putting two OSER4s in the same IO
+# with different FCLK networks - this will force the IDE to use two ways to
+# provide fast clocks to the primitives in the same cell. What exactly was used
+# is determined by the fuses used and table 2 of this cell (if CLK2 was used)
+# or table 48 of the HCLK responsible for this half (we already know which from
+# the previous steps)
+
 _hclk_to_fclk = {
     'GW1N-1': {
         'B': {

[yrabbit]

I'm sliiiightly concerned that in the process of replacing fuzzing fuzzing will introduce more and more hardcoded constants with unclear origin that will make it harder to add new FPGAs maybe? Would at least be good to leave some pointers where all these constants came from.

I have added descriptions. I think it's not worth describing how to find which wire is the output of each primitive (in the test case, connect the output to the LED, track the routing, etc).

[yrabbit]

And as you said there is indeed a lot of duplication during the transition, but that's fine. I'd even be fine with being a bit more radical and merging this without the duplication.

well, I'm not so brave :) I still use the disabling of the clock fuzzer, which dramatically reduces the base generation time. The resulting bases are, of course, unusable with the old apicula due to the lack of clock aliases, but otherwise it is the same codebase from which one or the other bases can be obtained.

If we cut off the duplication now... it will be two separate products, right?

[pepijndevos]

Yes something like that. We semi-regularly get people who ask how to add a new device, and I used to tell them to look at old PRs but actually the process changed quite a lot, so it'd be good to leave some breadcrumbs for future me and other people to understand where these numbers came from and what they mean when it comes to adding another device.

[pepijndevos]

So is this good to merge now? I haven't actually tested on hardware yet but we'll get to that when making a final release. For now lets get this in, do alpha release to progress Nextpnr, and then do final testing for a full release.

[yrabbit]

I think it will be possible to merge in the evening (your) because I could touch legacy pll-nanolcd. I will check it and correct it if necessary. Himabechel part works like clockwork ;)

[uis246]

Does it use fuzzed blank or constructs from scratch?

[yrabbit]

fuzzed one. There is too little knowledge yet to make an “empty” image.