prpplague has joined ##openfpga
Bike has joined ##openfpga
<sorear> what kinds of cheap chips would have DDR3 or DDR4 interfaces better than 800 MT/s
<prpplague> sorear: few "cheap" chips
<prpplague> sorear: if any
<prpplague> sorear: i can;t think of single one that you can get your hands on
<sorear> like a $5ish ecp5 can do 800 MT/s * x16 = 1.6 GB/s to a $5ish DDR3 chip; on the memory side you can definitely go much faster without a significant increase in cost but finding suitable controllers could be a challenge
<azonenberg_work> sorear: artix7 -3 can do ddr3 1066
<azonenberg_work> kintex7 -1 can do ddr3 1600 if you bump vccaux_io up to 2V, with default 1.8 it can do 1066
<azonenberg_work> in -2 you can do 1866 at 2.0V and 1333 at 1.8
<Bob_Dole> dem speedgrades
<Bob_Dole> how Wide could you reasonably go on ecp5 if you want to take that route over fast?
<Bob_Dole> I haven't looked at their packages to get pin count or speed capabilities of them
<azonenberg_work> Bob_Dole: i wouldnt go much over 32 bits on a dram controller, maaaybe 64
<azonenberg_work> per channel
<azonenberg_work> routing would be a nightmare after that
<Bob_Dole> it's a thing that might come up in the next year though, after SolraBizna's FACT has been made.
<azonenberg_work> FACT? is that that monster ecp5 cluster?
<Bob_Dole> FACT is just Durable 16bit computer with Some expandability.
<Bob_Dole> with a 65816 and ice40, an mram, and some sram at base level stuff.
<Bob_Dole> not sure I'll be commissioning him to do the GPU portion of desired risc-v system, or the risc-v system. Doing GPU probably has benefits in having an ecp5 and ram on a board that can be used for other development after getting the core and some driver work done on a normal desktop environment
<Bob_Dole> but that still.. is like 2 projects out. (ohgodastoldertest and fact.)
<Bob_Dole> thoughts moved to ust have an ecp5,, and I WAS proposing a wide pseudo-sram thing for the sake of simplicity, but if ddr3 is achievable why not? and a pci(e) interface.
<Bob_Dole> slightly tweaked risc-v core and tweaked llvmpipe to complement it as the Core/Driver
<sorear> $needsaname, operated as a vector machine, would have relatively terrible FP perf but actually competitive memory bandwidth :p
<sorear> i'm a little unclear how llvmpipe works in an asymmetric multiprocessing situation
<sorear> if I have N cores but only one of them is wired for vector issue
azonenberg_work has quit [Ping timeout: 264 seconds]
<Bob_Dole> being able to pair multiple cores in NUMA for llvmpipe to be able to use multiple fpgas to expand performance would be nice.
<Bob_Dole> but I am, at this very moment, considering "can I actually get solra to design this board and hack together a driver for it at all"
<bubble_buster> anybody familiar with bluespec? seems to be abandoned or in stealth mode?
<Bob_Dole> MIAOW might be a better thing to start from but there's risks in potentially pissing off amd. >.>
<Bob_Dole> I'm not, but now I want to know what that is, bubble_buster
<sorear> if you're not Threatening Their Revenue you don't have much to worry about
<sorear> bluespec is a company with a commercial-only HDL
<bubble_buster> seems to be heavily haskell based/inspired
<Bob_Dole> except companies sometimes feel obligated to sue, to make sure they can sue anyone that has a chance of threatening their revenue
<Bob_Dole> avoid the xerox situation and all that
<sorear> they're not dead, they're releasing new stuff just a few days ago
<sorear> it's hard for me to get too excited about a language with a proprietary compiler
<Bob_Dole> I am actively researching topics to develop a computer that would probably be roughly equivalent to my 400mhz Sun Ultra 5, to avoid proprietary.
<sorear> on the other hand, they're a (long) walk from here, and I'd like to meet the people involved *somehow*
<SolraBizna> does a HiFive Unleashed count as proprietary?
ym has joined ##openfpga
<Bob_Dole> no, but it counts as probably costing more than a couple fpgas with pci(e) linking them and maybe 100 dollars of RAM on it.
<Bob_Dole> and still probably needing the gpu side of things.
<Bob_Dole> and the gpu side of things maybe useful for getting useful graphics on a sun ultra 5 at this point in time.
<SolraBizna> I wouldn't be able to make a GPU that's faster than a FU540 running llvmpipe
balrog has quit [Quit: Bye]
<Bob_Dole> but how much of the fu540 be taken up running llvmpipe
<Bob_Dole> and also I was thinking about the U5 earlier. really sucks that All of its available GPUs have had driver dropped.
<Bob_Dole> and onboard only does 800x600 anyways.
<sorear> i'd like to see statistics on exactly what MATE (fex) needs the GPU to do
<Bob_Dole> useful info, I'm sure.
<Bob_Dole> (especially for desired application here.)
<sorear> the FU540… about 1/3 of the silicon area is for the four independent fma.d
<sorear> cores
<sorear> your gpu probably doesn't need 12 double precision GFLOPS
<sorear> (although that's kinda low by GPU standards, it's quite out of proportion with what the rest of the chip can do)
<Bob_Dole> the things I don't like about the FU540 is.. it uses a xilinx fpga to get an expansion bus on it and it costs 1k for a single board, without that.
<sorear> right, doing anything with shuttle chips is problematic
<sorear> hoping somebody mass-produces something with an exposed memory bus
<Bob_Dole> the FE310 would be nice if it had an exposed memory bus
<SolraBizna> the 65816 has all the processing power anyone could ever need
<Bob_Dole> get it running MATE and iceweasel
<SolraBizna> it was really hard to say that with a straight face
<sorear> dunno, factoring 512-bit numbers on the 65816 will be a slog
<SolraBizna> just need enough of them
<sorear> nobody needs to run iceweasel, but
<Bob_Dole> it might be a little harder to get chromium going
<SolraBizna> in seriousness, I don't know of any semi-modern web browser that can run in 16MiB of memory space
<Bob_Dole> yeah. Opera's Presto is the last thing I know of that was doing it
<Bob_Dole> and presto is dead
balrog has joined ##openfpga
<SolraBizna> sometimes I toy with the idea of making a giant computronium cube out of 65816es
<Bob_Dole> fpgas make it possible
<SolraBizna> it would be more fun if the gap between a 65816 and a "real CPU" weren't so great
<cr1901_modern> The only truly massive proble is the addr space.
<cr1901_modern> I just want an https/ssh impl on 6502/65816 and I would be happy, tbh. I can work around everything else.
<cr1901_modern> problem*
<SolraBizna> Doesn't sound too h...
* SolraBizna suddenly remembers that the S in HTTPS is for SSL
<cr1901_modern> Well, it's what the entire internet uses. And not much fun w/ homebrew that can't connect to other machines :)
<cr1901_modern> Deferring TLS stuff to an accelerator isn't a problem if it's truly impossible for 6502 to do TLS under its own power, but "using a computer orders of magnitude more powerful" defeats the point of retrofitting IMO
<SolraBizna> It's very possible, if you don't mind it being slow
<Bob_Dole> aren't there timeouts on that stuff
<Bob_Dole> so being slow can make it impossible
<cr1901_modern> That's what I'm afraid of
<cr1901_modern> I want possible, not fast
<SolraBizna> Hm...
<Bob_Dole> math time?
<cr1901_modern> sorear: ^^ Didn't you do the math?
<sorear> yes
<sorear> a 6502 can do a multiplication mod 2^255-19 in ~ 30K cycles
<sorear> at 1MHz, a curve25519 montgomery ladder takes about 2 minutes
<sorear> if you have 2MHz it should be very doable
<Bob_Dole> the 65816 mcu we're looking at can do 6-12mhz I think
<Bob_Dole> depending on voltage
<cr1901_modern> wdc silicon goes up to 14mhz officially; ppl have done up to 20mhz
<cr1901_modern> for 65816 and 25mhz for the 6502 impl they have
<Bob_Dole> 14mhz is at 5v though
<Bob_Dole> can't use very many memories with that anymore
<cr1901_modern> yes, in my case I would be using that :)
<cr1901_modern> Then I'll use dual voltage level shifters
<Bob_Dole> (bolt I suppose fast level shifters do exist)
<cr1901_modern> it's not worth losing half the bandwidth for that
<Bob_Dole> bolt? though*
<Bob_Dole> how the hell did I typo though as bolt
<sorear> Bob_Dole: bi-directional level shifters are very cursed
<cr1901_modern> I wouldn't use a bidir level shifter
<Bob_Dole> sorear, I've been a little worried about that detail
<whitequark> !track SCSI
<whitequark> glasgow scsi applet, how cursed is that
<cr1901_modern> wrong room?
<whitequark> oh
<whitequark> oops lol
<whitequark> seriously though
<whitequark> does anyone want it
<Bob_Dole> I haven't seen much about bi-directional level shifters that are usefully fast
<cr1901_modern> sorear: Err, autosensing bidir level shifters I wouldn't use
<whitequark> Bob_Dole: fxmas are up to 50 MHz
<cr1901_modern> ones with a manual dir pin should be fine
<whitequark> SN74LVTCs are like 250 MHz
<sorear> and the output will glitch at 50 MHz no matter what freq the input is!
<whitequark> yes
<Bob_Dole> I think I was looking at something adafruit was using that were way too slow and that's the only application I actually saw of them in use.. I suppose until whitequark's glasgow but I know nothing about those still. >.>
unixb0y has quit [Ping timeout: 264 seconds]
<cr1901_modern> SCSI has really stupid complex termination and cables :/ (well the 68 pin version anyway)
unixb0y has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
emeb has quit [Quit: Leaving.]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh_work has joined ##openfpga
lovepon has joined ##openfpga
azonenberg_work has joined ##openfpga
Zorix has quit [Ping timeout: 250 seconds]
Zorix has joined ##openfpga
Bike has quit [Quit: Lost terminal]
jcarpenter2 has quit [Ping timeout: 252 seconds]
jcarpenter2 has joined ##openfpga
futarisIRCcloud has joined ##openfpga
lovepon has quit [Ping timeout: 260 seconds]
lovepon has joined ##openfpga
lovepon has quit [Ping timeout: 252 seconds]
pie_ has quit [Ping timeout: 264 seconds]
GuzTech has joined ##openfpga
pie_ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
indy has quit [Remote host closed the connection]
indy has joined ##openfpga
m4ssi has joined ##openfpga
pie_ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<Bob_Dole> I keep seeing that futaris nick.. brain is autocompleting it to something different.
<whitequark> same >_>
<whitequark> also: futarchy
indy has quit [Ping timeout: 240 seconds]
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
<cr1901_modern> whitequark: How do you think I feel? We have a FUTA tax here.
<whitequark> incredible
hackkitten has quit [Read error: Connection reset by peer]
hackkitten has joined ##openfpga
<mwk> hey guys
<mwk> if anyone still has one of those laying around, I made a simple hacky script to program the FPGA on Digilent Basys 2 boards without using vendor tools
<mwk> I'm also going to add support for host-FPGA communication through the EPP protocol soon
<mwk> and: it seems a lot of other Digilent boards are using the same or same-ish protocol, so if anyone has such a board, I'd very much appreciate usbmon pcaps of you programming the FPGA via vendor tools
<mwk> especially if the device identifies as 0x1443:0x0007
<mwk> (but it seems there are likely other IDs that could be similiar)
<azonenberg_work> Nice, i'd love to add jtaghal support for those pogrmamers but dont have the time
<azonenberg_work> (pull requests welcome though)
<azonenberg_work> i can test on an Atlys once i dig mine up
<azonenberg_work> all of the boards i have handy right now are ftdi based
<mwk> are they digilent though?
<azonenberg_work> the atlys is
<mwk> there are some signs they could still use the same-ish protocol, just over a different transport
<azonenberg_work> the ac701 is a xilinx board with a digilent programmer module, ftdi based though
<azonenberg_work> the atlys has a... cypress mcu of some sort?
<mwk> fx2?
<mwk> yeah, those too
<azonenberg_work> i suspect
<azonenberg_work> but i havent looked at it in a while, it lived on a rack inside an old sun netra case :p
<mwk> AFAICT they use the same protocol, but you have to upload some fw to them to get them to speak it first
<mwk> while the basys2 has a preprogrammed AVR on it
<azonenberg_work> ah ok
<azonenberg_work> actually wait
<azonenberg_work> no it wasnt a fx2
<azonenberg_work> it was a pic
<azonenberg_work> pic24 or pic32
<mwk> hm
<mwk> *shrug*
<azonenberg_work> or was that for the usb-ps2 interface?
<azonenberg_work> i cant remember
<azonenberg_work> i'll check when i get a chance
<mwk> I'd say usbmon it and see :)
<mwk> anyway
<mwk> my main motivation for this is getting the EPP communication working
<azonenberg_work> more like, figure out which box it lives in :p
<mwk> for a uni project
<azonenberg_work> i have stuff all over the place during the construction
<mwk> programming it through jtag is just a bonus
<azonenberg_work> the only thing i have handy right now is my ac701
<azonenberg_work> and i had to move quite a few boxes to find it
<mwk> I quite like the lcient-server model of jtaghal
<mwk> but I suppose I cannot use it for anything other than jtag, right?
<azonenberg_work> It has very early stage SWD support
<azonenberg_work> and i do plan to eventually add other programming algorithms like PIC ICSP
<mwk> yeah, but
<mwk> I don't want to use it for programming
<mwk> but to talk to the already-programmed FPGA
<azonenberg_work> i have support for GPIO through FTDI programmers already
<azonenberg_work> adding more complex gpio functionality is totally doable
<azonenberg_work> i've also implemented my own antikernel noc over jtag protocol using it
<mwk> so ideally I'd like to have some hardware manager that handles the different ports of the USB device
<mwk> and connect EPP communication / JTAG programming to it through independent sockets
<mwk> EPP is not GPIO though, they handle it in the AVR firmware
<mwk> you send address, data tuples and it hanldes the protocol for you
<azonenberg_work> doesnt matter, from the perspective of a jtaghal client
<azonenberg_work> it's some kind of additional io interface on the programmer
<azonenberg_work> you might be able to bolt it on by exposing it as a debugger interface
<azonenberg_work> treat it as a memory mapped device
<azonenberg_work> not sure yet
<azonenberg_work> if you implement the programmer protocol we can talk over the best way to fit in the other features
<keesj> mwk: nice (to have a python based programmer)
pie_ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
Guest88256 has quit [Quit: leaving]
WilhelmVonWeiner has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
tpw_rules has quit [Excess Flood]
tpw_rules has joined ##openfpga
Bike has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 252 seconds]
genii has joined ##openfpga
pie_ has joined ##openfpga
rohitksingh has joined ##openfpga
plaes has joined ##openfpga
<tnt> "arachne-pnr: src/ void Router::route(): Assertion `cnet_net[cn] == nullptr || cnet_net[cn] == n' failed."
<tnt> Ring a bell to anyone ?
<tnt> I mean there is but it's supposed to be fixed.
<tnt> next-pnr also can't route that design :/
<daveshah> tnt: can you put the design somewhere?
pie_ has quit [Ping timeout: 264 seconds]
<tnt> daveshah:
<tnt> daveshah: for info, this actually works in a up5k. But trying a lp384 fails. icecube also works fine on the lp384 with half the fpga unused.
SpaceCoaster has quit [Ping timeout: 244 seconds]
SpaceCoaster has joined ##openfpga
pie_ has joined ##openfpga
<tnt> daveshah: any idea ? :)
<daveshah> Just looking, was afk
<daveshah> I guess it is to do with OUTPUT_CLK
<tnt> OUTPUT_CLK ?
<tnt> Ah on some IOBs ?
<daveshah> Yes. It seems that you have OUTPUT_CLK connected to a clock for one IOB of a tile, and ground/unused for the other IOB
<daveshah> There is only one OUTPUT_CLK per tile, so that is not allowed
<tnt> Interesting is that if I disable global promotion, it works.
<daveshah> Hmm
<sorear> is it a fileable bug that that asserts instead of giving an actionable error message?
<daveshah> Yes
<daveshah> Doesn't mean anyone will fix it
Bike_ has joined ##openfpga
<daveshah> I don't really have time for ice40 stuff before July 2019
<tnt> in the .blif, all the OUTPUT_CLK=clk_48m for all the SB_IO.
Bike has quit [Ping timeout: 256 seconds]
<sorear> sure, but if it's not recorded somewhere it will never be fixed]
<sorear> if it's recorded with a test case somebody can fix it in a few years
<sorear> i prefer "a few years" over "never"
<tnt> well I'm trying to understand the actual issue ...
<tnt> seems that if clk is in a global buffer, it fails.
<tnt> (wether it's auto-promoted or instanciated manually)
<daveshah> That is really odd
Bike_ is now known as Bike
m4ssi has quit [Remote host closed the connection]
renze has quit [Ping timeout: 252 seconds]
Miyu has joined ##openfpga
renze has joined ##openfpga
indy has joined ##openfpga
emeb has joined ##openfpga
<tnt> What's "X7/Y8/io_global/latch." ?
* prpplague trolls
<prpplague> tnt: it's the upgraded version of "V5/W6/io_local/switch"
<daveshah> tnt: that is the signal that latches the input value (icegate)
Laksen has joined ##openfpga
Miyu has quit [Ping timeout: 272 seconds]
emeb has quit [Ping timeout: 240 seconds]
emeb has joined ##openfpga
<tnt> Is there an option to disable net promotion in next-pnr ?
<tnt> daveshah: Mmmm, does that have anything to do with global buffers ?
<tnt> Ah ... instanciating a SB_GB_IO for the block pin directly fixes the issue.
mumptai has joined ##openfpga
<daveshah> tnt: aha
<daveshah> The problem is that the input to the latches (1'b0) is shared with the input to one of the global buffers
uovo has joined ##openfpga
<daveshah> using the pad input to the global buffer with an SB_GB_IO would fix that
<daveshah> tbh, I'm not sure how well tested the 384 support is at all...
renze_ has joined ##openfpga
laintoo_ has joined ##openfpga
Patater_ has joined ##openfpga
OhGodAGuardian2 has joined ##openfpga
plaes_ has joined ##openfpga
q3k1 has joined ##openfpga
jn___ has joined ##openfpga
tnt_ has joined ##openfpga
WilhelmV1nWeiner has joined ##openfpga
eightdot_ has joined ##openfpga
implr_ has joined ##openfpga
SolraBiz1a has joined ##openfpga
keesj_ has joined ##openfpga
rvense_ has joined ##openfpga
renze has quit [*.net *.split]
WilhelmVonWeiner has quit [*.net *.split]
gnufan has quit [*.net *.split]
keesj has quit [*.net *.split]
sgstair has quit [*.net *.split]
SolraBizna has quit [*.net *.split]
oeuf has quit [*.net *.split]
eightdot has quit [*.net *.split]
vup has quit [*.net *.split]
Patater has quit [*.net *.split]
q3k has quit [*.net *.split]
plaes has quit [*.net *.split]
OhGodAGuardian has quit [*.net *.split]
rvense has quit [*.net *.split]
Miyu has joined ##openfpga
tnt has quit [*.net *.split]
jn__ has quit [*.net *.split]
laintoo has quit [*.net *.split]
implr has quit [*.net *.split]
jn___ is now known as jn__
vup has joined ##openfpga
plaes_ has quit [Quit: Reconnecting]
plaes has joined ##openfpga
kristianpaul has joined ##openfpga
gnufan has joined ##openfpga
sgstair has joined ##openfpga
rvense_ is now known as rvense
implr_ is now known as implr
tnt_ is now known as tnt
<tnt> Leaving the .LATCH_INPUT_VALUE of all the instanciated SB_IO unconnected also works ...
<tnt> I'm failing miserably at re-creating the issue in a test case though.
Bike_ has joined ##openfpga
Bike has quit [Ping timeout: 256 seconds]
Bob_Dole has quit [Read error: Connection reset by peer]
Richard_Simmons has joined ##openfpga
Richard_Simmons is now known as Bob_Dole
ym has quit [Ping timeout: 264 seconds]
ym has joined ##openfpga
Sellerie has joined ##openfpga
<shapr> rqou: did you produce different boards for the weird russian nixie display panels?
<shapr> cause I have the urge to get mine working
Laksen has quit [Quit: Leaving]
Bike_ is now known as Bike
uovo is now known as oeuf
oeuf is now known as Ei
Ei is now known as oeuf
Bike has quit []
q3k1 is now known as q3k
azonenberg_work has quit [Read error: Connection reset by peer]
azonenberg_work has joined ##openfpga
mumptai has quit [Quit: Verlassend]
* qu1j0t3 pays attention
WilhelmV1nWeiner has quit [Quit: Reconnecting]
WilhelmVonWeiner has joined ##openfpga
Bike has joined ##openfpga
genii has quit [Remote host closed the connection]
emeb has quit [Quit: Leaving.]