<corecode>
hm what's this pi_eb_bank that i can't find in glbinfo now?
seldridge has joined #yosys
<corecode>
aha
<corecode>
i need to make up padin bits
leviathanch has joined #yosys
gsi__ has joined #yosys
gsi_ has quit [Ping timeout: 250 seconds]
<corecode>
okay
<corecode>
daveshah: yea i don't know where i get the io_clktoq from
<corecode>
or the model params
AlexDaniel has quit [Ping timeout: 268 seconds]
citypw has joined #yosys
rohitksingh_work has joined #yosys
pie__ has joined #yosys
<mrec>
I'm doing some serial communication however the results differ from synthesis to synthesis and that's not only confusing but wrong
<mrec>
I guess there's some bug in the synthesis tool itself otherwise the result wouldn't be random
<mrec>
and I highly doubt that this has anything to do with setup/hold/propagation delays
<mrec>
random in terms of .. it's stable for the image (even if I reload it) but if I do the synthesis again the result might be unexpected in another way
pie___ has quit [Ping timeout: 245 seconds]
<mrec>
I'm transferring some frames, the first value of the frame should be static, one line is used for synchronisation how comes that the static value is different from time to time if it is there at all
<mrec>
I never had such a basic issue with any other lattice part so I guess the ice40up5k is shit
<mrec>
looking at the rtl ... it's even synthesising things which it should cut out ... no no this thing is so wrong
<mrec>
it feels like when counting from 1 to 10 things break at 1
<mrec>
what a damn shit part ... it's like if rising_edge(shitclock) then if iter=2 then output<='1' else output <='0' end if; end if; is not working
<mrec>
iter++ of course
<mrec>
whatever it's so basic that it is impossible to fail normally
proteusguy has joined #yosys
<emeb_mac>
iin my experience when the synthesized design isn't doing what I expect it's usually down to me not having fully understood something.
<MoeIcenowy>
mrec: try Lattice Radient or iCEcube2?
<MoeIcenowy>
if it works with them, but not with Yosys/NextPnR/Icestorm
<MoeIcenowy>
it's a severe bug
seldridge has quit [Quit: WeeChat 1.4]
proteusguy has quit [Ping timeout: 246 seconds]
emeb_mac has quit [Quit: Leaving.]
proteusguy has joined #yosys
m4ssi has joined #yosys
<daveshah>
corecode: have you got timing html file?
proteusguy has quit [Remote host closed the connection]
rohitksingh_work has quit [Ping timeout: 250 seconds]
rohitksingh_work has joined #yosys
rohitksingh_work has quit [Ping timeout: 245 seconds]
citypw has quit [Ping timeout: 240 seconds]
<corecode>
yes
indy has quit [Ping timeout: 250 seconds]
<corecode>
daveshah: i only see propagation delays and timing checks
danieljabailey has quit [Ping timeout: 244 seconds]
<tnt>
mrec: just pastebin the exact code you're trying to run ...
<daveshah>
corecode: what you want is the propogation delay from posedge:clk to lcout
<daveshah>
in LogicCell40
<corecode>
ooh, i thought it is for SB_IO
<corecode>
1050, it says
<corecode>
somehow i have all propagation delays twice
<corecode>
odd
<daveshah>
Can you post the file? From memory if icecube.sh isn't creating the project correctly then icecube can produce funny timings
<tnt>
daveshah: you can only use 5V if the min Vf is large enough AFAIK.
<daveshah>
corecode: nextpnr always uses a SB_GB for global signals
<daveshah>
you can tell it not to for testing with "(* ROUTE_THROUGH_FABRIC=1 *)
<daveshah>
on the HFOSC
<tnt>
your chipdb for HFOSC has a port named 'CLKLF_FABRIC 0 18 slf_op_7' that seems suspicious.
<corecode>
doesn't the HFOSC directly go to the global network?
<daveshah>
well, through a padin
<daveshah>
the SB_GB is used to enable that, and also prevent anything else using that global buffer site
<tnt>
corecode: SB_GB kind of represents the 'global network'.
<corecode>
in the HFOSC tile
<corecode>
okay
<corecode>
so SB_GB can be used for both fabric signals and for signals that can be connected directly to the glb
<daveshah>
in nextpnr, this is how we represent this
<MoeIcenowy>
daveshah: I dug into the issue, and found that when dealing with VQM, the width of some intput/output of altsyncram depends on its parameters
<MoeIcenowy>
however yosys seems to have no support of this
<MoeIcenowy>
(Quartus uses its proprietary format to define altsyncram
<daveshah>
Yosys supports this for normal cells
<daveshah>
I don't know how it works for blackbox cells
<MoeIcenowy>
how to use it?
<MoeIcenowy>
oh sorry I found me wrong
<MoeIcenowy>
the uppercase and lowercase naming of the parameters are the same within Quartus when parsing VQM
<MoeIcenowy>
but is different on Yosys
<corecode>
so why are there only 18 cbits, and it is trying to access bit 21
<MoeIcenowy>
I just wrongly used lowercase in parameter def and lowercase in portdef
<corecode>
hm, it's trying to set a config bit in ipconn cell 0/19
m4ssi has quit [Remote host closed the connection]
<daveshah>
Ultra doesn't have IO tiles at the side
<corecode>
duh!
* corecode
makes up a song about rebuilding chipdbs
<daveshah>
:D
<daveshah>
we should add music like those old keygens
<ZipCPU>
daveshah: Who's building that HugeFPGA?
<daveshah>
:D
<ZipCPU>
Is that just the tinyFPGA EX renamed?
<daveshah>
yes, it was a bad combination of inspect element and gimp :P
<ZipCPU>
So ... there's really nothing there then? Got it.
<MoeIcenowy>
I got manually defined altsyncram work now
<MoeIcenowy>
but inferred ones still not work
<daveshah>
I don't think Intel RAM inference really works yet
<daveshah>
ZipCPU might know more?
<ZipCPU>
What device are we discussing? Altera?
<MoeIcenowy>
ZipCPU: yes
<ZipCPU>
I've been building a design with inferred RAM within it ... is that not working for you? Which device?
<MoeIcenowy>
ZipCPU: do you use Yosys to synth and Quartus to PnR?
<ZipCPU>
I have used Yosys to synth, but I'll admit my path stopped there
<ZipCPU>
My design needs DDR I/O elements, as well as the PLL, and I'm not (yet) certain how to properly synthesize those for Quartus PnR
<MoeIcenowy>
The inferred thing seems well, but it just doesn't work ;-)
<ZipCPU>
How so?
<tnt>
corecode: inside the FGPA the actual SB_GB circuit is probably not used, but 'virtually' instanciating a locked SB_GB for cores that drive the global network is how it's done in next pnr. This made it easier to support and also 'lock-out' that particular SB_GB from being used (since it would drive the same global network ...).
<MoeIcenowy>
Quartus has strict check on altsyncram parameters and ports
proteusguy has joined #yosys
<MoeIcenowy>
and VQM is not Verilog -- it has a more narrow grammar
<corecode>
hm, unable to find config bit IpConfig.CBIT_3
<corecode>
CLKHF_DIV_0
<corecode>
IpConfig.CBIT_3 B2[7]
<corecode>
<corecode>
it's in the chipdb tho\
<corecode>
hm no, i think this is a different CBIT_3
<corecode>
no, it's the hfosc, pretty sure
<daveshah>
corecode: are you sure that location is an ipcon tile?
<daveshah>
and that is going into the database correct
<daveshah>
*correctly
<corecode>
it's a dsp tile
<corecode>
but bitstream.cc replaces the name with IpConfig.
<daveshah>
Is it a dsp3 tile?
<daveshah>
Looks like only CBIT_0 is present in the config bit database for that
<tpb>
Title: ice40: support u4k by corecode · Pull Request #241 · YosysHQ/nextpnr · GitHub (at github.com)
<daveshah>
Awesome
<daveshah>
I'll take a look
<corecode>
thank you
noname_Matt has quit [Ping timeout: 256 seconds]
<tnt>
What's SMCCLK btw ?
noname_Matt has joined #yosys
<daveshah>
tnt: my limited understanding is SMCCLK exposes the internal configuration clock
<daveshah>
I don't exactly know how it behaves after startup
<daveshah>
But on the iCE40 Ultra iCEcube uses it to clock a register (with D input at 1'b1) driving output enables
<noname_Matt>
Has anyone tried writing a partial bitstream to an ice40 device without restarting it? (a warm boot perhaps?)
<noname_Matt>
I'm interested to know if it would be possible to lay things out such that the devices attached to a buss in an SoC could be swapped during operation
<daveshah>
As far as I know, any reconfiguration will lose CRAM and register values
<daveshah>
I don't even know a way to keep the config port open while the design is running
<daveshah>
OTOH, preserving BRAM across reconfig is supported
<corecode>
wow hot hardware update
<corecode>
and reload state from bram
<noname_Matt>
corecode: Can you elaborate a bit? I did see some info on enabling/disabling warm/cold rebooting, but nothing on what a 'hot' update would entail
<corecode>
i'm just extrapolating from the information
<noname_Matt>
I'm guessing this would reconfigure the device and clear all registers, but you're suggesting to recover from bram?
<daveshah>
So BRAM will be kept if the bitstream doesn't initialise it
<corecode>
dump all state into a bram via some shift register or mux, then in the new design reverse direction
<noname_Matt>
I see.
<daveshah>
atm the tools always include bram init in the bitstream, but that would be easy enough to change
<corecode>
i don't think an fpga is really made for that
<corecode>
i mean, can you load the DFF optionally from a different signal?
<noname_Matt>
Still requires explicit start/stop, but saves having to do a full reboot of the core.
<noname_Matt>
well, I think the FPGA is definitely not made for this, but then again it definitely wan't made to work with icestorm
<noname_Matt>
daveshah: what might be fun is to configure a simple logic circuit that responds to outside signaling, and measure at what point you lose CRAM/register contents
<noname_Matt>
and see if it can be skipped over, maybe
<daveshah>
I have attempted to readout CRAM after asserting CDONE and not got anything useful
<noname_Matt>
like, maybe it's only wiped if you're writing to the same block? I'm not aware of any trials and I'd be interested to know if anyone tried this during initial reverse engineering
<tpb>
Title: Project IceStorm Bitstream File Format Documentation (at www.clifford.at)
<noname_Matt>
so I don't know what you're talking about :(
<daveshah>
creset is a pin
<corecode>
config pins
<daveshah>
You assert it to reset the device, and you have to assert it to re enable the SPI programming interface
<daveshah>
As soon as you assert it, CRAM is wiped
<noname_Matt>
is there somewhere I can read about the programming procedure?
<corecode>
and i guess clocks stop running
<corecode>
yes, there is an app note
<noname_Matt>
when does the SPI interface become disabled?
<corecode>
i think CDONE goes high at some point
<corecode>
and that's it
<noname_Matt>
I ask because I guess the next logical question is if it's possible to get into an inbetween state where running and programming are both possible.
<noname_Matt>
is the app note on lattice's site somewhere?
<corecode>
i'd home not
<corecode>
yea
<corecode>
hope*
<daveshah>
SPI is disabled once you send opcode 0 payload 6 to wakeup and start running the bitstream
<daveshah>
It's possible there's a different command to run the design without disabling SPI
<corecode>
ah so far i've just pushed out the bin
<daveshah>
It's also unlikely given the structure of the device
<daveshah>
Yeah, effectively the bin is a series of commands
<noname_Matt>
might be fun to fuzz it and look for undocumented commands, but it sounds like you might be correct
<noname_Matt>
what dos warm boot in opcode 9 refer to?
<noname_Matt>
does*
<daveshah>
It enables use of the SB_WARMBOOT primitive
<corecode>
but warmboot is spi master
<daveshah>
Yeah
<daveshah>
Exactly the same commands are read off SPI flash in that mode
<daveshah>
Just the iCE40 is driving the clock and sends a read command first
<noname_Matt>
cool
<noname_Matt>
and I assume it will read the same opcodes and look for the same sort of termination?
<corecode>
so, do i try to upload a blinky design to my board
m4ssi has joined #yosys
<daveshah>
noname_Matt: the termination is the wakeup command again
<corecode>
well, opcode 0/6
<noname_Matt>
what if you send it a reboot instead? how does SB_WARMBOOT fit into it?
<noname_Matt>
reboot: 0/8
<daveshah>
Reboot just resets things
<daveshah>
WARMBOOT basically indexes into a jump table that points to the image, iirc
<noname_Matt>
reboot just starts everything over again?
<daveshah>
Yeah
<noname_Matt>
so warmboot allows you to select a starting point to read opcode from one of several locations, but requires the same resetting? is it related to is 4/*?
<daveshah>
Yes, warmboot also performs a reset of all but BRAM
<daveshah>
Yes, warmboot will index into a jump table of 4 opcodes that point to the real images
<noname_Matt>
that is, opcode 4/* not literally a table four entries long?
<noname_Matt>
I presume such a table is located at a certain spot and is indexed on some condition?
<daveshah>
I think each "warmboot applet" is 32 bytes in total
<daveshah>
With a 4 command to set the jump address and a reboot command which jumps to that address
<daveshah>
The warmboot primitive selects one of those applets
<noname_Matt>
hrm.
<noname_Matt>
when you say warmboot primitive, is this a series of opcodes, or a hardwired procedure?
<noname_Matt>
controlled by opcode 9/*?
<corecode>
SB_WARMBOOT
<noname_Matt>
A signal on the chip?
<corecode>
yes
<noname_Matt>
and this starts the procedure to select and load a bitstream?
<corecode>
i think you apply signals that select the bitstream
<noname_Matt>
ok. that makes sense
<noname_Matt>
thank you. I have a much better idea how all this work now.