<lsneff>
I definitely would appreciate assistance in designing the final database format.
<whitequark>
there's some amount of tension between the needs of the emitter and a consumer
<whitequark>
for example, a normal B-tree is not something I can emit in a CXXRTL waveform writer
<whitequark>
(I could emit it in reverse, in theory, like you would stream a ZIP archive, but meh)
<whitequark>
on the other hand, the consumer *does* need fast indexing
<whitequark>
I would personally separate the waveform dump itself (which would be append-only and very simple) and the waveform index (which would be produced by the viewer on the first run and help it with fast access, perhaps mipmapping as well, etc)
<whitequark>
but this is just my opinion
cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Ping timeout: 264 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
_whitelogger has joined #nmigen
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
<_whitenotifier>
[nmigen] hansfbaier commented on issue #554: Strange simulator behavior: clock signal pausing while sync blocks are speeding up - https://git.io/JLX6v
<lsneff>
A tree of averages down to the level of value change leafs might work well for mipmapping or something similar
<whitequark>
yep, i think that would be a good idea also
<_whitenotifier>
[nmigen] whitequark commented on issue #554: Strange simulator behavior: clock signal pausing while sync blocks are speeding up - https://git.io/JLX6L
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 256 seconds]
PyroPeter_ is now known as PyroPeter
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
<lsneff>
How can a tree like that be efficiently packed?
<whitequark>
perhaps take a look at what influxdb uses?
<whitequark>
well that or lmdb, that's also a reasonable option
<whitequark>
I think either of those might technically be overkill because the waveforms in your case are static
<whitequark>
but perhaps there are still lessons to be learned
<whitequark>
for example, I know that influx uses delta compression for timestamps and values
Bertl_oO is now known as Bertl_zZ
<lsneff>
I am as well
FL4SHK has quit [Ping timeout: 256 seconds]
FL4SHK has joined #nmigen
lkcl has quit [Ping timeout: 256 seconds]
cr1901_modern has quit [Ping timeout: 260 seconds]
lkcl has joined #nmigen
_whitelogger has joined #nmigen
lkcl has quit [Ping timeout: 264 seconds]
lkcl has joined #nmigen
FL4SHK has quit [Ping timeout: 240 seconds]
FL4SHK has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
lkcl has quit [Ping timeout: 256 seconds]
ianloic_ has quit [Read error: Connection reset by peer]
sorear has quit [Read error: Connection reset by peer]
_florent_ has quit [Read error: Connection reset by peer]
davidlattimore has quit [Read error: Connection reset by peer]
sorear has joined #nmigen
_florent_ has joined #nmigen
davidlattimore has joined #nmigen
ianloic_ has joined #nmigen
lkcl has joined #nmigen
lkcl has quit [Ping timeout: 256 seconds]
lkcl has joined #nmigen
Chips4Makers has quit [Remote host closed the connection]
sorear has quit [Ping timeout: 256 seconds]
davidlattimore has quit [Read error: Connection reset by peer]
ianloic_ has quit [Ping timeout: 260 seconds]
davidlattimore has joined #nmigen
sorear has joined #nmigen
ianloic_ has joined #nmigen
lkcl has quit [Ping timeout: 240 seconds]
cr1901_modern has joined #nmigen
lkcl has joined #nmigen
_whitelogger has joined #nmigen
lkcl has quit [Ping timeout: 260 seconds]
jeanthom has joined #nmigen
lkcl has joined #nmigen
Chips4Makers has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
<JJJollyjim>
beginner question: what's the deal with `ports`?
<JJJollyjim>
it seems as if anything i forget to assign is silently emitted as with a generate my_signal (length)'0
<JJJollyjim>
is it naive to think that forgetting to assign to something should be an error condition?
<whitequark>
there are some compatibility considerations, both with migen code run through nmigen.compat, and with coding styles used in both migen and nmigen
<whitequark>
for example, there are some buses with lots of signals that may not be useful to every peripheral, wishbone for example
<whitequark>
if you had to manually assign all of those, a lot of people would find it annoying.
<JJJollyjim>
hmm okay
<whitequark>
that said, this is something we're probably going to improve in the future, it's just not quite as easy as emitting a hard error every time that happens
<JJJollyjim>
and by convention, those optional signals are generally 0=dontcare?
<whitequark>
they are defined to always assume their reset value
<JJJollyjim>
ah right
<whitequark>
which is indeed zero by default
<whitequark>
but you can change it of course
<JJJollyjim>
ty
chipmuenk has joined #nmigen
<agg>
for the purposes of getting resource and timing estimates for a module by itself, where normally yosys would happily remove the entire module since none of its outputs are connected to anything, could I manually instantiate some LUT4s and connect to their inputs?
<whitequark>
hm
<whitequark>
if it's just the outputs that are an issue, you could mark those as (*keep*)
<agg>
I guess ideally I'd feed inputs with an unknowable value too so it can't optimise all the logic away when all the inputs are stuck at reset 0
<whitequark>
why not just make it the toplevel module?
<whitequark>
nextpnr issues?
<agg>
currently I just assign sequential IO locations to all inputs and outputs, but it's easy to run out
<whitequark>
i think nextpnr really ought to support "out-of-place" mode, not sure how hard that is (cc daveshah)
<agg>
I was assuming even if it was at the top level all the signals would need to end up being IO to avoid being removed
<whitequark>
i mean, that's implied
<agg>
which obviously is what I want for an actual design
<daveshah>
It does for ECP5, but not for iCE40
<whitequark>
yosys doesn't care how much IO you have though
<agg>
sure, but yosys doesn't give timing results either
<daveshah>
There's an open ticket, I'll do ice40 too when I have a moment
<agg>
or post-packing resource
<agg>
daveshah: at least in principle, any idea if a manual lut4 would keep signals from being removed, or would that just get removed itself if its output is unused?
<daveshah>
You would need (* keep *) on the LUT4 if its output is unused
<agg>
would that work for inputs too, to ensure they're not assumed to be always the same value? or can the synthesiser figure out that the LUT's inputs are unchanging and therefore the output won't either?
<agg>
I guess really I want a magic black box cell :p
<agg>
or indeed out-of-place synthesis
<whitequark>
you can always use an unknown black box, then techmap it to SB_LUT4 after synthesis as a workaround
<mwk>
there's an opt_lut_ins which optimizes such things away, but it won't touch anything marked with keep
<mwk>
otherwise, yosys opt passes generally only work on generic cells, not mapped ones
<d1b2>
<䲜䲜> i don't understand why migen treats signals driven by a register as a separate concept from signals driven by combinationals
<d1b2>
<䲜䲜> rather than treat registers as yet another module like spinalhdl does
Bertl_zZ is now known as Bertl
<whitequark>
uhm, i cannot type your name to reply to your message
<whitequark>
but in any case, can you elaborate your question? in nmigen at least, signals driven in comb and sync domains are treated quite similarly
<whitequark>
i haven't used spinalhdl so i might be missing some context you have
<d1b2>
<Elon Musk> well in nmigen registers are created implicitly by putting signals into a "domain" under a module
<d1b2>
<Elon Musk> logically i prefer to think of registers as just yet another basic element and prefer to instantiate them explicitly
<d1b2>
<Elon Musk> i guess it's just a syntactic difference but i personally find nmigen code quite hard to read because of the syntax associated with adding logic to a domain
<d1b2>
<Elon Musk> don't know if you can see my nickname change over the irc bridge but it should be in latin characters now
<d1b2>
<Elon Musk> like i find it hard to glance over nmigen code and find exactly what drives a certain signal
<d1b2>
<dub_dub_11> I think it's altera that have virtual IOs to deal with some of those problems with logic getting optimised out, though I don't know much about it and I don't know if lattice has anything similar
FL4SHK has quit [Ping timeout: 260 seconds]
<d1b2>
<Elon Musk> at least on xilinx the keep attribute doesn't prevent unused signals getting removed
<d1b2>
<dub_dub_11> @Elon Musk I suppose it's just making code more behavioural and slightly abstracting away the lowest level elements that are common to all FPGAs
<d1b2>
<dub_dub_11> Makes more concise code
FL4SHK has joined #nmigen
<d1b2>
<Elon Musk> sure though i prefer to think in terms of drawing a circuit rather than writing code
<d1b2>
<Elon Musk> HDL always puts the target of an assignment in front and this makes it easy to read
<d1b2>
<Elon Musk> when it isn't, you really have to read every line to figure out what's going on
<d1b2>
<Elon Musk> multiple assignments to a signal also bothers me, that's why i never use "process" in vhdl
<d1b2>
<Elon Musk> if/else blocks in hdl are also illogical to me, as it implies hardware can be made to disappear and reappear which it can't
<d1b2>
<Elon Musk> what really happens is a mux is added to the signals driven, and i prefer this to be explicitly spelled out
<d1b2>
<Elon Musk> spinal looks like it will let me do what i want, but scala is foreign to me while i'm familar with python
<d1b2>
<Elon Musk> i tried to get into migen/nmigen a few times but every time the syntax put me off
<d1b2>
<dub_dub_11> Not necessarily, it may be a LUT
<d1b2>
<Elon Musk> logically it's a mux, and only after technology mapping it becomes some luts
<d1b2>
<Elon Musk> for some discussions of why i don't like behavioral code
<d1b2>
<Elon Musk> in that example some very simple code did some nonobvious things that you wouldn't expect from reading the code, but that led to very bad timings
<d1b2>
<dub_dub_11> A mix with constant inputs is a lookup table :P
<d1b2>
<Elon Musk> sure
<d1b2>
<Elon Musk> just if i can see the mux i can easily tell how many luts that's gonna use per bit
<d1b2>
<Elon Musk> if i can't see the mux who knows
<d1b2>
<Elon Musk> on xilinx 7 series for example, a 2:1 mux before an adder may be sometimes permissible without a big performance penalty
<d1b2>
<Elon Musk> but a mux after an adder should almost always be avoided
<d1b2>
<Elon Musk> you no longer get to use the registers that are right at the outputs of the carry chain,
<d1b2>
<Elon Musk> and the signal has to travel out to another slice...
<d1b2>
<dub_dub_11> The tools do their optimisations and tell you if it works, and unless you are in hft it's often not important
<d1b2>
<Elon Musk> i highly recommend taking a look at the physical device view of your designs in vivado sometime,
<d1b2>
<Elon Musk> especially the view that shows you the switchboxes and the routing
<d1b2>
<dub_dub_11> If you need to change your code it's easy to look back
<d1b2>
<dub_dub_11> Yeah, I do (well ISE)
<d1b2>
<Elon Musk> 6 and 7 series are very similar
<d1b2>
<dub_dub_11> Yeah ik
<d1b2>
<dub_dub_11> I have a V5 which had the same slices essentially
<d1b2>
<Elon Musk> did you know all flipflops in a slice have to share the same clock and clock enable? so if you had registers that had different clock enables, the can't be packed into the same slice
<d1b2>
<dub_dub_11> Yeah
<d1b2>
<Elon Musk> this was relaxed only in later ultrascale devices
<d1b2>
<Elon Musk> in one design i had to take that into account to come up with a very tightly packed design
<d1b2>
<dub_dub_11> Which the nMigen domain syntax helps rather than hinders
<d1b2>
<Elon Musk> sure
<d1b2>
<Elon Musk> in most of the projects i'm on it almost isn't permissible to have any more logic delay than one adder between register stages
<d1b2>
<Elon Musk> so i have to be very careful where muxes are and make very good use of clock enables, but not too much clock enables because of the slice packing rule
<d1b2>
<dub_dub_11> What field is that though
<d1b2>
<dub_dub_11> It sounds like a relative edge case
<d1b2>
<Elon Musk> telecom/dsp
<d1b2>
<dub_dub_11> Ah
<d1b2>
<Elon Musk> stuff running at very high clock frequency means less logic can be used (e.g. one filter handling many channels rather than many filters)
<d1b2>
<dub_dub_11> ¯\_(ツ)_/¯
<d1b2>
<dub_dub_11> Maybe nMigen isn't the best tool there
<d1b2>
<dub_dub_11> And I think that's fine
<d1b2>
<Elon Musk> i'm still using vhdl and i'm looking at alternatives
<d1b2>
<dub_dub_11> Ah
<d1b2>
<dub_dub_11> Equally
<d1b2>
<Elon Musk> i've used python code to generate vhdl
<d1b2>
<Elon Musk> people tell me to switch to nmigen for that
<d1b2>
<Elon Musk> but the problem is the generated code works tightly with other hand written modules that are in vhdl
<d1b2>
<dub_dub_11> I think it's fairly easy to look at a design post PNR, see failing paths and trace that back to a point in nMigen code
<d1b2>
<dub_dub_11> Oh you can instance Verilog (and I'm pretty sure VHDL too) in nMigen
<d1b2>
<Elon Musk> ah
<d1b2>
<Elon Musk> i'll look into it
emeb has joined #nmigen
<d1b2>
<Elon Musk> although what i just need is a library to generate RTL with minimal fuss
<d1b2>
<Elon Musk> the syntax is important though because readability
<d1b2>
<dub_dub_11> Yeah I guess that comes down to preference a bit
<d1b2>
<dub_dub_11> Took me a while to get used to it for sure
<Chips4Makers>
@Elon Musk: Did you look at myhdl ? It seems more what you want. Personally to me I think one of the strong points of nmigen is that it makes circuit more like wirting coding and not about describing a crictuit.
chipmuenk has quit [Quit: chipmuenk]
sakirious has quit [Ping timeout: 272 seconds]
FL4SHK has quit [Ping timeout: 256 seconds]
FL4SHK has joined #nmigen
jeanthom has joined #nmigen
<lsneff>
What bridge were those messages through?
<miek>
the 1bitsquared discord
lkcl has quit [Ping timeout: 246 seconds]
jeanthom has quit [Ping timeout: 265 seconds]
lkcl has joined #nmigen
sakirious has joined #nmigen
emeb has left #nmigen [#nmigen]
Raito_Bezarius has quit [Ping timeout: 260 seconds]
Raito_Bezarius has joined #nmigen
emeb_mac has joined #nmigen
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 272 seconds]
FL4SHK has quit [Ping timeout: 272 seconds]
Chips4Makers has quit [Remote host closed the connection]
FL4SHK has joined #nmigen
<whitequark>
@Elon chiefly, the reason nmigen has special syntax for instantiating registers is that it considers clock domains first-class entities, unlike traditional HDLs
jeanthom has joined #nmigen
<whitequark>
it would, in principle, be possible to do something similar to what spinalhdl does, but... that's how things went. if you strongly dislike it, nmigen is not for you
davidlattimore has quit [Ping timeout: 268 seconds]