<berndj>
azonenberg: what limits the clock speed of those things with slicex/slicel/slicem?
Nephirus has quit [Quit: User terminated.]
Nephirus has joined #homecmos
fpgaminer has quit [Ping timeout: 246 seconds]
fpgaminer has joined #homecmos
fpgaminer has quit [Ping timeout: 240 seconds]
fpgaminer has joined #homecmos
<azonenberg>
berndj: you mean spartan-6? or FPGAs in general?
<azonenberg>
In any sequential/clocked logic
<berndj>
i guess spartan-6
<azonenberg>
there are two possible limitations to maximum operating frequency
<berndj>
trying to compare apples with apples, not with oranges :)
<azonenberg>
the first is how fast you can clock individual elements (flipflops, RAM blocks, etc)
<azonenberg>
The second is propagation delay
<azonenberg>
you cannot send the second clock signal to a flipflop until the data generated by the previous one has arrived
<azonenberg>
This can be further subdivided into switching delay of logic elements and routing delay on wires
<berndj>
i was reading about that fpga miner (bitcoin stuff) that could go up to about 135MHz - is that likely the first or the second constraint?
<azonenberg>
in FPGAs, routing delay tends to dominate
<azonenberg>
Oh, sorry
<azonenberg>
there's a third constraint
<azonenberg>
Power
<azonenberg>
The faster you switch the more power you need
<Sync_>
yes I have found out the hard way that ignoring the design softwares ideas can lead to interesting behavior
<azonenberg>
at some point you reach a situation in which you either cannot sink the heat fast enough, or you cannot feed electricity in fast enough
<azonenberg>
In general, propagation delay is your limiting factor for most logic
<azonenberg>
Extremely deeply pipelined stuff may run into the other two
<berndj>
yeah; is the power limit something that applies over the whole chip, or can you have (and feel) local intra-chip constraints?
<azonenberg>
in large chips, there can indeed be power limits for subregions
<azonenberg>
Anyway, in FPGAs normally you have a hard time operating THAT fast
<azonenberg>
because propagation delays dominate
<azonenberg>
Generally the logic elements are pretty fast
<azonenberg>
and the wires are slow
<azonenberg>
because you not only have R/C and transmission line delay
<azonenberg>
you also have switching delay for the multiplexers every time you change direction etc
<berndj>
so does 135MHz smell like routing delay or like element clocking?
<azonenberg>
Definitely routing delay
<azonenberg>
most block ram, DSP slices, etc in s6 can run up to 300-500 MHz if you can feed it data fast enough
<berndj>
what sort of numbers would you see if it were clocking or power limits?
<azonenberg>
The global clock tree, for example, cannot go over 500
<berndj>
there's an internal clock synthesizer, right?
<azonenberg>
There are PLLs, yes
<azonenberg>
but you need an external oscillator
<berndj>
or do you actually have to feed in 500MHz if you want that
<azonenberg>
You need an external clock which can be multiplied or divided by the PLL
<azonenberg>
but it needs something to lock onto
<azonenberg>
Usually I have a 20-100 MHz external clock
<azonenberg>
multiply up to around a GHz on the PLL so i have lots of common factors
<azonenberg>
then divide down to whatever i actually need
<azonenberg>
on spartan6 the PLL's internal VCO frequency has to be in the 480-1080 MHz range iirc
<azonenberg>
So if you want to turn, say, 20 into 40
<azonenberg>
you could multiply the 20 by 32 (the max allowed multiplier) up to 640 and then divide by 16 to get 40
<azonenberg>
Anyway, typical values for delays on spartan6 are about 30% gate/logic delay and 70% routing delay
chris_99 has quit [Quit: Leaving]
<berndj>
so i was just doing some exploratory design research for how to do a 74-series miner. it'd be 100+ chips just to make a very slow (20kH/s) miner