put ignition rev2+ builds into play

[nathanaelhuffman]

This puts the changes in place for rev2+ cosmo ignition images. This also creates a new fpga build for rev1 which is essentially orphaned due to different pin config.

In building this, we had a timing failure in oximux 16 on the cosmo-hp build so I adjusted the 1hot detection logic to be more logic-efficient.

[Aaron-Hartwig]

This also creates a new fpga build for rev1 which is essentially orphaned due to different pin config.

could we just get rid of this then?

[Aaron-Hartwig]

Ah, I see we do need to keep that rev1 build around. I was thinking we had version resistors here.

[nathanaelhuffman]

Yes given the changes, rev1 becomes a special case, and all future cosmos need a different image.

[Aaron-Hartwig]

Rather than comment throughout I'll just leave a top level suggestion. We should make the naming here explicit about which version of boards will be supported (we can debate rev numbers vs HCV letters). But I don't think having an _r1 build and a build without any suffixes makes it immediately clear what is supported. On other boards we've done things like add letters when the same image supports multiple versions, e.g., _abc.bit.

[Aaron-Hartwig]

lets make this cosmo_ignition_a

[nathanaelhuffman]

i'm ok with this and will fix tomorrow

[Aaron-Hartwig]

lets make this cosmo_ignition_b ?

[nathanaelhuffman]

So I don't love the sustainability of this longer term. In a nicer world I would have noticed this incompatible hw change during review and we could have had one image to rule them all, but alas.

What I specifically dislike about this is that historical runs and filenames change when new hw lands and, while it is now explicit for people looking at that point and forward, going back in history and figuring out what is related to what becomes more painful. It also forces downstream sw flag days: facade has to pick up new file names etc and a simple rollback becomes more complicated etc.

[nathanaelhuffman]

Rather than comment throughout I'll just leave a top level suggestion. We should make the naming here explicit about which version of boards will be supported (we can debate rev numbers vs HCV letters). But I don't think having an _r1 build and a build without any suffixes makes it immediately clear what is supported. On other boards we've done things like add letters when the same image supports multiple versions, e.g., _abc.bit.

I put more detailed comments in a thread above, but while I'm sympathetic to the goals here, I don't like this solution for the reasons enumerated there, but am open to chatting about alternatives that help meet these goals without ensuring future make-work for everyone.

[Aaron-Hartwig]

We chatted and are going to have the fpga-releaser tool handle bitstream file renaming per which HCVs are applicable. This gives us the option to decouple that from the internal file naming structure of the design in quartz.