rqou has quit [Read error: Connection reset by peer]
rqou has joined #yosys
dys has quit [Ping timeout: 268 seconds]
cr1901_modern has quit [Ping timeout: 256 seconds]
cr1901_modern has joined #yosys
Ultrasauce has quit [Remote host closed the connection]
Ultrasauce has joined #yosys
az0re has quit [Quit: Leaving]
N2TOH has quit [Read error: Connection reset by peer]
N2TOH has joined #yosys
emeb_mac has quit [Quit: Leaving.]
m4ssi has joined #yosys
az0re has joined #yosys
twnqx has joined #yosys
captain_morgan has quit [Quit: Ping timeout (120 seconds)]
captain_morgan has joined #yosys
dormito has quit [Ping timeout: 256 seconds]
N2TOH has quit [Read error: Connection reset by peer]
dormito has joined #yosys
N2TOH has joined #yosys
N2TOH_ has joined #yosys
dys has joined #yosys
N2TOH has quit [Ping timeout: 240 seconds]
thardin has joined #yosys
<thardin>
is vivado required just to use nextpnr-xilinx?
<thardin>
this line seems to indicate "no":
<thardin>
"Set XRAY_DIR to the path where Project Xray has been cloned and built (you may also need to patch out the Vivado check for utils/environment.sh in Xray)"
<ZirconiumX>
thardin: Depends on the target family
<ZirconiumX>
You need RapidWright for UltraScale[+]
<ZirconiumX>
But you can kinda get away with Project X-Ray for XC7
<thardin>
that's what I'm aiming for. trying to build the arty example, but it seems I need a newer yosys than what debian ships :)
<ZirconiumX>
Having a newer Yosys is a good idea anyway
<ZirconiumX>
It moves pretty quickly
<thardin>
*compiling*
<daveshah>
You need to patch out the Vivado check from prjxray environment.sh
<daveshah>
I'm working on a better fix
<daveshah>
It's not actually needed, it is just prjxray assumes you want to run fuzzers rather than just generate bitstreams
<thardin>
it worked!
<thardin>
managed to build the arty-a35 example
<thardin>
about time for lunch
<thardin>
daveshah: suspected something like that
<thardin>
might install vivado on some machine anyway, but at least things can be segregated
dys has quit [Ping timeout: 256 seconds]
dys has joined #yosys
<thardin>
getting the laser physicists excited here when concluding that sampling at around 1 Gsps is feasible
<daveshah>
Oversampling or real time? About 25Gsps oversampling is sort of possible on ECP5
<daveshah>
More on Xilinx as its tap resolution is finer
<thardin>
I saw one ADC that does 25 Gsps, transmitting over 10 LVDS pairs
<thardin>
but that's getting into overly advanced territory for now
<daveshah>
Oh, I was thinking about digital hacks, not ADCs
<daveshah>
Yes, 1Gsps real time ADC seems quite possible
<shapr>
oh hey, I have a job now
<shapr>
daveshah: what's the best way to send money in your direction?
<daveshah>
Patreon is easiest if that works for you
* shapr
signs up
* twnqx
stares at AD9213 buying page... 3.6k$ each in 1k quantity for a 10.5Gs/s ADC?
<shapr>
ah, fpga_dave
<daveshah>
yep
<twnqx>
some ICs are slightly overpriced
<daveshah>
It wouldn't surprise me if there were much bigger discounts than public for genuine large volume uses
<shapr>
signed up
<daveshah>
cheers!
<shapr>
no, thank YOU for all the awesome work!
* shapr
greedily reads about project xray
* ZirconiumX
sighs in project mistral
<shapr>
I bought the same hardware that Tommy Thorn got, I have the NeTV2 with the 100T chip. I know project xray only supports the .. 35? but I can hope
<daveshah>
Hopefully it's not too long before Xray gets 100T support too
<daveshah>
In the mean time there's plenty of work to get nextpnr running nice and fast for bigger/trickier parts...
<shapr>
Hopefully I'll soon(?) be sufficiently familiar with my new job that I can help.
dys has quit [Ping timeout: 256 seconds]
<awygle>
100T isn't that much bigger than the 85k ecp surely?
<thardin>
perhaps a bit of profiling is in order
<thardin>
one common way to speed things up is to remove as many allocations as possible
<daveshah>
The main problem is higher routing congestion
<daveshah>
It's more the Ultrascale where it still struggles quite a bit, but I think the larger xc7 devices can be improved too
<daveshah>
(ECP5 like most LUT4 devices is more generous in terms of routing resources)
<daveshah>
ECP5 has also had quite a bit more tweaking over the years
<daveshah>
I've done some profiling of routing and the problem is more doing too many operations (algorithmic) rather than those operations needing to be sped up
<daveshah>
But I have a plan going forward for various improvements still
<thardin>
hmm, right
awordnot has quit [Ping timeout: 268 seconds]
awordnot has joined #yosys
<thardin>
having some trouble getting nextpnr-xilinx --gui to draw anything but a blank grid when loading attosoc_routed.json or blinky_routed.json (--chipdb specified)
<thardin>
maybe vanilla nextpnr might work better, on an ice40 project I have laying around
citypw has quit [Ping timeout: 258 seconds]
emeb has joined #yosys
<thardin>
hrm no vanilla doesn't actually draw the routed ice40 design
<thardin>
ok so it's not entirely obvious it's necessary to have it do all the routing etc again by clicking pack and all that
<thardin>
like I'd expect if I already have my design ready it should just werk. maybe I'm not seeing something
<thardin>
don't see an option to load the .bin file
<thardin>
I guess you'd lose a bit of metadata that way tho, I suppose
<tnt>
The json file you load is not placed and routed so you need to do that. And atm there is no working way to load anyfile that contains the placed/routed design.
<tnt>
there is an option to load a .asc file but it's buggy/not working ATM and all metadata / signal names would be lost in there anyway.
<tnt>
there is an option to load a .json file with packed and placed cells (but not the routing) but that also fails to load / is buggy.
dys has joined #yosys
<thardin>
i see
<thardin>
being able to do incremental updates might be useful
<thardin>
will have to give the code a look some day
<tnt>
incremental update ?
<tnt>
when you re-synthesize the resulting json could be completely different.
<Degi>
Is it normal that nextpnr-ecp5 doesn't draw the design?
<tnt>
... do you actually _run_ the place and route ?
<Degi>
Oh now it shows, thanks
<tnt>
when you start in gui mode you need to use the menu to manually start all the phases of the implementation ... packing / place / route /. ...
<Degi>
I just modified the console command with --gui heh
N2TOH_ has quit [Ping timeout: 256 seconds]
N2TOH has joined #yosys
N2TOH_ has joined #yosys
m4ssi has quit [Remote host closed the connection]
N2TOH has quit [Ping timeout: 268 seconds]
ravenexp has joined #yosys
Cerpin has quit [Quit: leaving]
Cerpin has joined #yosys
somlo has quit [Ping timeout: 258 seconds]
m4ssi has joined #yosys
m4ssi has quit [Remote host closed the connection]
somlo has joined #yosys
m4ssi has joined #yosys
m4ssi has quit [Remote host closed the connection]
dormito has quit [Ping timeout: 265 seconds]
dormito has joined #yosys
emeb has quit [Quit: Leaving.]
<thardin>
looks like the hx1k might be enough for what I want to do. 33% used, 70 MHz. squares and low-pass filters incoming samples
<thardin>
with a bit of luck this might be my uni gig for a while, which could also result in some improvements in nextpnr