wbraun has quit [Remote host closed the connection]
kc8apf has quit [Write error: Broken pipe]
henriknj has quit [Write error: Broken pipe]
swetland has quit [Write error: Broken pipe]
_whitelogger has joined ##openfpga
eddyb has quit [Changing host]
eddyb has joined ##openfpga
eddyb has joined ##openfpga
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
_whitelogger has joined ##openfpga
Bike has quit [Quit: Lost terminal]
emeb_mac has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
somlo has quit [Ping timeout: 245 seconds]
Asu has joined ##openfpga
somlo has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
Asu has joined ##openfpga
_whitelogger has joined ##openfpga
freemint has joined ##openfpga
Hamilton has joined ##openfpga
rohitksingh has quit [Ping timeout: 248 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 246 seconds]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
Hamilton has quit [Quit: Leaving]
rohitksingh has joined ##openfpga
<tnt>
Sprite_tm: so, just how slow is MSC ?
<Sprite_tm>
Fair few seconds to mount the fs, for instance?
<Sprite_tm>
Probably mostly has something to do with the fact that I don't call the tinyusb process callback that often, though.
<Sprite_tm>
And that probably will improve when I get around to adding icache to the processor.
<Sprite_tm>
Tbh, I have a thorough but slow-ish flash translation layer on top of it as well, not sure how much impact that has.
<tnt>
Ah yeah, each tinyusb poll call will process at most 64 bytes, so it takes a lot of them :p
<tnt>
Probably doesn't matter until you fix the other issues, but to get the max perf you can also switch to double buffered EPs.
<Sprite_tm>
Eh, I have a grand total of 10MiB of storage... I don't think I'll need extreme amounts of speed anyway :P
<tnt>
:D
<Sprite_tm>
It's a nice change not to have to think about drivers and hardware, though... as it is, the combo of your usb hw and the tinyusb drivers Just Work, at least for what I've been doing with it.
<tnt>
Nice to hear :)
Asu has quit [Quit: Konversation terminated!]
Asu has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
rohitksingh has quit [Ping timeout: 248 seconds]
rohitksingh has joined ##openfpga
_whitelogger has joined ##openfpga
Asu` has quit [Read error: Connection reset by peer]
Asu has joined ##openfpga
rohitksingh has quit [Ping timeout: 276 seconds]
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
Asu has quit [Client Quit]
freemint has quit [Ping timeout: 245 seconds]
Asu has joined ##openfpga
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
Bike has joined ##openfpga
rohitksingh has joined ##openfpga
<Dolu>
Seem like there is no way to get Vivado unisim running in Icarus Verilog, nor getting cocotb to work with XSIM
<daveshah>
Dolu: I've run many of the unisims in iverilog
<Sprite_tm>
Hey all, do string parameters work in Yosys? I have a module with a string parameter with a default "x", then instantiate it with the parameter changed to "y", but it keeps telling me it's "x".
<Sprite_tm>
parameter ROM_HEX = "x" <- like that in the module
<Sprite_tm>
Non-string parameters do seem to work OK.
<daveshah>
Yes, they should work - I've never seen any problems using them
<daveshah>
I would need a more concrete example though. With strings you have to be careful with sizing
<Dolu>
Ahh daveshah, the issue between iverilog and unisim, is that it contain some blackbox which are given as encrypted IP (ex B_OSERDESE2) And it seem there is no way to get those encrypted IP for icarus verilog (as far i know)
<daveshah>
Ah yeah, no solution (or at least legal solution)
<tnt>
Sprite_tm: note that I think you'll see the module being synthesized several times, the first one with default param and then subsequent times with the param that are actually used.
<daveshah>
tnt: you can avoid that with `read_verilog -defer` or the newer command `read -vlog2k/-sv`
<Sprite_tm>
tnt: Aaaah... Hm, means I should have a default that always works I guess.
<tnt>
daveshah: ok, good to know !
<Sprite_tm>
daveshah: Cool! Erm, I think I use the synth_ecp5 command directly... what are my options then?
<daveshah>
I can't remember the exact rules, but it might be truncated unless you define the parameter `parameter [1023:0] ROM_HEX` or similar
<daveshah>
Just to `read_verilog -defer ...; synth_ecp5 -top top` (or `read -sv ...; synth_ecp5 -top top`)
<tnt>
Sprite_tm: you can just add read command before synth_ecp5.
<Sprite_tm>
Awesomesauce, I'll try that.
<Sprite_tm>
daveshah: Hmm, I'm getting no dice with that. Is this a very recent addition?
<daveshah>
`read_verilog -defer` is ancient. Adding defer-like behaviour to `read` is very new
<daveshah>
Note if you update Yosys then you need to update nextpnr too
<Sprite_tm>
Gotcha.
lutsabound has joined ##openfpga
<tnt>
Sprite_tm: what are you clocking the picorv32 at btw ?
<Sprite_tm>
tnt: 48MHz.
<Sprite_tm>
I think I can go faster, but this matches nicely with the usb.
<tnt>
yeah, not sure if it'd run at 2x ( 96 MHz )
rohitksingh has quit [Ping timeout: 245 seconds]
<daveshah>
96MHz is probably a bit high for the lower speed grade ECP5s (can't remember which one is on your board)
<Sprite_tm>
daveshah: 45f-8bg, so probably doable.
<Sprite_tm>
Pretty sure the kinks are in my memory subsystem tbh.
<Sprite_tm>
Also, I can probably get a ton less memory churn with a small per-processor icache, so I'll probably go that route.
<tnt>
Sprite_tm: when you get to the 'optimization' stage, trying out the vex-riscv might be worth a shot. It has built-in cache.
<Sprite_tm>
tnt: Agreed. Tbh, the picorv32 is kinda not worth optimizing that hard.
<Sprite_tm>
But some icache probably helps out a lot anyway.
<tnt>
On the up5k when running out of spram, the picrorv32 is the fastest option I found so far. Vex Riscv has a lower CPI ... but a much lower fmax as well.
<Sprite_tm>
Huh, what's the fmax of vexriscv, give-or-take?
<tnt>
~ 17 MHz IIRC.
<Sprite_tm>
Eek, that's not fast. The picorv32 on 48MHz is kinda close then. And I can just dump 5 of them on the ecp5 and get my mips that way :P
<Sprite_tm>
as in: they can interleave their access to the memory as they're not needing memory access most of the time anyway.
<tnt>
(note that this was in the 'minimal area' configuration, I think the highly pipelined version can go faster but ... ice40 is small :p)
<Sprite_tm>
Fair :)
<Sprite_tm>
Ah, up5k also isn't ecp5, thinko on my side... for my reference, any idea what the picorv32 does on an up5k?
freemint has joined ##openfpga
<tnt>
My minimal picorv32 setup can run ~ 30 MHz
<tnt>
( I usually clock it at 24 because .. USB)
lexano_ has joined ##openfpga
<Sprite_tm>
Okay, that's a less big difference than I thought.
<Sprite_tm>
Heh, gotcha.
<Sprite_tm>
Any reason why you dev for up5k and not ecp5 btw?
<tnt>
But I know the vex wasn't meeting timing at 24 so I had to run it at 12 and that was negating all the benefits.
<tnt>
Sprite_tm: I like the challenge :p Also, I'm much mor elikely to put a qfn48 in all my custom boards than a bga.
<tnt>
But I'll be doing some stuff for the ECP5 soon ... waiting on a board from Greg Davill.
<Sprite_tm>
Fair nuf :)
lexano has quit [Ping timeout: 244 seconds]
<Sprite_tm>
Hehe, if not, just wait for november :P
<tnt>
Well tbh, given ATM the board took 7 days to go from Adelaide to Melbourne in the online package tracking, ... it might not get here before november :p
<Sprite_tm>
:P
Jybz has quit [Excess Flood]
Jybz has joined ##openfpga
<Sprite_tm>
Uh-oh, that broke something...
<Sprite_tm>
terminate called after throwing an instance of 'nextpnr_ecp5::assertion_failure' what(): Assertion failure: failed to find timing cell in db (/usr/src/nextpnr/ecp5/arch.cc:657)
<daveshah>
There was a DSP timing change
<daveshah>
Try updating to latest Trellis, touch ecp5/trellis_import.py and rebuild nextpnr
<Sprite_tm>
Did the 1st already, not the 2nd.
<daveshah>
If you did the 1st already before updating nextpnr, the 2nd shouldn't be needed
<daveshah>
Unless the database submodule didn't update for some reason
<Sprite_tm>
Yay, that made it happy. Must've gone something wrong in updating everything.
lexano__ has joined ##openfpga
lexano_ has quit [Ping timeout: 244 seconds]
<tnt>
Sprite_tm: 16F84 ? :)
<tnt>
that brings back memories ...
<Sprite_tm>
Yep :P someone on another channel joked about the main proc of the badge going to be a pic, so I kinda had to :P
<Sprite_tm>
Plan is to have it control the LEDs, because why not :P
<tnt>
What size does it take ? fmax ?
<Sprite_tm>
Size: dunno tbh... can synth a prev version and look at the difference. Fmax: this pic handles an instruction in 2 cycles instead of 4, but I have it process every odd cycle so I can connect it to registered memory. With all that, it happily runs at 48MHz. No idea about Fmax.
<Sprite_tm>
Must be the fastest pic16f84 in the world :P
<tnt>
Mmm ... there used to be that company in the 90's that was doing "high frequency" (like 50-100 MHz) 8 bit MCU which was very high for the time. Can't remember the name ...
<Sprite_tm>
Scenix IIRC. Didn't have interrupts because 'at that speed, you can easily check for events yourself', iirc.
<tnt>
yes, Scenix !
<Sprite_tm>
Drooled over that in the Elector magazines when I was a li'l one, but iirc it needed some funky programmer that used the xtal pins.
<tnt>
Yup same, I ended up building the programmer (which could also do PICs and other chips) and I never used the scenix chips in the end.
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
<Sprite_tm>
Lol, seems people bootstrapped through the 16c84. Build comport programmer, flash sx programming code into pic16c84, flash sx code through it.
<tnt>
yup exactly :) Although I used a F84 AFAIR.
<Sprite_tm>
Eh, they're more-or-less the same.
<tnt>
sure, except the C64 were OTP IIRC ?
<Sprite_tm>
No, C was EEPROM-based, F was flash.
<Sprite_tm>
Also, C had shitty readout-protection, F slightly less shitty.
<Sprite_tm>
Yay, pic boots, but I now have a longest path through my hw multiplier in the riscv... guess the timings bumped there something there. Ahwell, can look into that tomorrow.
X-Scale has joined ##openfpga
Flea86 has quit [Quit: Leaving]
* tnt
is starring at "Generating ../ecp5/chipdbs/chipdb-85k.bba"
freemint has quit [Quit: Leaving]
emeb has joined ##openfpga
<cr1901_modern>
That is a rite of passage when compiling nextpnr :3
<tnt>
Yeah, I'm used to the ice40 one, but this is my first time with the ecp5 ;p
<tnt>
Lets's see if I can even just blink a led on that ecp5 board.
<tnt>
Mmm ... first question is ... what's the equivalent of iceprog ?
freemint has joined ##openfpga
<daveshah>
tnt: usually I use ecppack to write an SVF and then openocd (or your alternative of choice)
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined ##openfpga
rohitksingh has joined ##openfpga
freemint has quit [Ping timeout: 250 seconds]
rohitksingh has quit [Ping timeout: 268 seconds]
mumptai has joined ##openfpga
<tnt>
Does the FTDI not put out a clock when USB is not plugged ?!?
<tnt>
(On a ECP5 EVN)
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 246 seconds]
freemint has joined ##openfpga
<tnt>
daveshah: I'm trying to build your serdes lookback example on the EVN but :
<tnt>
terminate called after throwing an instance of 'nextpnr_ecp5::assertion_failure' what(): Assertion failure: wire != WireId() (/home/tnt/projects/ecp5/nextpnr/ecp5/arch.h:867)
<daveshah>
tnt: can you give me something I can try with?
<tnt>
daveshah: yup I wanted to switch to using the 200 MHz refclock. Usung the 12MHz pad was just as a quick build test :) Thanks for the REFCK_MODE balue.
<tnt>
TD-Linux: yeah, I'll find something to populate there.
<daveshah>
That should give 10x refclk (2Gbps rate). 0b100 is 25x refclk (5Gbps rate) but that almost certainly needs other magic numbers changed
<daveshah>
If the 200MHz doesn't work, 100MHz from a PLL with the exact same parameters is the other option (as they are that would be 2.5Gbps)
<tnt>
It does something (and it changes when I unplug the SMA loopback).
<tnt>
rx_pclk isn't really regulat though, so probably not working as it should.
<tnt>
daveshah: what were you feeding in CH1_RX_REFCLK ?
Asu has quit [Ping timeout: 246 seconds]
Asu has joined ##openfpga
<tnt>
That's the pin to feed a reference from the fpga clock tree right ? But here I want to use the dedicated refclk input..
freemint has joined ##openfpga
<daveshah>
CH1_RX_REFCLK can come from clock tree or refclk (its the _FF_RXI_CLK that always comes from the clock tree and usually is output by another pin on the SERDES)
<daveshah>
This was my example using the external reference
<daveshah>
(that was also a 100MHz clock, iirc, from the ispCLOCK on the Versa)
<tnt>
oh ok. But I actually noticed I have another issue. I soldered the SMA for DCU0. But DCU0 can't use the on-board refclk that feeds DCU1 AFAICT.
<daveshah>
There's some weird neighbour mode that allows sharing clocks between SERDES, but I don't know how it works
<daveshah>
Easier to use a PLL and fabric refclk, tbh
<daveshah>
Probably wouldn't be fine for 5Gbps but enough for a couple of Gbps ime
<tnt>
Yeah, I'll try that. In the end I'll use an external ref clk because I want some weird CPRI rates (which i why I soldered the SMA for DCU0 which allow external clock input), but I don't have the clock gen setup yet ...
<tnt>
Yeah, looks much better ! CDR_LOL and LOS are both low, TX_PLCK and RX_PCLK are beating in sync and the rx data looks fine (from what I can see by looking at LEDs ...)
<daveshah>
Sounds like all working!
<tnt>
Let's see if that works when going over a SFP+ transceiver.
<tnt>
And it does. Nice.
<tnt>
Now I just have 1000 parameters to understand to make it work like I need to :p
<kc8apf>
I recall FTDI parts can be configured to put out a clk even when disconnected. It's just sketchy if you're using the internal RC.
<cr1901_modern>
^^The (Non-Inferrable) Vendor Primitive Story
freemint has quit [Ping timeout: 250 seconds]
SpaceCoaster has quit [Read error: Connection reset by peer]
SpaceCoaster has joined ##openfpga
freemint has joined ##openfpga
Asu has quit [Quit: Konversation terminated!]
mumptai has quit [Remote host closed the connection]