<swetland>
whitequark: you might want to consider flipping your immediates and args for R* instructions
<whitequark>
swetland: why?
<swetland>
risc-v aligns the top bit of all immediates to simplify sign extension machinery, which seems smart to me
<whitequark>
hm
<swetland>
instead of sign-extending bit 2 for imm3, 4 for imm5, 7 for imm8, bit 7 becomes the high/sign bit for all your small constants
<whitequark>
hmmmmmm
<whitequark>
but then i have to shift the rest of them?
<whitequark>
also ALSO this doesn't work all that well with EXTI i think
<whitequark>
hm or maybe it does
<whitequark>
still
<whitequark>
this involves a wide mux that shifts the rest of the immediate back to low bits
<sorear>
having register specifiers and sign bits in a standard place is nice for pipelines because you take that completely out of the decode critical path
<sorear>
the immediate isn't needed until after Ra is read so the immediate can be a little bit garbled
<swetland>
yeah I haven't worked out all the edges, just thought I'd toss that out there while you were tinkering with the layout since it struck me as possibly a simple optimization that might be worth adopting
<whitequark>
swetland: sorear: this could be *very* easily tweaked as late in the design as desirable
<whitequark>
but also, i really don't get it
<whitequark>
i'll try measuring the decoder size i guess
<sorear>
i don't think it's likely to be limiting in boneless
<sorear>
i'm not advocating it
<sorear>
maybe worth a try if you're bored at some point
<swetland>
yeah it's probably of more value the wider your immediates get
<whitequark>
kk
<sorear>
remember their use-case is a 12->64 sign extended running at >1GHz
<sorear>
s/extended/extender/
jcreus has joined ##openfpga
<whitequark>
right
<mwk>
haha wtf
<sorear>
?
<mwk>
either the spartan 3 is much crazier than I expected, or I just found a bug in the xilinx router database
<mwk>
it seems they included Virtex 2's BRKH tile unchanged, without fixing up the wires for the new routing
<mwk>
and the wires that are new on 3s wrt 2v can't actually pass this tile
<mwk>
also the wires are named like 2v instead of 3s
<swetland>
whitequark: oh that's interesting -- I like that use imm3 as a "table of useful immediates"
_whitelogger has joined ##openfpga
<azonenberg>
mwk: lool
<azonenberg>
sorear: yeah i really liked that side of riscv
<azonenberg>
in terms of moving as much as they could out of the decode path
<swetland>
the ISA is rather bland, but it's very sensible. feels like they made reasonable choices.
<sorear>
a while ago I saw an academic FPGA design (John Hauser's GARP) where the smallest routable unit was 2 bits, not 1. Wondering now how much nextpnr would hate that :)
<daveshah>
I guess you can just pretend that 2 bits are actually a single bit
<swetland>
similarly, I like how the 16bit compressed format is something that has a straightforward 1:1 expansion to wider instructions
<swetland>
oh hey, I'm trying to poke around with the constraints stuff based on a slide clifford had at his talk -- where he uses an attribute on cells to assign them to a constraint region
<swetland>
and I can't seem to get attributes from verilog to "stick" to cells
<swetland>
they attach to wires/nets happily enough. Do I need to tag actual SB_* entities with attributes for this to work?
<whitequark>
or use the attrmvcp command
<whitequark>
see the synth_greenpak script for how to do it
<daveshah>
Not throwing away attributes on wires is an outstanding todo for nextpnr also
<swetland>
his ringosc exampled looked like just the sort of thing you'd want to constrain your synchronizer DFFs to be adjacent, etc
<daveshah>
That example is inside that PR
<swetland>
oh! I foolishly assumed he was talking about features in mainline ^^
<swetland>
I did update to tip-of-tree, just didn't guess it would be something not yet in tree
<daveshah>
Yeah, I probably forgot to mention that to him when sending him that example
<swetland>
was thinking a bit about clocks and names and wondering if clocks maybe should be distinct named entities which then are attached to nets/wires
* swetland
needs to poke around an the source a bit and better understand how the pieces fit
<jcreus>
actually, about that, what does the analytic placer need to know about clocks? is this already handled by constraints?
<sorear>
do we have an analytic placer now?
<jcreus>
I'm starting to work on it
ayjay_t has quit [Read error: Connection reset by peer]
<jcreus>
no promises, because I'm kinda diverging a bit from established literature
ayjay_t has joined ##openfpga
<jcreus>
I'm hoping it'll give decent results because the objective is explicit half perimeter, instead of the various analytic approximations
<jcreus>
(with a way to do timing, I think)
rohitksingh has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
<daveshah>
The analytical placer could use budgets, or criticalities, for vague timing support
<daveshah>
IMO most of the real use of fine timing optimisation would be in the SA legalisation/tidy pass after analytical placement
<azonenberg>
jcreus: well at some point
<azonenberg>
we need to detect high fanout nets and promote them to global clock nets using BUFG or equivalent
<azonenberg>
this includes clock, reset, etc
<azonenberg>
and there can be some hinting and.or explicit primitive instantiatino
<daveshah>
That's done in the packer, for the most part
<daveshah>
Don't think it's implemented for xc7 though, I think Eddie was instantiating the buffer manually
<_whitenotifier-6>
[whitequark/Boneless-CPU] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhLAX
<_whitenotifier-6>
[whitequark/Boneless-CPU] whitequark 88ccf98 - Flesh out v3 pipeline, make PC adder explicit.
_whitelogger has joined ##openfpga
<azonenberg>
yeah what i meant is, in terms of "knowing about clocks"
<azonenberg>
anything coming out of a bufg post packing/techmapping is a clock
<azonenberg>
from there on, it's constraint based
_whitelogger has joined ##openfpga
<_whitenotifier-6>
[whitequark/Boneless-CPU] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhLxw
GuzTech has quit [Remote host closed the connection]
GuzTech has joined ##openfpga
sgstair has quit [Read error: Connection reset by peer]
sgstair has joined ##openfpga
soylentyellow__ has quit [Remote host closed the connection]
soylentyellow__ has joined ##openfpga
maciejjo has quit [Remote host closed the connection]
lexano has quit [Ping timeout: 246 seconds]
lexano has joined ##openfpga
davidc__ has quit [Ping timeout: 246 seconds]
davidc__ has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
mumptai_ has quit [Quit: Verlassend]
mumptai has joined ##openfpga
_whitelogger has joined ##openfpga
rohitksingh has joined ##openfpga
Miyu has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
dj_pi has joined ##openfpga
rohitksingh has quit [Ping timeout: 244 seconds]
rohitksingh has joined ##openfpga
<jcreus>
just to make sure I'm not misunderstanding, constraint parents in nextpnr make the cell want to be some relative offset (given by constr_{x,y,z}) away from the parent, right?
<jcreus>
however constr_{x,y,z} seems to be zero all the time (e.g. on all the generated $carry LC cells), which is unfeasible, so the constraint ends up being "as close to the parent as possible"?
<daveshah>
No, infeasible constraints are an error
<daveshah>
I don't know what is happening here, tbh
<jcreus>
daveshah: hm, I was printing cells just to get familiar with them