<corecode>
daveshah: i don't seem to find a way to specify a global buffer network
<corecode>
only promote/demote
<daveshah>
Use a manually placed SB_GB
<corecode>
yea, doing that now
<corecode>
well, 8
<corecode>
otherwise it keeps placing it in the same location
<daveshah>
I'm pretty sure you can override this in floorplan view or the PCF file
Thorn has quit [Ping timeout: 246 seconds]
<daveshah>
Something like set_location name x y z
<corecode>
well, i'm trying to figure out the gb locations
<corecode>
but this seems to have worked
<daveshah>
You can see them in floorplan view
<daveshah>
At some point you'll probably need to create them one by one to find out which network each fabout drives
<corecode>
i just created 8 inputs, 8 SB_GB, 8 outputs
<corecode>
aaah
<corecode>
hm, how would i know?
<daveshah>
By creating them one by one manually placed at each location
<corecode>
if i cannot constrain it to a network, i constrain it to a location
<corecode>
and then it has to be that network
<daveshah>
And seeing which glb_netwk appears in the icebox_explain output
<corecode>
doesn't explain use the data that i'm trying to fill in?
<daveshah>
Not this data
<daveshah>
icebox_vlog does
<daveshah>
icebox_explain is lower level, all it needs is the list of tiles and the actual bitstream bit mapping
<corecode>
ah no
<corecode>
i can see both
<corecode>
the explain shows me the network number
<daveshah>
Yeah
<corecode>
and given the output, i know what input clock it was
<daveshah>
Yeah, that works
<corecode>
does the order matter in gbufin_db?
<daveshah>
No, but it does for padin_db
<corecode>
ok
<corecode>
what about the location within the tile? the 0 1, does that not matter for the gbufin?
<daveshah>
No, it doesn't
<corecode>
ok
<daveshah>
I think it is always 2, but that isn't used anywhere
<corecode>
the psb shows
<corecode>
set_io gbufin_3 6 0 1 # ICE_GB
<corecode>
not always 1 though
<daveshah>
Yeah, that's fine
<corecode>
for my fake padin, does it matter there?
<daveshah>
No, it doesn't
pie_ has joined #yosys
<corecode>
hm, vlog fails with nonexistant data
<corecode>
something in get_pll_bits
<corecode>
aha
emeb_mac has joined #yosys
cr1901_modern has quit [Ping timeout: 268 seconds]
<corecode>
daveshah: what do you mean by "So a tiny bit of semi-manual work is needed #first to discover this (basically run this script with show_all_bits=True #and look for the stuck bit"
<corecode>
run it completely?
<corecode>
i guess i'll see
* corecode
waits for fuzzing to end
emeb has quit [Quit: Leaving.]
cr1901_modern has joined #yosys
cr1901_modern has quit [Ping timeout: 244 seconds]
jevinskie has joined #yosys
gsi_ has joined #yosys
gsi__ has quit [Ping timeout: 246 seconds]
gsi_ has quit [Ping timeout: 246 seconds]
cr1901_modern has joined #yosys
seldridge has quit [Ping timeout: 245 seconds]
citypw has joined #yosys
citypw has quit [Remote host closed the connection]
rohitksingh_work has joined #yosys
citypw has joined #yosys
pie__ has joined #yosys
pie_ has quit [Ping timeout: 255 seconds]
gsi_ has joined #yosys
leviathanch has joined #yosys
proteusguy has joined #yosys
chaseemory has quit [Quit: chaseemory]
awordnot has quit [Ping timeout: 245 seconds]
awordnot has joined #yosys
emeb_mac has quit [Quit: Leaving.]
dys has quit [Ping timeout: 240 seconds]
cr1901_modern has quit [Ping timeout: 272 seconds]
cr1901_modern has joined #yosys
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
s_frit has joined #yosys
m4ssi has joined #yosys
pie_ has joined #yosys
pie__ has quit [Ping timeout: 250 seconds]
m_t has joined #yosys
danieljabailey has quit [Ping timeout: 246 seconds]
Thorn has joined #yosys
leviathanch has quit [Remote host closed the connection]
citypw has quit [Ping timeout: 258 seconds]
Thorn has quit [Read error: Connection reset by peer]
flaviusb has joined #yosys
<corecode>
gotta figure out where all these PLL ports come from
<daveshah>
corecode: icebox_vlog will tell you that
<daveshah>
Just connect each port to a pin and see where the routing for that pin ends up
<corecode>
yea, icebox_vlog still crashes based on missing data :)
<corecode>
but getting there
<corecode>
need to input the iolatch data
<daveshah>
sure, just fill in any old stuff to get icebox_vlog working, even comment it out
<daveshah>
There should be a script for the iolatch data
Thorn has joined #yosys
rohitksingh_work has quit [Read error: Connection reset by peer]
m_t has quit [Read error: Connection reset by peer]
AlexDaniel has quit [Ping timeout: 255 seconds]
jevinskie has joined #yosys
tlwoerner has quit [Quit: Leaving]
rohitksingh has joined #yosys
danieljabailey has joined #yosys
somlo has quit [Quit: Leaving]
tlwoerner has joined #yosys
leviathanch has joined #yosys
develonepi3 has quit [Remote host closed the connection]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<tpb>
Title: HP Saturn - Wikipedia (at en.wikipedia.org)
<sxpert>
this
<ZipCPU>
sxpert: You are missing the `default_nettype none instruction at the top ;)
<sxpert>
ah
<ZipCPU>
You have several unused signals: i_en_bus_recv, i_en_bus_ecmd, i_alu_pc, i_read_pc, i_cmd_dp_read ...
<ZipCPU>
Oh, and almost forgot i_en_bus_send
* ZipCPU
is running a verilator -Wall check
<sxpert>
those are goners
<corecode>
is that the original bus?
<sxpert>
corecode: yes
rohitksingh has joined #yosys
<sxpert>
theoretically the 4 datalines are bi-directionnal, but that may be impossible depending on the fpga
<ZipCPU>
You can turn the "noise" off by wrapping their definitions with "// verilator lint_off UNUSED" and "// verilator lint_on UNUSED". Alternatively, you can create one big unused chunk at the bottom with, "wire [N-1:0] unused; assign unused = { your_uused_wires };" and then wrap it with the Verilator lint statements
<ZipCPU>
(Replace N with the number of wires that are unused)
<sxpert>
no no, I ough to remove those unused signals, just didn't get to that yet
<ZipCPU>
That works too
<sxpert>
been furioulsy rewriting that thing 3 times or so ;)
<ZipCPU>
Still needs formal properties
<corecode>
good
<sxpert>
ZipCPU: well have to understand how that works first
<corecode>
yea me too
somlo has joined #yosys
citypw has quit [Ping timeout: 258 seconds]
<corecode>
daveshah: so what now?
<corecode>
i think i'm almost done
<corecode>
just need to do some pll port testing
<daveshah>
Next step is to make sure that icebox_chipdb generates the text database for arachne/nextpnr
m4ssi has quit [Remote host closed the connection]
<corecode>
now i just need to see what signal is actually routed to the respective fabout locations
<corecode>
for the pll ports
emeb has joined #yosys
<corecode>
how do i best trace the routing?
<emeb>
traceroute!
<daveshah>
corecode: just create a design with all the PLL pins connected to top IOs and run with icebox_vlog
<daveshah>
passing the PCF to icebox_vlog so it picks up port names too
leviathanch has quit [Remote host closed the connection]
rohitksingh has quit [Remote host closed the connection]
dys has joined #yosys
vzcx has joined #yosys
<vzcx>
has anyone had success using yosys/icestorm on openbsd?
<ZipCPU>
Are you struggling with anything in particular?
<vzcx>
i'm having trouble flashing my hx8k... seems to raise an error in libusb
<vzcx>
when using iceprog
<ZipCPU>
Does it build without problems?
<vzcx>
the iceprog tool? yes.
<ZipCPU>
What error do you get?
<vzcx>
usb_bulk_write failed
<vzcx>
this happens at the first call to send_byte, at the line commented "enable clock divide by 5"
* ZipCPU
doesn't have openbsd, and is struggling to know what to ask next
* vzcx
knows disappointingly little about ftdi, hardware generally, and what's supposed to be happening here
dys has quit [Ping timeout: 272 seconds]
<vzcx>
i appreciate the effort at least! zipcpu is very cool and having it as an example is really accelerating my practical knowledge of comp arch and verilog
<ZipCPU>
Thanks!
<ZipCPU>
My own knowledge of FTDI+USB is really slim as well
dys has joined #yosys
seldridge has quit [Ping timeout: 255 seconds]
seldridge has joined #yosys
<corecode>
daveshah: how do i find where PLLOUT_B is located at?
<corecode>
i guess it is PLLOUTCORE[1]
<daveshah>
It's PLLOUTCOREB/PLLOUTGLOBALB
<corecode>
but i'm looking at a vlog output, and i can't identify the location
<daveshah>
it will appear as an "input pin"
<corecode>
there is a whole lot of routing
<daveshah>
you should see a D_IN_0 in there?
<corecode>
aaaah
<corecode>
thanks
<corecode>
but where do i find the , 0 or , 1
<corecode>
// (13, 21, 'io_0/D_IN_0')
<daveshah>
0
<corecode>
from the io_0?
<daveshah>
yeah
<corecode>
aha!
<daveshah>
the PLLs are in the input path
<corecode>
sorting the routing information by coordinate is not as useful as sorting it by connection
<corecode>
ok
<corecode>
should i run a connectivity test?
<daveshah>
yes, that would be a good idea
<corecode>
it took very long last time, and then i aborted
<corecode>
you had some feedback on not using the 8k ram db or something like it
<daveshah>
yeah, you should be using the 8k ram db not the 1k ram db
<corecode>
i thought i was
<corecode>
elif self.device == "5k" or self.device == "u4k":