<d1b2>
<dub_dub_11> hmm the clock selection is either 100MHz, an external SMA input, or GCLKOUT. I guess in that case I pretty much have to leave it up to the user get the right frequency
<_whitenotifier-f>
[YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JkM4v
<lsneff>
vcd isn't a great format for fast parsing. whitequark: what do you think? Should I parse it into a different file format that I dump to disk, or into an in-memory structure?
<lsneff>
I'm not well-versed enough to know for sure how large these get
<whitequark>
oh sorry, i got distracted by nmigen-board PRs
<whitequark>
will give you a large vcd in a few minutes
<lsneff>
I can generate large ones, I'm just not sure what size these things generally top out at
<lsneff>
Have you ever seen a 10gig one, for instance?
<whitequark>
definitely
<lsneff>
Alright, dumping to temp file it is then
FFY00 has quit [Ping timeout: 260 seconds]
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
<_whitenotifier-f>
[nmigen] whitequark commented on issue #525: [RFC] Add InstanceResource to use Instance I/O as Platform I/O - https://git.io/JkMg3
FFY00 has joined #nmigen
<_whitenotifier-f>
[nmigen] whitequark edited a comment on issue #525: [RFC] Add InstanceResource to use Instance I/O as Platform I/O - https://git.io/JkMg3
<_whitenotifier-f>
[nmigen] whitequark edited a comment on issue #525: [RFC] Add InstanceResource to use Instance I/O as Platform I/O - https://git.io/JkMg3
<whitequark>
Lofty: enjoy
<Lofty>
whitequark: I instantly regret making that joke
<_whitenotifier-f>
[nmigen-boards] rroohhh commented on issue #128: [RFC] Testing and releasing nmigen-boards - https://git.io/JkDra
<_whitenotifier-f>
[nmigen-boards] whitequark commented on issue #128: [RFC] Testing and releasing nmigen-boards - https://git.io/JkDrX
<vup>
whitequark: what do you think about making the `Attrs` stuff in nmigen-boards a bit more structured? Like for example vendor code exposing the available iostandards as constants to be used in the boards.
<_whitenotifier-f>
[nmigen] rroohhh commented on issue #525: [RFC] Add InstanceResource to use Instance I/O as Platform I/O - https://git.io/JkD6O
<whitequark>
vup: that was the original plan but... it's very laborous
<whitequark>
if you want to attack it, i suggest you open an issue with the schemas
<whitequark>
once we have the schemas we'll figure out some way to integrate them
<mogery>
with that to work properly in intel i'm fairly sure you'd have to split up the intel.py per-series
<mogery>
(or you can put everything in there with notes about which platforms it works on, but i'm not sure that that'd be amazing)
<vup>
whitequark: I see, currently I am pretty busy with other stuff, but I will keep it in mind
<vup>
mogery: there are a bunch of unresolved questions around that I think
<vup>
for example on 7series the valid iostandards depend on the io band you are using (there are two main types HP and HR io banks)
<mogery>
yeah...
<mogery>
it might not be possible for all the series
<mogery>
but imo it's better than chucking all of them in one
<vup>
s/band/bank
<mogery>
although that might be the least laborous option
<vup>
a single fpga can have both types of io bank
<whitequark>
even a conservative schema is better than nothing
<whitequark>
(ie overly accepting)
<mogery>
true true
<vup>
yep
<mogery>
"vendor code exposing the available iostandards" how would you imagine that? like an enum-esque thing?
<vup>
something like that
<vup>
also I think it would just be helpful when writing the board definitions, because you could hopefully rely on your IDEs autocompletion to figure out the correct iostandard and not have to lookup the exact spelling for one vendor
<Sarayan>
Ohhhhhh nice page, I need that page
<mogery>
yeah that'd be great
<mogery>
i think that'd be done with pydoc
<mogery>
not sure though
<vup>
mogery: I *think* IDEs can handle enums just fine
<vup>
and yes very nice page :)
<mogery>
yeah
<mogery>
i was thinking of something more like: you type io_standard=" and then your IDE starts listing the possible options as strings
<mogery>
i know you can do that in JS, but idk about python
<vup>
ah
<vup>
not sure if there is widespread support for something like that in python
<mogery>
you could probably do it with docstrings
<mogery>
let me play around a bit
<mogery>
oh. vscode can show the docstring but it can't autocomplete for variables
<mogery>
probably best and most compatible would be enums
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
<mogery>
is there an easy way i can expand something like 0b11 into 0b1000, 0b10 into 0b0100, etc.?
<mogery>
other than m.If
<whitequark>
1 << n?
<mogery>
:facepalm:
<mogery>
ty
<mogery>
should've known that lol
<_whitenotifier-f>
[nmigen] whitequark commented on issue #525: [RFC] Add InstanceResource to use Instance I/O as Platform I/O - https://git.io/JkyvG
<mogery>
is there any way i can index value with a signal?
<mogery>
oh, this is more complicated than i thought
<whitequark>
indeed
<whitequark>
a lot of things in FPGAs are :)
<mogery>
oh also
<mogery>
"clkn_divide_by (integer) Must be greater than 0, *less than 256*
<mogery>
" is not correct on Cyclone IV at least. p_clk0_divide_by = 25000 is working just fine for me
<mogery>
why did that line split lol
lkcl has joined #nmigen
<vup>
wait really? are you sure?
<mogery>
yes
<mogery>
looking for the upper limit right now
<mogery>
42000 works
<mogery>
clkn_divide_by goes up to 42500
<mogery>
anything higher than 42500 errors out
<vup>
hmm CYIV-51005-2.4 is pretty clear about the the dividers only going up to 512 (or 256 in some cases)
<vup>
are you sure quartus is actually using 42500 for the divider and not reworking the configuration using a smaller multiplier and thus a smaller divider?
<mogery>
clkn_multiply_by also goes up to 42500
<mogery>
wait no it just built with 42501 what
<mogery>
vup: i have no idea
<mogery>
it might be reworking them.
<vup>
you don't have a frequency counter handy by any chance? :)
<mogery>
nope :(
<mogery>
i wish lol
<mogery>
the way 42500 worked was: p_clk0_divide_by = 42501, p_clk0_multiply_by = 1
<vup>
hmm
<vup>
interesting
<mogery>
err, p_clk0_divide_by = 42500
<vup>
ah
<mogery>
the frequency sounded right by buzzer+ear
<mogery>
but that's not a very credible measurement :D
<vup>
there are two divider is the path, so it is probably combining a division by 250 with one by 170 to get 42500
<mogery>
oh yes, probably
<mogery>
but shouldn't then 65025 also work?
<vup>
maybe
<mogery>
it did not
<vup>
it still has limits on the VCO frequency, maybe it can't meet them in that configuration
<vup>
does quartus give you any information about the error?
<mogery>
Error (15538): Can't implement PLL "buzz:buzz|altpll:pll|altpll_c5m:auto_generated|pll1" as Cyclone IV E PLL type File: D:/Projects/FPGA/playground/rzefpga_test/build/db/altpll_c5m.tdf Line: 28
<mogery>
Error (15094): Can't implement PLL because Post divider maximum count value exceeded. (Reduce division value or Fin frequency)
<mogery>
Error (15093): Can't implement clock multiplication and clock division parameter values for PLL "buzz:buzz|altpll:pll|altpll_c5m:auto_generated|pll1" File: D:/Projects/FPGA/playground/rzefpga_test/build/db/altpll_c5m.tdf Line: 28
<mogery>
Warning (15559): Can't achieve requested value multiplication of 1 for clock output buzz:buzz|altpll:pll|altpll_c5m:auto_generated|clk[0] of parameter multiplication factor -- achieved value of multiplication of 3 File: D:/Projects/FPGA/playground/rzefpga_test/build/db/altpll_c5m.tdf Line: 28
<mogery>
Warning (15559): Can't achieve requested value division of 65025 for clock output buzz:buzz|altpll:pll|altpll_c5m:auto_generated|clk[0] of parameter division factor -- achieved value of division of 256 File: D:/Projects/FPGA/playground/rzefpga_test/build/db/altpll_c5m.tdf Line: 28
<mogery>
and then Error: Quartus Prime Fitter was unsuccessful. 3 errors, 3 warnings
<mogery>
so it seems to be doing some magic
<vup>
yeah
<vup>
I guess the easy way to check would be to specify the internal division values directly instead of these
<vup>
oh and it can also cascade the counters
<mogery>
btw: the nMigen GitHub page says that it supports the Xilinx 7-series chips. does this mean that zynq-7000 series SoCs will also work?
<vup>
yes
<mogery>
nice
<vup>
somehow the architecture of the cyclone IV pll is even more complex than the 7series one, atleast the cyclone IV doesn't require any magic calibration values (or I have not found the configuration for them yet :)
<mogery>
heh
<whitequark>
basically anything that vivado understands can be used with nmigen
<whitequark>
i *think* you might hit some missing primitives with ultrascale+?
<mogery>
w o w ultrascale+ costs a lot
<whitequark>
yeah
<whitequark>
and from what i've heard, it's not even particularly good
<whitequark>
large/fast, yes. good, no
<mogery>
what is the main purpose of having an FPGA and a processor connected together?
<mogery>
like i'm not really sure what actual benefit it gives
<whitequark>
in general or in case of zynq specifically?
<mogery>
in general
<whitequark>
well, a hard CPU is faster, takes less area/power, and you don't have to synthesize it
<whitequark>
ironically, zynq's cpu<>fabric bridge is so inefficient, that you can synthesize a far slower CPU and still get ahead in performance because you now have 1-cycle transfers into fabric
<mogery>
haha
<whitequark>
some people also flip them around
<whitequark>
they buy a cpu with a bonus fpga
<mogery>
yeah
<mogery>
like the parts of zynq are fairly useful seperately
<d1b2>
<OmniTechnoMancer> I assume the Zynq is not optimised for low latency interaction with the fabric
<whitequark>
basically yes
<mogery>
an A9 processor is pretty useful, a 28k logic cell FPGA is pretty useful
<whitequark>
but people tend to find that out the hard way
<d1b2>
<OmniTechnoMancer> but does have quite high throughput for memory?
<whitequark>
it really depends on what you want to use that fabric for
<mogery>
but, when you put them together, other than a semi-decent video output or a PCIe device, not sure what use case it'd be really good for
<whitequark>
at a previous job i was working on a system that had to schedule events with sub-ns precision
<mogery>
wow. that's fast
<d1b2>
<OmniTechnoMancer> I think they keep trying to sell UltraScale+ as wifi hardware or something
<whitequark>
1/8 ns i think?
<whitequark>
eventually i think people figured out how to use zynq for that
<whitequark>
OmniTechnoMancer: in the booklet i think they say "over the horizon radar" and thats it
<mogery>
i'm looking at zynq because i found a devboard on aliexpress that has a zynq 7010 for like 10$ and it has more logic than the current FPGA i have
<d1b2>
<OmniTechnoMancer> ah, or maybe its just all the "wireless" in their emails i am interpreting
<whitequark>
maybe also like 5g prototyping
<whitequark>
it costs *far* too much for most sane applications
<mogery>
oh yes, they're pushing 5G pretty hard
<d1b2>
<OmniTechnoMancer> a 7020 is somewhat larger if you can find one for not much more cost
<mogery>
found a 7020 for 110$ but that's a bit more than i'm comfortable to spend on aliexpress
<d1b2>
<OmniTechnoMancer> also in typical style has somewhat sparse docs so perhaps not the best to start with
<mogery>
ooh, ethernet
<mogery>
that IO is quite tiny though
<mogery>
hmm
<mogery>
can i use my altera usb blaster as a general JTAG programmer for other FPGAs?
<mogery>
"However, the TANG Hex still routes its four USB ports and the Ethernet port to the Zynq via the same SMSC USB3320 hi-speed USB 2.0 ULPI transceiver"
<mogery>
true rpi style
<d1b2>
<DX-MON> if you want to have proper networking, more IO, etc.. you might also want to consider the Parallella if they're still available
<d1b2>
<DX-MON> (assuming you want a Zynq board)
<mogery>
i'll keep it in mind
<mogery>
dang, that has a whole another SOC on there
<trabucayre>
mogery: I use an altera usb blaster with ECP5 and artix
<mogery>
nice, ty
<d1b2>
<DX-MON> yeah, the Epiphany for when you need lots of small RISC cores chewing on a thing (designed with neural nets in mind but applicable to other things too)
<trabucayre>
just keep in mind to connect BOTH gnd pins...
<d1b2>
<OmniTechnoMancer> Oh yea the ethernet doesn't use the gigabit on the zynq on that board I forgot
<d1b2>
<OmniTechnoMancer> Parallella is interesting, I need to actually use mine :/
<whitequark>
mogery: usb blaster has bitbang mode so you can use it to jtag just about anything (slowly)
<whitequark>
actually wait, it *only* does bitbang
<_whitenotifier-f>
[nmigen-boards] whitequark commented on pull request #104: Add OLED connector to ulx3s.py - https://git.io/JkSef
<_whitenotifier-f>
[nmigen-boards] whitequark opened issue #129: Add `_n` suffix to names of pins with fixed inverter in resource factories - https://git.io/JkSeW
<_whitenotifier-f>
[nmigen-boards] GuzTech opened pull request #130: Change signal names to match polarity - https://git.io/JkSUQ
<_whitenotifier-f>
[nmigen-boards] GuzTech closed pull request #130: Change signal names to match polarity - https://git.io/JkSUQ
<_whitenotifier-f>
[nmigen-boards] GuzTech opened pull request #131: Change signal names to match polarity - https://git.io/JkSkk
<_whitenotifier-f>
[nmigen-boards] whitequark commented on pull request #131: Change signal names to match polarity - https://git.io/JkSkw
<_whitenotifier-f>
[nmigen-boards] GuzTech commented on pull request #131: Change signal names to match polarity - https://git.io/JkSkb
<_whitenotifier-f>
[nmigen-boards] whitequark commented on pull request #131: Change signal names to match polarity - https://git.io/JkSIZ
<_whitenotifier-f>
[nmigen-boards] GuzTech commented on pull request #131: Change signal names to match polarity - https://git.io/JkSIa
<_whitenotifier-f>
[nmigen-boards] whitequark commented on pull request #131: Change signal names to match polarity - https://git.io/JkSLe
jeanthom has quit [Ping timeout: 240 seconds]
<_whitenotifier-f>
[nmigen-boards] GuzTech opened pull request #132: Change Resource function parameter names to reflect polarity - https://git.io/JkSqU
<_whitenotifier-f>
[nmigen-boards] GuzTech closed pull request #131: Change signal names to match polarity - https://git.io/JkSkk
<mithro>
whitequark: Are you interested in evolving the nmigen platform boards to be usable to generate things like nice diagrams and stuff like virtual visual boards (for things like Renode / Verilator)? One of the things we where doing in the timvideos/litex-buildenv was to provide things like how to "locate" a given connector on a board (and any extra requirements like jumpers being set). Like I could imagine if you had a KiCad
<mithro>
PCB for the hardware you could even potentially go as far as doing a KiCad HTML BOM type thing which is directly interfaced to your RTL (no more trying to figure out which jumper pins to connect your USB UART too?). Would also be super easy to feed the LED output from Verilator to an LED on a picture and have it blink....
<whitequark>
mithro: in principle: yes, i think we can do that, or at least try to do that and see if it works out nicely
<whitequark>
in practice: i would like to start small, like having URLs and descriptions for every board