davidthings has quit [Read error: Connection reset by peer]
davidthings has joined ##openfpga
azonenberg_work has quit [Ping timeout: 246 seconds]
<tpw_rules>
is there brief documentation available anywhere for nmigne
<whitequark>
tpw_rules: unfortunately not yet, that's one of the goals for 0.2
<whitequark>
you can follow the docstrings, but that's not everything
<tpw_rules>
i found some tutorial on the lambda concept wiki
<tpw_rules>
which looks reasonable enough. i'm also trying to look up how to integrate existing verilog code
<tpw_rules>
like so i can instantiate a verilog module in my nmigen
<whitequark>
aha
<whitequark>
do you use nmigen.build?
<tpw_rules>
no i don't use anything yet. just thinking out loud
<whitequark>
you can do m.submodules += Instance("verilog_module", p_PARA=1, i_clk=ClockSignal(), i_en=1, o_dat=some_signal)
<tpw_rules>
but i probably will. that's what the boneless example uses, right
<whitequark>
yeah
<tpw_rules>
ok cool. i've decided this weekend i'm gonna get my icebreaker led panel working
<whitequark>
so if you do use nmigen.build, you also need to do something like `platform.add_file("verilog_module.v", open("/path/to/verilog_module.v"))`
<whitequark>
and then it'll be put in the appropriate place in the build tree and hooked up to the toolchain
<tpw_rules>
ok cool
<tpw_rules>
hm i installed the toolchain for the icebreaker at some point but i don't remember how
<tpw_rules>
one more thing to work out i spose. by the way if you have a few cycles i still have some questions about the boneless manual
<whitequark>
oh yeah, let's do it now
<tpw_rules>
ok so the first thing is i still think the flag names and jump mnemonics are bad on account of they're not like 6502 but if that's not up for debate then fair
<whitequark>
can you remind me your proposed changes?
<tpw_rules>
basically just change the flags to ZNCV and switch all the conditional Js to Bs
<tpw_rules>
i didn't make a real proposal yet
<whitequark>
i don't see why not
<whitequark>
J/B is a common distinction, mips does that too
<whitequark>
ok i guess mips is not to be emulated
<whitequark>
but this one makes sense on its own
<tpw_rules>
ok i'll make an actual list of changes around that then
<whitequark>
as for V, didn't that conflict with some other instruction?
<whitequark>
oh, you want to disambiguate that with B/J?
<tpw_rules>
V is already V
<tpw_rules>
i want to change S to N
<whitequark>
oh
<whitequark>
iirc that resulted in some awkward mnemonics
<tpw_rules>
that's already kind of ambiguous because of like JS and then all the jump if signed (x)
<tpw_rules>
i'll see if it feels right in the proposal
<whitequark>
so we currently have a JN
<whitequark>
(Jump Never)
<whitequark>
if you rename conditionals to start with B that stops conflicting
* jn__
jumps never
<whitequark>
:D
<tpw_rules>
also 6502 calls them BMI and BPL for branch minus and plus
<whitequark>
but 0 doesn't have sign
<whitequark>
in principle, BN and BNN would fit, but BNN seems weird
<tpw_rules>
idk my sincerely held religious belief is that 0 is positive and even
<tpw_rules>
but that's just me being silly
<tpw_rules>
the next real question is what happens if you do e.g. JRAL R0, R0. the manual and the spreadsheet disagree on if the registers are read or written first, or should it just be UNDEFINED?
<whitequark>
read first, that's a fairly fundamental property of the microarchitecture
<tpw_rules>
ok, then maybe the spreadsheet should be changed
<whitequark>
sure
<whitequark>
just fixed it
<_whitenotifier>
[whitequark/Boneless-CPU] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/Jeglp
<tpw_rules>
next deal, i think we might have discussed this before but i never wrote it down and so forgot. i would expect to have the shift operations stick the bit that falls off in carry, and maybe a rotation instruction that rotates through carry. leaving C UNDEFINED seems like a waste to me but maybe that extra logic is difficult
<tpw_rules>
or well since it's variable, maybe the last such bit for the shift
<whitequark>
I left it undefined to keep options open
<whitequark>
I'm not sure what's the utility of varshift through carry
<tpw_rules>
yeah that's true, i didn't realize that when writing down my questions
<tpw_rules>
the last one is the utility of dedicated flag set/clear instructions. they wouldn't be so useful with the previous decisions. but now i wonder if there should be an exchange flags instruction which would be necessary for interrupt routines, if someone hacked them on
<whitequark>
yes, there should be
<whitequark>
iirc we never arrived at a nice design
<tpw_rules>
microarchitecturally?
<whitequark>
no, from the ISA POV
<tpw_rules>
oh ok
<tpw_rules>
i mean i envision something really straightforward that just swaps the bottom four bits of a register with the four flags. i don't know if that has any wider implications
<whitequark>
iirc there were complications
<tpw_rules>
alright, well that can be poked at again later
<tpw_rules>
thanks for your time answering
<whitequark>
thank you for working on this!
<tpw_rules>
you're very welcome
davidthings has quit [Read error: Connection reset by peer]
davidthings has joined ##openfpga
Guest58288 has joined ##openfpga
davidthings has quit [Read error: Connection reset by peer]
Guest58288 has quit [Remote host closed the connection]
Guest58288 has joined ##openfpga
Guest58288 has quit [Read error: Connection reset by peer]
<_whitenotifier>
[whitequark/Boneless-CPU] whitequark pushed 1 commit to master [+0/-0/±4] https://git.io/Jeg4k
<_whitenotifier>
[whitequark/Boneless-CPU] whitequark 9ab562b - Update for native Enum support in nMigen.
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 268 seconds]
X-Scale` is now known as X-Scale
azonenberg_work has joined ##openfpga
emeb has left ##openfpga [##openfpga]
<OmniMancer>
Is there any way to tell what values are valid for a verilog module's parameters?
<tnt>
Read the documentation for that module :)
emeb_mac has quit [Quit: Leaving.]
<OmniMancer>
Ah, that might be a bit hard to find, I think it's the verilog blackbox for vendor primitives
Jybz has joined ##openfpga
Asu has joined ##openfpga
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
freeemint has joined ##openfpga
_whitelogger has joined ##openfpga
<OmniMancer>
I think I have worked out some tile sizes reasonably well now
freeemint has quit [Quit: Leaving]
freemint has joined ##openfpga
<OmniMancer>
I have LUT init bits now
jn__ has quit [Ping timeout: 240 seconds]
jn__ has joined ##openfpga
<OmniMancer>
found some strangeness already
<OmniMancer>
the datasheet suggests that the clock for the flipflops can be selected from clock input, inverted clock input, constant 0 or constant 1, but you can only pick inverted or regular
fibmod has quit [Ping timeout: 240 seconds]
<OmniMancer>
Also one of the latch/flipflop selector bits is in a strange place relative to other config for that slice
fibmod has joined ##openfpga
<OmniMancer>
daveshah: what do the numbers in the trellis fuzzer directory names signify? the order they are to be run in?
<daveshah>
Yeah
<daveshah>
Similar to init scripts etc
<OmniMancer>
is there an automated thing that runs them all?
<OmniMancer>
I resolved the issue I was having with the tile locations and sizes, I had the size wrong since the routing only tiles on the edges are thinner and my code to create a Chip from a bitstream was getting the bits in each byte in the wrong order
<daveshah>
No, I never automated it but it was designed so that would be possible
<OmniMancer>
ah okay
<OmniMancer>
So I have done lut init for the two kinds of slice
<OmniMancer>
and a bunch of misc reg config stuff
<OmniMancer>
now doing modes
<OmniMancer>
I am curious what the RAMW mode could be for lslices
Jybz has quit [Ping timeout: 265 seconds]
<OmniMancer>
daveshah: is there a good way to figure out a list of what modes slices support?
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
<pepijndevos>
OmniMancer, which FPGA are you fuzzing?
Jybz has joined ##openfpga
<pepijndevos>
Anyone have any code laying around for talking to the QSPI PSRAM on the Tang Nano?
<pepijndevos>
ZipCPU, would this be something your qspiflash code could deal with, or is it completely different?
mkru has joined ##openfpga
<OmniMancer>
pepijndevos: Anlogic eagle
<pepijndevos>
Ah cool.
<pepijndevos>
Eh... so this Tang Nano can't contain a framebuffer or anything. Interesting choice of hardware.
<pepijndevos>
The pixel clock runs at 33MHz, so I'm not even sure you could read anything from QSPI PSRAM fast enough.
<OmniMancer>
pepijndevos: its one of the smaller gowin parts yes?
<pepijndevos>
Aye, GW1N-1, 1152 LUT4
<OmniMancer>
I just recently got some of the Anlogic Tang boards
<pepijndevos>
Okay, so it has 4 BRAM I could configure as 13 addr bits and 8 data bits.
<pepijndevos>
So I could do 8x8 1bpp tiles in 2^12 bits and then use the other 2^12 bits for a 50x30 tilemap at 2x scale
<tnt>
pepijndevos: I have qspi code but it's for the ECP5, you'd need to adapt the phy layer.
<pepijndevos>
hmmm, for now I think I'll just cram stuff in BRAM.
<pepijndevos>
For QSPI I figure you'd need to do continuous reads at twice the pixel clock for it to work.
<pepijndevos>
And that is if you cram your data in a single byte. If you do 16 bit colour, you'd need to read at 4 times the pixel clock
<tnt>
You can't read continuously from PSRAM you can do bursts but it has a maximum CE low time of 8 uS so you can't read for longer than that without pause.
pie_ has quit [Ping timeout: 268 seconds]
<pepijndevos>
I suppose you have hblank to finish the read and start the next one
<ZipCPU>
pepijndevos: It looks similar enough that my qflexpress core might work, but it would only treat the device as a ROM--providing horrible RAM performance
<pepijndevos>
Meaning it'll do writes pages at a time?
<pepijndevos>
If I run out of bram I'll definitely try qflexpress
<pepijndevos>
IIRC you put a lot of effort into optimizing read performance
mkru has quit [Quit: Leaving]
<tnt>
I want to try and display a static 1080p image from PSRAM, I should have just enough bw for a 8 bit image on the had badge.
emily has quit [Remote host closed the connection]
emily has joined ##openfpga
<tpw_rules>
whitequark: what if we spell JN as NOP or NOPJ? i don't really see any good NOPs, maybe ADJW 0? J 0 would also work. i think everything else would touch the flags
freemint has quit [Ping timeout: 245 seconds]
zng has quit [Ping timeout: 245 seconds]
zng has joined ##openfpga
emeb_mac has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
<ZipCPU>
pepijndevos: The qflexpress core is designed to optimize reads. It doesn't understand write commands. Further, reads are so optimized as to no longer need any command--the controller sets the flash up so that it can just issue an address and get the data
<ZipCPU>
If you had a read/write QSPI core, you'd need to issue both read and write commands, and chances are the command would need to be given before either read or write
<ZipCPU>
(You could optimize it several ways ...)
<ZipCPU>
As currently written, writing to the QSPI device is a software intensive process--not something handled by the hardware itself
<ZipCPU>
Software needs to place the core into a special mode. Software then needs to issue the write command, the address bytes, and then the data bytes. A read/write controller would instead do this directly from the FPGA hardware
<ZirconiumX>
So, I'm reading through the ECP5 docs from Lattice, and they mention CCU2 "mode", however synth_ecp5 uses CCU2C primitives. So, is CCU2 a physical part of a PFU that gets routed, then?
<daveshah>
Yes, slices are set to CCU2 mode into which is packed a CCU2C (carry and 2 LUT4s) and up to two registers
freemint has quit [Ping timeout: 250 seconds]
<ZirconiumX>
So CCU2C is a representation of a slice configured for CCU2 mode?
Zorix has joined ##openfpga
<ZirconiumX>
You know, it's pretty annoying to check if your Quartus flow works correctly when Quartus itself ICEs in a way that is unique to you
<ZirconiumX>
Googling the error turns up a pastebin I made back in July of a stack trace *with the exact same bug*
<OmniMancer>
heh
<OmniMancer>
I have had some issues fuzzing some enum settings, perhaps there are some other requirements for them to generate any different bits
<daveshah>
ZirconiumX: yes, CCU2C is the combinational part of it, excluding the regs
<pepijndevos>
ZipCPU, hmmm thanks, I'll think about it. Another thing related to your blog: clock dividers. On your blog you mention that making a clock in logic is a horrible idea for timing, and I can see why, but I wonder what is the correct way to run a piece of logic in khz speeds, below the output of your PLL
<ZirconiumX>
Quartus has some *not great* primitive design, so I was looking at the other families for inspiration of how to do things "better"
<daveshah>
pepijndevos: most likely, using a clock enable
<pepijndevos>
hmmmm
<ZipCPU>
^ +1
<ZirconiumX>
For example I so far have three different (saner?) primitives for LUTs.
<ZirconiumX>
These then go through a rename pass to the final result
<ZirconiumX>
This being said I still have no clue if the approach works for the aforementioned reasons
<OmniMancer>
ZirconiumX: most inconvenient
<ZirconiumX>
Inconvenient doesn't begin to describe it
<OmniMancer>
I need to figure out how to start fuzzing routing
<ZirconiumX>
At its core, it's not too difficult. But it depends majorly on the information available to you
<OmniMancer>
as far as I can tell not especially much
<ZirconiumX>
As far as I can tell, the best approach we can get is essentially to pick random LUT tiles and connect them
<OmniMancer>
I get a bunch of names that might be pips out of the pnl files
<ZirconiumX>
And repeat until you can isolate a bit
<OmniMancer>
still have some logic config to figure out as well
<whitequark>
tpw_rules: great idea re NOP
<tpw_rules>
whitequark: alright that sounds good. does JN have a different cycle count to ADJW 0? I think JN would be less
<whitequark>
yeah
<tpw_rules>
maybe we can have like NOP3 or NOP4 or whatever the cycles are then
<whitequark>
i don't want to guarantee cycle count
<whitequark>
for one, a pipelined impl is reasonable
<tpw_rules>
alright. then i'll just spell JN as NOP
<whitequark>
yep
<tpw_rules>
also good news i'm trying to use nmigen and reading other people's code annoys me so i'm about to have a lot of questions
<tpw_rules>
so how would i make a struct of signals? so that i can like give it to a submodule without having to have 37 .eq statements
<tpw_rules>
what value is a Signal if it's set comb in an FSM but it's not that state?
<tpw_rules>
does it work like verilog where i would set it to the default value ahead of the FSM?
<ZipCPU>
In any process (always) block, signals not given values retain their last value
<tpw_rules>
sure in verilog
<tpw_rules>
i'm wondering about nmigen
<ZipCPU>
This can be a problem in combinatorial blocks, since keeping values like that requires a latch, and latches aren't necessarily fully supported in FPGAs
<ZipCPU>
Ahh, okay, I can't speak to nmigen. Sorry.
<tpw_rules>
also also in nmigen how can i output a clock to a pin? with enable too
<azonenberg>
tpw_rules: the general hardware solution for this (not sure if nmigen has any syntactic sugar to hide this)
<azonenberg>
is to drive a DDR output buffer with the clock
<azonenberg>
hard wire one input of the DDR buffer to 0
<azonenberg>
then tie the other to clock enable or constant 1 as appropriate
<whitequark>
tpw_rules: comb signal that is not driven is at its reset value
<whitequark>
tpw_rules: to output a clock, you request a DDR buffer, indeed. pin = platform.request("<pin name>", xdr=2); m.d.comb += pin.o_clk.eq(ClockSignal()), pin.o0.eq(0), pin.o1.eq(1)
<tpw_rules>
xdr=2 Just Works?
<tpw_rules>
:O my basic panel driver works first try! (once compile errors were resolved)
<whitequark>
nice
<pepijndevos>
I'm trying to port a piece of C code to VHDL, and it's so tempting to use variables everywhere rather than translate to a state machine.
<tpw_rules>
i have the opposite problem lol pepijndevos
<pepijndevos>
??
<tpw_rules>
when i'm programming c it's so tempting to just make everything a state machine
<pepijndevos>
Is that a bad thing? ;)
<tpw_rules>
fortunately not
<pepijndevos>
I wonder how much of a slow monstrosity I'd get if I'd just directly port C to VHDL with variables everywhere.
<tpw_rules>
which edge of the clock input corresponds to which DDR buffer output?
<whitequark>
o0 is the posedge output, o1 is the negedge output
<whitequark>
hm
<whitequark>
right, so what I recommended above would mean the clock is inverted
<tpw_rules>
well it's what i want i think
<tpw_rules>
hm, compilation is so fast there's no need to figure out how to do simulation :OP
<whitequark>
that's a bit dangerous
<whitequark>
nmigen doesn't let you write most kinds of unsound code, but debugging without simulating is still a good way to waste time
Jybz has quit [Quit: Konversation terminated!]
<tpw_rules>
is there a way to simulate a platform?
<tpw_rules>
or at least transplant the resources from a platform into simulation