kmehall has joined ##openfpga
Flea86 has joined ##openfpga
azonenberg_work has quit [Ping timeout: 252 seconds]
azonenberg has quit [Ping timeout: 268 seconds]
azonenberg has joined ##openfpga
azonenberg_work has joined ##openfpga
emeb_mac has quit [Remote host closed the connection]
Miyu has quit [Ping timeout: 246 seconds]
Bob_Dole has quit [Ping timeout: 250 seconds]
swedishhat has joined ##openfpga
MatrixBridge has joined ##openfpga
MatrixBridge has left ##openfpga ["User left"]
swedishhat has quit [Quit: Page closed]
m_w has joined ##openfpga
gsi_ has joined ##openfpga
swedishhat has joined ##openfpga
gsi__ has quit [Ping timeout: 244 seconds]
<swedishhat> hey everyone
<swedishhat> I have a bit of a problem when synthesizing an ECP5 design. Yosys is generating a bitstream that uses waaayyy too much of the fabric, and I wanted to know if there was any way to try to optimize the parameters to yosys (or NextPNR) to try to get it to fit
<swedishhat> Screenshot of the carnage:
<swedishhat> I don't think my humble MD5 core really should be taking up >1000% of the design
unixb0y has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
swedishhat has quit []
<sorear> what do you get with vendor tools?
dj_pi has joined ##openfpga
dj_pi has quit [Ping timeout: 255 seconds]
m_w has quit [Quit: Leaving]
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
_whitelogger has joined ##openfpga
Bob_Dole has joined ##openfpga
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
GenTooMan has quit [Quit: Leaving]
ZipCPU|Laptop has joined ##openfpga
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
Bike has quit [Quit: Lost terminal]
lutsabound has quit [Quit: Connection closed for inactivity]
_whitelogger has joined ##openfpga
qualia has quit [Ping timeout: 252 seconds]
qualia has joined ##openfpga
zem has quit [Ping timeout: 245 seconds]
zem has joined ##openfpga
rohitksingh has quit [Ping timeout: 255 seconds]
mumptai_ has quit [Quit: Verlassend]
mumptai_ has joined ##openfpga
mumptai_ has quit [Client Quit]
mumptai has joined ##openfpga
Asu has joined ##openfpga
<tnt> kbeckmann: ping ?
Bike has joined ##openfpga
Flea86 has joined ##openfpga
unixb0y has quit [Read error: No route to host]
unixb0y has joined ##openfpga
Miyu has joined ##openfpga
ZipCPU|Laptop has quit [Quit: Leaving]
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
<kbeckmann> tnt: pong
<tnt> kbeckmann: I think the two rows of pins on the pmods are swapped :/
<kbeckmann> oh i triple checked it but maybe i was thinking in the opposite way
<kbeckmann> but good feedback, let's fix it for the next rev
<kbeckmann> also there are missing pull ups. i put them between the connector and caps (3v3 rail)
<kbeckmann> (on i2c scl and sda)
<kbeckmann> but do you mean the pins should be swapped horizontally? cause that shouldn't be needed.. unless i messed up bigtime (both on my kilsyth board and sx1257)
<tnt> I mean the schematic says PMOD_4=CLK_OUT connects to P1A10 global clock input ... and it doesn't.
<tnt> it connects to P1A4
<tnt> wrt to the i2c, yeah, I saw the 2 added resistors, tha't actually how I started doubting the pinout because i2c is on the same 'row' as the clk.
_whitelogger has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
emeb has joined ##openfpga
Laksen has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
Miyu has quit [Ping timeout: 255 seconds]
<emeb> a couple months back there was some discussion here about how the TinyFPGA USB bootloader wouldn't work on the UP5K due to timing issues.
<emeb> has anyone done any further work on that?
<tnt> emeb: Well, I personally was never convinced of that theory because I got it working just fine on one of my up5k board ...
<emeb> tnt: oh interesting. did you have to tweak it or were you able to just do a simple port?
<tnt> I had to fix some bugs in it ,
<tnt> this has been merged since then.
<tnt> I also actually used icecube2 and not the open toolchain because (at least at the time), the open toolchain wasn't good enough to produce a design that met timing. But icecube2 did.
<emeb> tnt: that makes sense - seems that the open tools have limited timing specification/control ATM.
<tnt> Someone worked on splitting clock domains to ease timing a lot btw :
<emeb> ok - ISTR some discussion of that
<tnt> emeb: well, with nextpnr you can specify the constraint sufficiently good, but the place & route couldn't meet them :p
<emeb> tnt: yes - I've played with that some recently. It worked OK for my easy testcase.
<emeb> tnt: did you do anything special on the hardware side for the USB dp/dm interface?
<tnt> The fomu folks are also working on another usb bootloader, that uses a softcore. and I'm also working on generic a soft-cpu + usb core design ...
<emeb> ah good - that's a more general way to go forward.
<tnt> emeb: nope, just connected directly dp/dn to pins and add a pull up on ... dn or dp can't remember.
<emeb> tnt: cool - I can figure that bit out.
<tnt> emeb: yeah. I need to implement an isochronous USB device, so didn't want to do it all in hw :p
<emeb> exactly - don't want to have to redesign the verilog every time you change the class
<tnt> hehe yeah. I'm actually just starting now on the actual USB part because I had to finish my own cpu before :p
<emeb> heh - the downside of soft CPUs - everyone wants to build their own. :)
<tnt> I would gladly have passed. But ... can't really spare spending more than half the FPGA for the soft core, all the existing one I found were too big / too slow / ...
<emeb> well, I just got a 6502 running on a UP5K and it doesn't use up much. I suspect that's probably not what you needed though. :D
<tnt> emeb: Interesting. What fmax and resources ?
<tnt> I was aiming for 500 PLBs and 50 MHz.
<emeb> well, this is mixed in with a bunch of other RAM/ROM/peripherals and uses about 19% of the UP5K. I constrained the clock for 4MHz and it hit 16MHz.
<emeb> So a bit bigger and slower than what you want
<emeb> but if stripped down and constrained harder it might do better.
<tnt> 20% is actually pretty good nice.
<tnt> Was that an existing core ?
<emeb> very easy to use
<emeb> dropped ancient 6502 BASIC ROM into the system and it runs it just fine.
<tnt> Looking at the ALU it might actually be possible to tweak it a bit for better ice40 mapping.
<emeb> I'm sure there's lots of room for improvement.
<emeb> I linted it with verilator and it found some stuff that could be cleaned up - nothing major but a few warnings about bit-width mismatches, etc.
<tnt> I need to give it a shot to connect it to my hdmi text core at some point.
<emeb> that'd be cool.
<emeb> IIRC there are some free C compilers for 6502 that would make life easier.
<emeb> I used one of the UP5K SPRAMs as the main RAM for the 6502 - had to do a bit of fiddling to convert 16bit to 8bit but otherwise very simple.
<daveshah> cc65 in particular
<emeb> "32kB should be enough for everyone"
<shapr> 640k IS enough for everyone
* shapr buys a laptop with 128gb ram
<daveshah> 640k gigabytes :)
<emeb> this!
<shapr> no really, the laptop I'm using to type this has 128gb ram
<emeb> the future is already here - it's just not evenly distributed
<shapr> when daveshah first told me the hx8k was a medium-sized FPGA, I was confused
<shapr> how much ram on there? you sure about that?
* shapr hugs daveshah for being awesome
<daveshah> 128kbit...
<shapr> :-D
<emeb> that's a lot of RAM for a little FPGA.
<daveshah> although tbh it's a bit small to be medium
<daveshah> ECP5 85K is firmly medium, with a whole 3.7 MEGAbits of RAM
<shapr> whoa!
<tnt> I want a UP5k with ... 8k LCs and HX fabrix. And dual-ports SPRAMs :p
<shapr> mind you, the first time I looked at the ultrascale+ specs I was impressed... though mostly by the price
<shapr> I could buy this laptop seven times over for the price of a top of the line ultrascale dev kit
<emeb> hoity-toity folks coming around here talking about their huge Xilinx SoCs...
<daveshah> otoh, ultrascale+s are actually pretty good value to "rent" on aws
<shapr> yeah, last I checked the spot price was such that I could rent one for ten years before I'd pay more than buying one
<emeb> and by that time the one you bought would be old news
<shapr> right!
<daveshah> yeah, gives you an idea what kind of pricing they get
<daveshah> they aren't paying $38,639.22 each :D
<emeb> Xilinx's "special deal" prices for their pals are ludicrously lower than list.
<shapr> probably makes sense to get their hardware in the right hands first
<shapr> and then make back that money on the rest of us
<shapr> off the rest of us?
<daveshah> Same with everyone. Pretty sure the iCE40UP5K is <$1 if you buy a few million (literally)
* shapr is still thinking in Swedish :-/
* emeb imagines a "beowulf cluster" of iCE40UP5K
<shapr> daveshah: I'm excited about cascade, thanks for that link!
<shapr> hopefully I'll really get into fpga dev at some point
<daveshah> yeah, Yosys support will be awesome
<shapr> daveshah: how'd you get started with fpga dev?
<daveshah> shapr: making a readout circuit for a silicon photomultiplier with a machxo2
<nats`> <emeb> Xilinx's "special deal" prices for their pals are ludicrously lower than list. <= xilinx what ? :D
<daveshah> basically 16 fast counters, easy to do on an FPGA but hard to do on an MCU
<shapr> One of my coworkers took an FPGA class as part of his CS/EE degree at GaTech, even his final project was less complex than the synthesizer I want to build as a beginner project.
<daveshah> then I was hooked
<pie___> shapr, whats this about cascade?
<shapr> pie___: oh, I was whining that I don't want to use symbiyosys as a beginner, I want something more like a ghci/python repl
<shapr> and daveshah linked to cascade
* shapr finds the link
<shapr> so I filed an issue requesting yosys support:
<pie___> the fuck didnt know vmware does stuff like this
<shapr> It feels to me like it's easier to do build larger beginner things in software, but perhaps I'm biased because I first wrote code at 11 years old?
<shapr> daveshah: so you had an application that naturally fit an FPGA?
<daveshah> shapr: yeah
<shapr> I don't know enough to know if I have such a thing in my project list
<daveshah> anything with tricky IO requirements is a good fit
<daveshah> LED panel driving for example
<shapr> so, maybe a neopixel driver would be a better beginner project?
<shapr> I've built many cool things with neopixels, even a jacket!
<daveshah> it would be a great place to start
<emeb> matt!
<shapr> daveshah: thanks!
* sxpert is tugging along on his project
<sxpert> after several rewrites from scratch, I suspect I have the proper design
<sxpert> now, implementing the complete debugger / disassembler in hardware is potentially possible ;-)
<sxpert> dunno how convoluted it would be though, but doable ;)
<sxpert> daveshah: that device of mine seems to hover around 70MHz or so
<sxpert> according to pnr
<daveshah> That's pretty good on a speed grade -6 ECP5
<sxpert> haven't tested on real hardware just yet
lain has joined ##openfpga
<sxpert> I need to figure out how to get a serial port out ;)
<sxpert> and button up a few things
<sxpert> I may be looking at replacing the main registers by BRAMs
<sxpert> would probably save a lot of logic
<sxpert> and I think it would work, considering the ALU is 4 bits
<daveshah> the ECP5 also has distributed RAM, which often fits the CPU register case well
<daveshah> unlike BRAM it can be read asynchronously
lutsabound has joined ##openfpga
<sxpert> hmm
<sxpert> I'll have to check, but the larger registers I only access through the ALU within a state
<sxpert> daveshah: does declarations like fit the distributed ram model ?
<daveshah> Probably not
<sxpert> ok
<daveshah> Yosys is unlikely to infer something that deeply buried
<daveshah> It might need a Verilog array too
<sxpert> something like "reg [3:0] A[0:15];" ?
lain has quit [Quit: kthxbai]
<daveshah> yup
<sxpert> I see.
* sxpert marks it up for later ;)
<sxpert> daveshah: in that case, say I have "reg [3:0] D0[0:4];
<sxpert> how do I put it all in PC ?
<sxpert> can I just do "PC <= D0;" ?
<daveshah> No, anything like that and it can't become RAM
<sxpert> hah
<daveshah> In general memories have 1 or 2 read ports
<sxpert> including distributed rams I gather
<sxpert> they're not your run of the mill D FF ?
pie___ has quit [Quit: Leaving]
pie___ has joined ##openfpga
<daveshah> Indeed, they are a 16x4 RAM with a synchronous write port and asynchronous read port not a DFF
<sxpert> I see
<sxpert> so that would work for the current use
<sxpert> as long as I don't access them otherwise
<sxpert> and you need to access one address at a time from each side
<sxpert> got it
<sxpert> daveshah: hmm, "$write does not support argument type (vpiMemory)."
<sxpert> even after attempting to put the data into a temp buffer
<daveshah> I think you need to use a for loop over all items
<sxpert> had left the register in the write in there ;)
<sxpert> so, per clock, I can only access it once, is that correct ?
<sxpert> ok, it does seem to work ;)
Miyu has joined ##openfpga
<sxpert> daveshah: one register reduced the use by 200 luts !
<daveshah> sxpert: if accessed multiple times then Yosys has to duplicate the memory
<sxpert> per clock that is ?
<sxpert> ok
<sxpert> works for me
<sxpert> or does it do that for each "always @" instance ?
<daveshah> Yeah, so two accesses in the same clock cycle will result in two RAMs (with the same write inputs)
<daveshah> Regardless if they are in the same or different always blocks
<daveshah> However, Yosys will be able to merge into a single access if it can prove the two accesses are mutually exclusive
<sxpert> daveshah: what if you access in read mode twice with the same index register ?
<sxpert> (on the same clock)
<daveshah> Yosys should hopefully merge them, but I wouldn't rely on this
<daveshah> This is very much in the realm where even if it works for Yosys it is likely other tools won't behave in the same way
<sxpert> hah
<sxpert> suspect having a dozen duplicated rams is not an issue
<sxpert> am down to 1067 cells vs 1734 !
<daveshah> Very nice
<sxpert> and 6500 arcs down from 12k or so
<sxpert> funny now, I have a small square
lain has joined ##openfpga
<sxpert> and a bean shape below ;)
fooo has joined ##openfpga
the_new_lfsr has joined ##openfpga
<the_new_lfsr> hello everyone, I am thinking about buying a new FPGA. The one that I have is a cyclone III that needs for it to run QUARTUS II v.12 which no longer runs on my linux, no mater what. Also, its not mine... I thought about a budget of 150$. Any suggestions?
<sxpert> ULX3S ?
<daveshah> the_new_lfsr: what are you planning to do with it?
<daveshah> Any particular IO requirements?
<the_new_lfsr> daveshah: i am used to having a ton of switches and leds... but I don't care losing them if I can use open source tools with it
<daveshah> sxpert's suggestion of the ULX3S is definitely a good one, although it's not super easy to get hold of
<the_new_lfsr> I really don't know what kind of things I will end up doing with it, but at least I want to have "a list of boards" I could think realistically about buying
<the_new_lfsr> is it supported by nextpnr?
<daveshah> Yes
<the_new_lfsr> yeah! has a ton of them. I didn't expect it
<the_new_lfsr> I am dreaming right now but... How many luts would a CPU like the zipcpu or a RISC V of general purpose would take?
<daveshah> A few thousand at most
<daveshah> picorv32 in a medium config is 2000-3000 LUTs
<the_new_lfsr> ok, so it would perfectly fit
<daveshah> During place and route testing I determined that 11 maxed out picorv32s fit
<daveshah> in the 85k ECP5
<daveshah> A Linux capable OpenRISC SoC is about 15-20k LUTs
<daveshah> A higher end 64-bit RISC-V like Rocket more like 40k
<the_new_lfsr> ok, I am still years from doing such a thing but I also don't want to buy something incapable of doing it if its not out of budget
<the_new_lfsr> thanks!
<ZipCPU> A minimal ZipCPU costs about 1200 LUTs
<daveshah> That linked board is the largest (and fastest) FPGA currently with stable open source tool support
<sxpert> daveshah: are there any new other pnr algorithms to try so far ?
<ZipCPU> A CPU with everything on it (DMA, pipelined, i-cache, early branching, divide, multiply, SD card support, etc.) costs (on a Spartan 6) about 5176 LUTs
<sxpert> ok, will wait it out some more
<the_new_lfsr> daveshah: yes, but judging by the photo on the link it seems that lacks too many components and maybe its me but I never see enough clarifications in digikey
<ZipCPU> the_new_lfsr: What is it you want to do?
<daveshah> It has 8 LEDs, 8 dip switches, Arduino and Pi headers, various other IO, SERDES on SMA footprints
<daveshah> FTDI for JTAG programming and UART
<TD-Linux> I have one, super easy to use with yosys
<TD-Linux> (I recommend populating the 50mhz clock also)
<the_new_lfsr> ZipCPU: I really just want to have it so I can learn with it
<ZipCPU> Any particular peripherals you are looking for? Video? Network?
<ZipCPU> Or just the CPU?
<ZipCPU> Oh, I should also ask: Are you going to be doing DSP work at all?
<the_new_lfsr> maybe... should I really care a lot about I/O when the board has some video interface and so many GPIO?
<the_new_lfsr> again, I do not know much, but if I need, say, a PS/2, couldn't I download the correspondent IP core and fit it in? I know its not super easy, but not impossible, right?
<ZipCPU> Again, it goes back to depending upon what you wish to do
<ZipCPU> If you have a board with a PS/2 port, the cores are fairly easy to write
<TD-Linux> you can always wire one up yourself
<TD-Linux> you can also do something like the tinyfpga bx
<the_new_lfsr> I would like basically to emulate computing systems
<ZipCPU> The difficulty with downloading your own core is that the publicly available cores tend to be of ... variable quality
<ZipCPU> You might find yourself stuck debugging someone else's core
<daveshah> the_new_lfsr: the ULX3S is pretty good for that, there are some demos including Amiga already
<ZipCPU> Building an embedded computing system is fairly straightforward. The question quickly becomes: how much computing system do you want to play with?
<daveshah> It has HDMI for video, USB for keyboard/mouse and lots of PMOD-compatible pins
<TD-Linux> I ordered 3, I might be able to send you one
<the_new_lfsr> ok, so the link from digikey, is the same as this one?
<daveshah> No, different boards
<daveshah> The link from digikey is the Lattice evaluation board
Zorix has quit [Ping timeout: 250 seconds]
mumptai has quit [Remote host closed the connection]
<the_new_lfsr> ok, now I understand, because it really look less user friendly than the one from my link hahaha
<ZipCPU> the_new_lfsr: If you are interested in building a processor, then pay close attention to the memory available for each board
<ZipCPU> FPGA memory drivers are hit and miss. (Ask daveshah if there's an open source driver available for the ECP5 boards he's recommending ... he'd be the one to know)
<daveshah> the_new_lfsr: OTOH, you can easily buy the Lattice board and get it in a couple of days unlike the ULX3S
<daveshah> The Lattice board linked doesn't have any onboard RAM outside of the FPGA
<daveshah> The ULX3S has SDRAM which is nice and easy
<the_new_lfsr> I am seeing 4 blocks of 16 MB, right?
<daveshah> The ULX3S has a single 32MByte SDRAM chip
<the_new_lfsr> oh yes, it is visible from the picture, yet in flash says 4-16 MB
feuerrot has quit [Ping timeout: 264 seconds]
<daveshah> Yes, it also has a SPI flash chip, can be populated with different capacity
<daveshah> But some of that will be probably used for bitstream storage
carl0s has joined ##openfpga
unixb0y has quit [Read error: No route to host]
<the_new_lfsr> ok, I see
<the_new_lfsr> thanks
feuerrot has joined ##openfpga
unixb0y has joined ##openfpga
Zorix has joined ##openfpga
unixb0y has quit [Read error: No route to host]
unixb0y has joined ##openfpga
lutsabound has quit [Quit: Connection closed for inactivity]
fooo has quit [Ping timeout: 256 seconds]
<tnt> That's a GSM C0 carrier captured with the SX1257 PMOD connected to an icebreaker :)
<daveshah> ooh very nice
<zkms> nice
<zkms> how did you transfer the data from the icebreaker to that image?
<tnt> atm I just sent all the raw iq to the host through SPI.
<zkms> oic
<tnt> but ... can't be real time so I have a 14.5 ms buffer :p
<tnt> I wanted some sample raw data so I can prototype the DSP in simulation with real data before trying it on the ice40. Next step is doing decimation on the ice40 using the DSP to reduce the data rate and only shift the useful data to the host.
the_new_lfsr has quit [Quit: Leaving]
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 250 seconds]
Asu has quit [Remote host closed the connection]
Laksen has quit [Quit: Leaving]
emeb has left ##openfpga [##openfpga]