<litghost>
By default yosys appears to set unset BRAM init parameters to 'x'. Is there any option or command to force unset/unused BRAM INIT values to 0?
seldridge has joined #yosys
q3k has quit [Read error: Connection reset by peer]
<litghost>
Won't work, as the hardware BRAM inference (e.g. memory_bram) is the thing that is introducing the 'x'. I am fully defined the RAM, but narrower than the underlying BRAM primitive.
gsi_ has quit [Ping timeout: 255 seconds]
citypw has joined #yosys
gsi__ has quit [Ping timeout: 272 seconds]
gsi_ has joined #yosys
proteusguy has quit [Ping timeout: 250 seconds]
Forty-Bot has joined #yosys
<ZipCPU>
lighost: No, that should work
<ZipCPU>
You aren't running into the issue about not being able to use the iCE40 block RAMs for the first several clock ticks, are you?
leviathanch has joined #yosys
proteusguy has joined #yosys
rohitksingh_work has joined #yosys
pie___ has joined #yosys
pie__ has quit [Ping timeout: 250 seconds]
<MoeIcenowy>
litghost: add a new step
<MoeIcenowy>
refer to my code for Anlogic
<MoeIcenowy>
the Anlogic TD tool do not accept 'bx in BRAM/DRAM initialization
rohitksingh_work has quit [Ping timeout: 245 seconds]
rohitksingh_work has joined #yosys
jevinskie has joined #yosys
<litghost>
ZipCPU: No, this shows up in the final synthesized output. The problem is on Xilinx BRAM hardware, which Yosys techmapping an 18-bit wide 1024 deep onto a 16-bit wide 1024 deep primative. So the upper two bits of each depth is 'x'
<litghost>
Moelcenowy: Which step did you added? setundef appears to be the right command, but it doesn't seem to affect parameters. I'm working on a patch to add a -params mode, but unclear if that is the best approach.
<litghost>
Moelcenowy: Any chance you are referring to Moelcenowy?
<litghost>
anlogic_determine_init?
proteusguy has quit [Remote host closed the connection]
<MoeIcenowy>
it's anlogic_determine_init what I mentioned
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
develonepi3 has joined #yosys
leviathanch has quit [Remote host closed the connection]
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #yosys
leviathanch has joined #yosys
Cerpin has joined #yosys
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #yosys
emeb has joined #yosys
seldridge has joined #yosys
danieljabailey has joined #yosys
ylamarre has joined #yosys
voxadam has joined #yosys
<sxpert>
litghost: sounds like yosys uses the wrong primitive then
<sxpert>
daveshah: if, in a particular always block, I have multiple access to the same distributed memory with the index being generated by a wire, will yosys be able to use one single memory block ?
<corecode>
why not
<sxpert>
just asking if this is the right way to do it
<corecode>
yes, usually this is how you set defaults
<daveshah>
This should work, although a separate, explicit memory can never go wrong in any tool
<corecode>
you first write defaults, then you voerwrite them
<corecode>
rewrite*
<corecode>
overwrite* even
<corecode>
to prevent latches
<sxpert>
daveshah: sure, just trying to be the cleanest possible ;-)
<corecode>
think about how to do it in hardware
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sxpert>
well, I have a wire that is generating the index, with a bunch of | conditions
<corecode>
this is what i did, no idea whether that's good style or not
<sxpert>
to me this reads like a series of and gates to select the right thing, then an or gate to get the state out
<corecode>
yes
<corecode>
i'm not saying it is wrong
<ylamarre>
corecode: Watch out for partability, Vivado had trouble with this kind of priority encoding... not sure when/if it was fixed...
<corecode>
i find it harder to understand
<sxpert>
it also feels like telling the compiler what to do exactly
<corecode>
synthesis tool*
<sxpert>
whatever ;)
<corecode>
difference
<ylamarre>
It matters :p
<corecode>
i think they usually blow it up into a big karnaugh map and then reduce it again
<corecode>
just guessing
m4ssi has quit [Remote host closed the connection]
m4ssi has joined #yosys
* sxpert
learned digital electronics by blowing up ttl chips 25 or so years ago,,,
<sxpert>
somehow the teachers hated me ;-)
<sxpert>
such as when I told the teacher "why bother with karnaugh maps, just use a memory, put all the inputs on the address bus, and voila, 8 perfectly programmed functions out
<sxpert>
little did I know by then... that's what PALs/GALs were made of ;-)
<sxpert>
funny how an fpga macro cell is pretty close from a 16R4 ;-)
<corecode>
why funny
<sxpert>
well...
<sxpert>
it's the same stuff from 20+ years ago, shrunk down and copy/pasted 10k times ;)
* sxpert
loves delving in history to see how things advanced over time
<corecode>
daveshah: so what now after the icecube port?
<mrec>
this ice40up/icecube turns out to be a nightmare
<corecode>
what is?
<mrec>
Tool unable to find location for GB
<mrec>
I2712: Tool unable to find location for GB dcfx.sfifo.mem_doread_RNI83RD_0
<mrec>
what should that mean?
<mrec>
the entire simulation seems to be worthless with it :-(
<corecode>
do you have a lot of different reset and clock networks?
leviathanch has quit [Remote host closed the connection]
<mrec>
no
<mrec>
hmm
<mrec>
no such problem with radiant
<corecode>
yea icecube2 fails to place stuff for my design
<mrec>
are there any issues with icecube2 and the ice40up?
<corecode>
so i'll try yosys
<mrec>
I'm not a fan of the ice40up ... all the other lattice parts seem to be better and have a better simulation
<mrec>
I think I'll just dump that shit ice40up evb...
<mrec>
nonsense product, they better add more memory to the other fpgas
<daveshah>
corecode: next step if you are happy with the icestorm stuff is nextpnr support. First thing to do is check that icebox_chipdb dumps a text chipdb correctly
<daveshah>
Then it's pretty much a case of looking through nextpnr/ice40 for every up5k specific place and duplicating with necessary changes
m4ssi has quit [Remote host closed the connection]
maikmerten has joined #yosys
<mrec>
I wonder why the ice40up synthesis creates randomly different results... to me the lattice synthesis tools for this chip are absolute garbage
<tnt>
?
<mrec>
that's what I'm thinking the whole day already
<mrec>
entire/
<tnt>
heh, I love that fpga, actually pretty capable if you know how to use it. Also never had any issues with the tools really.
rohitksingh has quit [Ping timeout: 245 seconds]
<mrec>
me neither but only with xo2, xo3, ecp5
<mrec>
also ice40hx no problem
<mrec>
but ice40up ... everything's crazy
<mrec>
the biggest problem is that the simulation doesn't match
<tnt>
doesn't match what ?
<mrec>
I'm sending some data to the fpga and would like to receive some data back, however I get nothing it's stuck at 0V
<mrec>
and the interesting part is after synthesis sometimes it works a little bit but most of the time it doesn't
<mrec>
as long as I won't re-run the synthesis I can keep going with the half working image
<mrec>
what a nonsense
<tnt>
I'm pretty sure you screwed up something ...
<tnt>
I never had any issue that didn't turn out to be my fault.
<mrec>
just that I cannot figure it out for the entire day...
<tnt>
non-deterministic behavior points to timing issues often since PnR is always a random process that will always yield different result at every run.
<tnt>
what does the design even do ?
<mrec>
it's supposed to buffer some data
<mrec>
however I'm very far from that since I cannot even get the communication work at all
<tnt>
does it meet timing (and is properly constrained) ... are all the IO properly using IO registers and you properly did the setup/hold time analysis with whatever they're connected to .... etc ...
<mrec>
I never had such problems with other fpgas
<tnt>
well if you haven't done what I pre-cited above, you've always done things wrong and that was just dumb luck ... all those step should be standard for any design.
<ZipCPU>
mrec: What type of communication protocol are you trying to implement?
<tnt>
what hardware, what is it connected to, also, where is the code, ...
seldridge has quit [Ping timeout: 246 seconds]
seldridge has joined #yosys
seldridge has quit [Ping timeout: 245 seconds]
seldridge has joined #yosys
m4ssi has joined #yosys
maikmerten has quit [Remote host closed the connection]
<corecode>
daveshah: what's these mystery bits? how do i know whether i have that also on the ultra?
<corecode>
if (ctx->args.type == ArchArgs::UP5K && x == 25 && y == 14) {
<corecode>
// Mystery bits not set in this one tile
<corecode>
<daveshah>
Have a look at the explain output on an empty design and see if all the tiles have LC_x bits set in dsp and ipconn tiles
<corecode>
ok
<corecode>
thanks
<daveshah>
On the UltraPlus all but one of the dsp and ipconn tiles have these bits set
<corecode>
hm
<corecode>
For iCE40UL device, user can configure the internal pull up resistor strength of an IO to a predefined resistor value via attribute settings.
<corecode>
UL? what about UP and LP (ultra)?
<corecode>
why does the tech library documentation say only on UL, but you have it for UP?
<daveshah>
I know the UltraPlus can, because icecube allows you to enable it
<daveshah>
and I've tested it
<corecode>
in the constraints editor i can set pull-up to yes
<corecode>
but where would i set the strength
<daveshah>
But not change the value?
<corecode>
not in the UI
<corecode>
just yes/no
<daveshah>
Then the Ultra almost certainly has old style pullups not the new selectable strength ones
<corecode>
okay
<corecode>
so maybe in the docs they wanted to write UP but wrote UL
<daveshah>
UltraLite has them too
<corecode>
what are the chances that UP and UL have it, and LP doesn't?
<daveshah>
UL came before UP, so I think it's more likely they just never updated the docs after the UP release
<daveshah>
Quite likely, as UL came after iCE5LP
<corecode>
hm
<corecode>
i guess i should try changing the pcf
<corecode>
and see what happens
<daveshah>
Yeah
<daveshah>
add -pullup_resistor 3P3K and see if any cf_bits appear in the explain
<corecode>
interesting, we don't have any existing test
<daveshah>
No, I think my testing of that was very impromptu
<corecode>
ok, doesn't seem to change anything
<corecode>
i'm surprised that icecube doesn't complain
<daveshah>
Do you also have -pullup yes?
<corecode>
duh
<daveshah>
Yeah, it's funny that icecube accepts it then
m4ssi has quit [Remote host closed the connection]
<corecode>
hey, it just discarded my input
<corecode>
and therefore the pullup
<corecode>
so R_EN is 1 when there is no pullup?
<corecode>
yea, doesn't look like there is any effect when i set -pullup yes -pullup_resistor 3P3K
<daveshah>
It could be that the mystery bits are only set when the DSP is used
<corecode>
yes
<daveshah>
I remember on the UltraPlus I tried removing them out of curiosity and the DSPs wouldn't work
<corecode>
ah yes
<corecode>
hehe
<corecode>
do i have to care about ip_dsp_lut_perm?
<daveshah>
No, that is obviously the same looking at that output
<corecode>
what does that permutation do?
<daveshah>
For both real LUTs and the fake LUTs in the mystery bits (which are always a pass through from in2), there is a permutation from LUT init bit index to LC_i bit index
<daveshah>
Just to do with how the iCE40 bitstream is laid out
<corecode>
aha
<corecode>
now, how do i know whether some ipcon tiles will maybe get these mystery bits set?
<corecode>
because half of the ipcon tiles don't have bits set
<daveshah>
They might be set if you use an IP that is routed through one of those tiles
<daveshah>
You'd have to know the IP routing first though
<corecode>
so do i just always set the bits?
<daveshah>
At worst, setting them unnecessarily will probably slightly increase power consumption
<daveshah>
So it looks like there's a D flipflop with D connected to 1 (ie a LUT init of all 1s) and clk to the SMCCLK CLK output, driving the output enable of an IO
<daveshah>
I've not seen this before, but it reeks of silicon bug specific to the Ultra
<corecode>
aha!
<daveshah>
Probably because IO were being enabled slightly too early during startup and glitching
<corecode>
i've seen this before in the logs
<daveshah>
Interesting
<corecode>
Number of inserted LUTs to Legalize IOs with PIN_TYPE= 01xxxx :1
<corecode>
this is with the latest icecube
<corecode>
maybe an older icecube wouldn't do this?
<daveshah>
Could be
<corecode>
let me run that for up5k
<daveshah>
I've not seen it for up5k and I was using latest icecube2 I think
<corecode>
that is correct
<corecode>
this is crazy!
<corecode>
i wonder what happens if you don't do that step
<daveshah>
You found a mystery CBIT in the bitstream, right? That could be related
<corecode>
i don't see that cbit anymore
<corecode>
it could have been the dsp error
<daveshah>
Yeah, possible
<daveshah>
I doubt that the SMCCLK behaviour will need to be replicated in nextpnr initially to get something working
<daveshah>
In the long term, it might be needed if icecube is adding it to work around a genuine issue
<corecode>
yea i doubt it too - that's something they would have caught
<corecode>
there is one bit set in ipcon 25 3
<corecode>
let's see what explain says
<daveshah>
Given that every iCE40 has had slightly broken BRAM startup I wouldn't be so sure
<corecode>
buffer slf_op_5 sp12_h_r_2
<daveshah>
That looks like the routing from the SMCCLK output
<corecode>
yes
<daveshah>
IP always uses slf_op_i in ipcon tiles for outputs
<corecode>
yep
<corecode>
so now we know where the internal oscillator sits :)
<daveshah>
Well, not the user internal oscillators but the secret mystery one :D
<corecode>
yes exactly
<daveshah>
Might as well add it to the icebox cells list anyway
<corecode>
heh i found something new!
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
<daveshah>
I wonder if the UltraPlus has a SMCCLK primitive too
<corecode>
is it (25, 3, 0) or (25, 3, 1)?
<daveshah>
z doesn't matter for functional purposes so long as its unique within a tile
<daveshah>
If it appears in icecube floorplan view, use the coordinates that gives
<daveshah>
Otherwise, the first free z index in 25, 3
<corecode>
it just says IpConn tile
<daveshah>
Doesn't matter then - the only other place z is used is constraints, but that's kind of irrelevant for a cell that is one per device
<corecode>
ok
<corecode>
so how do i test whether this is recorded right in icebox
<daveshah>
There isn't really a way for these primitives
<daveshah>
Need to get round to proper extra cell support in icebox_vlog at some point
<corecode>
okay
<corecode>
man i need to disable my clean up trailing space on save
<corecode>
it adds so much churn that i have to remove