<ZipCPU>
Hey, this is cool, I've now managed to "prove" 3 different pre-fetches, a double buffered bus delay, an avalon to wishbone bridge, and an LFSR ...
<ZipCPU>
This formal stuff isn't really all that hard, and it tends to give me more confidence in my cores than the test-bench alone.
<qu1j0t3>
ZipCPU++
<ZipCPU>
o/
<ZipCPU>
The bus stuff's will be fun to post on ...
<awygle>
cr1901_modern: so why do GBAs scream at you?
<cr1901_modern>
awygle: I couldn't remember/find the details in my IRC backlog
<cr1901_modern>
It has to do with the fact that the GBA CPU's sound driver doesn't stop running when the cartridge is ripped out and will periodically execute data as code.
<cr1901_modern>
But that's imprecise enough that I just will stash it for later
<thoughtpolice>
cr1901_modern: FWIW it's not really in the same league as partial reconfig in Xilinx/Altera since you have to pick the bitstreams 'up front'. You can't load a new bitstream into flash while an iCE40 is plugged in, but you can pick from a set of images that already exist in flash.
<thoughtpolice>
Still pretty useful though! I kinda ported it because I was surprised it had this feature. Guess I always overlooked warmboot in the manual...
<cr1901_modern>
I don't understand the difference. Why would you want (and how would you) choose the bistream on demand?
_whitelogger has joined #yosys
<thoughtpolice>
iCE40 warmboot allows you to simply package up-to 4 .bin files into a single .bin file. The first .bin file is booted (or whatever you configure the reset vector to jump to, but I think `icemulti` always boots image #0). You can just pass control ('warm boot') to another .bin at any time, but new images require resetting/reflashing the device. So an easy use case is just app-switching (e.g. image #0 lets me choose images 1-3,
<thoughtpolice>
which may have e.g. sump2).
<thoughtpolice>
If it has enough flash, of course.
Judd_ has joined #yosys
<cr1901_modern>
I don't see the difference if in both cases, the FPGA needs to be halted
Judd_ has quit [Client Quit]
<cr1901_modern>
and well, can't you reset the FPGA internally (by redirecting an I/O to toggle the reset circuitry?)
<cr1901_modern>
ZipCPU: Not that I would willingly put myself in this situation, but does your eponymous CPU support C++ exceptions?
<thoughtpolice>
"One way requires you to power down and the other doesn't" is a first approximation. It's not always clear what "reset" means though. e.g. turning a PCIe device on/off again may be tricky (and honestly I'd imagine it to be somewhat annoying and slow comparatively). And what if you're on a SoC, and your ARM machine wants to reconfigure the bitstream, but it's attached to live pins? You might not necessarily want to reset the
<thoughtpolice>
whole FPGA if something else is attached at the time.
<thoughtpolice>
Also, in cases like the F1, they don't want to give you direct access to pins/peripherials, because they want to abstract out the interface you program against. This allows them to e.g. upgrade to new FPGAs later, or ship improvements (like better device utilization -- the F1 SDK recently shipped an update that e.g. gave more UltraRAMs to users than before). But you need to be able to load new bitstreams at any time, on
<thoughtpolice>
demand, too.
<thoughtpolice>
And also it's just convenient? We're basically doing image processing on FPGA/SOCs right now, so in our case it's not really world-ending to restart something, but it's just inconvenient to reset the FPGA just to load a new config. Just being able to have the driver negotiate 'hot upgrades' on demand is nice, and is better from a design POV (it forces us to abstract out board-specific logic, for one)
<cr1901_modern>
I misread your explanation, I see now. And by device reset, I meant "force the FPGA to start loading a bitstream again from SPI/whatever"
<cr1901_modern>
i.e. "what the ice40 does"
<thoughtpolice>
Ah, yeah. Unfortunately PR is one of those typical "Pay us <undisclosed sum> to get it"-features, which is a shame. Moreso for Intel than Xilinx, I guess...
<thoughtpolice>
I guess for Intel it's not really undisclosed.
<sorear>
had no idea
<cr1901_modern>
You have to pay for it for Xilinx?
<sorear>
there seem to be several versions of Vivado, the $3000 version comes with PR, the free-with-device version requires an unlock code
<thoughtpolice>
Actually not anymore if you have a real Vivado license, apparently. I'm one of those cheapskates.
<sorear>
the cost of the unlock code is not listed but it can't rationally be above $3000
<thoughtpolice>
From what I knew prior a PR license was something like $1k USD when it wasn't part of "Real" Vivado
<thoughtpolice>
Apparently it's cheaper now too so that's nice I guess.
<cr1901_modern>
I see
<cr1901_modern>
I'm stuck w/ ISE for a while, so... :P
<thoughtpolice>
They also support PR on all -7 series chips produced, which is nice. Intel doesn't do this unfortunately.
<sorear>
i thought you meant "PR is available only for institutional customers, several MM"
<thoughtpolice>
Ah, no. More like "Not easily available in the enthusiast setup really". Clearly, I'm just stingy!
<cr1901_modern>
I thought the warmboot primitive had some config options
mbuf has quit [Ping timeout: 258 seconds]
mbuf has joined #yosys
<cr1901_modern>
In any case, warmboot is probably satisfactory for any application I need for now; most I/O I would attach to an ICE40 could tolerate hi-z or pullups while the FPGA loads a new bistream
<cr1901_modern>
" e.g. turning a PCIe device on/off again may be tricky" Although I guess PCIe is _not_ such an interface :P (aside from power on of the entire system, which you have to wait for configuration anyway)
<cr1901_modern>
Idk it might be doable, PCIe is hotplug IIRC
* cr1901_modern
is thinking out loud, ignore
<sorear>
yeah, it'd be hotplug
<cr1901_modern>
I.e. "get signal you want to swap bitstreams, run a state machine to shut down PCIe link, wait for okay, then signal FPGA to reset/load new bitstream."
<cr1901_modern>
"load bitstream, bring link back online as part of reset FSM"
<cr1901_modern>
and possibly keep external state (SRAM) about whether this was initial power-on or reload when negotiating link
<cr1901_modern>
Not saying it's convenient or recommended :P. Just mulling over how it could be done :)
<sorear>
i believe the firmware update for at least some usb devices works that way
<cr1901_modern>
sorear: Hrm, good point, assuming the FPGA isn't accessing the flash after it loads a bitstream.
<cr1901_modern>
I was consdering the contrived case where I have multiple bitstreams on flash already and wanted to swap
<cr1901_modern>
sorear: Where yours is "update flash, tell FPGA time to reload, and then FPGA reloads the same bitstream again ('cept updated)?"
digshadow has quit [Ping timeout: 240 seconds]
dys has quit [Ping timeout: 240 seconds]
dys has joined #yosys
digshadow has joined #yosys
xshock has joined #yosys
<xshock>
hi. is anyone working on supporting ice40up5? The ultra plus series?
xshock has quit [Ping timeout: 260 seconds]
ravenexp has quit [Quit: WeeChat 1.9.1]
ravenexp has joined #yosys
m_t has joined #yosys
qu1j0t3 has quit [Ping timeout: 255 seconds]
qu1j0t3 has joined #yosys
<ZipCPU>
xshock: Yes
<ZipCPU>
cr1901_modern: It should, although I haven't tested it. I did build the support into g++ as I recall.
aw- has joined #yosys
befedo has joined #yosys
aw- has quit [Quit: Leaving.]
_whitelogger has joined #yosys
mbuf has quit [Quit: Leaving]
digshadow has quit [Read error: Connection reset by peer]
digshadow has joined #yosys
mbuf has joined #yosys
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined #yosys
befedo has quit [Quit: befedo]
mbuf has quit [Remote host closed the connection]
befedo has joined #yosys
adj__ has quit [Ping timeout: 248 seconds]
dys has quit [Ping timeout: 258 seconds]
adj__ has joined #yosys
dys has joined #yosys
dys has quit [Ping timeout: 248 seconds]
dys has joined #yosys
m_t has quit [Quit: Leaving]
befedo has quit [Quit: befedo]
LongHairedHacker has quit [Remote host closed the connection]