<ZipCPU>
Okay, we are talking about the same simulator
<ZipCPU>
But ... what constitutes a "memory mapped SPI port"?
<ZipCPU>
Flash memory?
<janrinze>
I have an Acorn Atom emulator that uses a hardware SPI port (8bit) that is accessed at a memory address
<ZipCPU>
Okay, but ... that's not specific enough to answer the question
<janrinze>
so it is a write to that address and a read to see the result
<ZipCPU>
That doesn't sound similar to the SD card's SPI protocol.
<ZipCPU>
In the SD card protocol, you write commands such as read or write sector to the card
<janrinze>
the write triggers the transfer, the read is done after a sufficiently long delay
<ZipCPU>
You then read/write a sector of data
<mmicko>
develonepi3: try with this parameter, boost python is usually separate install since it is optional and it is not in default build, so check without python support
<janrinze>
The protocol is handled in software
<ZipCPU>
The SD Card SPI protocol also has a rather complicated start up procedure
<janrinze>
It already runs on the FPGA, now i'd like to use the software emulator with the same ROM
<ZipCPU>
Would the flash emulator be more appropriate?
<ZipCPU>
That can handle reading and writing bytes, but again it's not a generic protocol--it's supporting a flash SPI protocol
<ZipCPU>
The flash requires specific commands to read and write from and to various addresses
<janrinze>
Let me explain, There is a ROM that implements a filing system and uses the SDcard SPI protocol to interface with the SDcard.
<ZipCPU>
Ahh ... okay, so you already know that it's the SD card SPI protocol?
<janrinze>
Yes. It already runs on my FPGA
<janrinze>
can read/write files on the SDcard.
<ZipCPU>
That sounds like it'd be worth trying
<ZipCPU>
Are you using Verilator?
<janrinze>
The emulator is written in C/C++
<ZipCPU>
Oh? No Verilog?
<janrinze>
Nope. The FPGA design is in verilog though.
<janrinze>
But running the Verilator version would cause quite a bit of overhead.
<ZipCPU>
Okay ... so, this still sounds doable, but you might need some more patching to make it work
<janrinze>
Yeah, that's what i am looking at.
<ZipCPU>
The SDSPI emulator takes CSn, SCK, and MOSI in, and returns MISO as a result
martin2250 has joined #yosys
<janrinze>
I think if i can modify it a little to have a byte interface ( just skipping the SPI clocks and such) it might just work.
<ZipCPU>
I make no warranties or guarantees
<ZipCPU>
:D
<janrinze>
:D understood.
<janrinze>
bottom line is just to have the appropriate communication and responses, including the read and write to a block of memory that holds the SDcard image.
<ZipCPU>
Well ... it might be worth trying
<janrinze>
there are some ROMs that use bitbanging interfaces that might be more appropriate for more direct implementation of your source code.
<janrinze>
Can try both solutions.
<janrinze>
The SDcard image is a whopping 100MB :-)
<ZipCPU>
Wow
<janrinze>
holds 1024 floppy images :D
<ZipCPU>
Hmm ... not sure if I should be impressed or dismayed at that statistic
<martin2250>
Hi everyone! I'm new here and I need some help getting my iCE40 boards working, anyone here who has some experience with the boot/configuration process or who can point me in the right direction?
<ZipCPU>
It's like saying I can run 50k slide rules all at once to do calculations ...
<ZipCPU>
martin2250: Were you the one posting to reddit the other day?
<janrinze>
haha.. 1980's system so we're actually talking about a 6502 system with SDcard :D
<martin2250>
yes, that was me
<ZipCPU>
martin2250: Welcome to the channel
<janrinze>
hi martin2250
<janrinze>
martin2250: which iCE40 board?
<ZipCPU>
I don't think I've tried configuring any of my iCE40s from flash
<janrinze>
i have.
<janrinze>
martin2250: using the yosys/nextpnr/icestorm tools?
<ZipCPU>
The tinyfpga code should be a decent example of what needsd to happen
<ZipCPU>
Sounds like you are missing a sync word of some type
<martin2250>
it's a basic breakout board for the LP1K-CM36. I've had to connect some pins together to get to inner pins but according to the documentation that should be fine
<janrinze>
martin2250: mosi miso not swapped? (there were some people with that issue on boards.)
<martin2250>
@ZipCPU did you read the post before the edit? I've tried to do slave configuration and it seems to accept the bitstream, just not actually start up
<ZipCPU>
Yeah ... I read it ... it doesn't make sense though, so I'm not sure how to comment on that
<ZipCPU>
I'd be curious to know your answer to janrinze's question
<martin2250>
janrinze I've looked at all traces on the scope and to my eye, the communication seems fine
<ZipCPU>
Can you configure the FPGA at all?
<ZipCPU>
If you could configure the FPGA at all, you might then be able to determine if the flash works according to spec and pinouts
<janrinze>
martin2250: I has some trouble with flash not waking up but you see the correct data stream so that's not the cause.
<ZipCPU>
Correct data streaming into ... the correct pin?
<martin2250>
I didn't get it to work so far. As described in the edit only indication that the bitstream is accepted by the FPGA is the fact that the pins take the correct state
<martin2250>
yes, I've tried swapping pins and it resulted in a short (with CC enabled on the lab supply of course)
<janrinze>
the pins , meaning the bitstream is loaded and the device is setting up I/O pins to the correct states?
<martin2250>
also it reacts differently when the flash is unprogrammed (it tries 6 times to load an image and then gives up)
<janrinze>
have you been able to verify your design on a differen HX1K board?
<martin2250>
janrinze when I assign a pin to a state in verilog and use slave configuration, the correct pin gets pulled to the correct level. the pin just doesn't go out of high-impedance mode
<ZipCPU>
Then how do you know it gets pulled to the correct level? That doesn't make sense ... ?
<janrinze>
indeed.
<develonepi3>
mmicko I used this, "-DARCH=ice40 -DBUILD_GUI=OFF -DBUILD_PYTHON=OFF .". I get -- Configuring architecture : ice40 then -- Configuring incomplete, errors occurred! The same without "-DBUILD_PYTHON=OFF".
<martin2250>
according to the datasheets, the bitstream takes effect immediately as it is loaded. when the configuration is finished, the pins go to low-z mode. so it seems the bits end up at the right place in SRAM
<janrinze>
martin2250: have you tried something like a blinky to see if you can toggle an output at a certain frequency?
<martin2250>
>Then how do you know it gets pulled to the correct level? I've connected a LED +resistor to the pin. so if the pin gets pulled up by a weak pullup, I can see the forward voltage on the scope. when I configure the pin as output/low, the voltage at the pin goes to zero
<martin2250>
same with all pins I've tried
<martin2250>
this doesn't happen if the pin is not configured or configured as an input
<ZipCPU>
Okay ... might it be a CRC issue with the flash image?
<janrinze>
martin2250: do you have the I/O bank voltages correctly connected?
<ZipCPU>
If it gets almost all of it, but doesn't finish properly, missing a CRC sounds like a possibility
<martin2250>
janrinze yeah, apart from the 'assign pin' tests, that's what I've tried to get working
<ZipCPU>
janrinze seems to have the better questions though ...
<martin2250>
a crc issue could be possible, it would fit the behavior, as the CRC is at the end of the file... that said I've used both icestorm and the official tools and both show the same behavior
<martin2250>
IO and core voltages are fine. I've soldered two boards so I don't think it's a soldering mistake
<martin2250>
does the iCE40 accept bitstreams that don't have the crc 'command' before the wakeup? maybe that's worth a try
<whitequark>
it seems strange that the pin output buffer gets *weakly* enabled
<martin2250>
maybe it's just that the pullup resistor (which is active on an unconfigured device) gets disabled by the bitstream
<ZipCPU>
Wouldn't blinky flush that out?
<daveshah>
It sounds to me like pullups are being configured by the bitstream, but because configuration doesn't finish the global output enable isn't asserted
<martin2250>
ZipCPU yes, that's (probably) why I see the voltage on the pin change when I upload blinky
<daveshah>
so the output drivers don't come on and the design doesn't do anything (internal write enable would be deasserted and FF reset asserted too)
<martin2250>
nextpnr/icestorm and the official tools leave the pullup active for unused pins, so that's why it is different when I change the pin in the bitstream
<martin2250>
daveshah yes, that describes the behavior pretty much perfectly
<daveshah>
That means either a CRC failures as discussed or a missing wakeup command
<daveshah>
Oh, do you have some clock cycles after the bitstream
<martin2250>
the wakeup command is there (checked the bits on the scope). unless it somehow misses a bit and throws off alignment, it should work
<martin2250>
yeah, I've even modified iceprog to conform better to the diagrams from the app note
noname_Matt has quit [Ping timeout: 258 seconds]
<martin2250>
I'm using a FT2232 for sending the configuration. the edges look good
<martin2250>
also tried the official lattice programmer at work (at least for flashing the flash chip, not for slave configuration)
<daveshah>
You could try reducing the clock frequency
<daveshah>
CDONE has a pullup?
<martin2250>
not sure if it will make a difference... both iCE40 and FTDI are rated for much higher speeds. I'll give it a try, give me a minute
<martin2250>
no, CDONE is connected to ground, as I had to make room for a via
<janrinze>
:D
<martin2250>
all the documentation states that CDONE is output only, is this a problem?
<tnt>
cdone needs to be high
<martin2250>
oh damn it
<tnt>
yea, the fpga will never finish config if cdone isn't pulled high.
<tnt>
I got bit by that ... I had a pull up on it and driving a transistor to light up a led ... but it then wouldn't rise above the 0.6v of the base-collector voltage and that prevented the ice40 from finishing config.
<martin2250>
thanks, that should really be much more prominent in the documentation...
<martin2250>
I'll try to scrape the pad off, maybe I can yet save the six boards I ordered... hopefully the FPGA survives the hot air gun treatment
vidbina has quit [Ping timeout: 265 seconds]
<tnt>
yeah, the doc and hw checklist tells you you need a pull-up but never _why_ and that despite being an output, it need to rise high for the fpga to actually finish config.
martin225032 has joined #yosys
martin225032 has quit [Remote host closed the connection]
<martin2250>
does it have an internal pull up?
<tnt>
yes
<martin2250>
(just checked, it does)
<martin2250>
thanks
<tnt>
they do recommend an external one, so I'd add one for 'safety' on any future design, but at least this time you might be able to get the rework working by just dicsonnecting the ball.
<tnt>
maybe you can drill the via out from the other side ?
<martin2250>
if I had enough room to route out the CDONE ball, I wouldn't have had to connect it to GND :P
<martin2250>
the via connects all ground pins of that package, so that won't work
<martin2250>
I'll head off to my workbench, back in a few minutes with good news hopefully. thanks for the help everybody and happy holidays!
martin2250 has quit [Remote host closed the connection]
rohitksingh has quit [Remote host closed the connection]
pie__ has joined #yosys
pie_ has quit [Ping timeout: 260 seconds]
martin2250 has joined #yosys
<martin2250>
Hi again! Slave configuration works now, seems though as if the SPI_SO ball got disconnected, so I'll probably need a few more tries. reballing a BGA is harder than I thought, somehow the solder won't ball up on the chip
<martin2250>
thanks again for your help!
emeb has joined #yosys
martin2250 has quit [Remote host closed the connection]