ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting October 5th
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
FFY00 has quit [Read error: Connection reset by peer]
_whitelogger has joined #nmigen
<d1b2> <dub_dub_11> Been using nMigen for a while and liking it very much, thank you whitequark for so much hard work 😃
<whitequark> i'm glad you like it
<d1b2> <dub_dub_11> Until the other day I hadn't actually got around to using it on my Stratix IV devboard but running a python script and watching the whole quartus process run just blew me away
<d1b2> <dub_dub_11> I was very excited 😄
<ktemkin> nMigen is very nice, yes
<ktemkin> I can't imagine doing this USB3 stack in oMigen, nor Verilog >.>
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 258 seconds]
PyroPeter_ is now known as PyroPeter
_whitelogger has joined #nmigen
hitomi2509 has joined #nmigen
chipmuenk has joined #nmigen
_whitelogger has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
samlittlewood has joined #nmigen
Asu has joined #nmigen
_whitelogger has joined #nmigen
<anuejn> @EmilJ I dont really know. I have never actually tested it
<d1b2> <EmilJ> oh... I sort of went with using the repo's cores and soc glue to synth myself a video output interface for a project in a class I have :D
<d1b2> <EmilJ> I'm maybe going to build and test litevideo on my board (only to the point of having a test signal) and then go back to the nmigen rewrite
<anuejn> well
<anuejn> the hdmi works for shure
<anuejn> the soc register abstraction too
<anuejn> those are quite well tested on hardware
<anuejn> only the camera example, which glues together a axi hp reader and hdmi output is untested
<anuejn> if you go for (which is basically a port of the litevideo hdmi tx code to nmigen) you should be fine
<DaKnig> does it output DVI or actual HDMI?
<DaKnig> in theory HDMI is backwards compatible with DVI-D but ... in practice some devices dont accept that
<d1b2> <EmilJ> okay, that's good to hear. Also it means that the issue I opened on github is only an issue of getting spammed with warnings
<d1b2> <EmilJ> I'm still contemplating what's wrong with Vivado throwing critical warnings when the code assigns a 10bit initial value to a 32bit AXI word... but claims the problem is that it isn't a 1bit.
<d1b2> <EmilJ> I'm pretty sure I've been told at some point that "initial values get ignored in hardware", would doing this help:
<d1b2> <EmilJ> m.d.comb += self.clock_pattern.eq(0b1111100000) with the reset=0b1111100000 arg removed?
<daveshah> Initial values are not ignored for FPGAs in general, including Xilinx FPGAs
<d1b2> <EmilJ> well, it's still supposed to be a constant register
<d1b2> <EmilJ> so no reason not to hard-wire
<daveshah> Yes, initial values only apply to registers not combinationally assigned signals like this
<daveshah> The warning sounds like a Vivado bug to me
<daveshah> Probably something being optimised but the initial value not being treated accordingly
<d1b2> <EmilJ> >:(
<d1b2> <EmilJ> that is so bad
<d1b2> <EmilJ> it's even a critical warning
<d1b2> <DX-MON> @DaKnig that sounds more like you had a bad cable or so.. because HDMI and DVI-D use identical signaling and signal encoding w/ HDMI only extending DVI-D's signaling to add in sound and HDCP signaling during the vblank interval
<d1b2> <EmilJ> anuejn: there are two, I assume you mean the one in experiments/ ?
<anuejn> yup
<anuejn> DaKnig: it does the div subset of HDMI (so no data islands and guard bands)
Degi has quit [Ping timeout: 240 seconds]
FFY00 has joined #nmigen
Degi has joined #nmigen
<DaKnig> I had to add in a null packet, the prelude and all the other crap for my screen to accept it
<DaKnig> @DX-MON maybe it is bad. but I use this cable with other devices without any problems...
<d1b2> <DX-MON> interesting.. that technically means they aren't implementing spec properly but I bet they'll give the excuse that "it's how we support DHCP" or so
<d1b2> <DX-MON> *HDCP
<DaKnig> its a Panasonic screen so I would have expected they would do it properly
<DaKnig> idk
<d1b2> <DX-MON> I know there are some screens out there (which are not strictly conformant) which require a HDCP negotiation to work even though the source might not use it
<DaKnig> actually I did not implement hdcp
<DaKnig> ... thats the thing where you ask the screen what display modes it supports right?
<DaKnig> I did not do this
<d1b2> <DX-MON> that's DDC
<DaKnig> what's HDCP then
<d1b2> <DX-MON> HDCP is the content protection stuff that's done over the fat LVDS data link
<d1b2> <DX-MON> High Definition Content Protection IIRC
<DaKnig> the one that enforces copyright protection or whatever?
<DaKnig> I did not implement that for sure
<d1b2> <DX-MON> correct
<d1b2> <DX-MON> interesting
<d1b2> <DX-MON> so you only did the audio signaling?
<d1b2> <DX-MON> or?
<DaKnig> I did not do anything besides video
<d1b2> <DX-MON> seeing as the only mandatory part of the spec is the video data
<DaKnig> I sent a null data island
<DaKnig> and the prelude/whatever the other thing is called
<DaKnig> sorry I am not that good with the termiology
<d1b2> <DX-MON> looks like you're refering to the packet header which is 4b/10b encoded
<DaKnig> there is the thing you send before and after packets to signify your packet is gonna start/end
<DaKnig> ah I remember that one. that's TERC4 iirc
<d1b2> <DX-MON> oh, and I was wrong.. HDCP (High-bandwidth Digital Content Protection) is negotiated over DDC too.. which makes a lot of sense and is luckily also completely optional per the spec
<DaKnig> preamble, guardband
<DaKnig> here that's what I meant
<d1b2> <DX-MON> this is very curious to me that your screen demands at least a null data island
<d1b2> <DX-MON> ah, indeed
<d1b2> <DX-MON> I wonder if I could "trick" something like the TFP-410 DVI-D framer into producing that data island.. it'd be gnarly, but might be reasonably possible
<DaKnig> I am not sure the data island was required by my screen, but for sure it did not work without the preamble/guardband
<d1b2> <DX-MON> mkay
<DaKnig> you you can produce a simple data island by hardcoding the contents, then sending it when you first have time in the frame
<DaKnig> for example when the vblank activates for the first time in the frame
<DaKnig> vsync*
<DaKnig> or when it deactivates for the first time
<d1b2> <DX-MON> sure, I was more thinking about the fact that those framers only do 8b/10b encoding by design so trying to figure out how to structure a data input to produce a valid 4b/10b symbol
<d1b2> <EmilJ> anuejn: how much should I care about slacks here? I'm getting ~5ns slacks in x,y_reg in hdmi timing generator... I've replaced the buffer writer with the Hdmi thing, my script is practically hdmi_test just with a different platform. I am not providing any of the lowspeed_signals in my PynqZ2Platform, by the way.
<DaKnig> afaik they made sure that each 10bit symbol could only correspond to one thing, either a 2b signal, an 8b signal or a 4b signal (or whatever else there is that I dont know about)
<d1b2> <DX-MON> such a symbol is IIRC a symbol error on the DVI-D spec, but any conforming screen should just throw away the first frame or ignore the symbol as it's in the vblank..
<DaKnig> no 8bit value in 8b10b could produce the values in 2b10b
<d1b2> <EmilJ> maybe I am missing hot plug detect operation...
<d1b2> <EmilJ> that would be awkward, wouldn't it.
<DaKnig> I am pretty confident that there is no such symbol that could be interpreted as both a 2b10b encoded signal and a 8b10b signal
<d1b2> <DX-MON> well, so.. I don't mind about 2b/10b.. I'm thinking about 4b/10b which is used by the data island
<d1b2> <DX-MON> I'd be willing to say that valid 8b/10b symbols must also alias 4b/10b just because of the number of bits involved
<d1b2> <DX-MON> and that's a good thing here as that'd mean I could trick a DVI-D framer into doing HDMI spec things
<anuejn> @EmilJ it should work even if it doesnt meet timing
<d1b2> <DX-MON> keep in mind too that I can present invalid state to the framer and it will encode that to the correct invalid-in-8b/10b symbol to gain me additional signaling
<anuejn> but you can start with a lower resolution modeline
<DaKnig> I dont think there are any aliases between 8b10b and 4b10b symbols
<anuejn> the one in the example is already beyond what the output buffers of the zynq can do in spec
<DaKnig> you can see the full list of all TERC4 encoded symbols in the hdmi standard
<DaKnig> they just list them
<anuejn> maybe start with 800x600@60 and then go upwards
<DaKnig> I dont know what a framer is
<d1b2> <DX-MON> thanks DaKnig - I'll give that a read once I'm off work
<DaKnig> (btw if you dont have the standard- you can legally get it by registering to the hdmi site and downloading it - use guerillamail or something if you dont want to give them your email)
<DaKnig> (and only an older version of the standard is available for free)
<d1b2> <DX-MON> as for what a framer is, it's a chip which takes video data in (straight 8-bit per colour on a 24-bit parallel bus + clock, raw vblank, hblank etc signals) and spits out a valid TMDS stream ready to go down a cable to a screen
<DaKnig> ah it's a physical chip
<d1b2> <DX-MON> have a look at the TI TFP-410 🙂
<DaKnig> there are less than 512 symbols for 8b10b encoding (some have only one version, some are invalid in high resolutions...) , 4 symbols of 2b10b and 16 symbols of terc4
<DaKnig> all those combined could easily fit inside the 1024 possible 10bit values
<d1b2> <DX-MON> yeah, I re-did my maths and realised that it's entirely possible that 4b/10b TERC4 can find symbols unused by the other two
<DaKnig> they made sure there's some hamming distance between them to space them out properly
<d1b2> <DX-MON> grumbles
<DaKnig> why arent multi-clock paths widely supported and when they are , require messing with constraints so much? it looks like such a good feature to have
<DaKnig> instead of wasting time on setup/propogation you can add more logic...
<lkcl> dlb2, DX-MON: TFP-410 is a good choice. there's others (alternatives), they're just not as easily accessible (datasheets, etc.)
<d1b2> <EmilJ> anuejn: it doesn't work even with the hdl as minimal as possible ._.
<d1b2> <EmilJ> as in, minimallly changed, 640x480
<d1b2> <EmilJ> I put in src/ of the nmigen-gateware repo, added the pynq platform file to devices/ and edited devices/
<d1b2> <EmilJ> I scp the bitstream to pynq and load it to PL with the python script
<DaKnig> I can access m.submodules as a dictionary too right?
<DaKnig> I would have to add some submodue multiple times now
<DaKnig> can I instantiate constant Records, or at least use `Record([("a",4)]).eq({"a":9})`?
hitomi2509 has quit [Quit: Nettalk6 -]
<jfng> DaKnig: m.submodules doesn't implement all dict methods; it provides getitem()/setitem() so you can do `m.submodules["foo"] = Foo()`
<jfng> but you can't iterate over it to list all submodules
emeb has joined #nmigen
<ktemkin> I don’t want to be That Girl, but Meeting?
<whitequark> ktemkin: meeting.
<whitequark> anyone has blockers?
<ktemkin> none over here
<lkcl> blockers no, wish-list yes: Display.
<lkcl> it's been absolutely invaluable in debugging a L1 cache FSM: two of us have had to hand-patch nmigen to use jfng's patch, out-of-tree
<lkcl> jeanthom's patch sorry
<whitequark> so that's actually blocked on $display support in yosys and cxxsim
<whitequark> i'll see what can be done
<lkcl> jfng: i've been thinking in the background continuously on-and-off about the CSR communication "issue / protocol", and it occurred to me that the DMI protocol, which is dead simple req/ack, might be a good option to consider
<lkcl> whitequark: star, thank you. didn't realise it was blocked - it does actually work!
<lkcl> but then again, ahh cxxsim - yes, we still can't use that until the things that cesar is investigating are resolved
<whitequark> well, it works with pysim, but it wouldn't work with cxxsim
XgF has quit [Remote host closed the connection]
XgF has joined #nmigen
<FL4SHK> when eta nMigen supports the new Record stuff
<_whitenotifier-f> [nmigen] alanvgreen commented on issue #425: Support for PLL primitives -
<FL4SHK> ooh, PLL primitives
<FL4SHK> such that I don't need to make the PLL with Quartus any more?
<FL4SHK> that'd be nice... I could port more of the code from one dev board to another
ianloic__ has joined #nmigen
guan_ has joined #nmigen
<d1b2> <EmilJ> well, you've always been allowed to just make an Instance of anything your FPGA and toolchain supports, if I understand it correctly
whitequa1k has joined #nmigen
<d1b2> <EmilJ> but at that point you need to be practically transcribing from your resource manual, or pre-existing HDL
tucanae47_ has quit [Ping timeout: 244 seconds]
ianloic_ has quit [Ping timeout: 244 seconds]
gravejac has quit [Ping timeout: 244 seconds]
guan has quit [Ping timeout: 244 seconds]
ianloic__ is now known as ianloic_
smkz has quit [Ping timeout: 244 seconds]
whitequark has quit [Ping timeout: 244 seconds]
guan_ is now known as guan
tucanae47__ has joined #nmigen
tucanae47__ has joined #nmigen
gravejac_ has joined #nmigen
tucanae47__ is now known as tucanae47_
gravejac_ is now known as gravejac
gravejac has joined #nmigen
gravejac has quit [Changing host]
smkz has joined #nmigen
emeb_mac has joined #nmigen
<d1b2> <dub_dub_11> Oo that was the next thing I wanted to try
<FL4SHK> question about nMigen
<FL4SHK> regarding `m.submodules`
<FL4SHK> can I put a list in there?
<FL4SHK> a list of class instances that are `Elaboratable`
<FL4SHK> I do mean a Python `list`
<tpw_rules> i'm pretty sure you can but it should be very simple to test
<DaKnig> why not just `+=` in a loop :)
<FL4SHK> oh
chipmuenk has quit [Quit: chipmuenk]
<tpw_rules> it's also supports string indexing if you want to name your items in the list
<FL4SHK> I see.
<FL4SHK> that answers that
<tpw_rules> like i have for i, obj in enumerate(objs): m.submodules["obj_{}".format(i)] = obj
<tpw_rules> more or less
<FL4SHK> yeah, that's the kind of thing I was after
<FL4SHK> for the equivalent of generate loops in SV
<tpw_rules> as much as i think invoking the X-Y problem is a trash copout, ...
<anuejn> @EmilJ hmm... that sounds odd
<anuejn> is there any inversion you have to do?
<anuejn> or are some lanes swapped?
<anuejn> do you have any other (working) gateware which produces hdmi on your hardware?
<d1b2> <EmilJ> I wrote a bit more stuff in this here issue:
<d1b2> <EmilJ> it includes a link to "canonic" VHDL sources from Xilinx. I have tested that Overlay and yep, it sure can emit HDMI
<DaKnig> I have 2 lists of signals, called x,y of the same length. I want to find the index i of the highest x then output x[i] and y[i], how should I do this in a pipelined fashion efficiently? I have a very slow clock for this and I'd rather it be done in one clock
<d1b2> <EmilJ> "pipelined but in one clock" wait isn't that really contradictory
<DaKnig> well pipelined or preferrably one clock
<DaKnig> preferably*
<d1b2> <EmilJ> I'm not very experienced at all with that but my brain is coming up with either "log(length) of smaller operations" or "one big operation"
<DaKnig> I guess I could compare each of them to each of the others, then have the binary results go into a short signal (with 1 bit for every combination of signals) and then have a big lookup table for this
<DaKnig> hmm this would be in ~O(1) for small n (or n^2 with a low coefficient)
<d1b2> <EmilJ> naw
<d1b2> <Darius> wouldn't it just be a bit pile of comparators in a tree?
<d1b2> <EmilJ> I don't think that would work
<d1b2> <Darius> obviously the deeper it is the slower it will go, but..
<d1b2> <EmilJ> Unless you want factorial(length) comparisons
<DaKnig> not factorial, just quadratic
<d1b2> <EmilJ> how come
<DaKnig> every one thing against every other thing
<DaKnig> there are n things
<DaKnig> so n*n
<d1b2> <Darius> I think you would need log2(n) comparators
<DaKnig> thats a different solution
<d1b2> <Darius> but it would be deep
<d1b2> <EmilJ> riiight, not factorial, it's more like, n choose 2
<d1b2> <EmilJ> which rounds up to n^2
<DaKnig> why are you falling back to probability lol
<d1b2> <EmilJ> yeah I really like the log2(n) solution
<d1b2> <EmilJ> because I am somewhat sleep deprived today. Apologies
<DaKnig> I guess the log2(n) solution is better but would take more lines of code :(
<d1b2> <EmilJ> also, "n choose 2" is not probability, it's combinatorics
<d1b2> <Darius> I would think you could generate most of it
<d1b2> <EmilJ> and honestly why would you compare things to themselves
<d1b2> <EmilJ> yeah you are in #nmigen, generate RTL away
<DaKnig> @Darius the n^2 solution (with smaller tpd I think) takes literally 2 lines :)
<DaKnig> @EmilJ O(n(n-1)) = O(n^2)
<d1b2> <EmilJ> true
Asu has quit [Ping timeout: 272 seconds]
<FL4SHK> finally getting into writing some HDL code again
<FL4SHK> how do I simulate nMigen code?
<FL4SHK> formal verification doesn't feel like the right answer for some of what I'm doing
<FL4SHK> mainly because formal doesn't seem to handle multi-cycle results
<FL4SHK> like for a divider
<FL4SHK> ...I am specifically making a divider
<whitequa1k> check out examples/basic/
<d1b2> <Darius> (eg)
<FL4SHK> cool
guan has quit [Ping timeout: 272 seconds]
guan has joined #nmigen
<DaKnig> FL4SHK: for multi cycle you could try adding a fifo for delay
<FL4SHK> delay for what?
<DaKnig> to delay the input so that you could check it against the output
<FL4SHK> that's an idea
<FL4SHK> it works for pipelined stuff, too
<DaKnig> maybe not fifo, but a simple shift register
<FL4SHK> yeah
<FL4SHK> a shift register is more like it
<DaKnig> also only check after the max number of clocks
<DaKnig> if it might take less than that
<DaKnig> a fifo would be the more "correct" way to do it I think but I am not sure if the prover would understand it. but what do I know.
<FL4SHK> the idea would be to send the inputs into a FIFO as well
<DaKnig> that's what I said
<FL4SHK> oooh
<FL4SHK> er, right
<FL4SHK> but don't forget about the oracle
<DaKnig> ?
<FL4SHK> assuming you need to send it down the FIFO
<FL4SHK> guessing you don't need to
<DaKnig> sending what?
<FL4SHK> the oracle
<FL4SHK> what to compare the DUT's output against
<DaKnig> I dont understand
<DaKnig> ah
<DaKnig> but .. you are comparing it against the python div or?
<DaKnig> `assert(yield delayed_input_1//yield delayed_input_2 == output)`
<DaKnig> or something like that
<DaKnig> you could also connect the oracle to the delayed input instead of delaying its output if you are doing it like that
<FL4SHK> I think it'd be compared against yosys's div
<whitequa1k> if you use pysim it doesn't involve yosys
<FL4SHK> that's true, but we were discussing formal there for a bit
<whitequa1k> ah
<FL4SHK> by the way, I really like being able, once again, to do things like compare two things of different sizes, or assign to things of different sizes
<FL4SHK> can't do that in VHDL (which I only use for work)
<FL4SHK> It's more of an SV thing
<FL4SHK> though here's a cool thing I'm going to be doing in this module I'm working on in nMigen
<FL4SHK> so the quotient digit search in long division is basically a priority encoder
<FL4SHK> you want the largest thing less than or equal to the current remainder
<FL4SHK> I need to be able to generate a different priority encoder based upon a generic
<FL4SHK> can't freaking do that in VHDL or SV
<FL4SHK> nMigen makes it trivial
<FL4SHK> I need a different number of `m.Case`s in an `m.Switch` depending on how many bits per cycle my long divider computes
<DaKnig> VHDL doesnt allow comparing things of diff size?
<FL4SHK> wait
<FL4SHK> maybe it does allow that
<FL4SHK> for `unsigned` and `signed`
<FL4SHK> I think it does, yes
<FL4SHK> it's too picky about when you can mix sizes though, IMO
<FL4SHK> just, darn it, all I want to do is assign the constant `0` to a signal
<FL4SHK> I shouldn't have to tell it hte size of my constant
<FL4SHK> VHDL is pretty cleanly designed as a language
<DaKnig> (others => '0')
<FL4SHK> yeah but that's not nearly as short as it should be
<FL4SHK> VHDL has these sticking points in it for me
<FL4SHK> I'd never use it over nMigen
<FL4SHK> I'm too much of a metaprogramming nut
<FL4SHK> okay, fine, I'd use it at work
<FL4SHK> why the crap is adding type generics to `record` something they didn't do
<FL4SHK> they did this unconstrained record elements thing
<DaKnig> type safety maybe
<FL4SHK> no, there's nothing non type safe about this
<FL4SHK> any language worth its salt will let you use type generics with a custom type
<FL4SHK> (C is not worth its salt)
<FL4SHK> at least C has void pointers
<FL4SHK> though those may cause you to have a speed loss on systems without icache
<FL4SHK> icache honestly seems to help strengthen the use of void pointers over C++ style type generics
<FL4SHK> but I'd sure as heck like a C++ like interface for type generics in C
<FL4SHK> even if it uses void pointers underneath (I don't mind that)
_whitelogger has joined #nmigen
<DaKnig> nmigen says that it cant elaborate None
<DaKnig> but ... whre did I assign None? how would I go about fixing this?
<DaKnig> oh right. I forgot `return m`.
<DaKnig> a little error message that points to the right elaboratable would have helped
<whitequa1k> there is an error message
<whitequa1k> look above
emeb has quit [Quit: Leaving.]
<DaKnig> ah right you already told me about this one
<DaKnig> sorry.
<DaKnig> and I missed it again since it was above the trackback