<TD-Linux>
my diy ulx3s is working, I've only tried the demo f32c bitstreams though. for whatever reason when I load a f32c program it doesn't seem to start executing (though the built in monitor rom is working)
emeb_mac has joined ##openfpga
<Flea86>
TD-Linux: Nice work
gsi_ has joined ##openfpga
gsi__ has quit [Ping timeout: 245 seconds]
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
Bob_Dole has quit [Ping timeout: 264 seconds]
Bob_Dole has joined ##openfpga
<TD-Linux>
looks like prjtrellis is going so fast that all the ulx3s demos have already bitrotted...
<q3k>
oh?
<q3k>
is this a hand assembled ulx3s?
<q3k>
iirc the internal monitor runs off block ram, so maybe your sram connectivity is having issues
<TD-Linux>
anyone know of what fork of TG68K is the most up to date?
<tnt>
TD-Linux: didn't even know TG68K before you mentionned it:. Sorry.
<tnt>
\o/ First custom picrorv32 system running on the icebreaker. 2.5kLC and 25MHz fmax. Could have been worse.
<horizon>
tnt: as you've said, each day one step closer... :)
rohitksingh has quit [Ping timeout: 240 seconds]
Asu has joined ##openfpga
wpwrak has quit [Ping timeout: 268 seconds]
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
wpwrak has joined ##openfpga
Laksen has joined ##openfpga
flaviusb has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
flaviusb has joined ##openfpga
<tnt>
mmm, my picorv32 system seems to be misbehaving :/
rohitksingh has quit [Ping timeout: 255 seconds]
<tnt>
if I call print_hex ... it loops, printing the same hex number over and over again ... wtf, no idea what would cause that.
<daveshah>
Have you tried a simulation?
<tnt>
Not for the current config no. Have to simulate the spi flash now :/ But I'm not even sure it's a hw issue. If I write the loop "for (int i=0; i<8; i++) {" That works. if i do "for (int i = 7; i >= 0; i--) {" it loops forever.
<cr1901_modern>
signed underflow is UB
<tnt>
UB ?
<cr1901_modern>
Undefined Behavior
<cr1901_modern>
so my guess is the compiler is optimizing into an infinite loop
<tnt>
huh ? I mean ... going from 0 to -1 in a signed type should totally be valid ...
<cr1901_modern>
b/c the loop condition will never terminate unless "i" underflows
<tnt>
it's not an underflow.
<cr1901_modern>
tnt: Well it's UB in C
rohitksingh has joined ##openfpga
<daveshah>
so 0-1 is undefined in C?
<tnt>
?!?!?
<cr1901_modern>
oh wait, I'm sorry...
<cr1901_modern>
tnt: Ignore me, read it wrong :P
<cr1901_modern>
0->-1 and -1->0 are the exceptions to "changing sign is an over/underflow"
<cr1901_modern>
tnt: Anyway, was the assembly code optimized to an unconditional jump back into the loop?
<tnt>
No, I think something is getting corrupted somewhere.
<tnt>
and it's just 'luck' that changing the loop direction doesn't loop forever.
<daveshah>
I've seen picorv32s do very funky stuff if the ready/valid behaviour of the memory wasn't quite right
<tnt>
Yeah, I'd suspect either that, or the logic that reads from flash and populates the SPRAM before boot is screwed up.
<tnt>
But mem test works just fine, so I was hopeful I got it right.
rohitksingh has quit [Ping timeout: 255 seconds]
<tnt>
Well, I guess it's testbench time :/
rohitksingh has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
Bike has joined ##openfpga
ayjay_t has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
lutsabound has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
<tnt>
Of course i had to pick the 1 spi read command not supported by the spi flash model in the picrorv32 repo lol.
<tnt>
Found the first bug ... startup code clears the RAM ... but i'm executing from RAM, so not a great idea.
<tnt>
Although the comment 'zero initialize entire scratchpad memory' is a bit measleading since it doesn't zero the RAM at all, it write the address to each address *N = N basically.
<tnt>
And the culprit was ... badly initialized stack pointer ... I set it to 0xffff ... instead of 0x10000
<AndresNavarro>
I just made a pull request to see if we can start working on MachXO2 from within Project Trellis
<AndresNavarro>
I want to avoid maintaining a fork if at all possible, trying to make more or less frequent pull requests and trying to be sensible in avoiding cluttering too much the code base with MachXO2 specific code
<whitequark>
isn't Trellis about ECP5?
<whitequark>
is MachXO2 similar to ECP5?
<AndresNavarro>
It's pretty similar. Same bitstream format, almost identical LUT4 arch and local routing
<AndresNavarro>
There's some differences but I hope not enough to warrant a whole new project
<AndresNavarro>
With minimal changes I was able to generate the tile maps and the config bits
<whitequark>
oh huh
<AndresNavarro>
for the luts
<whitequark>
very interesting
<whitequark>
why the different name?
<whitequark>
is that just a really small ECP5?
<whitequark>
I see it tops out at 6k
<AndresNavarro>
Well the MachXO/XO2/XO3 are much smaller devices
<AndresNavarro>
from 256 luts up to about 7k and without dsp or serdes
<whitequark>
hmmm
<AndresNavarro>
They mostly intended for glue logic, although the bigger ones are quite decent
<AndresNavarro>
I feel they are nicer than the original ice40s
<AndresNavarro>
They have more flexible LUTs (including embedded memory support and fast carry chains like the ECP5)
<AndresNavarro>
And hardened I2C and SPI
<whitequark>
hmmm
<whitequark>
i wonder if maybe there should be a Glasgow rev with MachXO2 once it's done
<whitequark>
the small amount of LUTs bothers me
<AndresNavarro>
Then you are better off with the ECP5
<whitequark>
fine
<AndresNavarro>
I think these will really shine for small things you woulnd't bother with an fpga right now
<whitequark>
probably will stay with ice40
<whitequark>
hx8k is decently large
<whitequark>
ecp5 has inconvenient packages iirc, and needs more support logic...
knielsen has quit [Ping timeout: 240 seconds]
<AndresNavarro>
I mean the tinyfpga A1/A2 are just $12 with a XO2-256 and $18 with a XO2-1200. Another nice thing is they don't need any external component (other than a few caps, and maybe a ferrite bead and a resistor)
<AndresNavarro>
In verty maneagable packages too
<AndresNavarro>
The bigger one is just 6864 LUTS though
<AndresNavarro>
In a TQFP-144 package
<emily>
whitequark: huh, the plan for ECP5 revE changed?
<AndresNavarro>
MachXO3 which I think should be similar go out to 9000 LUTS but only bga packages I think
<whitequark>
emily: no, i was thinking of MachXO2 revCD
<whitequark>
BGA is fine
<emily>
whitequark: I somewhat dislike how the revisions are both version numbers and variants/segmentation...
<whitequark>
emily: the revisions are just segmentation
<whitequark>
after revD0 is out, new revCs are still possible
<emily>
but A/B?
<whitequark>
new revBs would have been possible if that whole branch wouldn't have been a dead end
<whitequark>
if FXMA worked at all there might've been a revB1
<whitequark>
revA was before I properly decided on the scheme
<whitequark>
pretend it doesn't exist
<emily>
fair enough
<emily>
may I recommend "series" over "revision"
<emily>
or "type" or something
<whitequark>
that's already on the PCBs so eh
knielsen has joined ##openfpga
<whitequark>
every device needs stupid naming quirks
<daveshah>
AndresNavarro: thanks!
<daveshah>
whitequark: xo2 has faster IO than ice40
<whitequark>
mhm
<whitequark>
how much faster?
<whitequark>
and what about fabric?
<daveshah>
800-900Mbit/s LVDS, IIRC
<daveshah>
With 4:1, 8:1 and 7:1 gearboxes as well as plain ddr
<whitequark>
mhm, right
<whitequark>
that could be quite useful
<daveshah>
Not sure about fabric speed, suspect slightly faster than iCE40
<whitequark>
so i'll have my options open i guess...
<tnt>
Damn those RAM4K are annoying to use :/
<emily>
whitequark: serD coming after revC would be appropriately cursed naming, don't you think
<emily>
also the almost-clash with serdes
<whitequark>
ewwww
photon70 has joined ##openfpga
rohitksingh has joined ##openfpga
AndresNavarro has quit [Ping timeout: 245 seconds]