dj_pi has joined ##openfpga
emeb_mac has joined ##openfpga
gsi_ has joined ##openfpga
gsi__ has quit [Ping timeout: 245 seconds]
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
sgcarnaval has quit [Ping timeout: 258 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
vonnieda has joined ##openfpga
vonnieda has quit [Client Quit]
GenTooMan has quit [Quit: Leaving]
noobineer has joined ##openfpga
Bike has quit [Quit: Lost terminal]
rohitksingh_work has joined ##openfpga
kmehall has quit [Remote host closed the connection]
vonnieda has joined ##openfpga
kmehall has joined ##openfpga
Zorix has quit [Ping timeout: 252 seconds]
genii has quit [Remote host closed the connection]
Zorix has joined ##openfpga
knielsen has quit [Ping timeout: 248 seconds]
emeb has quit [Quit: Leaving.]
flammit has quit [Ping timeout: 252 seconds]
flammit has joined ##openfpga
sgcarnaval has joined ##openfpga
mkdir has joined ##openfpga
<mkdir> anyone around
<mkdir> ?
<sensille> just anyone? sure
<mkdir> cool! thinking about getting a new fpga dev board
<mkdir> have a papillio pro (spartan 6)
<mkdir> thinking about artrix 7 digilent dev board or ice40
<mkdir> any thoughts?
<Sprite_tm> Depends what you want to do.
<sensille> i mainly use my $60 china-artix 7-board
<sensille> artix 7 is much more powerful than ice 40
<mkdir> hmm I see, how about tools though?
<tnt> you're pretty much stuck with vivado
<mkdir> considering ice40 because it seems to be easier to get up and running
<sensille> which is ... usable
<mkdir> does vivado work on linux yet?
<sensille> yes
<mkdir> what tools does ice40 have
<mkdir> well that's good atleast
<tnt> yosys + nextpnr.
<tnt> (the open source toolchain)
<Sprite_tm> mkdir: If you're going for open-source toolchain, the ecp5 may be a better choice... same toolchain, more LUTs for your money and in general.
<sensille> but really ... what do you want to do with it?
<mkdir> well rn just get it up and running, learn verilog and stuff, the papillio pro would have been fine but the tools have been frustrating
<mkdir> i don't have Windows
<mkdir> only Linux and Mac, mac tools would be so preferable for now
<tnt> ISE is also on linux ... (for spartan 6).
<mkdir> looking at the ecp5... hmm
<mkdir> i couldn't find Webpack ISE on linux
<mkdir> link?
<mkdir> also what are other good fpgas?
<tnt> to get started I like the ice40. Yes, it's smaller than the ecp5 but you still need to do quite a big thing to fill it up if you're coding it yourself.
<tnt> Also the fact it is small is actually a plus for learning IMHO because your "mistakes" won't be hidden by large and fast fabric. If you screw something up ... it just won't work.
<tnt> just my 2ct.
<mkdir> appreciate it ^
<tnt> Also being in "easier" packages, if you want to integrate in your own projects, it's a bit nicer. (obviously only applicable if you want to make your own boards).
<Sprite_tm> True, it depends. I'm more in the camp that proves 'You wouldn't download a CPU' wrong ;)
<mkdir> hmm what is the difference between ecp5 and ice40? I haven't heard of the ecp5. Is it more powerful? The dev board is actually cheaper lol
<Sprite_tm> And pfffff, bga-381 is perfectly solderable. I have had no issues with any of the boards I did with that.
<tnt> Sprite_tm: I run a USB enabled riscv in less than half a up5k ...
<Sprite_tm> (note: 1/1 working is also 'no issues')
<mkdir> btw are there any mac tools for lattice fpgas?
<Sprite_tm> tnt: Fair nuf, but for random devboard farting around, I'm squarely in the 'more = better' camp. Would hate to have a great idea that happens to take up 110% of my fabric.
<tnt> Sure, depend on your skill level. But soldering 380 balls if you need 20 IO/s is a bit overkill :p I see it as a "stepping stone" from using a 8 bit micro in your project (or small arm-m0) to a fpga.
<tnt> mkdir: the open source tools will run on mac.
<tnt> (so ecp5 or ice40)
<tnt> Sprite_tm: sure, that's why I have both :p
<Sprite_tm> Gotcha :) In the end, it's still garden shedding; ecp5/ice40/..., you're mostly going to run into the same issues anyway.
<Sprite_tm> *bike shedding
<mkdir> maybe i'll get both, how do these compare to spartan 6, just curious?
<mkdir> I imagine ice40 is less powerful
<mkdir> but how about ecp5
<TD-Linux> ecp5 is similar sized
<TD-Linux> if you are learning verilog you are not going to run out of space on an ice40 any time soon
<sorear> ecp5 and ice40 are two Lattice product lines. ice40 was acquired from SiliconBlue, ecp5 is "native"
<sorear> so there are a lot of fairly gratuitous differences between them, they were designed out of communication from each other
<mkdir> hmm very interesting
<TD-Linux> mkdir, I would recommend a tinyfpga bx or an icebreaker
<tnt> +1
<Sprite_tm> +1 here as well
<sorear> the ecp5 line is larger and faster although there's overlap. ice40 targets "low power"
<tnt> https://store.tinyfpga.com/products/tinyfpga-bx https://www.crowdsupply.com/1bitsquared/icebreaker-fpga The BX is nice and small to integrate in your project, the icebreaker is nice if you want to use PMODs (pre-made extensions modules).
<tnt> Both have tons of examples available and communities aroud them.
<mkdir> ooh very cool
<mkdir> leaning towards ecp5 or tinyfpga-bx
<mkdir> what fpga does tinyfpga have on it
<tnt> ICE40LP8K
<tnt> For ecp5 I know https://radiona.org/ulx3s/ is fairly popular
<mkdir> also, how about Arduino Vidor lol
<tnt> machxo2 doesn't have any open toolchain.
<tnt> I think you have to use Lattice Diamond for that.
<mkdir> ooh..
<Sprite_tm> Otherwise nice chip though, I ditched that for the ECP5s though. Kinda old though; you may want to get the LCMXO3 if you go that route.
<Sprite_tm> But ECP5/ICE40 is more preferable because open toolchain :)
<Sprite_tm> Hmm, now I'm wondering how much overlap there is between mxo* and ecp5...
<mkdir> yeee love the open toolchain
<mkdir> maybe i'll just get ICE40 and artix 7
<tnt> Sprite_tm: a lot I think. someone started adapting treillis for it.
<mkdir> what fpga does tinyfpga use
<tnt> As noted above : ICE40LP8K
<mkdir> oh my bad
<mkdir> tnt: where do i get the ulx3s
<mkdir> just wanna compare prices
<tnt> "We are currently in the production of small batch of full-featured 85F ULX3S.
<tnt> If you are interested to get your hands on one, drop us an e-mail."
<Sprite_tm> 85f is nice and huuuge.
<mkdir> Sprite_tm: which board you got?
<mkdir> for ecp5
<Sprite_tm> mkdir: I built my own :) has a '45f on it.
<mkdir> respect
<mkdir> is Linux Diamond just fine?
<mkdir> still considering the Mouser board lol
<mkdir> machxo2 i mean
<mkdir> I mean Lattice Diamond
OmniMancer has joined ##openfpga
<Sprite_tm> Diamond is... okay. It's yer big-arse integrated development environment. If you like IDEs, it's doable. If you don't, you find yourself throwing something together from the command-line tools and a Makefile or something real quickly.
<tnt> it's possible to run ... but needs to fiddling. I always have issue with the licensing system and some libraries ...
<Sprite_tm> Aye. It's cute and small and fast and real easy to set up in comparison to the competition though. Not that that's praise to Diamond, mind you...
emeb_mac has quit [Ping timeout: 268 seconds]
<mkdir> hmm I see... Sprite_tm have you tried artix 7
<sorear> there are a lot of "someone started" open toolchains
<sorear> including iirc 3 different "started" on spartan-7
m4ssi has joined ##openfpga
<Sprite_tm> sorear: Never messed around with Vivado, but did do ICE back in the day.
<tnt> ISE :)
<sorear> s/7/6/
<Sprite_tm> *ISE
<Sprite_tm> Think I had a Virtex 2 I did some stuff with. Pretty pricy FPGA (got it because I could get a bunch of boards with it on it for free) but old even back then.
<tnt> virtex 2 pro with embedded ppc :)
<Sprite_tm> No pro, unfortunately :) would probably have whipped up a linux system from that if I had it.
<mkdir> there any other ecp5 dev boards?
<Sprite_tm> You have the official Versa board, but it's expensive.
<mkdir> also is the machxo2 a good chip? how does it compare to ecp5 and ice40
<tnt> ~ ice40 I think.
<Sprite_tm> Kinda. It goes up to 7K luts or so iirc, same as Ice40. From memory it
<Sprite_tm> 's faster though.
<tnt> Thats's the versa.
<tnt> The one you pointed at is the "breakout" board.
<Sprite_tm> mkdir: Ah, I didn't know of that one. Looks pretty OK, especially because it has a '85F on it.
<Sprite_tm> Pricey though, for what it is.
<tnt> Sprite_tm: and they don't provide the SMAs :p
<mkdir> yee pricey
<mkdir> honestly i think ice40 + artix 7 will be fine. It's good so that I can try out different ools
<mkdir> i'll also try getting the Xilinx ISE on my linux for my spsrtan 6
<mkdir> out of curiosity what are the best dev boards for spartan 6? is the papillio pro fine
<tnt> There are so many of them ...
<mkdir> as long as papillio is okay, that's fine. I wanted the spartan 6 microboard, but I can't find it anywhere anymore
<Sprite_tm> Depends on your purpose. If you have special requirements, grab a board with that, or a board with expansion where you can plug that in. For just faffing around, grab the cheapest one with the biggest FPGA and the most IO pins.
<mkdir> saw it a couple months ago
<Sprite_tm> IN your case, the papillio is probably your very best devboard, because you already own it :P
<mkdir> haha yeah
<mkdir> it also has a lot of IO
<mkdir> well more IO pins than microboard
<mkdir> Sprite_tm have you tried any spartan 6 dev boards?
<Sprite_tm> mkdir: Nope.
<Sprite_tm> XC3042, Virtex 2, Cyclone 2, MachXO2 and -3, Ice40 and ECP5, that's all.
<mkdir> good amount, how do Altera products compare?
<Sprite_tm> No clue. It's been years since I used that.
<mkdir> also, is ecp5 your fav?
<Sprite_tm> At the moment, certainly.
<mkdir> how about ice40? aside from the fact that it's less powerful
<Sprite_tm> It's fine as well.
<Sprite_tm> Tbh, it feels like you should spend less time thinking about what you should buy, and more time getting some Verilog written. You're better off getting to know the pros and cons of your current FPGA that way, and that'll help you figure out if others are good or bad.
<mkdir> yeah, i think i will try again with my spartan6 tomorrow.
<mkdir> I couldn't load anything using my virtualbox
<mkdir> i loaded in some bit files on mac but only using gadgetfactory software not Xilinx tools
<mkdir> tomorrow ima try dual booting linux and downloading Xilinx ISE
<Sprite_tm> Good luck!
<mkdir> thanks... i didn't know the setup would be so frustrating. Previously, I've done much firmware on embedded systems while the tools there are frustrating as well
<mkdir> atleast they are supported on my primary OS (Mac)
<mkdir> turns out Mac is the worst for FPGA dev
<mkdir> ty for all the help
<mkdir> everyone
mkdir has quit [Quit: Page closed]
sgcarnaval has quit [Ping timeout: 258 seconds]
mkdir has joined ##openfpga
<mkdir> what were those open src tools for ice40 again?
<mkdir> yosys +?
<tnt> nextpnr
<mkdir> ty ty
<RaYmAn> the open tools are soooo much less frustrating to work with :D
<RaYmAn> on both ice40 and ecp5
<mkdir> glad to hear :)
<mkdir> both verilog and vhdl are supported with the opentools am i right
<tnt> no
<Sprite_tm> No, Verilog mostly. VHDL is kinda-sortta supported but not really a first-class citizen
<mkdir> mmm kk all good
flea86 has joined ##openfpga
mkdir has quit [Ping timeout: 256 seconds]
cpresser has quit [Remote host closed the connection]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Asu has joined ##openfpga
rombik_su has joined ##openfpga
cpresser has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined ##openfpga
ironsteel has joined ##openfpga
pie__ has joined ##openfpga
<pie__> awygle, watching https://www.youtube.com/watch?v=giQ8xEWjnBs . huh.
<pie__> awygle, how prevalent are laser inter-satellite comms?
<pie__> man these finances people are rediculous
<pie__> and i still cant spell that word
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
futarisIRCcloud has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
s_frit has joined ##openfpga
GenTooMan has joined ##openfpga
s_frit has quit []
s_frit has joined ##openfpga
rohitksingh has joined ##openfpga
<hackerfoo> Is there any interest in an open source non-C HLS compiler? I've been working on one for a language called Popr (https://github.com/hackerfoo/poprc). Here it is calculating Collatz stopping time on a BASYS3: https://youtu.be/hJgHxzZesVE
<hackerfoo> Here's the relevant code in Popr: https://github.com/HackerFoo/poprc/blob/master/tests.ppr#L170-L179
<hackerfoo> You can see the generated Verilog by typing `:cv collatz` here: http://hackerfoo.com/eval.html
<Hoernchen> well, uh, .. can the language be used to solve actual real world problems?
emeb has joined ##openfpga
<hackerfoo> Hoernchen: I'm working up to it. There is a calculator example which is part way to an interpreter: https://github.com/HackerFoo/poprc/blob/master/tests.ppr#L291-L330
<hackerfoo> If you write an interpreter for some bytecode and then synthesize it, you get a processor.
<Hoernchen> keep in mind that new and exotic languages are not really what people are looking for when trying to increase development speed by involving a hls compiler
<hackerfoo> Hoernchen: That's not what people looking for a C HLS compiler are looking for.
<hackerfoo> But any high level language can increase development speed.
<hackerfoo> Anyways, I'm not selling anything, this is open source.
<tnt> hackerfoo: the previous company where I worked at, they switched to HLS some years back, "going all in", so all new cores where done with hls etc ... and they kept at it for several years to really give it a fair shot. But after a few years, they reverted to VHDL. When they wanted the control to do cores that were smaller and faster than the competition, hls just kept getting in the way ...
<emeb> not at all surprising
<hackerfoo> tnt: Other companies, including the one I work for, have had success with C HLS. But I think my language is better suited than C.
<tnt> emeb: yeah, I wasn't that surprised either. I already have trouble sometime to get verilog/vhdl code to generate the exact logic I want so adding a layer above that ...
knielsen has joined ##openfpga
<emeb> tnt: my current thinking about HLS is that it probably works OK if you're in a hurry and you don't care too much about efficiency of implementation.
<daveshah> Yes, I wrote a simple tool that generated a pipeline datapath from a C-like language for an augemented reality project at university
<tnt> yeah, when I played with it to prototype something quickly, it's nice.
<daveshah> Managed to fit a surpising amount in a 16k Cyclone III, and saved a lot of time balancing latencies
<daveshah> But certainly wouldn't want to use HLS for everything
<tnt> but ehn I hear people, "oh great we can just take ffmpeg and build it with hls !" ... huh yeah right ...
<emeb> lol
<daveshah> Yeah, that's just crazy
<daveshah> A lot of the benefits from using an FPGA come from things that software languages just don't do and are hard to analyse
<daveshah> e.g. integers that aren't multiples of 8 bits as a simple example
<rombik_su> Probably, HLS is best suited for acceleration applications, where you can justify using Stratix 10/Virtex US+ chips
<hackerfoo> My compiler also generates C. It was interesting that some things were actually easier in Verilog.
<hackerfoo> I think HLS will be very popular if FPGAs are ever widely adopted, to keep up with software project schedules.
<tnt> I pray it won't.
<Hoernchen> lol
<daveshah> This is a snippet of the custom C-like language I used, an example of Sobel edge detection (I keep meaning to turn this into something useful and open source, but haven't had time)
<nats`> I tested a lot of them and for now my preferred is SpinalHDL
<nats`> :)
<tnt> software dev state is not something to do again.
<daveshah> Not convinced SpinalHDL is really HLS as such
<daveshah> closer to higher level HDL
<Dolu> nats` <3
<Dolu> Right, SpinalHDL isn't a HLS
<emeb> daveshah: that C-like looks pretty clean.
OmniMancer has quit [Quit: Leaving.]
<daveshah> The parser for it certainly wasnt! Which is why I haven't released it (but the whole project this was part of was only a 3 month thing...)
<hackerfoo> daveshah: Nice. What does the output look like? I'm interested in the code if you release it.
<daveshah> The output is horrible VHDL
<emeb> heh
<nats`> right it's a high level HDL
<nats`> but I never understood what the point in HLS
<nats`> unless people wants to make the same mistake as systemc for example
<nats`> mixing well known language and new paradigm is often a mistake
<nats`> (my favorite example is CUDA)
<hackerfoo> Why does HLS have to mean C/C++?
<Hoernchen> i don't really see the tight c++ integration in cuda as a mistake compared to opencl
<nats`> I guess it's a matter of taste :)
<emeb> daveshah: tools for designing efficient datapaths & pipelines at a high level could be a nice adjunct for HDL coding. I used to use something called Module Compiler that worked in a similar way - we did some stuff in MC and the rest in Verilog. Worked well.
<nats`> hackerfoo, not C/C++ but wanting to copy software pratice to hardware design
<daveshah> emeb: Yup, this is very much intended for pipelined, streaming type stuff rather than creating complex FSMs from code
<daveshah> Need to get ECP5 DSP inference in Yosys done before I go back to any of this stuff though...
<emeb> +100
<emeb> good DSP inference is key
<hackerfoo> Functional code maps well to hardware, but has problems with resource management, so Popr was designed to address that, originally intended for embedded C.
<hackerfoo> Another important thing is to allow free mixing of higher and lower level language, meaning the generated code needs to be pretty clean.
<hackerfoo> Or at least the interface needs to be clean.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 258 seconds]
flammit has joined ##openfpga
sgstair_ has joined ##openfpga
flammit has quit [Ping timeout: 248 seconds]
sgstair has quit [Ping timeout: 248 seconds]
pie__ has quit [Ping timeout: 272 seconds]
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 245 seconds]
Ellied has quit [Ping timeout: 248 seconds]
flaviusb has quit [Ping timeout: 248 seconds]
m4ssi has quit [Remote host closed the connection]
flaviusb has joined ##openfpga
genii has joined ##openfpga
wpwrak has joined ##openfpga
pie__ has joined ##openfpga
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
sgstair_ is now known as sgstair
sgcarnaval has joined ##openfpga
rohitksingh has quit [Ping timeout: 258 seconds]
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
rombik_su has quit [Read error: Connection reset by peer]
tms_ has quit [Ping timeout: 248 seconds]
rohitksingh has joined ##openfpga
<hackerfoo> daveshah: Are you familiar with Halide? https://halide-lang.org/
<hackerfoo> I worked on an accelerator ASIC for (more or less) that language (Pixel Visual Core.)
<hackerfoo> I think it's a good example of how high-level code can outperform hand-written low-level code.
<hackerfoo> But it's not hardware. An HDL backend for Halide would be interesting, though.
<Hoernchen> halid is the first thing that came to mind as daveshah mentioned sobel
<Hoernchen> so i immediately googled for a fpga backend..
<TD-Linux> for my field (video decoding) there are some cores designed with HLS. they are fifo city though
<daveshah> Halide looks quite interesting
<daveshah> Thanks!
Dolu has quit [Ping timeout: 244 seconds]
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 244 seconds]
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 245 seconds]
Jybz has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 245 seconds]
m_w has joined ##openfpga
Asu` has quit [Quit: Konversation terminated!]
Asu has joined ##openfpga
Dolu has joined ##openfpga
vonnieda has joined ##openfpga
tms_ has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
futarisIRCcloud has joined ##openfpga
<hackerfoo> Huh. I worked with Jing. I didn't know he wrote an HLS backend.
<hackerfoo> Ah, it generates C for an HLS C compiler. Still neat.
<TD-Linux> this is something that you really don't want to do without oss tools though. otherwise you can only ship a fixed bitstream/bitstreams with your product
<hackerfoo> It could be worse. You could have to use a "cloud" compiler. That's where things seem to be going.
<Hoernchen> lol
rohitksingh has quit [Ping timeout: 246 seconds]
felix_ has quit [Quit: leaving]
felix_ has joined ##openfpga
sgstair has quit [Ping timeout: 245 seconds]
m_w has quit [Ping timeout: 246 seconds]
gnufan_home has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
_florent__ has quit [Read error: Connection reset by peer]
sorear has quit [Ping timeout: 276 seconds]
_florent__ has joined ##openfpga
sorear has joined ##openfpga
Asu has quit [Ping timeout: 268 seconds]
vonnieda has joined ##openfpga
synaption[m] has quit [Quit: Idle kick: User has been idle for 30+ days.]
Bike has joined ##openfpga
futarisIRCcloud has joined ##openfpga
m_w has joined ##openfpga
sgcarnaval has quit [Ping timeout: 258 seconds]