<qu1j0t3>
pie_: Unwarranted and nasty sarcasm aside, though, I've acquired a vintage Fluke DMM that's got a slight fault x_x Another project for a noob
<pie_>
woooo~ \o/ xD
<pie_>
well now i have another person to look up to
<pie_>
unwarranted nasty sjw stuff aside, i could not decide if she was a woman or a man, even though im pretty sure Tatjana is a womans name xD i guess today is just that kind of day
<pie_>
qu1j0t3, anyway that stuff is glorious
<qu1j0t3>
pie_: Isn't it though!
<pie_>
"Verbalisations tend to exclude reality.
<pie_>
Just look, maintaining internal silence, until the meaning of my work becomes clear."
<pie_>
" Tatjana built this ocilloscope in 1958. She was only 14 years old. An interest in scientific instruments was established at an early age." wait wait wait
<pie_>
qu1j0t3, kinda sucks how theres only pictures though
specing has quit [Read error: Connection reset by peer]
azonenberg_work has quit [Ping timeout: 260 seconds]
promach__ has joined ##openfpga
promach__ has quit [Client Quit]
scrts has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
m_w has quit [Quit: leaving]
DingoSaar has quit [Remote host closed the connection]
DingoSaar has joined ##openfpga
oeuf has quit [Read error: Connection reset by peer]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
oeuf has joined ##openfpga
<rqou>
offtopic question: can somebody explain to me what exactly a debian "binNMU" is?
<rqou>
debian documentation doesn't seem to make much sense unless you already know how everything works
_whitelogger has joined ##openfpga
theMagnumOrange has joined ##openfpga
theMagnumOrange has quit [Max SendQ exceeded]
theMagnumOrange has joined ##openfpga
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 248 seconds]
indy has quit [Ping timeout: 258 seconds]
indy has joined ##openfpga
digshadow has joined ##openfpga
scrts has joined ##openfpga
<eduardo__>
rqou: no problem. Lets see in one year how things go when you are done with your master.
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
cr1901 has quit [Ping timeout: 246 seconds]
cr1901 has joined ##openfpga
JSharp is now known as jaesharp
jaesharp is now known as JSharp
awygle has joined ##openfpga
<awygle>
whew. moved. in the sense that my worldly possessions are piled in a corner of this (quite nice) apartment and i can only access the internet through my phone.
awygle has quit [Ping timeout: 260 seconds]
cr1901_modern has quit [Read error: Connection reset by peer]
specing has joined ##openfpga
teepee has quit [Ping timeout: 245 seconds]
teepee has joined ##openfpga
Marex has quit [*.net *.split]
brizzo has quit [*.net *.split]
wolfspraul has quit [*.net *.split]
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
promach__ has joined ##openfpga
specing has quit [Ping timeout: 255 seconds]
m_t has joined ##openfpga
promach__ has quit [Quit: Leaving]
Marex has joined ##openfpga
brizzo has joined ##openfpga
wolfspraul has joined ##openfpga
laintree has joined ##openfpga
laintoo__ has quit [Ping timeout: 255 seconds]
coino has quit [Ping timeout: 248 seconds]
digshadow has quit [Ping timeout: 248 seconds]
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 260 seconds]
teepee has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
m_t has quit [Quit: Leaving]
scrts has joined ##openfpga
specing has joined ##openfpga
teepee has quit [Ping timeout: 255 seconds]
teepee has joined ##openfpga
<felix_>
eduardo__: i wonder if you already have written to the 34c3 assembly team that we want a (open) fpga assembly? there was some email maybe a month ago; if you didn't get that, i could formward it to you
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
DingoSaar has quit [Remote host closed the connection]
<rqou>
alright, felix_ please please try to get me a voucher
enriq has joined ##openfpga
<rqou>
azonenberg: fun problem: addition is commutative, so individual adder bits can be flipped
<rqou>
there probably isn't a good way to tell which signals should be grouped together
<enriq>
hello. Ive been told that people here is developing free tools for fpgas here. I was asking at ##fpga about command line tools to program a CPLS, namely the ISE Design Suite
<rqou>
hi enriq
<enriq>
sorry I meant, namely the Xc9572xl
<enriq>
ehllo rqou
<rqou>
yes, we're working on some open-source tools, but they're not quite "ready for production" yet
<enriq>
and cpld like that one is supported?
<rqou>
also, nobody is working on the 9500/9500xl right now. those parts aren't as powerful and are super old
<enriq>
this is just "hobby" for me
<rqou>
the current work is on the coolrunner-ii
<rqou>
is there a particular reason you want to use the 9500xl series?
eduardo_ has joined ##openfpga
<enriq>
rqou because I can get it here cheap (I live in argentina), it's more than adequate for my needs
<enriq>
but I'll check the coolruuner-ii
<enriq>
I'm pretty newbie
<rqou>
the major feature that you lose in coolrunner-ii is 5v tolerant IOs
<enriq>
I was looking at a "punk" way of programming
<enriq>
not that awful 5GB ide
eduardo__ has quit [Ping timeout: 260 seconds]
<azonenberg>
enriq: yeah oru tools are a bit smaller than tha t:p
<azonenberg>
this is where we are with the 32a bitstream RE - effectively done
<rqou>
unless you want to solve the "how to place P-terms effectively without blocking other macrocells" problem
<azonenberg>
we're still working on the toolchain stuff
<rqou>
fixed OR arrays suck
<balrog>
ahh, xc9 is fixed-or?
<rqou>
yup, most cplds seem to be fixed-or
<rqou>
but it has "p-term steering/stealing"
<rqou>
with a really complicated diagram to explain how to do that
<balrog>
oh, that
<balrog>
so it can "borrow" p-terms from unused cells?
<enriq>
rqou I'll ask which chip the board has. Which one has to be?
<felix_>
rqou: i'll see what i can do. other question is if eduardo_ (or someone else) also tries to get a voucher for the project; it's not that likely that we get two or more replicating vouchers
<enriq>
you say that it looks like the correct one?
<rqou>
enriq: right now the tools aren't ready yet, but xc2c64a will probably be added soon
<azonenberg>
enriq: as of now the two most developed backends for our project are Silego GreenPAK4 and Xilinx CoolRunner-II, with the most fully supported chips being the slg46620/slg46621 and xc2c32a
<azonenberg>
We have to figure out one ROM on the 64a to support it, then do a bit of coding
<rqou>
enriq: from what i've seen, most xbox modchips are an xc2c64a, but some are an xc2c128
<rqou>
they're both coolrunner-ii
<enriq>
so apt for these tools
<enriq>
good
* enriq
downloads and buys
<rqou>
balrog: yeah, it can borrow p-terms from unused cells, but only in some cases and not other cases
test123456 has quit [Quit: Leaving]
<rqou>
and then the timing calculations get really complicated
<rqou>
because going through the mux is often slower
<balrog>
yup
<rqou>
also, interestingly, afaict the 9500 and 9500xl are different
<rqou>
but we don't know how exactly
<balrog>
any decaps of either/both?
<balrog>
anyone compared bitstreams?
<rqou>
yeah, the bitstreams for the 9500/9500xl don't have any hints/comments
<rqou>
unlike XPLA3/coolrunner-ii bitstreams
<rqou>
decaps aren't likely to be that necessary
<rqou>
CPLDs tend to be pretty simple. it's just that nobody has spent the time to work on it
<rqou>
e.g. coolrunner-ii .jed files have comments like 'Note Block 0 PLA AND array *'
digshadow has quit [Ping timeout: 276 seconds]
<rqou>
whereas xc9500xl bitstreams are just several thousand lines of 'L0000000 00000000 00000000*'
digshadow has joined ##openfpga
<azonenberg>
balrog: i have decaps and top metal images
<enriq>
the tools compile on linux right?
<balrog>
azonenberg: are they on sipr0n?
<rqou>
our tools compile on linux but also work on mac/windows
<azonenberg>
rqou: i notice you inferred an xor3 for the top bit of the adder
<rqou>
yeah, because there's no carry-out
<rqou>
i'm working on it :P
<azonenberg>
I think it would make more sense to say, if you have a xor3 with one input driven by a carry output of a full adder
<azonenberg>
create a full adder and leave the carry-out NC
<rqou>
yeah, i'm working on it
<rqou>
i'm going to do that at the same time i convert the rest of the chain into $alu
<rqou>
this step finally involves writing "real code" :P
<azonenberg>
That works
<rqou>
actually wait
<rqou>
ugh
<rqou>
$add has no carry-in/carry-out
<rqou>
but the verilog backend doesn't understand $alu
<rqou>
i guess if there's no carry in, no carry out, and no fanouts on any of the carry wires, i'll generate $add/$sub instead
<azonenberg>
Carry in/out is easy
<azonenberg>
Well, carry out is easy
<azonenberg>
just make the result 1 bit wider
<azonenberg>
zero-pad the inputs
<azonenberg>
Carry in i can't imagine encountering unless the cell it originated from was a half adder in which case you absorb it into the adder chain
<azonenberg>
If it's something else, you just leave them as adder cells or something because they might not have actually been real adders
<azonenberg>
just some other logic function that was equivalent to a full adder
<azonenberg>
Make sense?
promach has quit [Quit: SuchZNC - Such ZNC, many free, w0w... -- https://suchznc.net]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
<rqou>
hmm, but what about an "actual CPU ALU?"
<coino>
is there a way to drive 1,5 GHz memory from 33MHz clock
<rqou>
PLLs?
<rqou>
although this sounds like a really strange question. what are you trying to do?
<coino>
drive GDRR5
<coino>
from PSoC
<rqou>
that's unlikely to work
<coino>
why
<rqou>
psoc probably isn't fast enough
<rqou>
why are you trying to use gddr5?
<coino>
bandwidth
<coino>
200 GB/s
<rqou>
but the datapaths in your controller (the psoc in your case) need to have that much bandwidth too
<rqou>
i don't think psoc does
<coino>
I see
<rqou>
what are you building? can you use a more powerful FPGA?
<coino>
cryptography hashing
<rqou>
a scrypt miner?
<coino>
I suppose, GPU are very efficient
<rqou>
you almost certainly need an asic to be competitive
<coino>
competitive with what
<rqou>
with other miners
<coino>
nit's not scrypt
<coino>
diff algo
<rqou>
i thought all cryptocurrency miners were now asics?
<coino>
Etash is memory hard
<coino>
rqou, no
<rqou>
so the "butterfly labs" stuff i've seen die photos of
<rqou>
what is that for?
<azonenberg>
rqou: sha256
<azonenberg>
bitcoin
<azonenberg>
it's IBM 65nm iirc
<azonenberg>
coino: you're not going to run gddr5 on a psoc
<rqou>
zeptobars says TSMC, not IBM
<azonenberg>
for starters, most dram (including gddr5) has a minimum refresh frequency
<azonenberg>
coino: and if you clock it too slow you'l lspend all your time on refreshes and have none for accessing it
<azonenberg>
rqou: which BFL part? there's probably more than one
<rqou>
oh sorry, i got it confused with yet some other bitcoin asics
<azonenberg>
coino: doesnt matter, if you had a faster FPGA you'd be fine
<azonenberg>
but psoc cant get close to that operating freq
<rqou>
yeah, you can usually overclock programmable logic, but not _that_ much
<coino>
azonenberg, FPGA max operating frequency + GPIO speed?
<azonenberg>
coino: max frequency depends on the logic you're running
<azonenberg>
But i can assue you that the io toggle rate of a psoc is not above 100 MHz
<azonenberg>
assure*
<coino>
how do GPU do 200 GB/s
<azonenberg>
and you'd need closer to 1 GHz to use GDDRx properly
<azonenberg>
coino: first, they have really wide memory buses
<azonenberg>
512+ bit
<coino>
not all
<azonenberg>
Allowing for address pins etc you're looking at 800+ pins on your chip just to talk to the ram
<azonenberg>
The GTX 1080, just to use a random example
<azonenberg>
is 320 GB/s memory bandwidth across a 256 bit bus
<coino>
800 io pins
<coino>
wow
<azonenberg>
Which is 10 Gbps on each of 256 pins
<coino>
so like a 10Gbps FPGA with 256 bit bus
<azonenberg>
There is no fpga on the market with that many serdes
<coino>
seems GPU are very efficient
<rqou>
are they actually serdes?
<azonenberg>
rqou: I dont know if they do clock recovery
<azonenberg>
but they're certainly serializers of some sort
<azonenberg>
coino: the biggest virtex ultrascale+ has 128 transceivers, up to 32 Gbps each
<azonenberg>
But you can only use 10 Gbps for GDDR5
<rqou>
but PHASER_OUT is also a "serializer of some sort"
<azonenberg>
rqou: yes but the normal selectio can't do 10 Gbps
<coino>
azonenberg, so that ultrascale would be overkill and expsneive
<azonenberg>
coino: So, your max bandwidth coming off that chip is 524 GB/s and that goes down to 160 GB/s if you run each of the transceivers at 10 Gbps
<azonenberg>
Best option if you want lots of ram bandwidth on a modern FPGA is probably to just throw lots of DDR4 on there
<rqou>
why don't we have FPGAs with HBM/eDRAM yet?
<azonenberg>
rqou: i think they're coming out in the next generation
<azonenberg>
altera at least is working on them
<coino>
whats the point if they cost 20k
<azonenberg>
coino: asic prototyping
<azonenberg>
Not bitcoin mining :p
<rqou>
you can probably get xilinx to knock it down a couple k :P
<azonenberg>
So let's see, max GPIOs on a virtex ultrascale is ~1400, call it 1024 bit for your theoretical max DDR4 bus at 2.6 GT/s per pin is 332 GB/s
<coino>
azonenberg, is it feasible to to something that is 1/10, 1/100 smaller scale/cheaper
<azonenberg>
(allowing some pins for address/control)
<azonenberg>
Keep in mind you're talking sixteen sodimms here
<azonenberg>
have fun designing that board
<azonenberg>
It won't be cheap
<coino>
someone suggested using LPDDR3 and optimize for power use instead of speed
<azonenberg>
Also, offtopic for this channel
<azonenberg>
since certainly nothing supported by an open toolchain at this point has any kind of performance close to that
<rqou>
feel free to contribute :P
<coino>
i see
<coino>
thanks
<azonenberg>
Side note i'm impressed
<azonenberg>
i did not know GPUs were up to 10gbps per GPIO for RAM yet
<rqou>
me neither
<azonenberg>
is that single ended you think?
<coino>
there are new models with HBM2 coming out
<azonenberg>
or something akin to LVDS
<coino>
seems like FPGA are way behind
<azonenberg>
coino: FPGAs don't sell hundreds of millions of units like GPUs do
<azonenberg>
they lack economies of scale
<azonenberg>
especially on the high end
<rqou>
although from what i've seen xilinx fpgas really are a bit lacking on IO
<azonenberg>
the giant ones are nomrlaly only used for asic prototyping
<azonenberg>
also most big stuff is message passing, not shared memory
<azonenberg>
shared mem scales very poorly
<coino>
Etash algo is a memory hard algo
<coino>
makes it ASIC resistant because it forces a time-memory ratio worse than 1:1
<coino>
that's why GPU are good, with 200Gb/s
<azonenberg>
So give up and use gpus like everyone else?
<coino>
well sure
<coino>
but what's the fun in that
<azonenberg>
Or use real money :p
<coino>
:)
<coino>
real money instead of monopoly money?
<azonenberg>
instead of magic computer money that costs as much in electricity to produce as it's worth
<azonenberg>
If you're lucky
<azonenberg>
Don't forget the power bill of your air conditioner
<coino>
azonenberg, that was one of the motivations
<coino>
a smaller scale device
<coino>
that could run on less power
<azonenberg>
So you want something that uses $100 instead of $1000 a month
<azonenberg>
to produce $50 instead of $500 of magic computer money
<coino>
doesn't seem feasible tho
<azonenberg>
I fail to see the point
<coino>
you mean unless it's more efficient
<coino>
I suppose this is where ASIC come into play
<cr1901>
azonenberg (when you get the chance): What are the synthesis semantics of assigning an initial value to a Verilog reg _without_ using an "initial" statement later to assign the value?
<azonenberg>
cr1901: reg[3:0] foo = 4'ha;
<cr1901>
yes exactly
<azonenberg>
just like declaring + initializing a variable in C
<cr1901>
then what is the "initial" keyword for in the context of "initial reg[3:0] foo = 4'ha;"
<cr1901>
or "initial foo = 4'ha;"
* cr1901
doesn't remember which is legal
<azonenberg>
the former is, i think, not legal
<azonenberg>
the latter is initializing ,but not declaring
<azonenberg>
you still have to declare foo
<azonenberg>
so you could do reg[3:0] foo; initial foo = 4'ha;
<rqou>
azonenberg: you're forgetting about default net types :P
<azonenberg>
rqou: if you ever write RTL that relies on a default net type
<azonenberg>
get lost :p
<cr1901>
Interesting that it requires a keyword to initialize after declaring...
<cr1901>
in any case, Verilog is confusing, example #4987
<azonenberg>
cr1901: So, that's actually a shortcut for
<azonenberg>
initial
<azonenberg>
foo = 4'ha;
<azonenberg>
Which is a shortcut for
<azonenberg>
initial begin
<azonenberg>
end
<azonenberg>
foo = 4'ha;
<azonenberg>
all assignments in verilog must be in either a "initial" or "always" block
<cr1901>
Ahhh okay, now it makes sense. They just allow that shortcut for convenience
<azonenberg>
It's a side effect of the begin/end "curly braces" being optional for a single-statement block, just like in C
<azonenberg>
and the newline vs whitespace being treated the same by the parser
<azonenberg>
same way you could say if(foo) bar=1;
<azonenberg>
in C
<cr1901>
Ohh, right I forgot about that
<cr1901>
mainly b/c I don't rely on that shortcut in my own code (and it's kinda pet peeve when I see it in others)
<azonenberg>
i always initialize regs in the declaration or not at all
<azonenberg>
the only exception is if i need a loop or something to fill a 2D array
<cr1901>
azonenberg, so Idk if you've seen the orconf presentation on yosys, but it has this example >>
<cr1901>
I just lost about 18 hours (on and off) because I didn't recognize that the initial value was 0
<azonenberg>
Waaait
<azonenberg>
why is cnt commented out
<cr1901>
oops
<cr1901>
that was me testing something
<cr1901>
ignore the comment, sorry :P
<azonenberg>
Lol
m_t has quit [Quit: Leaving]
<cr1901>
B/c there was no initial next to "cnt"'s declaration, I implicitly assumed it was ignored, not realizing the "initial" was implicit
<cr1901>
(And yes, commenting cnt out does make BMC fail)
<jn__>
[slightly off-topic] hmm, "Cadence's QuickTurn emulation system is a Solaris-based chip emulation system" (source: a patch from nvidia in ARM Trusted Firmware). interesting that there are still commercial products that run on Solaris
<rqou>
maybe it's solaris x86?
<jn__>
possibly
DocScrutinizer05 has quit [Disconnected by services]