peepsalot has quit [Quit: Connection reset by peep]
mwk has quit [*.net *.split]
mwk has joined #prjmistral
QDX45 has joined #prjmistral
<Sarayan>
okay, all 7 dies are in, that way it'll easier to check whether my generic code is generic
peepsalot has joined #prjmistral
<Lofty>
We're probably going to need to figure out a mapping from SKU to die, but that can be done ~later~
<Sarayan>
You mean like:
<Sarayan>
{ "5CEBA4F23C7", "e50f", "e50b", CycloneV::PKG_F23, 'C', 7, [](const Model *m) -> CycloneV * { return new cvm_e50b(m); } },
<Sarayan>
{ "5CGTFD7C5F23C7", "gt150f", "gt150f", CycloneV::PKG_F23, 'C', 7, [](const Model *m) -> CycloneV * { return new cvm_gt150f(m); } },
<Sarayan>
{ "5CGTFD9C5F23C7", "gt300f", "gt300f", CycloneV::PKG_F23, 'C', 7, [](const Model *m) -> CycloneV * { return new cvm_gt300f(m); } },
<Sarayan>
{ "5CGTFD5C5F23C7", "gt75f", "gt75f", CycloneV::PKG_F23, 'C', 7, [](const Model *m) -> CycloneV * { return new cvm_gt75f(m); } },
<Sarayan>
{ "5CGXFC3B7F23C8", "gx25f", "gx25f", CycloneV::PKG_F23, 'C', 8, [](const Model *m) -> CycloneV * { return new cvm_gx25f(m); } },
<Sarayan>
{ "5CSEBA6U23I7", "sx120f", "se120b", CycloneV::PKG_U23, 'I', 7, [](const Model *m) -> CycloneV * { return new cvm_se120b(m); } },
<Sarayan>
{ "5CSXFC4C6U23A7", "sx50f", "sx50f", CycloneV::PKG_U23, 'A', 7, [](const Model *m) -> CycloneV * { return new cvm_sx50f(m); } },
<Sarayan>
BTW, I just can't find the difference at the quartus level between 5CSEBA6U23I7 and 5CSEBA5U23I7 (A6 vs. A5)
<Sarayan>
the first is se120b and the second se90b, the secod is supposed to have less of everything on the same die, but under the chip planner I see zero difference
<Sarayan>
the file for the 90b says it has 85000 LEs and the 120b 110000, but these are marketing numbers given they're round
<Sarayan>
ok, it also says it has a different number of LE_COMB and FF, but I don't see where it says which ones are missing
<Sarayan>
afaict, it doesn't
<Sarayan>
a 5CSEBA6U23I7 probably work as-is on a 5CSEBA5U23I7
<Sarayan>
_firmware
<Sarayan>
+
<Sarayan>
Can we actually limit the number of LE_COMB/FF/etc without actually removing them from the BEL list?
<Lofty>
Probably a question for daveshah
<daveshah>
You could just have a little thing that checks the total count
<Sarayan>
I'd rather avoid the "open source stuff ignores intel limits, drm!drm!drm!"
<daveshah>
Although I'd accept a PR surrounding said code in #if 0
<Sarayan>
dmca, etc
<Lofty>
Hmmm...
<daveshah>
I didn't do anything like this for the ECP5 12k nor did Claire for the iCE40 4k
<Lofty>
Sarayan: honestly, even if we try to add an artificial restriction like that, somebody can just read the code and patch it out
<Lofty>
I don't think it's worth even trying
<Sarayan>
Then I should just not put it in, because as far as I can tell it's the only difference
<Sarayan>
there is nothing on the firmware generation side
<Sarayan>
e.g. no model number in the stream
<Sarayan>
(afaict again)
<daveshah>
Do they have the same IDCODE
<Lofty>
We don't know at present
<Sarayan>
I didn't see an idcode in the firmware
<Sarayan>
nor in the "model description file"
<daveshah>
Interesting
<Sarayan>
well, err, no, there is a model value in the model description file
<Sarayan>
but I dont think it goes in the firmware
<daveshah>
I know Intel reuses IDCODEs more readily than others, as the Quartus programmer asks you what device you actually want
<Lofty>
The ECP5-12k is functionally identical to the 25k, right, daveshah?
<daveshah>
ECP5 and Xilinx both have parts of the IDCODE in eFuse so it can be set for marketing/test reasons
<daveshah>
Lofty: yes, same die, different IDCODE bit in eFuse
<Lofty>
I'm wondering whether Intel/Altera actually go to the trouble of disabling these ALMs
<Lofty>
To improve yield or whatever
<Sarayan>
they can't
<Lofty>
Sure they can
<Sarayan>
because right now in the files the list of BELs is the same for a5 and a6
<daveshah>
That would be like ECP5 and Xilinx
<daveshah>
Where they just limit the total count
<Sarayan>
only the total number of available bels is changed
<daveshah>
Not a particular region of the device
<Lofty>
Mmm, fair
<Sarayan>
so since the pnr can put them anywhere, they can't disable them
<Sarayan>
I was hoping they did, actually, so we'd just have followed the hardware
<Sarayan>
hmmm, there may actually be something in the options header, I'll have to make sure
<daveshah>
I'd be surprised if there was nothing at all
<daveshah>
Otherwise you could just tell Quartus you had the bigger device
<daveshah>
and then run the resulting bitstream on the smaller device
<Lofty>
I do know there's like this vertical migration mode where you can make a bitstream that apparently runs on multiple devices
<Lofty>
So, uh, that might actually be possible.
<Sarayan>
Lofty: they're in fact the same die, and the packaging for a given die (pad-pin connections) is independant of the model
<Lofty>
Okay, fair
<Sarayan>
and the migration mode is about pinout
<Sarayan>
If I say "HSSI_STRIP_SUPERBLOCK", does that ring a bell for anybody?
<daveshah>
In the Xilinx world SSI = stacked silicon interconnect