<ZirconiumX>
Doesn't the Chrome Nix package have to do something cursed like break SHA-1 because of it trying to self-update or something?
<eddyb>
I have no idea
<whitequark>
ZirconiumX: no that's someone just showing off i think
<pepijndevos>
whitequark: I'm super curious how you plan to improve your CPU. Mine is very... minimalistic, so given all the stuff boneless supports, it's probably better than mine in features/area.
<emily>
mhm, I've started to maintain the free fpga tools in nixpkgs
<emily>
well, except ghdl which someone complained about being old still :P
<emily>
currently getting ready to bang my head against glasgow
<pepijndevos>
whitequark: Not sure I get what you mean by nstage cpi pipelining, since as you say, if every stage needs a memory cycle, what is there to gain?
<_whitenotifier>
[whitequark/libfx2] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjAQP
<pepijndevos>
whitequark: my problem is more fundamental... hence I'm reading wikipedia pages... my understanding of what pipelining is is just not compatible with *not* doing things in parallel, so I'm trying to understand what you even mean. Because you can't just do a fetch every cycle, so not sure how you get rid of the state machine.
<whitequark>
pepijndevos: the state machine would be implicit in the pipeline interlocks
<whitequark>
it'd do the same thing basically
interruptinuse has joined ##openfpga
<whitequark>
but laid out in a way more friendly to synthesizers
<whitequark>
think of it this way
<whitequark>
i am describing a process
<whitequark>
an FSM describes it in imperative way
<whitequark>
a pipeline describes it in a dataflow way
<pepijndevos>
hmmmm
<ZirconiumX>
Sure, but doesn't that mean you can still only have one instruction in flight at a time?
<whitequark>
of course
<whitequark>
that's fine
<pepijndevos>
So I imagine you'd have each stage just try to do its thing and have some data-ready signal to the next stage, or some bus arbiter on the memory... which just sounds like a one-hot encoded state machine, but if that makes the synthesizer more happy, sure :)
<whitequark>
pepijndevos: exactly that
<whitequark>
i already have a bus arbiter actually
<pepijndevos>
ok haha
<eddyb>
> Can't find iCE FTDI USB device (vendor_id 0x0403, device_id 0x6010 or 0x6014).
<eddyb>
hehe nice it works now! well, I need to plug my iCEstick in, but at least everything else is unbroken
<pepijndevos>
I've been thinking about making my CPU pipelined, but for me the *MAJOR* constraint is area. I'd rather have it run at 100kHz than make a PCB with 200 chips, eh, ZirconiumX?
<pepijndevos>
But mine is bit-serial, so it'd be a *MAJOR* speedup, potentially.
<ZirconiumX>
I mean, being a bit-serial architecture means it'll run at 100 kinsn/s anyway :P
<whitequark>
pepijndevos: in case of glasgow pipelining shouldn't make an FPGA impl any larger
<whitequark>
since most LUTs come with free FFs
<whitequark>
well. all LUTs
<pepijndevos>
lol, yea , not the case on 7400 logic sadly
<ZirconiumX>
So, with the fastest DIP SRAM I could find at 12ns, Boneless can do ~20MHz
<ZirconiumX>
Sorry
<ZirconiumX>
20 Minsns/s
<whitequark>
that's faster than on ice40
<pepijndevos>
ZirconiumX: how do you calculate these numbers?
<pepijndevos>
Yea, but... can the rest of the CPU do 20MHz on 74AC?
<ZirconiumX>
First I'd need to work out the critical path for it :P
<whitequark>
80 MHz
<whitequark>
(probably not)
<whitequark>
i preemptively apologize for how inefficient my CPU is
<pepijndevos>
ZirconiumX: what I did to get a ballpark figure is run LTP, and multiply that number with the propagation delay of the average 74AC chip
<pepijndevos>
IIRC that's about 5ns typical or 8ns worst
<whitequark>
spherical 74AC chip in vacuum
<pepijndevos>
exactly haha
<pepijndevos>
So my topoligical path was like 9 long so rougly 80ns worst case or 50ns on average
<pepijndevos>
So anyewere between 10-20MHz maybe
<pepijndevos>
But I assume for boneless the critical path might be longer
<ZirconiumX>
Let's find out!
<whitequark>
the carry chains are huge
<whitequark>
like you're looking at 16 levels for carries and probably at least 3 more if not worse
<pepijndevos>
bit-serial ftw
<ZirconiumX>
Well, the 74283 is a 4-bit carry-skip adder
<ZirconiumX>
(or that's how it's generally implemented anyway)
<whitequark>
oh interesting
<ZirconiumX>
Fastest adder with 7400 logic is probably pairing 74181/74182 for LCU
<ZirconiumX>
Unfortunately those are difficult to obtain
<pepijndevos>
whitequark: here is an idea to make it faster and pipelined: nyble-serial!! Since every instruction almost takes 4 cycles, you can do a 16 bit op in 4 serial parts of 4 bits :)))
<whitequark>
;w;
<pepijndevos>
I think in general carry-lookahead adders are done in max 4 bits too, so perfect match XD
<mwk>
aaaaa
<pepijndevos>
I'm not l33t enough to know what ;w; means
<ZirconiumX>
It's an emoticon :P
<pepijndevos>
(or google is not good enough at googleing puctuation)
<pepijndevos>
But it does not look like anything to me...
<whitequark>
i'm an eldritch creature from deep sea actually
<emily>
it's a crying cat face
<whitequark>
yes
<emily>
the dot is the eye, the comma is the tear, the w is the face
<emily>
it's like "o.o"
<pepijndevos>
wow...
<emily>
it is the most important emoticon. and also the most important emotion
<ZirconiumX>
One of these days this channel will end up on /r/nocontext
<emily>
also, when is boneless going to use those potatosemi chips
<pepijndevos>
I did a learn
<emily>
(w is a cat face because... well, cat faces kind of look like that. it's a sideways :3 that suffers a bit from it)
<emily>
shocking conclusion: :'3 = ;w;
<pepijndevos>
WHAT IS A POTATOSEMI CHIP??? THIS CHANNEL IS SO CONFUSING haha
<ZirconiumX>
emily: The potato semi chips are limiting enough that the propagation delay might make it slower
<emily>
even though they seem to express very different emoticons to me
<ZirconiumX>
pepijndevos: gigahertz frequency 74 logic
<emily>
:'3 "oh boy, that's great. i'm having lots of fun right now. please ignore the tears"
<ZirconiumX>
Made by Potato Semiconductors
<whitequark>
it's actually called that
<whitequark>
it's a pun on "potato chips"
<whitequark>
not sure if Yagami Light was involved or not
<pepijndevos>
ZirconiumX: I think the output should be the same, but it will include different things, and may not include the source dff or target dff itself depending on how far you go in eihter direction
<eddyb>
`python setup.py develop` outside of virtualenv appears to try to write into global directories, which can't possibly work... but I'm an idiot and I should make `.` a Nix python package lol
<ZirconiumX>
The architecture itself is essentially an accumulator machine
<eddyb>
idk how much propagatedBuildInputs counts as misuse there but it works
<emily>
it's correct
<pepijndevos>
My original design was more like whitequark's, where the registers are in memory but using bit-serial SPI RAM.
<ZirconiumX>
SPI is slooowww
<emily>
you might also want ` checkInputs = [ yosys symbiyosys yices ];`
<pepijndevos>
So it'd be 100% streaming from memory directly to memory. It actually used *different* memories so you'd not have to store anything
<eddyb>
emily: do you have all of this somewhere already?
<eddyb>
I feel like I'm wasting my time lol
<pepijndevos>
But uppon realising a single instruction would take over a hundred cycles, I gave up on that madness
<pepijndevos>
The awesome parts was that you could do 128-bit operations no problem because there are no registers. Just keep reading
<ZirconiumX>
Pepijn's talked to me a lot about it, I know most of its tricks
<emily>
eddyb: I didn't upstream my nmigen derivations because there's no release
<eddyb>
sure. I tend to keep such things in gists
rohitksingh has quit [Ping timeout: 276 seconds]
<emily>
working on a glasgow derivation now which would include that though, so it's ready for when I get my revC1 :)
<emily>
eddyb: mhm, the repo is mostly just private because I'm embarrassed at being bad :p
<emily>
I just set stuff up so I could have a dev environment
<emily>
I've been working on upstreaming things though
<ZirconiumX>
the repo is mostly just private because I'm embarrassed at being bad :p <--- aren't we all, though? :P
<eddyb>
yeah I use private gists for a similar reason :P
<pepijndevos>
ZirconiumX: bad, embarrassed, or both? XD
<ZirconiumX>
Both
<eddyb>
anyway if this is already handled then I'm just making noise
<ZirconiumX>
By the way, whitequark, it's like £140 in chips to build a boneless out of 7400 logic
<pepijndevos>
And 300 in PCB
<ZirconiumX>
It'd be a hell of a minicomputer though :P
<whitequark>
heh
<pepijndevos>
Still debating with myself if my CPU will be a 10x10 N-layer two-sided SMD board or a huge DIP board
<ZirconiumX>
SMD probably works out cheaper
<ZirconiumX>
And likely somewhat faster
<pepijndevos>
I figured 100cm^2 should fit 50 chips on each side, so it'd need a lot of layers and tricky assembly
<pepijndevos>
Huge DIP board looks cooler, but the price of the PCB will not be fun
<pepijndevos>
On the other hand, if the 10x10 board needs 6 or 8 layers, that might not be cheap ether.
<pepijndevos>
Gigatron is 2 layers and 40 chips or so? *jealous*
<ZirconiumX>
pepijndevos: I've been making some adjustments to the AC library to reflect Mouser stocks
<pepijndevos>
Like what?
<pepijndevos>
I personally try to get all my stuff from Farnell because they are less annoying with shipping, but I admit they have a smaller collection.
<ZirconiumX>
The AC158 4x1MUXI2 is SOIC only and non-stocked
<ZirconiumX>
Which bumps the number of chips up a bit
<pepijndevos>
Bleh, fernell does not have them *at all* so I agree. Sad though.
<whitequark>
ZirconiumX: why do you use DIP anyhow?
<pepijndevos>
To compensate, I've seen some chips that we use that have direct *and* inverted outputs, and we use only one.
<ZirconiumX>
pepijndevos's script produces KiCad netlists that use the DIP footprints
<ZirconiumX>
It's entirely possible to get them to use SOIC, and the production boards definitely should
<pepijndevos>
That'd be fairly easy to change though
<pepijndevos>
DIP is pretty and easy to debug though
<pepijndevos>
I feel like if you're going to build a minicomputer, aestetics matter. Else, just use an FPGA
<ZirconiumX>
If TopoR is going to be the production router, it should probably be informed of pin-swapping abilities though
<pepijndevos>
Is that a thing we have to do in the part library?
<ZirconiumX>
No, I don't think KiCad supports it
Asu has quit [Ping timeout: 245 seconds]
<pepijndevos>
through-hole=built-in via! What's not to like :)
freemint has quit [Ping timeout: 250 seconds]
Asu has joined ##openfpga
<ZirconiumX>
There's also the undocumented ability to gate-swap too
<pepijndevos>
so how do you tell topr about it?
<ZirconiumX>
You can export to an XML-based format that TopoR outputs
<ZirconiumX>
And then you'd read that and match up the chip numbers with chip parts
<ZirconiumX>
And then re-import it again
<ZirconiumX>
Actually when I tot up the number of chips it's "only" £130
<ZirconiumX>
So slightly less with the group discounts
<ZirconiumX>
s/group/bulk/
<pepijndevos>
Is that DIP or SOIC or it's about the same?
rohitksingh has joined ##openfpga
<ZirconiumX>
DIP
<pepijndevos>
Uhoh farnell only has 74AC157 in SOIC, so I guess it's Mouser or SOIC
<pepijndevos>
I bet if you increase %c[oi]n high enough it'll evetually connect, but it might become a huge mess
<pepijndevos>
basically co exctends the output of the selection by n, and ci extends the input selection by n
<ZirconiumX>
I haven't figured out what %co1 does :P
<pepijndevos>
x does both ways
<pepijndevos>
so my script extracts the nodes in the critical path, but then it needs to expand the selection so that the wires between the nodes are also included
<pepijndevos>
If there is a lot of bus magic between them, it might not work (0:0 - 11 type of stuff)
<pepijndevos>
So if you do co3 it will take the selected node, and everything within 3 steps of the output node
<pepijndevos>
So it explodes quickly
<pepijndevos>
The ltp command also gives wire names, but I could not get that to work
pepijndevos has left ##openfpga ["Good Bye"]
pepijndevos has joined ##openfpga
<pepijndevos>
welp
* ZirconiumX
slow claps
<pepijndevos>
My brain is not compatible with two screens
davidc__ has joined ##openfpga
<ZirconiumX>
pepijndevos: Out of morbid curiosity I built a library out of the parts that Potato Semi have
<pepijndevos>
omg
<ZirconiumX>
Boneless is 400 chips (compared to 240 AC chips)
<pepijndevos>
But... GHz!!
<pepijndevos>
Well, not bad I suppose
<ZirconiumX>
Most chips seem to be in the region of $3-$4 each
<ZirconiumX>
So that's easily >$1k
<davidc__>
ZirconiumX: potato semi ghz freqs are with extremely low output loading
<davidc__>
ZirconiumX: so long nets / decent fanouts won't be anything near the rated speed
<ZirconiumX>
Sure, but it's fun to imagine
<davidc__>
sur e:)
<ZirconiumX>
>Operating frequency up to 270MHz with 15pF load
<ZirconiumX>
davidc__: I'm targeting 74AC logic; HC might be too slow
rohitksingh has quit [Ping timeout: 276 seconds]
carl0s has joined ##openfpga
<ZirconiumX>
pepijndevos: If you want something truly terrifying, Mouser have ECL logic chips
<pepijndevos>
They have what?
<ZirconiumX>
emitter-coupled logic
<pepijndevos>
Do I need this in my life?
<ZirconiumX>
In terms of speed, ECL > CMOS
<pepijndevos>
And more importantly, can you make a yosys library for them
<pepijndevos>
And in what terms ECL < CMOS?
<ZirconiumX>
Power consumption
<ZirconiumX>
ECL draws a lot more power than CMOS
<ZirconiumX>
With that comes heat
<ZirconiumX>
So much so that ECL was tried for a little while commercially (the MIPS R6000 comes to mind) and quickly abandoned for CMOS
<pepijndevos>
hmmm
<ZirconiumX>
It relies on the physics of a transistor
<ZirconiumX>
They're like an electronically controlled switch
<pepijndevos>
At university all they teach is CMOS basically. Well, of course a *bit* of BJT, but not much. Makes sense, but also a bit sad sometimes.
<ZirconiumX>
But while BJT and CMOS rely on switching transistors on and off
<ZirconiumX>
It's actually faster to go between states of "mostly on" to "mostly off"
<ZirconiumX>
This is ECL
<ZirconiumX>
However, and this is kind of the limits of my understanding, transistors prefer being fully on or off, and run more efficiently in these states
<ZirconiumX>
I suspect this might be an area that whitequark knows more than I do in
<pepijndevos>
Yea, you know... power is voltage times current right?
<pepijndevos>
So in fully on there is no voltage and fully off there is no current, so ideally no power dissipation in the transiistor
<pepijndevos>
So in CMOS (neglecting leakage) it only costs power to switch, because then you need to charge and distcharge paracitic caps during which there is both voltage and curren accros the transistor
<pepijndevos>
It always messes me up that "saturation" means the exact oposite in BJT and MOSFET
<pepijndevos>
The mosfet equivalent forwards to "current mode logic", which I think is a more useful way to think about it.
<pepijndevos>
Current status: thinking about gray-ish codes for low power. I'm obviously not the first to think this.
<ZipCPU>
pepijndevos: I have another lowpower suggestion: Keep any unused wires at zero. Many protocols include a "valid" wire together with a bunch of data wires. If valid is low, why should the data wires be changing?
Asu has quit [Read error: Connection reset by peer]
<azonenberg_work>
ZirconiumX: if you are going to be making a physical boneless
<azonenberg_work>
have you considered some of the WLCSP 74xx chips?
<azonenberg_work>
some of the smaller 74xx are available in like 2x8 or so ball 0.5mm BGAs that are possible to fan out on a single layer with normal design rules
<azonenberg_work>
would make the design far denser
<azonenberg_work>
but i think they're mostly HC not AC
<TD-Linux>
also that sounds like mega cheating to me
<azonenberg_work>
Also consider QFN
<azonenberg_work>
For example (not recommending this specific series but it shows the available packaging)
<azonenberg_work>
(looks like most of the really dense stuff are 74LVC)
<TD-Linux>
I'm going to be disappointed if this project involves less than 10kg of raw fr4
<azonenberg_work>
That last one is a 74138, 3:8 demux, in a 3x4mm 0.65mm pitch WLCSP
<azonenberg_work>
its only 2 rings of balls so should also be fanout-able on one layer
<azonenberg_work>
TD-Linux: see, i want to build a simple computer one day using fully modern discrete components
<azonenberg_work>
imagine if package technology progressed to the current day but we never got beyond small scale integration
<azonenberg_work>
what would a computer made of modern 74xx / cd4000 series parts look like? high density BGA packages with MLCCs for decoupling
<TD-Linux>
azonenberg, make it on flex and fold it up
<azonenberg_work>
it doesnt even have to be a whole computer, a uart would be nice to try for example
<azonenberg_work>
or, given my love of ethernet
<azonenberg_work>
a 10baseT PHY?
<azonenberg_work>
i wonder if i could make timing with that
<azonenberg_work>
20 MHz seems a bit fast for discrete 74xx...
<cr1901_modern>
azonenberg: _In practice_ I've seen 20 MHz work w/ discrete 74xx for carefully allocated designs for homebrew computers. It is very much out of spec tho.
MarcelineVQ has quit [Read error: Connection reset by peer]
<cr1901_modern>
Which, I mean, if you're doing homebrew, design for in-spec, then keep increasing the speed until it fails :P
<cr1901_modern>
then push it down 20% for margin :P
MarcelineVQ has joined ##openfpga
<azonenberg_work>
over commercial temp range 10.5 ns setup, 1ns hold
<azonenberg_work>
at 2.5V
<azonenberg_work>
at 3.3V, 6.5 ns setup, 1 ns hold
mumptai has quit [Quit: Verlassend]
<mwk>
haha
<mwk>
alright, so I got a new programmer
<TD-Linux>
>160mhz
<TD-Linux>
wow. also I thought LVC was faster?
<mwk>
guess what, using DebugBitstream with Virtex 5 == failure to boot FPGA
<mwk>
so... why hasn't anyone noticed that before
<mwk>
guess nobody used it ever?
<mwk>
whitequark: btw, an interesting data point
<mwk>
at least on Virtex 5 and Spartan 3, using JSTART will start up the FPGA whether the CRC was right or not
<mwk>
as in, you get DONE=1
<mwk>
but, assuming you have a normal bitstream and there's corruption in the config data, the device will desync on the first CRC check, between frame data and LFRM (aka DGHIGH) command, so interconnect is still disabled and the device effectively isn't doing anything
<mwk>
the status register shows GHIGH still asserted, and the startup sequence still in state 0 somehow (but with done asserted)
<mwk>
GTS_CFG_B is not asserted according to status, but I think GTS_USR_B is (because the config machinery aborted before processing the final CTL command, and the bit is 0 on reset), so the I/Os are inactive as well
<mwk>
matter of fact, that's probably the reason why CTL is the last register to be written in the bitstream
<ZirconiumX>
azonenberg_work: My target is AC logic, which only comes in stuff like TSSOP
<ZirconiumX>
There doesn't seem to be much faster logic, since LVC doesn't contain much of the logic I rely on
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 258 seconds]
emeb_mac has joined ##openfpga
freemint has joined ##openfpga
freemint has quit [Ping timeout: 250 seconds]
Asu` has quit [Ping timeout: 244 seconds]
Asu` has joined ##openfpga
<kc8apf>
mwk: debug bitstream doesn't work on 7 series either. There's a note buried in ug470 about LOUT not being supported so the bitstream fails
MarcelineVQ has quit [Read error: Connection reset by peer]
MarcelineVQ has joined ##openfpga
Jybz has quit [Ping timeout: 264 seconds]
Bike has joined ##openfpga
pie_ has joined ##openfpga
freemint has joined ##openfpga
tlwoerner has quit [Read error: Connection reset by peer]
carl0s has quit [Remote host closed the connection]