futarisIRCcloud has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #yosys
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 272 seconds]
GoldRin has quit [Read error: Connection reset by peer]
rohitksingh has joined #yosys
emeb_mac has quit [Ping timeout: 272 seconds]
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined #yosys
maikmerten has joined #yosys
<corecode>
daveshah: i'm trying to add LED_DRV / RGB_DRV support for u4k
<corecode>
the issue is that LED_DRV_CUR is a separate instance
<corecode>
so somehow i need to tease apart which bits are for LED_DRV_CUR and which are for RGB_DRV
<daveshah>
corecode: Is LED_DRV_CUR used for anything else?
<corecode>
also for IR_DRV
<daveshah>
If so you could see which bits are common in the two usages
<corecode>
yea
<corecode>
but i don't think i have that for my package
<corecode>
need to look again
<daveshah>
Guess you might need to use a different package for that test
<corecode>
i wonder what the point of this is
<corecode>
it has an output signal
<corecode>
and that signal can only be routed to either RGB_DRV or IR_DRV
citypw has quit [Ping timeout: 248 seconds]
<daveshah>
It almost seems like leaking their implementation detail into user designs
<corecode>
yes
<corecode>
i wonder whether i can somehow force synthesis and placer to keep the LED_DRV_CUR without connecting anything to it
<corecode>
maybe with an explicit place?
<daveshah>
You can put a placement constraint in the pcf file but that won't stop it removing things
<daveshah>
Putting (* keep *) on it might work but I've never tried
<corecode>
it looks like the LED_DRV_CUR is exactly the same location (modulo size) as CURREN is
<daveshah>
Oh that's odd. Same z too?
<corecode>
(25, 19, "CBIT_5")
<daveshah>
Interesting, the UltraPlus sets CBIT_5 in a tile on the other side of the device (0, 28, CBIT_5) when the RGB driver is used
<daveshah>
Is there a CURREN signal anywhere (either on the LED_DRV_CUR or the RGB itself)? On the UltraPlus it routes into tile 25,29 which is equivalent to Ultra tile 25,19
rohitksingh has quit [Ping timeout: 268 seconds]
<corecode>
(0, 18, "CBIT_5")
<corecode>
as well
<corecode>
hm nevermind
rohitksingh has joined #yosys
_whitelogger has joined #yosys
Jybz has joined #yosys
proteusguy has quit [Ping timeout: 246 seconds]
futarisIRCcloud has joined #yosys
proteusguy has joined #yosys
_whitelogger has joined #yosys
dys has quit [Ping timeout: 258 seconds]
_whitelogger has joined #yosys
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
lutsabound has joined #yosys
_whitelogger has joined #yosys
dys has joined #yosys
maikmerten has quit [Remote host closed the connection]
<corecode>
daveshah: i forgot, how do i visualize the placer results of icestorm?
<corecode>
i want to know verify lutff is connected to which io pad
<daveshah>
corecode: use nextpnr --gui
<corecode>
uhm
<corecode>
i mean the result from icecube
<corecode>
not from nextpnr
<daveshah>
Oh, it's called something like "floorplan" or "physical" view
<daveshah>
Haven't used icecube for a while though
<corecode>
yea but somehow i can't synthesize after opening the project
<corecode>
odd
<corecode>
hm, but i can't see what path it takes
<corecode>
mh
<corecode>
so how do i trace these connections?
cr1901 has quit [Quit: Leaving.]
<corecode>
i.e. the sequence of routing and buffers
cr1901 has joined #yosys
citypw has joined #yosys
cr1901 has quit [Ping timeout: 246 seconds]
cr1901 has joined #yosys
citypw has quit [Ping timeout: 245 seconds]
emeb has joined #yosys
<daveshah>
corecode: icecube doesn't any view of the routing
<daveshah>
icebox_explain and icebox_vlog will have to do...
cr1901 has quit [Quit: Leaving.]
cr1901 has joined #yosys
cr1901 has quit [Ping timeout: 248 seconds]
<corecode>
so... what to do with this silly output
<emeb>
the strange relationship between SB_LED_DRV_CUR and SB_RGB_DRV has always puzzled me
cr1901 has joined #yosys
<corecode>
yea
<corecode>
seems shoehorned in
<corecode>
why is there this enable pin?
<corecode>
ah maybe otherwise the synthesis tool will throw it away
<emeb>
maybe for power mgmt?
<corecode>
one is the constant current somethingsoemthing
<corecode>
the other the specific LED drivers
<emeb>
right, but the current source may pull some power and shutting it down may help reduce sleep power.
<corecode>
and by having a virtual signal go from one to the other, the synthesizer can't optimize it away
<corecode>
yes
<emeb>
the Ultra data sheet and appnotes don't provide any detail on this - just say that it supplies a 40uA reference and takes 100us to stabilize after EN is asserted.
<corecode>
yea also the vlog doesn't show anything
<corecode>
nor does the exp
<corecode>
i think it's purely virtual
<corecode>
previously it was part of the RGBA
<corecode>
now it is in a separate instance
<emeb>
yep - and in ultralite and ultraplus it's rolled into the other cores.
<emeb>
probably a consequence of the failed pwm core on ultra
<corecode>
hmm
<corecode>
i think in the ul/up they decided to not have that silly extra instance and instead use the same enable signal twice?
<corecode>
hm
<corecode>
i guess we won't find out - ir400_drv periph is not mapped in icebox
<emeb>
heh - not much point in pursing that then.
<corecode>
not at the moment
<emeb>
that thing is scary anyway :)
<emeb>
YOU CAN'T HANDLE THE CURRENT!!!
cr1901_modern has joined #yosys
<tnt>
It's split probably because it's shared and so that's their way to reflect it in HDL.
<corecode>
yes
<corecode>
do ul/up only have either ir or rgb?
<tnt>
up only has RGB.
cr1901 has quit [Ping timeout: 245 seconds]
<corecode>
can somebody explain what nextpnr's ice40/pack.cc:1116 does?
<corecode>
the disconnect all external ports
<corecode>
is that checking whether the RGB* ports are connected elsewhere?
<corecode>
i guess it does
<tnt>
There is no real wires connection that block to the IO pins.
<corecode>
so, it is called SB_RGB_DRV for the ultra
<tnt>
Not normal routing anyway.
<tnt>
So we remove those wires in nextpnr.
<corecode>
how do i best modify nextpnr?
<corecode>
i mean, naming wise
<corecode>
most of the code applies as well to the ultra
<tnt>
Maybe a generic is_sb_anyled_drv ?
<tnt>
that would cover sb_ir500_drv / sb_barcode_drv / sb_ir400_drv / sb_ir_drv / sb_rgba_drv / sb_rgb_drv
<tnt>
(I think I didn't forget any ...) Then a std::map of the cell name -> an array of the 'special output pins names'.
<corecode>
i don't feel comfortable extending this to IR
<corecode>
not in this change
<tnt>
well you can just put all the 'non tested / supported' ones in /* */
<corecode>
i wonder what i have to do to get the rgb_drv bits into the chipdb
<corecode>
how does create_ice_cell() get called for SB_RGBA_DRV?
<tnt>
It doesn't ?
<tnt>
The cell is already there in the .json when loading.
<corecode>
so why is there code?
<tnt>
create_ice_cell is called when conversing from one cell type to another. Like SB_DSP16 -> ICESTORM_DSP
<tpb>
Title: Dropbox - 0609191105.jpg - Simplify your life (at www.dropbox.com)
<emeb>
err... 64 color :P
<tnt>
emeb: :)
<emeb>
frankly, the composite NTSC w/ color was more challenging than VGA, even though VGA looks better.
<tnt>
Well yeah, not surprising, ntsc was made for analog stuff ...
<tnt>
vga even though the signal itself is analog is way closer to what digital interface video looks like.
<corecode>
so how do i test whether a port is connected to a bel
<tnt>
corecode: huh ? What are you trying to check ?
<corecode>
whether the LEDPU port from LED_DRV_CUR is connected to RGB_DRV
<tnt>
Basically you need to take both cells, then from the cell you get the port, from the port you can find the net and then on the net you can check if the driver is the LED_DRV_CUR and is net.users.size == 1 and if that user is indeed a RGB_DRV.
<corecode>
and do i erase the net?
<tnt>
Yeah since it's not a normal net.
<corecode>
but then if i delete it, i can't test it in the other cell
<corecode>
hmm
<tnt>
Yeah, you'd basically do the test/delete in only one of the cell.
<emeb>
set a private flag "I deleted LEDPU" and test for that?
<corecode>
ah hang on
<corecode>
the cells are sorted
<corecode>
so one is always processed before the other
<corecode>
lexical sort?
<corecode>
i guess bellid index
<corecode>
ah no, idstring
<corecode>
i think the better choice is a flag, yes
<corecode>
what happens if i erase a net, but not all ports connected to it?
<tnt>
well you must not delete the port, but you need to disconnect them.
<tnt>
if not ... assert / segfault / general pain and badness.
<corecode>
Error::Illegal Connection: Pin 'RGBPU' of instance 'RGB_DRV' of type 'RGB_DRV' should be driven by 'LEDPU' pin of 'LED_DRV_CUR' type instance
<corecode>
so that's the message icecube spits out when you wire up 0
<corecode>
however, if you don't wire up anything (don't mention the port), you don't get an error
<corecode>
but somehow the LED_DRV_CUR instance is being optimized away then
<corecode>
ci->ports.erase(ctx->id("RGB0"));
<corecode>
<corecode>
so what's that then?
rohitksingh has quit [Ping timeout: 272 seconds]
lutsabound has quit [Quit: Connection closed for inactivity]
AlexDaniel has joined #yosys
lutsabound has joined #yosys
<corecode>
hm, do i need to make a new ipcon_u4k db?
<corecode>
or do i dump stuff into the 5k?
<daveshah>
corecode: what do you need to add?
<corecode>
the RGB_DRV
<daveshah>
What bits does it add to that database?
<corecode>
i don't know
<corecode>
i'm struggling with icefuzz's Makefile
<corecode>
i need to dump the bits somewhere
<daveshah>
If its just some extra config bits then it's fine just to use the 5k one
<corecode>
ok
<corecode>
hm i don't know how i can get these bits extracted
<corecode>
oooh
<corecode>
mistakes were made
<corecode>
ah no
<corecode>
derp, of course no new bits show up, because the same bits are already used under a different name
<daveshah>
Yes, will just be the same old CBIT_n
<daveshah>
What will be needed is the mapping in icebox specifying what the bits actually do (as part of the extra cell stuff)
<corecode>
yea i have that
sammylin has joined #yosys
<sammylin>
ERROR: no timing info for port 'Y[4]' of cell type '$alu'
<sammylin>
I used a commandline argument of --freq 16
<sammylin>
Is there another way I should specify the timing constraints for my clock?
<corecode>
yea it linked
<corecode>
yosys comes tomorrow
cr1901 has joined #yosys
<daveshah>
sammylin: there shouldn't be a '$alu' cell going into nextpnr at all
<daveshah>
It's complaining about a lack of timing data because it doesn't know anything at all about that cell type