<tpw_rules>
alright, i've got boneless hooked up to the panel
<tpw_rules>
at least a framebuffer on the panel
<whitequark>
:D
<tpw_rules>
now i can blink one led on it. or more once i actually instantiate the pieces
<tpw_rules>
the python function based assembler is Rd, Ra, Rb right
<tpw_rules>
oh wait i figured it out
<tpw_rules>
turns out it doesn't whine if you stick a constant where a register should be...
<tpw_rules>
i wonder why? variable Rn isn't just an integer. but e.g. SRL(R6, R7, 1) silently does the wrong thing. i'm not sure what it even does do
<tpw_rules>
hmm, i think the limit on this is gonna be block ram. is there any easy infrastructure to program the icebreaker flash with code and then copy it to the internal SRAM?
<whitequark>
tpw_rules: Rn inherits from int, for better or worse
<whitequark>
in the original design it was just an int
freemint has joined ##openfpga
<tpw_rules>
also i guess i just want something to put whatever binary data into flash when programming
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 240 seconds]
<zignig>
tpw_rules: I have a bunch of boneless work in https://github.com/zignig/gizmotron , I'm currently attempting to convert it over to the CSR system.
<tpw_rules>
CSR?
<whitequark>
control/status registers
<tpw_rules>
oh ok you haven't got flash working yet
<rvense>
tpw_rules: wouldn't want to be hit with that
<rvense>
tpw_rules: it looks fantastic!
<tpw_rules>
thank you! i'm cleaning up the source some but i'll release it in like half an hour
<tpw_rules>
also i hope you understand the purse is a $9 barbie toy, not my own invention :P
<rvense>
oh, i thought you'd added the leds
<tpw_rules>
no, actually
<tpw_rules>
i did stick in an icebreaker fpga to control them
<tpw_rules>
but for some confluence of reasons i don't quite understand, it was possible to buy a $9 barbie toy which had a 32x16 hub75 led panel built in, plus control circuitry which i've ditcvhed
<rvense>
yeah, was about to say, can you really get that many leds in a purse for 9 dollars?
<rvense>
what a world we live in
<tpw_rules>
well MSRP was like $59
<rvense>
ah, that makes more sens
<tpw_rules>
but they ended up on amazon on ultra clearance and one of my youtubers made a video on them. it was like $7 when he released it and i watched the price go up in real time :P
<tpw_rules>
sadly not. there's just space for your phone which programs the controller. it's entirely hard plastic
<rvense>
ah, ok
<tpw_rules>
but for the price there's no reason not to buy it. it's also a relatively nice low power panel. it runs great at 3.3v and doesn't melt eyes
<rvense>
hm, no reason not to buy
* rvense
looks at pile of unused junk
<tpw_rules>
according to amazon, it's been in my junk pile since janruary 12, 2019
<rvense>
i kind of want an led panel on my backback now though
<tpw_rules>
or i guess 14, allowing time for shipping
<rvense>
it looks like a fun project
<tpw_rules>
it's probably pretty powerful with just the stock controller. apparently you can make arbitrary designs and animations on your phone and program them in
<OmniMancer>
I have made a rudimentary pnl parser, which will be useful for harvesting route pip names for fuzzing I guess
<tpw_rules>
whitequark: i'm probably not using it to your vision but the boneless python-mode assembler vexes me
<zignig>
tpw_rules: nice work, I will have to read your code and digest.
<zignig>
I've just been working on the my conversion of the boneless interface to CSR system, currently broken and over complicated.
<zignig>
that said the complication will simplify adding peripherals ( perhaps even yours ) to a boneless.
freemint has quit [Ping timeout: 264 seconds]
<tpw_rules>
i mean it was as simple as can be
<zignig>
for various values of "simple" .... ;P
<whitequark>
tpw_rules: you are using it appropriately AFAICT
<whitequark>
i intend to add a register allocator so that you don't have to bother with "temp"
<whitequark>
but other than that seems fine
<zignig>
cool you got it working , putting data into the spram on the UP5k would give you a lot more font space and wiggle room.
<tpw_rules>
alright. i got bit again by R0 is equivalent to 0. i also got bit by apparently all label references are relative. i was hoping to be able to do like ADDI(temp1, curr_msg_ptr, "message") but i have to MOVR into a register
<tpw_rules>
also is there any way to store data in the assembly other than "EXTI and don't use the top 3 bits"?
<tpw_rules>
anyway i think my next interest is figure out a PLL so i can run the LED faster than the cpu. the clock domain is already divided by the dual port framebuffer memory
<whitequark>
tpw_rules: re R0: ack. i'll consider that next time i touch the assembler
<whitequark>
re label references: yes. there's no expressions with labels yet. that's a bit annoying to add, but would be useful
<whitequark>
re store data in assembly: sure. instead of INSN(...) just write like 0x6969
<tpw_rules>
oh, lol
<zignig>
whitequark: and having an way to get the absoulte address of labels for use in jump tables.
<whitequark>
yes, I'll add a jump table directive
davidthings has quit [Remote host closed the connection]
davidthings has joined ##openfpga
davidthings has quit [Read error: Connection reset by peer]
<zignig>
tpw_rules: anyway sleepy time for me now, excellent work on your barbie-handbag-blinky-thing ;)
<tpw_rules>
thank you!
<tpw_rules>
oh that's rude that the PLL eats the clock signal. i was hoping to have the cpu and led domains running at non integer multiples
OmniMancer has quit [Quit: Leaving.]
Laksen has joined ##openfpga
<whitequark>
eats?
<whitequark>
oh, you can run it through fabric then
<whitequark>
use the _CORE variant instead of _PAD
<tpw_rules>
it doesn't look like that helps. "If an instance of ice40_PLL_CORE or ice40_PLL_2F_CORE is placed, an instance of SB_IO in “output-only” mode can be placed in the associated IO cell location."
<tpw_rules>
it has some kind of B port but the doc isn't really clear on what it does
<whitequark>
ohh right, i see what you mean
<whitequark>
UP5K only has one PLL
<tpw_rules>
yes
freemint has joined ##openfpga
<whitequark>
SB_PLL40_2_PAD gives you the source clock on PLLOUTGLOBALA, and generated on PLLOUTGLOBALB
<tpw_rules>
that's what i'd like. where is it documented? it's not in the lattice tech notes i'm finding
<whitequark>
"Lattice iCE Technology Library"
pie_ has quit [Remote host closed the connection]
<tpw_rules>
i found one that says siliconblue
<whitequark>
yes
<whitequark>
SB_ is for SiliconBlue
<whitequark>
which Lattice bought
pie_ has joined ##openfpga
<tpw_rules>
alright, found that. thank you
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
fsasm_ has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
emeb_mac has joined ##openfpga
Laksen has quit [Quit: Leaving]
<pepijndevos>
Is the Icebreaker clock really 12MHz or more like 11.whatever? My uart only works at 6400 and my RF stuff not at all.
<whitequark>
pepijndevos: should be pretty precisely 12 MHz
<whitequark>
but it's not a crystal
<pepijndevos>
Weird...
<whitequark>
oh, no, I'm wrong, it's a crystal
<whitequark>
12 MHz XTAL oscillator (shared with FPGA)
<pepijndevos>
with clk_freq => 12_000_000, baud_rate => 9600 but somehow on my laptop I have to do picocom -b 9400 for it to work. It works all the way down to 9000 so I would guess the oscillator is *pretty* far off or this IP is broken AF or my laptop is broken AF
<pepijndevos>
daveshah, yea I used that but since my code was in VHDl I figured using the one I linked would be easier... I guess I was wrong.
freemint has joined ##openfpga
sgstair_ has joined ##openfpga
sgstair has quit [Ping timeout: 265 seconds]
sgstair_ is now known as sgstair
<tpw_rules>
zignig: did you manage to get the PLL working?
<tpw_rules>
because there were some errors in the linked code and i fixed them but it doesn't work. about to sit down and debug it
<tpw_rules>
because there were some errors in the linked code and i fixed them but it doesn't work. about to sit down and debug it
<tpw_rules>
oops up arrowed wrong again
<tpw_rules>
ok i found a working example. zignig you should probably be aware that your code doesn't work
<tpw_rules>
also the timing analyzer doesn't seem to be aware of the higher clock frequency
<tpw_rules>
whitequark: is there an issue having two ResetSynchronizers? if i do i get a "nmigen.hdl.cd.DomainError: Signal (clk reset_sync) refers to nonexistent domain 'reset_sync'" and i wonder if the reset_sync domain made in the ResetSynchronizer isn't handling local=True correctly
<tpw_rules>
hm i must have missed something with clock domains. now the logic explodes and it can't fit into the fpga, despite only using like 20% of it earlier
<tpw_rules>
oh, it's failing to use block ram
<tpw_rules>
but why? i just asked for a read port in a different domain from the write port and the lattice docs say that's how the dual port ram is designed
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<tpw_rules>
oh, it can't handle the read port being transparent in dual clock mode
<tpw_rules>
what does transparent mean anyway? it doesn't need to clock out the read data? it reads the data being written if the address is the same?
Jybz has quit [Excess Flood]
Jybz has joined ##openfpga
<whitequark>
tpw_rules: yes
<whitequark>
transparent means it adds forwarding logic
<whitequark>
which doesn't work if you have two different domains because it's impossible
<tpw_rules>
ok yeah that makes sense
<tpw_rules>
wonder if there's a way to warn about it before nextpnr explodes trying to pack one shitty block ram across every single logic cell
<whitequark>
yes
<whitequark>
that entire part of nmigen *and* yosys needs some serious redesign (the UI will be nearly same though)
<tpw_rules>
is that ResetSynchronizer behavior expected? just made a quick, if not small, test case
<whitequark>
uh, no, sounds like a bug
<tpw_rules>
ok i can file an issue if that's easier
<whitequark>
yep
<tpw_rules>
ok i can file an issue if that's easier
<tpw_rules>
arrowed again.
<ZirconiumX>
Well, I have some bugs to fix on my end, and Intel have bugs on theirs, but I have an ABC9 flow for the Cyclone V.
<tpw_rules>
also how can i tell yosys the clock frequencies? it doesn't know the frequency of my PLL derived signal
<ZirconiumX>
Yosys doesn't care
<ZirconiumX>
nextpnr is the bit that cares
<tpw_rules>
nextpnr? idk there's something in top.tim
<tpw_rules>
well how do i do it
fsasm_ has quit [Ping timeout: 250 seconds]
kmehall has quit [*.net *.split]
_whitenotifier has quit [*.net *.split]
pinoaffe has quit [*.net *.split]
jhol has quit [*.net *.split]
sensille has quit [*.net *.split]
awygle has quit [*.net *.split]
pointfree has quit [*.net *.split]
sensille has joined ##openfpga
awygle has joined ##openfpga
pointfree has joined ##openfpga
_whitenotifier has joined ##openfpga
kmehall has joined ##openfpga
pinoaffe has joined ##openfpga
jhol has joined ##openfpga
Asu has quit [Ping timeout: 240 seconds]
Asu` has joined ##openfpga
Bob_Dole has quit [Ping timeout: 250 seconds]
sgstair has quit [Read error: Connection reset by peer]