<swetland>
also turns out the cpu actually does work (at least the implemented bits), I had a typo in my test program so I was trying to write the address of screen memory into the character code rather than the other way 'round
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
unixb0y has quit [Ping timeout: 252 seconds]
unixb0y has joined ##openfpga
Maya-sama has joined ##openfpga
Miyu has quit [Ping timeout: 268 seconds]
Maya-sama has quit [Ping timeout: 252 seconds]
<TD-Linux>
do I need to make any board config changes to get the ecp5 evn demo working?
GenTooMan has quit [Quit: Leaving]
rk[genie] has joined ##openfpga
rohitksingh_work has joined ##openfpga
pie___ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
Bike has quit [Quit: sleep]
rk[genie] is now known as rk[ghost]
tavy has quit [Quit: WeeChat 2.2]
TavyCats has joined ##openfpga
azonenberg_work has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
luvpon has quit [Ping timeout: 250 seconds]
<daveshah>
TD-Linux: I don't think so
<daveshah>
I didn't write that demo. But I think it needs the button pushed to do anything for some reason
<TD-Linux>
yeah I tried pushing the button to no avail. it may have bitrotted or something, I'll try to figure it out
<SolraBizna>
is it more efficient to write constant all-ones to a register than it is to write some other non-zero constant?
<RaYmAn>
TD-Linux: it worked ok here. it needs USB connected to work though cause otherwise no clock
<TD-Linux>
yeah it uses the 21mhz ftdi clock right?
<RaYmAn>
12
<RaYmAn>
but yes
<TD-Linux>
also wow the built in demo program has a really long startup time. is that really the fastest it can load a config?
<RaYmAn>
yeah that confused me a bit too
<daveshah>
Maybe it is set with a low ish frequency
<daveshah>
You can configure that in the bitstream header
<RaYmAn>
I had to fix the openocd config to get it programming as my board want showing up with the expected ftdi decryption
<RaYmAn>
wasn't*
<daveshah>
There must be multiple variants
<TD-Linux>
okay I got it working with the leds set to a constant 01010101
<TD-Linux>
weird one LED is dimmer
<daveshah>
Just to double check is JP2 fitted?
<TD-Linux>
actually it's stuck on if I set it to 11111111
<TD-Linux>
yes it is
<TD-Linux>
my board also came with the dip switches set incorrectly for the stock program to work
<daveshah>
I'll try and look into this today
<daveshah>
Trellis is still very broken tbh
<TD-Linux>
that's why I got this board before starting a pcb design with it :)
<RaYmAn>
on the plus side, it's pretty easy to get the picorv32 example it comes with to work on the evn:)
<TD-Linux>
btw is there another board you're working with more (other than the tinyfpga ex which will be great when it's out)
<RaYmAn>
I haven't done anything serious, but trellis seems to work awesomely so far:) haven't even bothered downloading diamond
<daveshah>
No I'm fed up with the tinyfpga and given up with it
<daveshah>
All my testing has been on the Versa or ULX3S both with the 45k
<daveshah>
I do have an EVN and an 85k ULX3S but not used either much
<RaYmAn>
why is that?
<TD-Linux>
well the versa has better io
<daveshah>
I just haven't found the tinyfpga bootloader on the ecp5 reliable
<daveshah>
It fails to program reliably, and has bricked itself
<TD-Linux>
hopefully it will get better with time. the bx one is great
<TD-Linux>
the tinyfpga ecp5 bootloader is diamond based I assume
<daveshah>
Yes
<daveshah>
I'd go for a ft2232h jtag any day of the week anyway
<RaYmAn>
I guess size and cost makes that hard on a board like tinyfpga
<daveshah>
Indeed
<daveshah>
But for what I do I'd rather have more stuff onboard for Trellis testing anyway
<TD-Linux>
yeah not paying the ftdi tax is worth a lot
<RaYmAn>
aren't the JTAG pins brought out though?
<daveshah>
To a 1mm header that's a pain in its own right
<RaYmAn>
right
<daveshah>
Unfortunately I damaged my type C Ex prototype trying to unbrick it and haven't got round to fixing it yet
<TD-Linux>
for my first ice40 based board I just used a soic-8 clip for development :^)
<RaYmAn>
BTW, is it possibly to use the 200mhz differential clock on the evn with trellis? I ordered a 50mhz oscillator to fit that later, but it's annoying the board only works with USB attached until then
<daveshah>
Yes it should be fine
<RaYmAn>
cool
<daveshah>
The 100MHz diff clock on the Versa works fine for me
<daveshah>
Just do IO_TYPE=LVDS
<TD-Linux>
that 200mhz oscillator is the first one I've seen in a package like that, it is a hot new trend?
<RaYmAn>
ah, nice!
<daveshah>
If it's a mems one, keep it away from helium!
<SolraBizna>
lol
<daveshah>
TD-Linux: out of curiosity, can you go back to the broken EVN blinky design and send me the .config file? I have a thought about what the issue might be
<TD-Linux>
daveshah, sure
<TD-Linux>
also I think the pinouts might be wrong in the example
<TD-Linux>
e.g. ecp5 evaluation board says one of the LEDs is on A13 but that's not in the lpf file at all
<daveshah>
Yes, I can see that now
<daveshah>
It seemed I messed up when converting it to an LPF
<TD-Linux>
well, a simple issue to fix :) should I send a patch?
<daveshah>
Sure
<daveshah>
Would be curious if it worked with the pinout fixed
<TD-Linux>
yeah testing that now
<TD-Linux>
it doesn't, but the leds look correct now.
<TD-Linux>
now it behaves like no clock
<daveshah>
Can you try replacing the logic with a 28-ish bit counter, and the LEDs connected to the top 8 bits?
<TD-Linux>
oh that counts fine
<TD-Linux>
well
<TD-Linux>
it suddenly got stuck
<daveshah>
Hmm
<TD-Linux>
yeah it counts up to a certain value then freezes
<TD-Linux>
different value each time
<daveshah>
I'll look into it today
<TD-Linux>
oh usb suspend I bet
<TD-Linux>
unplugging and replugging usb makes it work for a bit agian
<daveshah>
The solution might be to use the 200MHz clock instead
<daveshah>
Pin Y19 and LVDS IO type
<TD-Linux>
daveshah, yeah okay the demo now works perfectly (including the button), I just wasn't fast enough before to push the button before usb suspends
<daveshah>
Ah I see
<daveshah>
Actually, Y19 is tricky because it's the serdes refclk which is a special case
<TD-Linux>
I see the versa board config has that already?
<TD-Linux>
oh it's P3 and not Y19 tho
<daveshah>
The Versa board also connects the clock to regular IO
<daveshah>
nextpnr at the moment only supports the serdes refclk when used with the serdes
<daveshah>
This is just a limitation of the way we place it
m4ssi has joined ##openfpga
GuzTech has joined ##openfpga
<RaYmAn>
at least they bothered to include a footprint for a 50Mhz (or whatever freq) oscilator :)
<tnt>
Can the placer move cells around if the packing step put a BEL aattribute on them ?
<daveshah>
No, it shouldn't do
<tnt>
Apparently it decided to do it anyway :p
<tnt>
My guess is somewhere this is 'forced' for global buffer because only some buffers can drive reset lines
<tnt>
and it needed 4 of them because it promoted 4 reset lines ... so it ripped up the one that was put there for th epll global out.
Dolu has joined ##openfpga
<daveshah>
It still shouldn't do that
<daveshah>
tbh we should be abandoning BEL attributes for the bel/belStrength fields of a cell either
<daveshah>
s/either/anyway
<daveshah>
Looks like the ripup part of the placer needs a check that belStrength is strong or less (it is set to user for Bels constrained by attribute)
<tnt>
RROR: failed to place cell '$gbuf_vga.vga0.startline_$glb_sr' of type 'SB_GB'
<tnt>
Yeah, now it does what I expect.
<tnt>
(fail to find a placement because it promoted too much stuff)
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<daveshah>
RaYmAn: jfyi, I've made a few changes to the example on master to remove a couple of obsolete workarounds (proper LPF instead of the manual IO buffers and a PLL instead of using registers to divide the clock)
<RaYmAn>
awesome! I'll try it out:)
Miyu has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
Bike is now known as Bicyclidine
genii has joined ##openfpga
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 244 seconds]
Flea86 has left ##openfpga [##openfpga]
<RaYmAn>
daveshah: works great on ECP5-EVN with some modifications :) Got it runnign with PLL multiplying up to 48 mhz and the uart outputting at ~115k (I modified my EVN for UART -> FTDI connection).
emily has joined ##openfpga
<RaYmAn>
I'm trying to figure out how to get hte PLL output onto a pin though. nextpnr asserts when doing the straightforward assign clkout = clk; where clkout is a random Pin. I guess it needs to be specific pins to do the output?
<daveshah>
No any pin can be a clock output
<daveshah>
I think this might just be the global router being a bit fussy.
<daveshah>
What is the assert? This is definitely a bug
<RaYmAn>
picking one of the GPLL inputs actually made it go further ,but moved it back now to get the assert
<RaYmAn>
terminate called after throwing an instance of 'nextpnr_ecp5::assertion_failure'
<RaYmAn>
what(): Assertion failure: no tile at (124, 4) with type PLL0_UR (/home/rayman/fpga/nextpnr/ecp5/arch.h:983)
<q3k>
RaYmAn: almost feels like i've seen this before - are you on a relatively new version of trellis&nextpnr?
<q3k>
i did get a PLL output to pin working via nextpnr a week or so ago
<RaYmAn>
q3k: yes, from today
<q3k>
ah then that's a bug
<q3k>
even a regression
<RaYmAn>
I wouldn't rule out me as an error source just yet either :) I have zero idea what I'm doing
<q3k>
can you submit an issue to nextpnr with a reproductible example?
<q3k>
regardless, failing with an assertion like this is fairly user hostile
<RaYmAn>
I'll try
fibmod has quit [Ping timeout: 245 seconds]
<daveshah>
RaYmAn: ah, I see
<daveshah>
will push fix in a sec. seems just like an off-by-one
<RaYmAn>
just when I got a minimal reproduction case ;)
<RaYmAn>
I got it working with outputting the input clock directly, just not when using the pll in-between
<daveshah>
Yeah. Just had the PLL tile coordinates off-by-one. Totally unrelated to design content
<daveshah>
Try pulling and rebuilding nextpnr?
<daveshah>
q3k: unrelated bug in the same bit of code
<RaYmAn>
works perfectly :)
<daveshah>
great
<daveshah>
happy to merge a PR once you're done
<daveshah>
with the evn soc
<RaYmAn>
cool
GuzTech has quit [Quit: Leaving]
shapr_ has quit [Changing host]
shapr_ has joined ##openfpga
shapr_ is now known as shapr
rohitksingh has joined ##openfpga
fibmod has joined ##openfpga
balrog has quit [Quit: Bye]
balrog has joined ##openfpga
<_whitenotifier>
[whitequark/Glasgow] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fpuEq
<_whitenotifier>
[whitequark/Glasgow] whitequark cb093eb - access: add name hints to generated TSTriples.
<_whitenotifier>
[whitequark/Glasgow] whitequark 7313098 - target.hardware: explicitly set clock constraint for sys_clk.
<swetland>
ah, refs/pull/n/head it's weird that the pull request page itself seems to have no indication of how to do this
<swetland>
thanks
<shapr>
swetland: worked?
<swetland>
yup
<shapr>
spiffy
<qu1j0t3>
swetland: yes i agreee
<swetland>
I found a help page but it suggested I click on the merge button to get commandline instructions, but since it's not my project / I don't have privs, there's no merge button to click on
<swetland>
people hate on gerrit a lot, but I have to say I prefer the submit/review workflow there massively.
<qu1j0t3>
^^^^^
<qu1j0t3>
PR's are not really code review
<swetland>
I think a main part of it (besides web ui differences) is there's no need to create your own personal project to push stuff to to then request pulls from -- you check out xyz, you make changes on a local branch, you push to refs/for/master and it goes into the review queue
<swetland>
also, I dunno if github supports this but you can do version-to-version diffs in gerrit, so if I give feedback on a CL and the author pushes a new version to address those changes it's really easy to see exactly what was changed
<mithro>
swetland: Github supports viewing a single commit in the PR interface
<daveshah>
Yeah, I've never had too big a problem with the Github PR interface either
<daveshah>
I would certainly much rather have Github over a linux style mailing list for example
<daveshah>
But I know this is one of those contentious topics :P
<swetland>
not a fan of review-in-email myself, either
<swetland>
side-by-side visual diff with ability to add commentary to any line is much nicer
<qu1j0t3>
daveshah: if you'd ever used Gerrit or Reviewboard it's clear they're not really comparable
<daveshah>
I did use Gerrit for work a few years ago
<daveshah>
Don't think its benefits outweigh the accessibility of Github for FOSS projects
<qu1j0t3>
:)
<qu1j0t3>
just depends what kind of review you actually need, i guess.
<qu1j0t3>
i'm sure most projects don't need something more sophisticated.
<qu1j0t3>
funny though that github hasn't recognised it as an enterprisey differentiator... or have they? do they have a $$ code review product?
<swetland>
that's the main downside of gerrit -- it's foss but somebody has to run an instance and I'm not aware of any free service doing that
<mithro>
PolyGerrit is a pretty big improvement over the old Gerrit interface
<qu1j0t3>
i didn't even mind the old interface... it's not like RB isn't clunky either lol, but they work
<swetland>
yeah it wasn't pretty but it got the job done.
<swetland>
but more back on topic, I'm trying to use --pre-pack to set clock constraints but I seem to be doing it wrong and not getting much feedback
<daveshah>
The current timing constraints system is pretty crude
<swetland>
Info: Max frequency for clock 'vga.vram.rclk': 33.43 MHz (PASS at 12.00 MHz)
<swetland>
Info: Max frequency for clock 'vga.vram_clk': 12.82 MHz (PASS at 12.00 MHz)
<swetland>
Info: Max frequency for clock 'spi_clk_$glb_clk': 59.84 MHz (PASS at 12.00 MHz)
<daveshah>
I do plan to add support for constraints on ports and PLL-derived constraints which will solve most of the problems
<swetland>
yeah, I'd just like to convince it that the desired freq for those are 25/12/6 respectively
<daveshah>
So the netnames to use for constraints would be `vga.vram.rclk`, `vga.vram_clk` and `spi_clk` (without the $glb)
<swetland>
ah yeah that would
<daveshah>
Be warned with the current placer and router they might not make much difference anyway
<swetland>
I'm curious why I can't use top.clk25m say (which is the net connected to the PLL GLOBALB that eventually hits vga.vram_clk)
<daveshah>
This is a Yosys issue
<swetland>
ah the nets get optimized around / renamed during synthesis?
<daveshah>
Yosys has *very* strange rules for picking which name to use for a net
<daveshah>
Then at that `top.clk25m` is something nextpnr just doesn't even see
<daveshah>
One solution going forward might be to use Verilog attributes for clock constraints, which Yosys will keep with the net
<swetland>
yeah I think that would make the most sense... otherwise the names of your clock nets could change with design changes (as I see happening here)
<daveshah>
I think putting (* keep *) on the top level nets might preserve the top level name
<swetland>
the world definitely needs a matrix of what verilog/sv features/attributes/etc are supported by what tools ^^
<daveshah>
Yosys' README is nice for Yosys itself at least
<daveshah>
Strangely it seems (* keep *) doesn't help here
<daveshah>
I guess "keep" just means don't optimise away, it doesn't prevent it being renamed
<swetland>
so even when a constraint seems to work:
<swetland>
Info: constraining clock net 'clk12m_in' to 12.00 MHz
<swetland>
python grumbles at the very end:
<swetland>
Traceback (most recent call last):
<swetland>
File "hdl/ice40.prepack.py", line 1, in <module>
<swetland>
ctx.addClock("clk12m_in", 12)
<daveshah>
Oops
<daveshah>
I think it prints the first message too early
<daveshah>
Lemme fix
<swetland>
ordering seems to make a difference
<swetland>
if I add ctx.addClock("spi_clk", 6) *before* that one
<swetland>
I get the message for both 6 and 12
<swetland>
but if it's after I get only 6
<swetland>
but yeah if the 12 is always failing but reporting success first that would explain it
<daveshah>
Fix pushed
<daveshah>
It will now print a warning if the constraint doesn't match a net in the design
<swetland>
Info: constraining clock net 'spi_clk' to 6.00 MHz
<swetland>
Warning: net 'top.clk12m' does not exist in design, ignoring clock constraint
<swetland>
Warning: net 'clk12m_in' does not exist in design, ignoring clock constraint
<swetland>
much nicer! thanks
<swetland>
nextpnr feature request: a total count of warnings issued printed just before the tool finishes (as otherwise it's easy to mess them in the full spew)
<swetland>
yay hdmi pmod boards back from fab at oshpark. gotta kick off a digikey order
<shapr>
whoa cool
<shapr>
where can I buy those?
<shapr>
swetland: are you brian? aka @dnaltews?
<swetland>
yes (dnaltews is my last name backwards -- sadly swetland@ was taken by somebody who tweeted once in 2009 and apparently never used the site again..)
<shapr>
"I remain convinced that if sufficient information were available on internals/layout/bitstreams/etc, we'd see a revolution in tooling like we did when gcc started displacing the (often terrible) vendor compilers in the 90s."
<swetland>
I worked on X/Mosaic in the mid-90s and remember having to build and test on 8+ different OSes with differently broken vendor compilers. It was a sad time.
<shapr>
I first got paid to write code in the 90s
<swetland>
I remember saving up to buy Turbo C 2.0 in high school ^^
<shapr>
I wasn't very good then, but I'm slightly better now.
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rohitksingh has quit [Ping timeout: 272 seconds]
jevinskie has joined ##openfpga
<fseidel>
wow, that's really cool
<fseidel>
seems super useful
<whitequark>
swetland: holy shit, i had no idea
<whitequark>
i wrote a horrible hack for migen to display symbolic FSM state names..
<azonenberg_work>
whitequark: What would be nice is a parsing step or yosys pass
<azonenberg_work>
that converts sv enum names to those filter files and auto-configures gtkwave for the signals you're simming / probing
<swetland>
whitequark: I forget when I discovered it but it's a total game changer
<whitequark>
azonenberg_work: yosys doesn't even do enums yet...
<swetland>
for simple stuff you can just provide a text file of value name pairs one per line
<whitequark>
swetland: how do you use that?
<azonenberg_work>
whitequark: i know :p
<whitequark>
can it be embedded into the vcd somehow?
<swetland>
or you give it a program that takes a value as a filter and spits out the label
<whitequark>
i want migen to do it automatically
<swetland>
that would be super cool
<azonenberg_work>
i have a cross-language enum framework in splash that generates .vh, .h, etc files for different languages
<azonenberg_work>
for tables of constants like register IDs that are used across HDL and firmware
<swetland>
I'm not sure if there's a way to fully automate it
<swetland>
I usually setup gtk and save off settings once I have it all happy
<azonenberg_work>
so it was easy to make it dump those in a format that the ILA could read too
<swetland>
er gtkwave
<swetland>
I wonder if any of the various vcd formats support metadata
<swetland>
seems like something that could be added and would be crazy useful
<swetland>
or even if there was a standard companion file for names-for-enumerated-signal-types or whatnot
TavyCats has quit [Ping timeout: 240 seconds]
TavyCats has joined ##openfpga
m_w has joined ##openfpga
<tnt>
I use lxt2 most of the time now for non trivial stuff ... much smaller/faster.
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined ##openfpga
<pie__>
any recommended guides for pcb stuff (with kicad)?
* pie__
is the unqualified workforce not taking your jobs for cheap :P
<swetland>
I should add "learn to use kicad" to the vacation project list
<pie__>
i have my schematic in a state that seems ok at this point
<pie__>
I havent picked parts yet, but I figure I can get the basic gist of pcb stuff for when I have the rest of the project at hand.
<pie__>
I seem to have at least minimally figured out how to assign footprints, and read in a netlist.
<TavyCats>
pie__: on newer kicad you can just press `f8` in the schematic and it'll switch to the pcb and update it
<pie__>
yeah but like i have to do the initial layout and stuff? and I dont know anythign about this layers stuff
<pie__>
or how youre supposed to design a pcm
<pie__>
pcb
<pie__>
i mean, i can make some probably reasonable guesses
<pie__>
do i just search youtube for a random kicad pcb tutorial?
<adamgreig>
if you do make sure it's at least reasonably recent
<adamgreig>
there must be some good ones
<adamgreig>
but modern kicad (v5 or the v6 nightlies) has _so_ many improvements to pcb editing
<adamgreig>
and yes: it will dump all your footprints from the schematic into an empty pcb, and it's up to you to draw the pcb edges, place all the parts on the pcb, and then draw copper tracks to connect them all together
<adamgreig>
it will draw straight lines (the "ratsnest"/airwires) between all pads that need to be connected, so you know what needs to go to what
TavyCats has quit [Ping timeout: 246 seconds]
TavyCats has joined ##openfpga
azonenberg_work has quit [Ping timeout: 246 seconds]
TavyCats has quit [Ping timeout: 250 seconds]
<pie__>
adamgreig, yeah i figured out about that much, i.e. that at a high level thats what i need to do :P
<pie__>
so, after a bit of a hiatus, i started googling and largely looking at EE stackoverflow