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 hdmi_test.py (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 hdmi_test.py, 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 ._.
<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 - https://git.io/JUbMI
<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> 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
<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