m4ssi has quit [Remote host closed the connection]
gsi_ has joined #yosys
gsi__ has quit [Ping timeout: 250 seconds]
noname_Matt has quit [Quit: Page closed]
proteusguy has joined #yosys
emeb_mac has joined #yosys
_whitelogger has joined #yosys
proteusguy has quit [Ping timeout: 245 seconds]
proteusguy has joined #yosys
emeb has left #yosys [#yosys]
m4ssi has joined #yosys
pie___ has joined #yosys
pie__ has quit [Ping timeout: 255 seconds]
proteusguy has quit [Ping timeout: 245 seconds]
proteusguy has joined #yosys
m4ssi has quit [Remote host closed the connection]
proteusguy has quit [Ping timeout: 255 seconds]
emeb_mac has quit [Quit: Leaving.]
tlwoerner has quit [Excess Flood]
xdeller__ has quit [Remote host closed the connection]
tlwoerner has joined #yosys
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined #yosys
dys has joined #yosys
xerpi has joined #yosys
xerpi_ has joined #yosys
xerpi has quit [Ping timeout: 245 seconds]
xerpi_ has quit [Ping timeout: 244 seconds]
Laksen has joined #yosys
xerpi_ has joined #yosys
xerpi__ has joined #yosys
xerpi_ has quit [Ping timeout: 245 seconds]
xerpi__ has quit [Remote host closed the connection]
xerpi__ has joined #yosys
xerpi__ has quit [Remote host closed the connection]
xerpi__ has joined #yosys
xerpi__ has quit [Ping timeout: 255 seconds]
xerpi__ has joined #yosys
xerpi__ has quit [Remote host closed the connection]
leviathanch has joined #yosys
<MoeIcenowy>
how much current will an iCE40UP5K cost at most?
<tnt>
like 10-20 mA 1.2v core current at the _very_ most.
<tnt>
for the IO ... well, that's mostly whatever you connect on those IO.
proteusguy has joined #yosys
danieljabailey has joined #yosys
citypw has quit [Remote host closed the connection]
citypw has joined #yosys
<tnt>
I have no idea if it's even doable, but I wish there was a way to tell yosys to not create a different control set (i.e. Clk / CE / Set/Reset) for the bits of a same vector create from the same verilog statement.
xerpi has joined #yosys
<tnt>
It's virtually never what I want.
<tnt>
"Great you saved 1 LUT4 by using the Set/Reset ... but (1) it's not really saved because the LUT4 is there anyway and has to be used as pass through (2) now the entire PLB is used up by 1 LC because that controlset is not used anywhere else"
<corecode>
\o/ the bin works!
<corecode>
blinks
<daveshah>
\o/
<corecode>
finally i can unrecurse my yak
<corecode>
and get on with my cpu design
<daveshah>
:D
<corecode>
tnt: what would you like to see instead?
<corecode>
daveshah: is there anything else i need to do for these PRs, or do we just wait until somebody commits?
<daveshah>
I'll get clifford to review the icestorm one, then merge the nextpnr one once that's done
<corecode>
cool
<tnt>
corecode: well instead of using the 'set' line, it could pack an OR in the LUT4 before the FF.
<corecode>
aha
<corecode>
if it is a sync set
<tnt>
it is.
xerpi has quit [Remote host closed the connection]
<tnt>
And in another instance, for some reason, it decided to use the CE line instead of a MUX with previous value for a _single_ bit of a 12 bit vector ... (even though it doesn't save anything, the LUT4 before that FF could be used for that with no overhead).
<corecode>
isn't that a thing the placer also needs to have a say in?
<tnt>
the synth does the LUT packing, so it should know that this fits inside the LUT preceding the FF.
<daveshah>
It wouldn't be a big pass to unpack CE/SR if (a) the FF is driven by a LUT with spare inputs or (b) the FF is driven by a non-LUT or LUT with fanout >1
<daveshah>
not that I have time to write it any time soon
<corecode>
why fanout>1?
<daveshah>
somewhat arbitrarily we separate the FF from the LUT in these cases rather than duplicating the LUT
<daveshah>
probably slightly reduces routing congestion, as only one signal to route rather than 1-4
<corecode>
ah, the DFF can only receive input from the LUT out?
<daveshah>
yeah
<daveshah>
unlike most other FPGA arches
<corecode>
i see
<corecode>
who inserts the passthrough LUT?
<daveshah>
nextpnr
<corecode>
but if you wrote a pass to check for LUT out > 1, you might as well do it in yosys?
<tnt>
daveshah: thing is, I'd mostly like that decision to be based on the full vector rather than individual bits, to avoid creating different control sets.
<corecode>
will do
<corecode>
tnt: because of timing?
<tnt>
corecode: because I don't want to waste PLBs
<corecode>
for a vector you have the advantage of sharing the signals tho
<tnt>
corecode: LCs with different control set can't be packed in the same PLB.
<corecode>
yes
<MoeIcenowy>
daveshah: how to estimate how much power will iCE40 drain?
<daveshah>
I think Lattice have a tool somewhere
<MoeIcenowy>
I'm considering to make a board with small-size LDO
<daveshah>
the answer is not much :)
<MoeIcenowy>
daveshah: is there an upper bonud
<MoeIcenowy>
bound *
<daveshah>
for the up5k? 30mA
<MoeIcenowy>
the datasheet says booting peak current
<MoeIcenowy>
but no highest operation current
<daveshah>
no, that's quite hard to specify
<MoeIcenowy>
maybe I should download the design checklist by Lattice?
<tnt>
MoeIcenowy: the icebreaker uses sot-23 linear regulators.
<daveshah>
fwiw, MARLANN (simple CNN accelerator) using all DSPs, SPRAM and majority of LUTs at 20MHz consumes 14mA Vcore
<daveshah>
going above 40MHz for a large design would be very hard, so that would give about 30mA max
<corecode>
MoeIcenowy: yea, also understand difference between core and IO current
<MoeIcenowy>
tnt: okay ;-)
<MoeIcenowy>
seems that 200mA is enough?
<corecode>
for what rail
<daveshah>
If it draws 200mA Vcore it is probably dead :P
<daveshah>
IO pins are 8mA nominal max current, so max for all 36 non-open-drain pins is 288mA, but that's quite a crazy case
<corecode>
i use a mic5504-1.2 fwiw
<tnt>
daveshah: or like me you soldered it 90deg off :p
<corecode>
daveshah: yea but isn't switching current higher?
<daveshah>
corecode: maybe a bit, probably not that significant at iCE40 freqs and slew rates though
<corecode>
ok
<corecode>
well, knowing the application + math = success
<MoeIcenowy>
tnt: is your chip still alive?
<MoeIcenowy>
or does it rest in peace?
<tnt>
MoeIcenowy: it survived just fine :)
develonepi3 has quit [Remote host closed the connection]
develonepi3 has joined #yosys
<corecode>
imaginary current
<MoeIcenowy>
oh as a Computer Science student I know none about imaginary in circuits
<corecode>
it's a joke
<corecode>
because the chip was 90 degree offset
<shapr>
zing
danieljabailey has quit [Ping timeout: 245 seconds]
leviathanch has quit [Remote host closed the connection]