FFY00 has quit [Quit: dd if=/dev/urandom of=/dev/sda]
FFY00 has joined #yosys
<DaKnig>
you can switch to sv and use assert :)
<Lofty>
DaKnig: that's not the behaviour thardin is looking for - $assert does not make Yosys error out, as far as I know
<DaKnig>
ah, they want the synth to error out
cr1901_modern has joined #yosys
<cr1901_modern>
I'm trying an experiment to build chipdbs in nextpnr ahead of time, and I'm quite confused about the options I need to set. Why do we need to set EXTERNAL_CHIPDB if there's already a (for instance) "ECP5_CHIPDB" variable?
<cr1901_modern>
What does the BBASM_MODE value "embed" mean? How does it interact with the other two variables above?
<tpb>
Title: GitHub - YosysHQ/nextpnr: nextpnr portable FPGA place and route tool (at github.com)
<daveshah>
ECP5_CHIPDB selects the bba files to use for the build, EXTERNAL_CHIPDB actually configures it to mmap the chipdbs at runtime rather than include them in the binary
<cr1901_modern>
Okay, so what I can gather then, the CMake projects to build the chipdbs only generate the .bbas
<cr1901_modern>
So you can't cross-compile the *bins from the chipdbs- only the *.bbas
<cr1901_modern>
Oh wait... I remember what embed does... that's some weird C++ extension that effectively implements "incbin" found in an assembler worth its salt
<thardin>
DaKnig: I've looked a bit at SV, might give some of its features a go at some point
<thardin>
for now I'm happy just making sure parameters are sensible :)
<DaKnig>
(I dont even use sv or suggest using it; its just that in many cases you are using sv features when you think you are doing just verilog)
<thardin>
aha
<thardin>
I take it negative shifts aren't a thing? else these checks would be less necessary
<thardin>
as in 3 >> -1 == 6
<DaKnig>
parens
Asu has quit [Ping timeout: 258 seconds]
emeb has joined #yosys
<Lofty>
thardin: that would require much more hardware, so no, negative shifts are not a thing
Asu has joined #yosys
<cr1901_modern>
>So you can't cross-compile the *bins from the chipdbs- only the *.bbas
<cr1901_modern>
This isn't as bad as I thought... because the *.bbas compress REALLY well to send them over network
Asu has quit [Ping timeout: 258 seconds]
Asu has joined #yosys
kraiskil has quit [Ping timeout: 265 seconds]
Asuu has joined #yosys
Asu has quit [Ping timeout: 246 seconds]
<thardin>
Lofty: aw
<thardin>
though that just means an if is necessary
kraiskil has joined #yosys
<thardin>
has anyone tried using yosys together with gnuradio? as in compiling a grc flowgraph using yosys
<thardin>
because it strikes me that a direct conversion receiver should be possible using the UP5K
<daveshah>
I think dkozel or tnt might have been?
<tnt>
thardin: huh what now ? You can't take an arbitrary flow graph coded in C++ and just "compile" it to a FPGA ...
<tnt>
you could do something akin to rfnoc where you use the gui to basically 'connect' stuff but each block still needs to be implemented for your target fpga. (and then write approproate architecture on the fpga to pass data between them etc ...)
<tnt>
And that's especially true for something like a UP5k whih is rather slow and small and so you need implementation tailored to it to use it to its full potential.
<thardin>
tnt: I mean on the GRC level
<thardin>
I'm fairly sure I've read gnuradio can put parts of a flowgraph on FPGAs
<tpb>
Title: GitHub - jpendlum/gr-zynq: GNU Radio support for Xilinx Zynq based FPGA accelerators (at github.com)
<thardin>
interesting
<thardin>
so it uses some zynq-specific library rather than a general verilog thing?
<Ultrasauce>
a generalized approach would be a huge undertaking
<thardin>
or would it?
<thardin>
red pitaya does something like that, but with R
<thardin>
relies on vivado unfortunately
<tnt>
thardin: yeah, as I mentionned RFNoC ... that targets Xilinx Kintex and the like ...
<tnt>
and as I said, blocks needs to manually implemented, you can just "wire them up" in the gui that's it.
<thardin>
obviously the blocks themselves need implementing. I'm mostly getting at the plumbing side of things :)
<thardin>
gnuradio has no support for bitdepths not a multiple of 8bit tho, I think
<thardin>
ah you said "can" not "can't"
<DaKnig>
you can always pad your signals with 0s
<DaKnig>
if its 12 bits, just connect the top bits to the remaining bits
xtro has joined #yosys
craigo has joined #yosys
strongsaxophone has joined #yosys
kraiskil has quit [Ping timeout: 258 seconds]
<strongsaxophone>
exit
strongsaxophone has quit [Quit: leaving]
<thardin>
DaKnig: waste of lcs tho
<Lofty>
No?
<Lofty>
That would be purely routing.
<thardin>
hum
<thardin>
i suppose padding would be optimized out
<Lofty>
It *is*, through the wreduce pass.
<DaKnig>
one trick I found recently is that if you use the top bits as the padding, it gives you a bigger range and you still have constant resolution
<DaKnig>
and it makes sense because you are pretty much multiplying by 0b100..01 to get that result
<DaKnig>
so d(3 downto 0) & d(3) & d(2) to get 6 bit samples from 4 bit samples instead of just d(3 downto 0) & (others=>'0')
<DaKnig>
(or whatever the equivalent Verilog is
maartenBE has quit [Ping timeout: 258 seconds]
maartenBE has joined #yosys
emeb_mac has joined #yosys
<dkozel>
thardin: Hey. Yes. I've been writing an example of building LiteX SoCs from GNU Radio Companion flowgraphs
<dkozel>
I have a litepcie DMA Source and Sink block, but lack the time and LiteX experience to get interesting blocks setup correctly
ayazar1 has joined #yosys
ayazar1 has quit [Client Quit]
<thardin>
dkozel: ooh
tux3 has joined #yosys
Asuu has quit [Quit: Konversation terminated!]
_whitelogger has joined #yosys
<cr1901_modern>
whitequark: Building .bbas on a remote machine and then xferring them to another to build nextpnr works like a charm. Ty for your effort :D!
<whitequark>
i'm happy it works for you!
<cr1901_modern>
I've built yosys/nextpnr enough that I wrote a script to automate it. Added remote .bba support tonight. And for the first time in over a year, I got a working yosys/nextpnr on an ARM machine (plan to add nmigen as well soon).
<dkozel>
thardin: I'd be very interested in chatting about the *extensive* current efforts going on in GR to add much better heterogeneous computing support plumbing
<dkozel>
There's a lot of content about it in the GRCon lineup next month
<dkozel>
I'm hoping to talk about my LiteX proof of concept there, but I'm one block short of a good demo and conference prep is eating all my time