<chaseemory>
ZipCPU, i managed to get the Ethernet port working on the Nexys Video, it was a mixture of a few issues, wireshark came in super handy
emeb has left #yosys [#yosys]
<ZipCPU>
Yaaayyy!!!
<ZipCPU>
chaseemory: Can you tell me what you used for the clock on the transmitter?
emeb_mac has joined #yosys
<chaseemory>
i made two 125MHz clocks in an mmcm, one 90degrees out of phase, i dug through the layers of the code in the repo and thats the clock it seems to be using for the tx_clk
<MoeIcenowy>
but I don't love to utilize DDR on FPGA
citypw has quit [Ping timeout: 258 seconds]
shabgard has joined #yosys
<corecode>
daveshah: ok, i think the last thing is to fill the extra_cells_db
<daveshah>
corecode: yeah
<daveshah>
for SB_WARMBOOT, create one and trace the routing in icebox_vlog
<daveshah>
for the remaining IP, hopefully the script for the UltraPlus is adaptable
<corecode>
warmboot i already handled
<corecode>
well, i'll skip the i2c and spi for now
<corecode>
but hfosc and lfosc is important
<corecode>
i guess there is no test fixture for it yet
<corecode>
what's the easiest way to figure out where config bits sit?
<corecode>
set them and look in the explanation?
<MoeIcenowy>
oh my laptop's LCD screen is too small in points to use the DDR2 controller IP from Quartus ;-)
<corecode>
daveshah: do i have to modify the standard cell library to access the TRIM input?
<corecode>
huh, icecube says "no top-level module"
<corecode>
what's that about
<corecode>
ah!
<corecode>
found it
leviathanch has joined #yosys
<corecode>
daveshah: trying to find the extra_cells for the hfosc - how do i know the location of the CLKHF output? i used it for a SB_IO output clock, but vlog says:
<corecode>
wire io_19_31_0;
<corecode>
// (0, 0, 'glb_netwk_4')
<corecode>
// (9, 31, 'io_global/outclk')
<corecode>
// (19, 31, 'io_0/PAD')
<corecode>
// (19, 31, 'padin_0')
<corecode>
is (0, 0) credible there?
<daveshah>
yes, it is global network glb_netwk_4
<daveshah>
routed through the padin of 19, 31
<corecode>
because on the 5k it is (0, 29)
<daveshah>
the global networks are really in every tile, so it doesn't matter
<corecode>
aha
<daveshah>
it's the glb_netwk_4 that's important
<corecode>
hm, why doesn't vlog show the HFOSC
<daveshah>
it doesn't support them
<corecode>
aha :)
<corecode>
hm, i thought HFOSC was global network 5 according to docs
<daveshah>
wouldn't be the first mistake in Lattice docs
<daveshah>
it's glb_netwk_4 on the up5k too
<corecode>
is that different from some other global buffer stuff?
<daveshah>
no
<daveshah>
the only difference is the SB_GB driving a different glb_netwk_i to the SB_GB_IO/padin at the same location
<corecode>
now i question my padin_io and padin_glb_netwk
<corecode>
so the HFOSC is global network 4, but routed via padin_glb_netwk 5?
<corecode>
oO
<daveshah>
no
<corecode>
or is that output of icebox_explain just what i did
<daveshah>
the HFOSC is global network 4 plain and simple
<daveshah>
this is entirely padin
<corecode>
ok, so i need to switch those two around
<daveshah>
which two?
<corecode>
HF and LF padin
<daveshah>
yeah
<corecode>
ok i need to redo my gbufin
<corecode>
i had some bogus data on it which confused me
<daveshah>
the important thing gbufin is totally unrelated to padin
<daveshah>
it's just coincidental that the locations are the same
<corecode>
especially if i cannot trust the ice docs
<corecode>
which means my explain output is unreliable as well
<daveshah>
no, the explain output will always be correct
<daveshah>
it doesn't rely on gbufin or padin at all
<corecode>
for the extra bits it uses the extra bit info
<corecode>
which was wrong for me
<daveshah>
ah, right
<daveshah>
inside logic, IO tiles, etc the glb_netwk_* will always be correct though
<corecode>
ok
<daveshah>
they are based on the low level routing bits determined by icefuzz and the glb files
<corecode>
ok, i'm looking at gbufin right now
<corecode>
i have clk on pin 44
<corecode>
which the docs say is G6
<daveshah>
The global numbers for the docs are for padin
<daveshah>
not gbufin
<corecode>
what? how would that be useful
<daveshah>
i.e. the global numbers in the docs (if they are correct) will only apply if using SB_GB_IO
<daveshah>
SB_GB are driven from fabric rather than an IO pin
<corecode>
yes, i thought gbufin is from the outside
<daveshah>
no, gbufin is for SB_GBs from fabric
<corecode>
god damn, these names are so confusing
<daveshah>
padin is for SB_GB_IOs from the IO pins
<corecode>
alright, back to padin
<daveshah>
beware that connecting to a SB_GB to a pin doesn't guarantee that icecube will place that GB next to the pin (unlike an SB_GB_IO)
<corecode>
so i have a sb_gb_io, and explain says it uses glb_netwk_1
<daveshah>
yeah
<corecode>
but the docs say it is G6
<daveshah>
this is inside a logic/io tile and not extra bits?
<corecode>
it also sets extra bits
<daveshah>
ignore the extra bits for now, just look at the routing in logic/io tiles
<corecode>
should i use explain or vlog?
<daveshah>
explain
<daveshah>
also, extra bitS or just one extra bit?