<whitequark>
daveshah: one thing I came up with recently is an idea for `splitnets`
<whitequark>
if `splitnets` would set `hdlname` *and* appropriate offset for each part, then it is possible to reconstruct the original signal when processing the final netlist
<Sarayan>
am I wrong to think that cxxrtl would be mostly reusable to generate in-memory executable code (through llvm ir or something) rather than compilable c++?
<whitequark>
Sarayan: unfortunately you are wrong
<whitequark>
well
<Sarayan>
damn
<whitequark>
this is a bit subtle
<whitequark>
if you only look at LLVM it seems like there is an obvious way to do this, just use iN for Signal(N)
<Sarayan>
except it doesn't lower?
<whitequark>
it sort of does
<whitequark>
but you really don't want to see what it lowers to
<whitequark>
if you wanted to stay purely in-memory i think the most realistic option is to link libclang or something
<daveshah>
whitequark: sounds good, ad splitnets, I could do something similar in nextpnr when it splits nets
<whitequark>
daveshah: wonderful
<Sarayan>
I'm still thinking about how to do a nice debuffer
<Sarayan>
debugger
<whitequark>
debugger as in?
<Sarayan>
as in what you have to debug software in C++, except for nmigen
<Lofty>
We have things like gtkwave
<whitequark>
can you describe a few examples of things you'd like to do?
<Sarayan>
sure
<Sarayan>
take a design like my arcade stuff
<Sarayan>
preload the Memory from external files, possibly change some registers by hand
<Sarayan>
run the clock for a while
<Lofty>
Doesn't this boil down to incremental builds?
<Lofty>
Since a ROM would likely get boiled down into logic
<whitequark>
uhm... not in cxxrtl
<Sarayan>
add an interpreter for the output signals so that it turns them into an image for instance, or into audio
<Lofty>
Oh, right, cxxrtl doesn't optimise
<Sarayan>
of course, look at the signals at any time
<whitequark>
it does
<whitequark>
it just specifically doesn't bitblast memories
<whitequark>
because it wants to let you replace ROMs
<whitequark>
Sarayan: so... "preload the Memory from external files, possibly change some registers by hand, run the clock for a while" all should be already working?
<Sarayan>
and re of-course, do the same thing without reconfiguring (but starttime from clock zero is ok) when you change a source
<whitequark>
"add an interpreter for the output signals so that it turns them into an image" is what cxxrtl blackboxes do, also already upstream
<Sarayan>
It's a lot more about integration and UX
<whitequark>
hmm
<whitequark>
so you don't want to be writing C++ code?
<Sarayan>
I like C++, but there's a point at which it gets innefficient to go back to it all the time
<whitequark>
sure, neither do I, er
<Sarayan>
especially when you go "huh, what happened in this register?" and you have to add more code to read it, restart stuff, etc
<whitequark>
I mean makes sense :)
<whitequark>
okay. hmm.
<whitequark>
so if you could use the same python interface as pysim, would that help?
<whitequark>
maybe with a REPL?
<Sarayan>
I don't actually know
<Sarayan>
pretty much what I want is to have everything recorded and making it easy to update the source and see the new result
<whitequark>
well
<Sarayan>
I don't care so much about incrementalism than about sessions
<whitequark>
it ranges from "reasonably easy" to "completely impossible" depending on what you mean by "without reconfiguring"
<Sarayan>
in fact
<whitequark>
nmigen can't really guess that a Signal in one run is the same as a Signal in another (except if you have the exact same netlist, I guess)
<whitequark>
so if your HDL doesn't change, replaying just testbench/debugging code is doable
<Sarayan>
without reconfiguring = without telling it again "go read that ram from here, that rom from there, set that register to this value, handle that output as a video signal"
<Sarayan>
if the register has changed of name, the setting drops to the floor, that's not an isue
<Sarayan>
issue
<whitequark>
that is an issue actually
<whitequark>
because nmigen doesn't know (and cannot know) what "name has changed" means
<whitequark>
it only knows "name disappeared" and "name appeared"
<whitequark>
you know move detection in git? same deal
<Sarayan>
Oh, I see it more as "the register with this name, put that value" and as long as the name exists and the value is compatible, as in good bit count, it goes in
<whitequark>
right ok
<whitequark>
that is totally doable
<Sarayan>
e.g. best effort without insanity
<whitequark>
so if you put that code into a function... you already get what you want today, right?
<Sarayan>
leaving the human to fix things up when changes happened
<whitequark>
or is there something i'm missing?
<Sarayan>
well
<Sarayan>
example of thing I want to do: write a sprite generator
<Sarayan>
I have captures of the state of the external sprite ram, the palette, the internal cpu-accessible sprite registers
<Sarayan>
and I want to write the generator and test what I write when I write it
<Sarayan>
so that means the dma that copies the external sprite ram in the internal one with "sorting"
<Sarayan>
then the selector than sees which sprites are active, the line renderer, etc
<Sarayan>
which means looking at registers, at internal ram, and video output etc depending on where I am in the development
<Sarayan>
if I have to find out the registers I'm interested in every run and change the c++ code and everything, I just don't have the patience
<whitequark>
yeah, what about python code?
<Sarayan>
pretty much the difference between printf debugger and having a decent debugger interface
<Lofty>
Maybe I'm misreading this, but it sounds like you have the same problem I do, but are trying to fix it differently, Sarayan
<Sarayan>
python only if the speed makes it decent
<whitequark>
sure, that's the plan
<whitequark>
have decent speed but the same interface as pysim
<whitequark>
no actual interaction with c++
<Sarayan>
and I'm not sure how easy it would be to see a signal through time or a register with pysim
bubble_buster_ has joined #nmigen
<Sarayan>
when you debug you tend not to know what you want to see until you want to see it
<whitequark>
sometime after cxxrtl gains vcd support
<Sarayan>
because complete complete, when you end up with a full cpu in the stack, that's just too much
anuejn_ has joined #nmigen
<whitequark>
yeah, you'll be able to filter
<whitequark>
good night
<Sarayan>
good night to you
MadHacke1 has joined #nmigen
mwk_ has joined #nmigen
withig has joined #nmigen
plaes_ has joined #nmigen
zignig_ has joined #nmigen
hell__ has quit [Ping timeout: 246 seconds]
bubble_buster has quit [Ping timeout: 246 seconds]
nengel has quit [Ping timeout: 246 seconds]
mwk has quit [Ping timeout: 246 seconds]
MadHacker has quit [Ping timeout: 246 seconds]
felix_ has quit [Ping timeout: 246 seconds]
bubble_buster_ is now known as bubble_buster
<Lofty>
Night WQ
plaes has quit [Ping timeout: 264 seconds]
zignig has quit [Ping timeout: 264 seconds]
Asu has quit [Ping timeout: 264 seconds]
anuejn has quit [Ping timeout: 264 seconds]
felix__ has joined #nmigen
<Lofty>
Sarayan: I really do think we have similar problems
<Sarayan>
We very probably do
hellsenberg is now known as hell__
mwk_ is now known as mwk
Asuu has quit [Remote host closed the connection]
<Degi>
Huh, you can do physics simulations in nmigen...
Asu has joined #nmigen
futarisIRCcloud has joined #nmigen
<Lofty>
Degi: I mean, sure, but they won't be all that fast :P
<Lofty>
Unless you run it on an FPGA I suppose.
SherpaPierpa has joined #nmigen
SherpaPierpa has quit [Remote host closed the connection]
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
withig is now known as nengel
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
<Degi>
Huh, when I use SyncFIFO compilation takes much longer than using SyncFIFOBuffered and it says that 0% of DP16KD tiles are used and that 163% TRELLIS_SLICE are used. (with SyncFIFOBuffered it uses 1 % slices and 18% DP16KDs)
<tpw_rules>
FPGAs can't implement SyncFIFO generally cause BRAM isn't asynchronous
<tpw_rules>
so it has to use all the LUTs as RAM instead
<Degi>
Hmh but SyncFIFOBuffered works just fine?
<tpw_rules>
yeah, because it doesn't require asynchronous RAM
<tpw_rules>
so it can use the RAM blocks
<tpw_rules>
iirc the only disadvantage to SyncFIFOBuffered is that if you write an element on one cycle, it won't be available on the output until the next. but it's a FIFO, so just add one more element if that's a problem ;P
<Degi>
Hmh what does asynchronous mean here? That it can read and write from different clock domains?
<Degi>
Heh yes I wrote a thing which records data and then sends it over UART. Works just fine with SyncFIFOBuffered.
<tpw_rules>
that you don't have to clock it to read
<tpw_rules>
on non-async memory you give it the address one cycle, then get the data the next
chipmuenk1 has joined #nmigen
<tpw_rules>
when reading
<Degi>
Hm so that it has like a builtin address counter which increases every clock cycle?
<tpw_rules>
no. there's just logically a register in the middle of it
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
chipmuenk has quit [Quit: chipmuenk]
jeanthom has quit [Ping timeout: 272 seconds]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 246 seconds]
jeanthom has joined #nmigen
<whitequark>
Degi: so this relates to a property of FIFOs called "first word fallthrough" and their latency
jeanthom has quit [Ping timeout: 272 seconds]
<Degi>
Oh so a non-buffered one wants the first word to instantly fall through and that isnt possible with BRAM?
<Sarayan>
it's not so much instantly as before the next clock
<Degi>
Hm yes, if you make the clock go faster, weird things happens
<Degi>
(Like when you clock an ECP5 at 800 MHz, then a too long logic chain fails)
<Sarayan>
yeah
<Sarayan>
static ram of old was async that way, you had a maximum time for answer but no clock anywhere
<Sarayan>
now everything is clock, synced and annoying ;-)
<Degi>
I think I have some chips like that... You give them an address and they give back data
<Sarayan>
exactly
<Degi>
Ah yes, so BRAM needs 1 clock cycle between addr and data out
<Sarayan>
yeah
<Sarayan>
whatever the clock (even if there's a maximum speed I'm sure) there's a need for a clock edge
<whitequark>
Degi: yep!
Sarayan has quit [Ping timeout: 272 seconds]
Sarayan has joined #nmigen
Asuu has joined #nmigen
<Degi>
Heh I tried to clock an UART off of PCIe and that went kinda wrong, the 100 MHz signal has like 4 MHz bandwidth. After downclocking the signal to below 100 MHz and then putting it through an async fifo it worked (for some reason I couldnt get the UART to work on a PLL)
Asu has quit [Ping timeout: 260 seconds]
ianloic has quit [Ping timeout: 260 seconds]
_florent_ has quit [Ping timeout: 246 seconds]
ktemkin has quit [Ping timeout: 272 seconds]
sorear has quit [Ping timeout: 272 seconds]
bubble_buster has quit [Ping timeout: 244 seconds]
key2 has quit [Ping timeout: 244 seconds]
levi has quit [Ping timeout: 272 seconds]
pdp7 has quit [Ping timeout: 244 seconds]
levi_ has joined #nmigen
rohitksingh has quit [Ping timeout: 252 seconds]
key2 has joined #nmigen
Cynthia has quit [Ping timeout: 240 seconds]
_florent_ has joined #nmigen
futarisIRCcloud has quit [Ping timeout: 252 seconds]