fix: enforce canonical ordering for tile port directions

[KelvinChung2000]

Make Direction orderable in canonical (NORTH, EAST, SOUTH, WEST, JUMP) order and sort tile ports by direction in parseTilesCSV so generated wire orderings are deterministic regardless of input row order.

[read-the-docs-community]

Documentation build overview

📚 FABulous | 🛠️ Build #32563292 | 📁 Comparing bad5961 against latest (473203d)

  🔍 Preview build  

4 files changed

± user_guide/building_doc/fabric_definition.html
± _modules/fabulous/fabric_definition/define.html
± _modules/fabulous/fabric_generator/parser/parse_csv.html
± generated_doc/fabulous/fabric_definition/define/index.html

[IAmMarcelJung]

Just some minor comments, rest LGTM. Also, the functool docs mention that also __eq__ should be defined, but probably we don't need it here since we won't have this case anyway (and it's a should, not a must after all)?

[EverythingElseWasAlreadyTaken]

This breaks the bitstream spec for FABulous 2.0 fabrics.

His is a diff of a fabric build with main and then let this PR version run over it again:

I'm not sure why, but for some reason, for FABulous 1.0 fabrics, this is not the case, the bistream spec is the same there. Thats why the reference tests did not catch this.

[KelvinChung2000]

I thought this was safe since Python's sorting is stable. It is probably that we do not sort at 1.0. Then sorting starts at 2.0 but that sort on sort changes something. This is looking like sorting at "W,E,b", not "b,W,E"

[KelvinChung2000]

At some point, we need to update the bitstream spec generation so that it remains stable regardless of how we change the front side from a random value. This is too annoying to deal with.

[EverythingElseWasAlreadyTaken]

At some point, we need to update the bitstream spec generation so that it remains stable regardless of how we change the front side from a random value. This is too annoying to deal with.

Yes, this is really annoying.
For 3.0 we can rethink the whole bitstream spec, but for now, we can't break it.

[KelvinChung2000]

I did this one because https://github.com/FPGA-Research/fabulous-tiles/blob/main/tiles/classic/E_IO/E_IO.csv is not in the correct order of NESW, the sort is to make this not matter. I will see what should be done.

[EverythingElseWasAlreadyTaken]

I did this one because https://github.com/FPGA-Research/fabulous-tiles/blob/main/tiles/classic/E_IO/E_IO.csv is not in the correct order of NESW, the sort is to make this not matter. I will see what should be done.

Overall the sort makes sense, but sadly this breaks things.
We could either go for a version check or just postpone this after official 2.0 release.

I've added FABulous 2.0b4 demos to the reference tests, to ensure that we don't add regression in the spec generation in the future.
FPGA-Research/FABulous-demo-projects#9