<whitequark[cis]>
aren't all hyperram devices pin compatible
<whitequark[cis]>
damn, 250 MHz clock
<esden[m]>
Yeah I think they are. The issue is IO voltage, if the clock is diff pair or not, and also the max clock. (the last one is not really an issue for us as we will have a hard time reaching any of them anyways)
vegard_e[m] has joined #glasgow
<vegard_e[m]>
I believe all hyperbus devices fall within a common superset of IO
<esden[m]>
In our case the main issue is the IO voltage. There are 3v3, 1v8 and 1v2 devices that I have seen.
<vegard_e[m]>
IIRC the dual hyperram+hyperflash ones just adds another chip select
<vegard_e[m]>
and yeah, IO voltage is an issue
<vegard_e[m]>
I went with 3.3V on orbtrace to save needing an 1.8V regulator, which I regret, since 1.8V had much better availability last I checked
<esden[m]>
This is our current RAM-Pak schematic. There are definitely some N/C balls on the chips right now.
<esden[m]>
There seems to be the biggest sellection of Hyperram parts that run at 1v8
<vegard_e[m]>
yeah
<esden[m]>
I honestly don't remember at the moment 😦
<whitequark[cis]>
no, it cannot officially
<vegard_e[m]>
IIRC there were also a pin difference where some chips added another power ball
<esden[m]>
I bet they did it to make the lottery go in their favor. 😛 /jk
<vegard_e[m]>
🙂
<esden[m]>
whitequark (@_discord_182174208896401419:catircservices.org) you can read out from the chips how big they are. Right?
<whitequark[cis]>
esden: uhhhhhh
<whitequark[cis]>
it's not standardized
<esden[m]>
*sigh* >_<
<whitequark[cis]>
I think what we should do is to add an "addon ID" into the main NVM and then read it out from the chip and compare with expected
<whitequark[cis]>
because in my imagination, the bitstream would statically take chip size into account
<esden[m]>
So the user would have to configure their glasgow with the addon they installed?
<whitequark[cis]>
correct
<whitequark[cis]>
we can do that automatically though
<whitequark[cis]>
since the chips have a (probably) reasonably unique ID in them
<esden[m]>
mhh... ok. Because I have the feeling that we will be seeing different sizes of RAM-Paks ... it is just too tempting not to do
<esden[m]>
I will order some of the 256 parts while I am at it.
<esden[m]>
s/256/256MBIT/
<whitequark[cis]>
I'm imagining glasgow run selftest addon-ram-pak detecting the chip size, comparing it to one from a known addons table, and flashing it
<esden[m]>
Ahh ok. Yeah, that would make it relatively streight forward.
jamie3456[m] has quit [Quit: Idle timeout reached: 172800s]
<vegard_e[m]>
are you out of pins on the expansion connector? otherwise you could put a little metadata eeprom on each ram-pak to make up for whatever the chips lack themselves in metadata
<whitequark[cis]>
that would be exactly as annoying though
<whitequark[cis]>
since it still requires loading a bitstream (slow, disruptive)
<whitequark[cis]>
there's no real problem in figuring out the chip size by reading out their ID0/ID1 registers on the host; it's only a problem if the bitstream has to do it
rcombs[m] has quit [Quit: Idle timeout reached: 172800s]
ewenmcneill[m] has joined #glasgow
<ewenmcneill[m]>
From memory last time the wiring harness was discussed, the "sockets" on the end of the wiring harness were basically shell-less "Du Pont", and using pin-to-pin "Du Pont" wires would probably work as adapters if you just wanted a one off solution.
<ewenmcneill[m]>
Plus I think the 20-pin headers are just standard 0.1" 10x2 headers, which might give you some more options if you want to make your own.
redstarcomrade has quit [Read error: Connection reset by peer]
notgull has joined #glasgow
notgull has quit [Ping timeout: 264 seconds]
notgull has joined #glasgow
notgull has quit [Ping timeout: 268 seconds]
Foxyloxy has joined #glasgow
icb[m] has joined #glasgow
<icb[m]>
Aren't there 512Mbit HyperRAM chips? Feels like using the largest part available (for a reasonable price) would make the most sense for a general purpose expansion board
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<esden[m]>
icb (@_discord_313441571230056459:catircservices.org) "reasonable price" is the thing here...
<esden[m]>
infineon tends to be quite unreliable source unfortunately...
<esden[m]>
and 8 bucks is a lot
bburky[m] has joined #glasgow
<bburky[m]>
I was trying the analyzer applet on some I2C data, but I'm getting "FIFO overrun". I see from some previous chat history here that's expected... ok I won't try to hard make it work then.
<bburky[m]>
However, it prompted me to try `glasgow run benchmark source` (thanks for mentioning the `benchmark` applet!). I'm seeing `benchmark source` failing (most of the time) on Windows 11, but works fine on Linux. Is this expected?
<bburky[m]>
(Also, I get ~260µs `benchmark latency` on Windows vs ~150us on Linux, but I don't expect that to be a huge issue. Interesting to note though.)
<esden[m]>
Yeah I found that one. I will do some math and we will see. I also have to check if it does not need some extra CS line or something dumb like that.
<icb[m]>
I completely understand wanting to minimize the number of SKUs offered. Less of an inventory headache, and easier on the software support side too. But if it's a few dollars in BOM cost, seems like the larger size would be worth at least considering
<esden[m]>
Yeh I have to see how the breakdown looks. I agree that making the biggest option the default will make things less complicated
<icb[m]>
Looks like the pinout matches. It's not one of the dual CS# parts
<esden[m]>
Ok good!
<icb[m]>
Internally, it's two separate 256Mbit dies, but they listen to different parts of the address space, so operate with one chip select
Foxyloxy has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<esden[m]>
Ahh ok, some older versions did have an extra CS line for the second die.
mobius has joined #glasgow
<icb[m]>
Yeah, the HyperRAM/HyperFlash dual die packages do that still
Foxyloxy has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
<whitequark[cis]>
<bburky[m]> "I was trying the analyzer applet..." <- > <@_discord_279486267333410817:catircservices.org> I was trying the analyzer applet on some I2C data, but I'm getting "FIFO overrun". I see from some previous chat history here that's expected... ok I won't try to hard make it work then.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/tfffIKWBJMKcJgrmiDtMcGuf>)
<sorear>
does glasgow make a precise distinction between an addon and a DUT?
<mobius>
Got my Glasgow this last week. *yay*
<whitequark[cis]>
<sorear> "does glasgow make a precise..." <- addons don't really exist yet, DUTs do
ar-jan has quit [Ping timeout: 260 seconds]
<bburky[m]>
I: glasgow.cli: running handler for applet 'benchmark'
<bburky[m]>
I: glasgow.applet.internal.benchmark: running benchmark mode source for 8.000 MiB
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #glasgow
<whitequark[cis]>
that's fascinating
<whitequark[cis]>
it means data did not actually arrive correctly
<bburky[m]>
...Wow. Yeah. I modified it to write to disk actual and golden, and it does appear to be entirely wrong data that make no sense. I will say I tried some applets today like i2c-initiator and memory-24x and they work fine... I have no idea how or why this test is completely failing.
<whitequark[cis]>
probably a libusb bug
<whitequark[cis]>
try taking the first 512 bytes from golden and searching for it in actual
<whitequark[cis]>
you'll probably find it somewhere within the first 16 512-byte blocks
redstarcomrade has joined #glasgow
<bburky[m]>
Yeah, it's offset by 0x0400 it seems? I searched for the first 0x00-0xff bytes of actual and they first appear at 0x0400 (the test pattern is repeats, so it occurs later too)