danieljabailey has quit [Quit: ZNC 1.6.6+deb1ubuntu0.1 - http://znc.in]
FL4SHK has quit [Ping timeout: 250 seconds]
leviathanch has joined #yosys
FL4SHK has joined #yosys
gsi__ has joined #yosys
gsi_ has quit [Ping timeout: 246 seconds]
proteusguy has quit [Remote host closed the connection]
leviathanch has quit [Remote host closed the connection]
<MoeIcenowy>
sxpert: I think someone did initial RE on EP4CE6
<MoeIcenowy>
BTW I have ordered a EP4CE115 board for CNY ￥495 (around USD $75)
mobius has quit [Quit: leaving]
citypw has joined #yosys
_whitelogger has joined #yosys
danieljabailey has joined #yosys
seldridge has quit [Ping timeout: 255 seconds]
s_frit_ has joined #yosys
pie__ has joined #yosys
s_frit has quit [Ping timeout: 246 seconds]
pie___ has quit [Ping timeout: 250 seconds]
s_frit_ has quit []
s_frit has joined #yosys
emeb_mac has joined #yosys
proteusguy has joined #yosys
proteusguy has quit [Excess Flood]
proteusguy has joined #yosys
rohitksingh_work has joined #yosys
seldridge has joined #yosys
seldridge has quit [Ping timeout: 255 seconds]
proteusguy has quit [Read error: Connection reset by peer]
emeb_mac has quit [Quit: Leaving.]
proteusguy has joined #yosys
dys has quit [Ping timeout: 250 seconds]
Thorn has quit [Ping timeout: 245 seconds]
m4ssi has joined #yosys
Thorn has joined #yosys
<promach>
is it possible that bmc passed at depth = 5 , but failed at depth = 10 ? Note that I am using "proof: depth 10" in sby file
dys has joined #yosys
dys has quit [Ping timeout: 255 seconds]
citypw has quit [Ping timeout: 257 seconds]
<ZipCPU>
promach: Absolutely!
<ZipCPU>
It's actually a common problem in one of my counter exercises. The counter gets set and starts counting down from 22, goes to idle, and then gets set and counts down again
<ZipCPU>
The only problem is ... we use a depth of 20 for the exercise, and there are often bugs at the point where the counter stops, waits, and restarts -- all at clock 22+, long after the 20 clocks necessary for the depth of 20
proteusguy has quit [Ping timeout: 255 seconds]
proteusguy has joined #yosys
<promach>
ZipCPU: ok
<promach>
I know what went wrong in my code now
AlexDaniel has joined #yosys
<corecode>
what did?
<corecode>
daveshah: how should i proceed with this port?
<daveshah>
corecode: have you tested some small designs through icebox_vlog
<corecode>
not explicitly
<corecode>
i think some of the test scripts do that
<daveshah>
It would be worth trying a few designs manually and making sure the output is sane
<corecode>
i think at least i need to confirm the global networks & pins
<daveshah>
There are some Verilog designs for testing global networks in icefuzz/tests
<corecode>
yea, i will have to add some other footprint to cover all pads
<daveshah>
If it's anything like the UltraPlus, not every theoretical pad is covered even over all footprints...
<corecode>
what does that mean
<daveshah>
there are some IO locations that are not used in any package
leviathanch has joined #yosys
<MoeIcenowy>
maybe they will furtherly provide packages with more pins ;-)
seldridge has joined #yosys
citypw has joined #yosys
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #yosys
tmeissner has joined #yosys
jevinskie has joined #yosys
jevinski_ has quit [Ping timeout: 258 seconds]
emeb has joined #yosys
s_frit has quit [Read error: Connection reset by peer]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined #yosys
jevinskie has quit [Ping timeout: 250 seconds]
citypw has quit [Ping timeout: 240 seconds]
emeb has quit [Read error: Connection reset by peer]
emeb has joined #yosys
tmeissner has quit [Ping timeout: 255 seconds]
jevinskie has joined #yosys
jevinskie has quit [Client Quit]
leviathanch has quit [Remote host closed the connection]
m4ssi has quit [Remote host closed the connection]
SpaceCoaster has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
SpaceCoaster has joined #yosys
chaseemory has joined #yosys
rohitksingh has quit [Remote host closed the connection]
dys has joined #yosys
<corecode>
daveshah: hm, the ultralite datasheet says that global pin X is connected to global buffer X
<corecode>
is that different from global network X?
<daveshah>
No, it isn't
<daveshah>
global pin X drives global buffer X
<daveshah>
also, are you doing the ultra or the ultralite, btw?
<daveshah>
beware that the SB_GB which drives from fabric (as opposed to SB_GB_IO from the global pin) at the same location drives a different global network
<corecode>
ultralite, i think ice5lp
<daveshah>
ice5lp isn't the ultralite, it's the ultra
<corecode>
aha!
<corecode>
meh
<corecode>
why are they so bad with names
<daveshah>
the patch so far was the u4k, which is the ice5lp/ultra not the ultralite
<daveshah>
yeah, ikr
proteusguy has quit [Ping timeout: 246 seconds]
pie__ has quit [Ping timeout: 250 seconds]
<corecode>
daveshah: how would i force use of a specific global network? i'm trying to figure out the fabout locations
<daveshah>
corecode: you can constrain it in the icecube floorplan view, or in the pcf file
<daveshah>
I can't remember the syntax for the latter
<corecode>
aha
<corecode>
okay
<corecode>
i'll just skip the two padin that don't exist on this footprint
<daveshah>
icebox requires all 8 padins
<corecode>
ah
<corecode>
but there are not even 8
<daveshah>
hmm
<corecode>
at least not documented
<daveshah>
the remaining ones should be at the same location as the fabouts
<corecode>
and what about the extra bits?
<corecode>
just keep them short?
<daveshah>
missing extra bits are fine
<corecode>
thank you
<daveshah>
it's only the padin_pio db that has to have 8 entries
<daveshah>
two of the extra bits will come from the oscillators
<corecode>
ah i guess it is called gbufin
<daveshah>
hopefully with oscillators and all packages all 8 extra bits will be covered in any case
<corecode>
i don't think so
<daveshah>
gbufin is the fabouts (x, y, global network)
<corecode>
ok
<corecode>
bit of a misnomer
<daveshah>
for some reason the documentation for it ended up in icebox_chipdb.py (the exporter)