<d1b2>
<Hardkrash> I would also say that you should include the ability to render analog values as well.
<whitequark>
yeah, you should't limit yourself to just binary
<lsneff>
Isn't an analog value just a digital value with many bits? :P
<whitequark>
you need at least 0, 1, z, x, bit vectors, enums, strings, and analog values come naturally
<whitequark>
yep
feldim2425_ has quit [Remote host closed the connection]
<whitequark>
well, they are rendered differently
feldim2425 has joined #nmigen
<whitequark>
but you already want custom-ish rendering
<lsneff>
I don't really know why I'm doing this, I got into FPGAs because I need a lock-in amplifier for a diy afm I'm designing, but I'll give it a try.
<lsneff>
Don't expect too much
<whitequark>
ha, mood
<anuejn>
can one emit "events" or what they are called (like in the first sceenshot on teh logicpoet site) from nmigen and display them in gtkwave?
<anuejn>
that seems like a thing I already wanted a few times
<anuejn>
or annotate time ranges with comments?
<whitequark>
anuejn: events: not atm, but people have requested this so it will likely be possible
<lsneff>
Is that a thing that vcd supports?
<whitequark>
yes
flow has quit [Remote host closed the connection]
<anuejn>
nice :)
<anuejn>
can events in vcd span time ranges?
<whitequark>
no
<anuejn>
ah sad
<lsneff>
It's kind of wack how inefficient vcd files are
<whitequark>
yup
<lsneff>
Probably could fit the same data in a tenth of the size
<whitequark>
gtkwave invents two or three formats to replace vcd
<whitequark>
and somehow they're all even worse
<whitequark>
i considered writing them from outside of gtkwave and without using its C code
<whitequark>
that's unrealistic
<lsneff>
Yeah, a tenth is probably unrealistic, maybe 1/5 of the size is more likely
<lsneff>
Yeah, I've heard a few other binary formats mentioned
<whitequark>
no, i mean, using the formats without using gtkwave's source code
<lsneff>
Oh, I got ya
<whitequark>
is what's unrealistic
<whitequark>
right
<lsneff>
And those are all somehow worse than vcd?
<whitequark>
yes
<whitequark>
they're implementation-defined with no spec
<whitequark>
if you can even call that "defined"
<lsneff>
Oof
<whitequark>
and the C code that uses them is tightly coupled to the rest of gtkwave
<whitequark>
*reads/writes them
<lsneff>
Oh no
<lsneff>
Gtkwave sounds like the physical representation of the worst parts of the GNU world
<whitequark>
most GNU software is written in a much better fashion
<whitequark>
like... gtkwave already has the debugger you want, for verilog only
<whitequark>
i've looked into how it could be hooked to nmigen in any way
<lsneff>
Oh I didn't realize it had that
<whitequark>
and the answer is that you run
<whitequark>
run as fast as you can
<DX-MON>
I mean, it's GTKWave, not GNUWave..
<DX-MON>
it's written in a GTK fashion..
<lsneff>
Back when I was doing wasm stuff, I had to integrate with llvm to generate code and that was horrendous. This sounds much worse
<lsneff>
Anyway, I'll start figuring out the rendering stuff
<lsneff>
And maybe someone can start speccing out a better trace format
<whitequark>
hey, i maintained the llvm c api for a while
<lsneff>
No offense intended, I don't think it had anything to do with the api
<whitequark>
ah. what was it?
<lsneff>
It's just that llvm is designed in a particular wat
<lsneff>
*way
<lsneff>
That doesn't really work well when you look at it from another language
<whitequark>
hrm
<whitequark>
i also maintained the ocaml bindings
<whitequark>
i think the main issue is how much it likes to assert
<lsneff>
That's one of the things ya, also just completely terrible documentation, even on thr c++ side
<whitequark>
that's true
<whitequark>
you're expected to read a lot of C++
<whitequark>
for better or worse
<lsneff>
Yes
<lsneff>
I think perhaps the main issue is I very much dislike C++
<whitequark>
entirely reasonable
<lsneff>
thank you
<lsneff>
voicing it on twitter or hm hasn't garnered me very much support
<lsneff>
s/hm/hn
<whitequark>
i write a lot of C++ code. of course i don't like C++ :p
<asu>
heh, i've actually been thinking of a similar project lately (only vague ideas though)
<lsneff>
Alright with it being written in rust?
<asu>
i was thinking of rust or c++ myself, but tbh i think the choice mostly boils down to what lib you are going to build the ui on
<whitequark>
100% onboard with rust
<lsneff>
Cool, I'll probably use wgpu then
<whitequark>
yup, sounds like a good choice to me
<asu>
i might be interested in contributing if you are interested but i can't guarantee it considering my average perseverence to work on projects :p
<lsneff>
Well, I'll start it and once I get something basic working, contributions are welcome
<whitequark>
same from me
<asu>
how does gtkwave handle big vcds anyway?
<asu>
(as in, loading times and scrolling around)
<whitequark>
it's generally quite good, especially once you let it convert to fst
<lsneff>
Fst is a file format?
<whitequark>
yes. gtkwave has fst, vzt, lxt and lxt2
<lsneff>
Designed for fast traversal or something?
<whitequark>
basically
<lsneff>
Geez, there's basically no documentation on it
<lsneff>
There's a paper at the end of the gtkwave manual about it, but there's no spec.
<whitequark>
told ya
<asu>
not sure what would be the best approach for parsing the vcd in general, i'm guessing that you can implement "getting the changes from A ns to B ns" by binary searching around the file for the chunk you care about, or something like that
<asu>
(that might be overkill, though)
<whitequark>
or index it
<lsneff>
Yeah, I think building an index would be the way to go
lkcl has quit [Ping timeout: 264 seconds]
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #nmigen
lkcl has joined #nmigen
ming__ has joined #nmigen
_whitelogger has joined #nmigen
<whitequark>
lsneff: i *told you*
<lsneff>
I haven't found any mipmapping stuff yet
<whitequark>
i'm calling it mipmapping in a casual sense
<whitequark>
i don't think gtkwave calls it that
<whitequark>
i know pulseview literally uses mipmapping
electronic_eel has quit [Ping timeout: 240 seconds]
<d1b2>
<OmniTechnoMancer> too much aliasing with spreadsheets
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #nmigen
<lsneff>
Haha
lkcl has quit [Ping timeout: 256 seconds]
lkcl has joined #nmigen
samlittlewood has quit [Read error: Connection reset by peer]
samlittlewood has joined #nmigen
ming__ has quit [Quit: Connection closed for inactivity]
DaKnig has quit [Ping timeout: 256 seconds]
DaKnig has joined #nmigen
DaKnig has joined #nmigen
lkcl has quit [Ping timeout: 256 seconds]
mogery has joined #nmigen
<mogery>
hey, i'm working on a board definition for an RZ EasyFPGA A2.2 board i found on aliexpress. it uses the Cyclone IV, but i've actually found something odd in the board design itself.
<mogery>
unlike other boards which i've seen definitions for, this one only has 1 pin for each VGA channel.
<mogery>
the pins are connected to a 1K resistor, and then sent to the VGA connector. IIRC the resistance on the display's side is 75 ohms. with some napkin math, that's about 0.23V when voltage divided from 3.3V
<mogery>
doesn't that mean that the signal will be very dim?
<mogery>
err, not the signal, the image.
lkcl has joined #nmigen
<whitequark>
that sounds about right
<mogery>
alright
mogery has quit [Read error: Connection reset by peer]
mogery has joined #nmigen
emeb has joined #nmigen
jeanthom has joined #nmigen
<mogery>
is there any way i can set the clock speed from 50MHz to 40MHz in a module? trying to do VGA things
<Sarayan>
from as in variable?
<mogery>
wdym?
<mogery>
50MHz as in that's the clock that my FPGA dev board provides
<mogery>
am i able to set that to be lower? or is it a fixed rate
<Sarayan>
a fpll can give you 40 easily
<vup>
for c
<vup>
for cyclone IV you need to use a altpll I think
<mogery>
ty ty, i'll try to put something together
<vup>
you can set attribute "$NAME" of an instance using the `a_$NAME=...` argument of Instance and connect inputs and outputs using the `i_$NAME=...` and `o_$NAME=...` arguments of Instance
<Degi>
How can I divide a two's complement number by 2^n? Can I just do x >> n?
<Degi>
(Where x = Signal(signed(16))
<d1b2>
<geo> you want an arithmetic right shift to preserve the sign
<Sarayan>
is n variable?
<d1b2>
<geo> (for an arithmetic right shift you do a standard logic right shift, then fill in the vacant bits on the left with copies of the sign (MSB) bit from the original number)
<mogery>
what do the p_$NAMEs do?
<Degi>
geo: For n = 8, could I do Mux(i[15], i[:-1] >> 8 | 0b1111111100000000, i[:-1] >> 8)?
<vup>
mogery: it sets parameters
<mogery>
oh right
<vup>
ie what is done in verilog using `defparam` or the `module_name #(.$NAME=...) instance_name (.ports=...)`
<mogery>
so all the altpll_component.<> stuff under defparam, i should put that with p_ right?
<mogery>
like if i had altpll_component.foo = "BAR"; i would put p_foo = "BAR"?
<d1b2>
<geo> degi: yeah that should work
<vup>
mogery: yes
<vup>
(I think the example in the user guide is wrong, it should use PLL_1.<>, not altpll_component.<>)
<mogery>
oh, so the way i'd do 40MHz is i'd set clk0_divide_by to 5 and then set clk0_multiply_by to 4?
<mogery>
(5 bc inclk0 is 50mhz)
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #nmigen
<vup>
maybe, usually the PLLs have some constraints on the internal frequency, so 10 MHz might be below the supported range there
<Degi>
Usually there is a third parameter to increase the internal PLL clock
<vup>
you probably need to multiply the divisor and multiplication factor by 16 or so to be in the valid range for the PLL internal oscillator
<mogery>
p_clk0_multiply_by = 64 ?
<mogery>
sooo p_clk0_divide_by = 80,
<vup>
yep I think so
<mogery>
oh, and: after that code, will things in m.d.sync occur at 40MHz? or do i need to change that?
<mogery>
should it be m.d.cd_sync instead?
<vup>
no m.d.sync will use the default clock (if the platform specifies one)
<vup>
Ah no sorry I misread, m.d.sync should indeed be a 40MHz clock with that
<mogery>
oh cool!
<mogery>
alright, time to plug in my monitor :D
<mogery>
hopefully things won't explode
<mogery>
Error (176310): Can't place multiple pins assigned to pin location Pin_101 (IOPAD_X34_Y18_N21)
<mogery>
hmmmm
<vup>
typo in the board file?
<mogery>
might be..
<mogery>
apparently not, this board might be absolute garbage though
<mogery>
according to it's docs, hsync is on pin 101
<mogery>
but quartus says: Info (169125): Pin ~ALTERA_nCEO~ is reserved at location 101
<mogery>
oh. need to set device and pin options apparently
<mogery>
aaand quartus is just not responding
<vup>
I think you want `set_global_assignment CYCLONEIV_RESERVE_NCEO_AFTER_CONFIGURATION "USE AS REGULAR IO"` in the qsf file
<mogery>
exactly
<mogery>
can i mess with the qsf file in nmigen?
<vup>
unfortunately I don't think so
<vup>
whitequark: Lofty: ^
<asu>
[20:16] <vup> Ah no sorry I misread, m.d.sync should indeed be a 40MHz clock with that
<asu>
is that so? i'm reading that the output clock of the pll is cd_sync.clk, wouldn't m.d.sync be unaffected?
<vup>
asu: yes, the name for a ClockDomain is either the name supplied as constructor argument or infered from the variable name, stripping any `cd_` prefix
<asu>
oooh i see
<mogery>
i gotta get used to how magical python is
<vup>
so its name is "sync" and adding it to `m.domains` makes `m.d.sync` use it, `cd_sync.clk` is simply the associated clock signal and then drives that clockdomain (its equivalent in that aspect to `ClockSignal("sync")`)
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #nmigen
<mogery>
<vup> unfortunately I don't think so
<mogery>
is it bad if i just clone nmigen and add the line into vendor/intel.py
<whitequark>
vendor/intel should have overrides, like vendor/ecp5 does
<mogery>
vup: it was actually set_global_assignment -name CYCLONEII_RESERVE_NCEO_AFTER_CONFIGURATION "USE AS REGULAR IO"
<mogery>
can i change that via command line options in quartus_map?
<vup>
no clue, I have not use anything else than cyclone v and even that not really
<vup>
I think a PR adding a way for users to add commands to the qsf file like the other vendors (xilinx/lattice) do would be readily accepted though :)
<mogery>
hmm, i don't think my monitor liked that VGA signal
emeb_mac has joined #nmigen
<mogery>
and now the output of the iGPU isn't even coming on
<mogery>
brb rebooting
mogery has quit [Read error: Connection reset by peer]
mogery has joined #nmigen
<mogery>
ye olde power cycle did the trick
<mogery>
just gotta get good @ vga
<mogery>
re PR: i'm not sure where one would configure that? maybe in platform.build?
<whitequark>
moment
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/Jk1ji
<Lofty>
Long-term I want to just take vendor/intel.py and specialise it for each architecture
<Lofty>
Because I'm kinda concerned that adding things to the QSF for all devices is going to end up with a rule that's valid for one device being invalid for another
<whitequark>
mogery: what's nCEO?
<whitequark>
Lofty: yep, sounds reasonable to me
d1b22 has joined #nmigen
d1b2 has quit [Read error: Connection reset by peer]
d1b22 is now known as d1b2
<mogery>
nCEO is chip-enable-out. used for cascading multiple cyclone FPGAs. the board uses the nCEO pin as a VGA pin, no idea why. but because of that, nCEO must not be reserved for the build to be successful if VGA is used.
<whitequark>
so its default function is never useful, right?
<Lofty>
It's theoretically but not practically useful
<vup>
not on that board atleast
<mogery>
yup, not on that board.
<Lofty>
There's a bunch of other pins which are similar "must be enabled in QSF" I think.
<Lofty>
But I mean: not sure if they're portable across families.
<vup>
well I would argue this option should just be part of the board file, it is never useful in its default function on that board, but it could theoretically be useful on other boards, so vendor/intel.py should not do it (atleast on by default)
<_whitenotifier-f>
[nmigen-boards] whitequark commented on issue #122: Defining adv7513 resource for a new board with subsignals different from DE10-Nano - https://git.io/JkMfK
<_whitenotifier-f>
[nmigen-boards] whitequark closed issue #122: Defining adv7513 resource for a new board with subsignals different from DE10-Nano - https://git.io/JksBo
<_whitenotifier-f>
[nmigen-boards] whitequark commented on issue #122: Defining adv7513 resource for a new board with subsignals different from DE10-Nano - https://git.io/JkMf7
<_whitenotifier-f>
[nmigen-boards] whitequark commented on issue #108: ULX3S IO is screwy - https://git.io/JkMfh
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JkMsF
<_whitenotifier-f>
[nmigen/nmigen] whitequark 59ef6e6 - build.plat: make `verbose` work like all other overrides.
<_whitenotifier-f>
[nmigen] whitequark closed issue #497: Inconsistent behavior with "verbose" override vs others - https://git.io/JUlxw
<_whitenotifier-f>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JkMsp
<_whitenotifier-f>
[nmigen/nmigen] whitequark ac5ccf9 - Deploying to gh-pages from @ 59ef6e6a1c4e389a41148554f2dd492328820ecd 🚀
<d1b2>
<dub_dub_11> I will get on that configurable clock change for the De4. I don't remember the details but it's possible that some of the alternate clocks don't have a fixed frequency, like they come from a PLL or whatever. I will see
<whitequark>
sounds good
<_whitenotifier-f>
[nmigen-boards] GuzTech commented on pull request #104: Add OLED connector to ulx3s.py - https://git.io/JkMGS
<_whitenotifier-f>
[nmigen-boards] GuzTech edited a comment on pull request #104: Add OLED connector to ulx3s.py - https://git.io/JkMGS
<_whitenotifier-f>
[nmigen] whitequark commented on issue #525: [RFC] Add InstanceResource to use Instance I/O as Platform I/O - https://git.io/JkMnb
<_whitenotifier-f>
[nmigen-boards] whitequark commented on issue #37: Option to factor out "clk" from "spi_flash" on Lattice ECP5 - https://git.io/JkMnp
<_whitenotifier-f>
[nmigen-boards] whitequark closed issue #37: Option to factor out "clk" from "spi_flash" on Lattice ECP5 - https://git.io/JkMnh