futarisIRCcloud has joined ##openfpga
<_whitenotifier> [Glasgow] kbeckmann opened issue #79: Performance issues when writing lots of data - https://git.io/fp0Ys
<_whitenotifier> [Glasgow] kbeckmann edited issue #79: Performance issues when writing lots of data - https://git.io/fp0Ys
TavyCats is now known as tavycats
tavycats has quit [Ping timeout: 250 seconds]
adamgreig has joined ##openfpga
<adamgreig> (cross-asking from #yosys because apparently tnt might have a good idea:) I have an ice40 hx8k design using a pll with a clock into GBIN0 (on the same cell as the X16/Y33 PLL); arachne places fine but nextpnr errors saying the PACKAGEPIN for the SB_PLL40_PAD must be GBIN5 (X16/Y0, the cell with the other PLL)
<adamgreig> I'm guessing it's picked the other PLL and then complained that the pad input is not in that cell, but I'm not really sure. any ideas?
<adamgreig> i have prepared a minimal example: https://gist.github.com/adamgreig/5d7cf57256cb41b7643b078f21831b79
<cr1901_modern> tnt: Yea sorry I volunteered you for this
<cr1901_modern> :)
<tnt> adamgreig: yeah, pll placing in next-pnr is dumb ... it picks a random one.
<tnt> adamgreig: you can use (* BEL="xxxxx" *) attribute on the PLL to force it.
<adamgreig> trying a whole load of different seeds didn't seem to change it
<adamgreig> ah cool, thanks!
<tnt> BEL="X16/Y33/pll_3"
<adamgreig> yep
<tnt> "random" as in ... whatever order they show up in the chipdb which is fixed ...
<adamgreig> ah :p
<adamgreig> so I could instantiate the other pll first as a dummy?
<tnt> "first" is kind of relative , you have no ide in which order nextpnr will process them.
<adamgreig> where should that attribute go exactly? can't get it to be picked up
<tnt> before the 'SB_PLL40_PAD'
<tnt> You're using nextpnr git right ?
<tnt> Because support for that is like ... 3 days old.
<adamgreig> I am using nextpnr git but I think it's been about a week since I pulled it
<adamgreig> so I will do that :p
<adamgreig> welp
<adamgreig> fish: “nextpnr-ice40 --hx8k --package…” terminated by signal SIGSEGV (Address boundary error)
<adamgreig> it does successfully constrain the pll to the right cell with that attribute though ;)
swetland has joined ##openfpga
tavycats has joined ##openfpga
Flea86 has joined ##openfpga
emeb has quit [Quit: Leaving.]
jevinskie has quit [Ping timeout: 260 seconds]
unixb0y has quit [Ping timeout: 246 seconds]
tavycats has quit [Ping timeout: 240 seconds]
unixb0y has joined ##openfpga
lovepon has quit [Ping timeout: 260 seconds]
genii has quit [Remote host closed the connection]
GenTooMan has quit [Quit: Leaving]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
tavycats has joined ##openfpga
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 240 seconds]
Bike has quit [Quit: Lost terminal]
rohitksingh has joined ##openfpga
lovepon has joined ##openfpga
zkms has quit [Quit: WeeChat 2.2]
zkms has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
edmoore has joined ##openfpga
_whitelogger has joined ##openfpga
<tnt> adamgreig: I'd suggest opening an issue with a traceback for that.
rohitksingh has joined ##openfpga
<_whitenotifier> [Glasgow] whitequark commented on issue #79: Performance issues when writing lots of data - https://git.io/fp0lb
tavycats has quit [Quit: WeeChat 2.2]
tavycats has joined ##openfpga
tavycats is now known as tavy
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined ##openfpga
lovepon has quit [Ping timeout: 260 seconds]
futarisIRCcloud has joined ##openfpga
Bike has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Miyu has joined ##openfpga
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
moho1 has quit [Quit: WeeChat 2.0.1]
moho1 has joined ##openfpga
moho1 has quit [Client Quit]
kbeckmann has joined ##openfpga
GenTooMan has joined ##openfpga
ZipCPU has quit [Ping timeout: 260 seconds]
rohitksingh has joined ##openfpga
ZipCPU has joined ##openfpga
moho1 has joined ##openfpga
<tnt> Is there a way to 'print' computed localparams values in yosys ?
<tnt> $display does nothing (unsurprisingly)
<tnt> oh wait, nm, $display works fine, my bad.
Dolu has joined ##openfpga
<_whitenotifier> [Glasgow] whitequark opened issue #80: Write a generic strobe generator - https://git.io/fp0wo
<_whitenotifier> [Glasgow] whitequark edited issue #80: Implement a generic strobe generator - https://git.io/fp0wo
<cpresser> I fail to find the power requirement for the ice40up. how much current does my supply need to provide?
<daveshah> cpresser: It depends on your design. The static power is 75µA. I would be surprised if a design needed a core power of more than 50mA
<cpresser> i found this one table which says startup peak power = 12mA
<cpresser> perhaps i should also look into all the appnotes
<cpresser> but it looks like a 150mA LDO should be enought for the 1v2 core supply
<daveshah> Power is quite hard to define for an FPGA, because the theoretical worst case design will be a lot higher than any sensible user design
<swetland> I was bummed to learn it was a 3+ supply device the other day
<daveshah> Certainly a 150mA LDO is more than enough
<tnt> I made a up5k design toggling 3000 FFs at every cycle at 87.5 MHz and core power was slightly less than 50 mA.
<swetland> not the end of the world, but so much else about it is nicely simple
<daveshah> swetland: you can get away with VccNVCM coming from a diode from 3.3V
<daveshah> that is what Lattice do in all their app notes
<swetland> oh cute
<adamgreig> if you don't need nvcm you can just put 3v3 onto vccnvcm, aiui
<swetland> then it's just core and io?
<adamgreig> the abs max is 3v6
<daveshah> requiring 1.2V core does keep power down too compared to an internal LDO
<swetland> yeah I doubt I'd ever use OTP vs external spiflash
<cpresser> the 'reference design' (as in lattice breakout boards) just has a 1.2 and 3.3 supply
<cpresser> and the diode trick
<adamgreig> ice40 lp/hx at least, the recommended operating conditions for VPP_2V5 when using spi config are 2.3-3.46V
<adamgreig> so I think the diode is only required if you plan to actually program the flash
<whitequark> except they use a schottky
<whitequark> instead of a silicon diode
<whitequark> lmao
<daveshah> :D
<daveshah> as for VccPLL
<daveshah> they managed to put the filter cap *before* the 100R resistor
<cpresser> the example has "CDBU0520" which drops around 0.15V
<cpresser> daveshah: yep, that was a wtf moment; I moved the caps in my design
<swetland> hw vendor reference designs are similar to hw vendor driver code... use caution at a minimum
<adamgreig> throw in the bin and ignore
<swetland> adamgreig: well sometimes they contain valuable clues about the truth behind the lies in the datasheets
<cpresser> its usually a good staring point.
<adamgreig> depends on the vendor i guess
<tnt> I make a small up5k board for experimentation and in doubt, I had 1.5A supply for Vcore, 2.5v IO and 3.3v IO ... I think that was a bit overkill now :p
<daveshah> Yes :P
<daveshah> Maybe if you *really* overvolt
<tnt> Well ... I originally soldered the fpga 90 deg off because I misread the pin1 marker on the silk screen ... no idea what voltage I sent where.
<tnt> Still works :p
<qu1j0t3> wow
<cpresser> i will most likely have 150mA Vcode and 200mA Vio. should be enough. battery powered, for the lulz
rohitksingh has quit [Ping timeout: 240 seconds]
<mithro> whitequark: Any idea how long you have to wait after a EOP before you can start a new packet?
<whitequark> mithro: EOP?
<whitequark> context?
<mithro> whitequark: End of Packet (USB high speed)
<whitequark> ah
<whitequark> no idea
<whitequark> I haven't implemented USB on that level
<mithro> Seems like " Low-/Full-Speed Bus Turn-around Time and Inter-packet Delay" -- "A device must provide at least two bit times of inter-packet delay. "
<swetland> something I'm kinda surprised more FPGA hobbyists don't play with is Ethernet. 10/100 PHYs are $1-3 in qty1 and RMII is surprisingly simple to interface with
<qu1j0t3> azonenberg_work has simply claimed that ground and won't cede an inch
<qu1j0t3> all the experimentation
<adamgreig> swetland: have you done a mac on fpga? i'm actually looking at this today for a little hobby thing
<adamgreig> torn between a $1 PHY and a $3 MAC+PHY
<adamgreig> microchip make three different families of MAC+PHY which you can talk to over a SPI or a 16-bit bus and just blat packets at
<adamgreig> (one they made themselves, one they bought from SMSC, one they bought from micrel)
<adamgreig> also I'd have expected mii to be easier than rmii to diy on an fpga
<adamgreig> since you don't have to fuss with clocks so much
<adamgreig> not sure how much of my {time,ice40hx8k} would be taken up by a mac though
<swetland> https://github.com/swetland/zynq-sandbox/tree/master/hdl look at eth_rmii_*.sv eth_capture.sv etc
<swetland> eth_rmii_{tx,rx}.sv handle getting packets on/off the wire
<swetland> eth_capture.sv is a sniffer interface against AXI (I built this all on ZYNQ)
<adamgreig> so talking rmii/mii to the phy seems alright
<adamgreig> but implementing a mac?
<swetland> just a matter of taking the inbound packet stream and writing it somewhere
<swetland> and fetching packets from somewhere and pushing them out
<swetland> most of what I was doing was a bit non-traditional, using ethernet for a robotics control bus
<adamgreig> like ethercat rather than tcp/ip?
<swetland> yeah
<swetland> designed where you have a chain of nodes that (in hw) send a status packet upstream every time a command packet flows downstream
<swetland> AXI interface on the other side of that, little rtos running on the A9 cores
<adamgreig> makes sense
<azonenberg_work> swetland: I did a *phy* on an fpga :D
<swetland> azonenberg_work: nice! that's a bit more impressive
<azonenberg_work> I mostly do gigabit on my fpga stuff
<swetland> RMII really is quite straightfoward
<azonenberg_work> (RGMII)
* swetland nods
<azonenberg_work> But i saw cnlohr had bitbanged 10baseT on an attinyt
<azonenberg_work> I decided to see how hard 100base-TX was to bitbang :p
<swetland> ahaha
<azonenberg_work> FPGA and a dozen resistors
<azonenberg_work> With pre-emphasis too :D
<azonenberg_work> swetland: anyway, i strongly recommend against using the ENC*24J600 or similar for an FPGA
<azonenberg_work> they're designed for MCU usage, the bus is incredibly awkward to use in FPGA
<swetland> oh those microchip spi mac/phy things?
<azonenberg_work> yeah
<azonenberg_work> There is no reason not to just put your mac in the fpga
<swetland> yeah, I just use an actual PHY speaking some MII descendant
<azonenberg_work> yeah
<azonenberg_work> i'm writing my... third? fpga tcp/ip stack
<adamgreig> azonenberg_work: is there much to the MAC?
<azonenberg_work> newly optimized and tweaked for 10G performance
<azonenberg_work> adamgreig: If you don't support half duplex it's quite trivial
<azonenberg_work> i consider half duplex deprecated and refuse to support it :p
<swetland> yeah, like I said, it's just take packets from rmii, drop 'em in a fifo or ram, take packets from fifo or ram and shoot 'em out rmii
<swetland> obviously you can get infinitely fancy on top of that
<adamgreig> sure, there's an awful lot of fanciness built in to the microchip mac+phy things
<adamgreig> but it's mostly stuff like filters, checksum offload, buffers, other things you don't really need
<azonenberg_work> i dont even have a buffer in my mac, i just spit out stuff 32 bits per clock
<azonenberg_work> my intended use case is hardware tcp/ip offload so i process everything in real time
<azonenberg_work> then have commit/drop flags to indicate whether the checksum was good or not
<azonenberg_work> As of now, despite the name, my TriSpeedEthernetMAC only works for 1G mode
<azonenberg_work> the CRC is wrong in 10/100
<adamgreig> well I think you've convinced me to give up on picking between microchip's exasperating selection of mac+phy chips
<adamgreig> why is the bus annoying to use from an fpga ooi?
<azonenberg_work> would be easy to fix but i deal with 10/100 so rarely i never had an incentive
<azonenberg_work> adamgreig: you have to poke registers and write data with address then data on one bus
<azonenberg_work> when you could just stream data out
<azonenberg_work> like, a GMII MAC is basically just "add the CRC at the end"
<adamgreig> I haven't looked at gmii at all; is it realistic on an ice40hx8k?
<adamgreig> application data rate is sub-100Mbps so was just going to do that
<azonenberg_work> adamgreig: 8 bits each way, source synchronous, at 125 MHz
<azonenberg_work> RGMII is the same thing but DDR'd to 250 MT/s on a 4-bit bus
<swetland> https://github.com/swetland/zynq-sandbox/blob/master/hdl/eth_rmii_rx.sv takes clk/dat0/dat1/crs from rmii, accepts packets, spits out bytes at a time, checks crc
<azonenberg_work> I dont know how fast ice40 is
<azonenberg_work> Gate count, not a problem
<daveshah> It's perhaps doable at a push on the HX
<daveshah> Most likely not on the slower LP or UP grades
<swetland> 100mbit 50mhz clock may be friendlier there
<azonenberg_work> Yeah
<azonenberg_work> I'm going to be implementing RMII for the first time on INTEGRALSTICK
<azonenberg_work> i have a RGMII PHY on the FPGA but the MCU has a RMII port on it
<azonenberg_work> so i'm going to be implementing a little switch on the FPGA where I push stuff for the MCU's MAC address to the MCU
<azonenberg_work> and process the other 900 Mbps worth of traffic on the FPGA
<adamgreig> heh
<swetland> ahaha
<adamgreig> and just talk rmii directly to the mcu?
<azonenberg_work> Yeah
<azonenberg_work> no phy for that link
<adamgreig> yea
<swetland> yeah I did similar with ZYNQ
<adamgreig> fun that that makes more sense than trying to do any other sort of high data rate bus into the mcu
<swetland> just to poke at it. for real stuff just used the AXI interfaces
<azonenberg_work> adamgreig: i hooked up the DCMI bus too, plus SPI and a uart
<azonenberg_work> But i expect rmii will be my mainstay
<azonenberg_work> Here's the board if you're curious
<adamgreig> my original plan here was fpga -> 16 bit memory bus -> mcu -> rmii -> phy -> ethernet
<adamgreig> but goodness is fpga -> phy going to be simpler
<azonenberg_work> adamgreig: yes, verym uch so
<swetland> yup
<daveshah> azonenberg_work: are those small bgas hyperram BTW?
<azonenberg_work> daveshah: the 2 at the top? yes
<adamgreig> is this the fast sampling scope?
<azonenberg_work> 2x 64M hyperram, artix7 ftg256, stm32f777 tfbga216, ksz9031
<azonenberg_work> adamgreig: no, this is a FPGA+MCU SoM that i plan to use as the brain of a lot of projects
<azonenberg_work> So i dont have to do all that bga fanout and decoupling over and over and over
<azonenberg_work> the idea is, you just drop in a pair of connectors and hook up peripherals
<azonenberg_work> then slap one of these on top
<azonenberg_work> you have fpga, mcu, ram, flash, and ethernet pre-assembled
<azonenberg_work> freesample may (i'm not 100% on this) be a host board for this module
<adamgreig> ah yes freesample was what i was thinking of
<adamgreig> nice
<adamgreig> why even have the f7 vs a slightly chunkier fpga?
<azonenberg_work> you mean a zynq?
<azonenberg_work> i wanted a MCU to run software-based stuff on, and it's much easier to bring up a cortex-M bare metal than a cortex-A
<adamgreig> sure, or some more gates for a softcore
<adamgreig> fair
<azonenberg_work> the stm32 also has half a MB of sram and 2 MB of flash
<adamgreig> the f7s are pretty nice anyway
<azonenberg_work> thats hard to get in an fpga :p
<azonenberg_work> and getting a softcore up to 200 MHz that has performance of a m7 is not easy
<adamgreig> tempted to use the f7 for fpga prom/programming?
<azonenberg_work> certainly not without using a ton of fpga gates
<azonenberg_work> No
<azonenberg_work> it has no connection to the fpga flash
<azonenberg_work> I plan to implement TFTP or something for firmware updates though
<azonenberg_work> in hardware on the fpga
<adamgreig> yes, ethernet bootloading for everything
<azonenberg_work> the mcu and fpga are both on one jtag chain
<azonenberg_work> which is the intended development firmware loading interface
<azonenberg_work> (no SWD)
<swetland> zynq is pretty nifty, but, yeah, you need a fair amount of goop to boot on A7 vs M3/M4
<azonenberg_work> So far i will be using integralstick as the brain of a DIN rail mount PLC-esque industrial controller
<azonenberg_work> the management CLI for LATENTRED
<azonenberg_work> and maybe the brain of FREESAMPLE
<swetland> on the other hand, we implemented much of that goop for lk back in '14 at replicant https://github.com/littlekernel/lk
<azonenberg_work> swetland: on the topic of fpga hobbyists doing ethernet...
<adamgreig> can be nice to be able to boot into linux with shared memory with the programmable logic though
<tavy> these names sound like somethingy ou'd see in a CIA leak
<adamgreig> they sort of are, right
<azonenberg_work> tavy: i suck at naming projects so i pick two random words
<azonenberg_work> if i dont like the sond, i repeat
<azonenberg_work> sound*
<azonenberg_work> occasionally i pick the words specifically for the project because they fit well
<swetland> switch baseboard for your som?
<azonenberg_work> like STARSHIPRAIDER is a dig at the bus pirate being slow and obsolete
<tavy> nice
<azonenberg_work> FREESAMPLE = f/oss + sampling oscilloscope
<azonenberg_work> swetland: Yes and no
<azonenberg_work> That's an 8 port SGMII line card
<swetland> ah
<azonenberg_work> LATENTRED will be a 24x 1G + 4x 10G port 1U ethernet switch
<azonenberg_work> three of those line cards, a backplane, and a brain board that has a big beefy kintex-7 for the switch fabric and an INTEGRALSTICK to run the CLI
<azonenberg_work> the FPGA will be used for I/O expansion because the kintex doesnt have enough pins left after 24 lanes of SGMII and a QDR-II+
<azonenberg_work> The original plan was to have the stm32 and a spartan7 on that board but i realized the combo was likely to be something i'd use in other projects so i refactored and put it into its own board
<azonenberg_work> then i swapped the spartan for an artix to get more pins
* swetland nods
<swetland> this is a familiar story
<azonenberg_work> right now i have the line card ready for fab (but may need tweaking of connector placement once i finish the brain board)
<azonenberg_work> i have to design the backplane and brain still
<azonenberg_work> integralstick is almost ready for fab
<azonenberg_work> the 10G MAC/PCS core is ready to go
<azonenberg_work> the 1G MAC is ready to go but i have to write a GMII-SGMII bridge
<azonenberg_work> the MAC address table with learning and vlan support is ready to go
<azonenberg_work> the arbitration and forwarding fabric for the switch needs to be written
<azonenberg_work> swetland: https://i.imgur.com/meEmIGS.png
<azonenberg_work> this is the planned overall structure
<azonenberg_work> buffer sizes to be tuned
<swetland> you doing this commercially or is this just a massive hobby project? ^^
<azonenberg_work> Massive hobby project. Lol
<_whitenotifier> [whitequark/Glasgow] marcan pushed 2 commits to master [+0/-0/±6] https://git.io/fp0Mf
<_whitenotifier> [whitequark/Glasgow] marcan 20b2f3d - Glasgow.lib: Add TCA9517 symbol
<_whitenotifier> [whitequark/Glasgow] marcan 06e0125 - revC: more layout work on port A & misc
lovepon has joined ##openfpga
Bob_Dole has quit [Remote host closed the connection]
Bob_Dole has joined ##openfpga
<whitequark> marshallh: :D
<whitequark> erm
<whitequark> marcan: ^
<marshallh> yeet
Dolu has quit [Ping timeout: 245 seconds]
tavy has quit [Ping timeout: 252 seconds]
Stary has joined ##openfpga
Adluc has quit [Ping timeout: 252 seconds]
Adluc has joined ##openfpga