<podrian>
Hello! Relatively new to Verilog... I have a design which makes use of `generate` blocks (they are named), and Yosys's write_verilog() is elaborating with names along the lines of `mod_type \genblk[0] (ports)`, I suspect the backslash is escaping the brackets, but it appears that neither iverilog nor verilator know how to handle a module with
<podrian>
brackets in its name (i'm driving everything with cocotb, so I guess it could be a cocotb thing).
<podrian>
Is there a way to modify the way the generate block module names are instantiated to something like `genblk_0_` rather than `\genblk[0]` ???
podrian has left #yosys [#yosys]
podrian has joined #yosys
podrian has left #yosys [#yosys]
podrian90 has joined #yosys
podrian90 is now known as podrian
podrian has quit [Remote host closed the connection]
podrian has joined #yosys
<podrian>
I guess it's actually something more like `\genblk[0].module(ports)` but I think it should be clear anyway :)
fakedad has joined #yosys
podrian has quit [Remote host closed the connection]
Degi_ has joined #yosys
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
srk has quit [Ping timeout: 240 seconds]
srk has joined #yosys
citypw has joined #yosys
srk has quit [Remote host closed the connection]
srk has joined #yosys
az0re has quit [Remote host closed the connection]
az0re has joined #yosys
vidbina has joined #yosys
emeb_mac has quit [Quit: Leaving.]
awordnot has quit [Ping timeout: 265 seconds]
awordnot has joined #yosys
m4ssi has joined #yosys
vidbina has quit [Ping timeout: 260 seconds]
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined #yosys
xtro has quit [Ping timeout: 256 seconds]
kristianpaul has quit [Ping timeout: 272 seconds]
kristianpaul has joined #yosys
jakobwenzel has joined #yosys
peepsalot has quit [Read error: Connection reset by peer]
peepsalot has joined #yosys
aep has joined #yosys
<aep>
how would i figure out how pins are named in nextpnr? is there a human readable list?
<daveshah>
what do you mean? what pins?
<aep>
the pin names you assign in pins.cnf .
<daveshah>
cnf?
<daveshah>
I'm afraid I need a bit more context, I'm not even sure what a cnf file is
<aep>
err pcf, sorry
<aep>
i'm trying to port some hello world to a 40up5k board, but none of the pins exist
<aep>
nextpnr-ice40 --up5k --package sg48 --freq 20 --json top.json --pcf pins.pcf --asc top.asc ==> ERROR: package does not have a pin named '8A' (on line 1)
<daveshah>
the pins are the package pin numbers, not the board pin numbers
<aep>
right, where would i find them to guess what they're named?
<aep>
i tried pretty much all the name formats in the datasheet
<daveshah>
it's the physical, QFN48, pin number
<aep>
this is probably obvious to someone who has used the propriatary tools, but i never did
<aep>
allright, next problem is i have never used lattice diamond, so im not familiar with the specific macros. like, i dunno what SB_PLL40_CORE is but nextpnr tells me to use a PAD PLL instead for which i also dont know the macro
<aep>
is there a document i could read that contains this stuff without going through the whole propriatary thing?
<aep>
lattice docs just say i should look in the ominous "iCE Technology Library" which is probably inside diamond?
<aep>
yeah just found the pdf and it contains exactly what i need to know. sorry for the noise D:
jakobwenzel has quit [Quit: jakobwenzel]
elGamal has quit [Ping timeout: 256 seconds]
kristianpaul has quit [Ping timeout: 256 seconds]
kristianpaul has joined #yosys
vidbina_ has joined #yosys
vidbina has quit [Ping timeout: 256 seconds]
<dkozel>
daveshah: Were you working with an Alveo 250?
<daveshah>
I was, although I haven't had time for that recently
<dkozel>
Ok, it's looking like we might be able to host one with a Xilinx license on a public server if that would be helpful to anyone
<dkozel>
Anything that we can do to help improve FOSS support, I'd be interested in hearing.
<daveshah>
I can't really think of anything that's going to be particularly practical there, tbh
<daveshah>
working on IP is probably going to be more useful right now
<dkozel>
For signals DSP, that's happening. What IP are you thinking of?
<fakedad>
Hi, do either of you have any tips regarding how to change the naming of `generate` block arrays?
fakedad has left #yosys ["User left"]
maartenBE has quit [Ping timeout: 256 seconds]
maartenBE has joined #yosys
<aep>
hm, im failing at doing the PLL correctly. documentation says "It is strongly recommended that the configuration of the PLL primitives be accomplished through the use of the PLL Configuration tool that is offered as part of the iCEcube2 software."
<aep>
is there an open source alternative?
emeb has joined #yosys
jakobwenzel has joined #yosys
<daveshah>
yes, icepll
<aep>
oh nice, thanks
<aep>
hah that actually worked out of the box. this stuff is NICE
<aep>
i mean, its clear which clock fails, but not where.
<daveshah>
it looks like you have a path via uart.usb_fs_pe_inst.usb_fs_out_pe_inst.ep_put_addr[0]; uart.usb_fs_pe_inst.usb_fs_out_pe_inst.ep_get_addr[0]; uart.ctrl_ep_inst.detect_pkt_end; uart.usb_uart_bridge_ep_inst.get_out_data etc
<aep>
thats not actually my stuff, and it works fine when i remove all of my code
<daveshah>
the critical path looks to be entirely within the usb core
<aep>
yeah that's what confuses me
<daveshah>
it's possible that your code is making things more congested so putting more pressure on stuff overall, or it's just random
<aep>
am i reading the error message correctly that the whole design is clocking at 18Mhz?
<aep>
ERROR: Max frequency for clock 'clk_48mhz_$glb_clk': 18.00 MHz (FAIL at 20.00 MHz)
<daveshah>
Yes
<aep>
thats extremly slow for a 48Mhz clock D:
<daveshah>
if you look at the bottom, you can see only a very small proportion of paths are failing (negative in the histogram)
<aep>
i probably did some noob mistake that made a bad layout or something
<daveshah>
you can't do all that much in 48MHz on an iCE40UP5K, tbf
m4ssi has quit [Remote host closed the connection]
<aep>
i dunno, i guess i could just yolo in a higher clock, but i'm trying to learn here
<aep>
actually, i can't? a higher clock doesnt fix it. does that mean it's something not on the clock path?
vidbina_ has quit [Ping timeout: 260 seconds]
<daveshah>
A _lower_ clock (below ~18MHz in this case) 'fixes' a timing failure
<daveshah>
Not a higher one
cr1901_modern has quit [Ping timeout: 260 seconds]
jakobwenzel has quit [Ping timeout: 244 seconds]
elGamal has joined #yosys
cr1901_modern has joined #yosys
<aep>
errr, i think i dont understand what clocks this is reffering to. there's a pll and there's the thing you pass to --freq
<aep>
i _think_ the --freq argument is actually what its checking against, and obviously lowering that will make it pass, but that's kinda bad because i need to hit some timings for usb
<aep>
nut nothing i do with the pll seems to have any influence on the histogram
<daveshah>
yeah nextpnr-ice40 doesn't derive PLL timing constraints yet (mainly because with some of the stranger modes it's surprisingly hard to get right)
<daveshah>
to your PCF file, add `set_frequency clk_48mhz 48`
<aep>
ah nice! now the output makes more sense. still failing to understand why my code wont pass tho
<daveshah>
is this usb core designed for the up5k?
<daveshah>
the critical path makes me think it probably isn't; it looks a long way away from reaching 48MHz
<aep>
no.didnt find any. this is for the lp8k
<aep>
isnt the LP slower than the UP?
<daveshah>
then tbh it probably isn't going to have a short enough critical path to pass timing on the up5k
<daveshah>
no, the UP is significantly slower
<aep>
ooooh
<aep>
funny. i bought into the marketing of "low power" versus "ultra"
<daveshah>
at the bottom is 'Info: 22.5 ns logic, 33.0 ns routing'
<aep>
oooh
<daveshah>
in this case you've blown out your 48MHz budget just on logic, with nothing at all left for routing (which is often more delay than logic particularly for larger designs)
<aep>
yeah i think i can live with 20Mhz
<daveshah>
the USB core is probably designed to run at 48MHz only
<aep>
this is helpful now that i understand. bit confusing output
<aep>
uuh yeah but how would it ever run at 48Mhz if the PLL is 48 and it does a bunch of stuff on clock
<daveshah>
FPGA clocks are fixed by the PLL frequency - if the PLL is set to 48MHz then it is running at 48MHz
<daveshah>
if it fails timing, then it might not work reliably - FPGA timing models are very conservative at room temperature, but you might start seeing failures if it warms up
<cr1901_modern>
Just run it and increase the frequency until it stops working. Then dial the frequency back by 20% :) (don't actually do this)
<aep>
yeah, i was just wondering what you mean by 'designed to run at 48MHz only'.
<aep>
the original makefile specified --freq 20 ... so it never validated at 48?
<daveshah>
the core is designed to run at 48MHz because it oversamples the 12MHz USB rate by x4
<aep>
ah yes
<daveshah>
no, they were probably just relying on the fact that it failed timing but still worked even on the lp
kristianpaul has joined #yosys
<aep>
thats how i got confused. it was never valid lol
<daveshah>
unless their PLL was actually set up to run at 20MHz, but that's a very unlikely frequency for a USB FS core which invariably pick integer multiples of 12MHz
<aep>
nope. was at 48
<aep>
which makes sense
<aep>
i guess i just need to find a different fpga that can actually do this
<daveshah>
tbf, it probably would have got a lot closer to 48 on a lp and been a lot less marginal
<aep>
right
<daveshah>
it's definitely possible to do USB on a up5k
<aep>
how would i know btw? experience or can you actually know this from the spec?
<daveshah>
the trick is to do the fast part in the 48MHz domain and the rest in a 12MHz or 24MHz domain
<daveshah>
I know because people have done it (e.g. fomu, icebreaker-bitsy)
<aep>
uuh by domain you mean a different clock? this thing only has one
<aep>
oh right, i should look at fomu
<daveshah>
there are various ways of getting multiple clocks from the PLL
<daveshah>
you can either output clock and clock/2; or clock and input clock mirrored
<cr1901_modern>
daveshah: Uhh, without thinking about it too much, why does "input clock mirrored" work to improve timing closure?
<aep>
the ice40 b evb (the black one)
<daveshah>
cr1901_modern: it's to do with the routing limitations of the iCE40 (can't use a dedicated PLL pin as a general input), not timing
<daveshah>
aep: should be fine, it's only the early upduinos that have broken PLL circuitry
<cr1901_modern>
hmmm
<aep>
yeah the weird core i found works perfectly despite failing timings
<aep>
i'll try no2fpga again. maybe i just didnt use it correctly (since there are no docs)
<daveshah>
I know from past experiences of people trying to get the old tinyfpga bootloader working on the up5k (which was fine on a lp8k but also failed timing badly on the up5k) it worked on some boards but not others
<daveshah>
because of process variations between the chips, slight vcc differences between regulators, etc
<aep>
yeah, i dont think i want to ship this with failing timings :D
<aep>
btw, since i'm asking a lot of dumb questions. does anyone know any learning material that specifically uses yosys?
<aep>
i'd totally pay for a course. but the ones i had usually just do a bunch of clicks in some gui and never explain anything
<aep>
oh neat
<daveshah>
as far as the more intricate side of timing analysis specific to nextpnr goes, I don't think there is a particularly good reference to that - but that is definitely something that can be improved
<daveshah>
the timing code in nextpnr is long overdue a substantial rewrite for better performance and functionality, so if you have any suggestions to presentation improvements, that would always be appreciated (and at some point I will do derived PLL constraints for ice40 which will make using them less confusing)
<aep>
oh yeah, it would very much helped if the "timing failed because this net takes 20ns" would be more obvious
<daveshah>
The problem is that for something like this, the failure is for a whole path rather than a single net
<aep>
hm yeah. i still have no idea where the problem is.
kristianpaul has quit [Read error: Connection reset by peer]