<DiffieHellman>
Hi, I have an iCEstick I'm trying to use as a SPI flasher (through the FTDI 2232H of course). I've determined that via flashrom port=A,csgpiol=0 seems to be connected to CS or physical pin 71. Does anywhere have any ideas as which physical pins CSGPIO1-3 are connected to?
<ZipCPU>
Not me, sorry. Have you checked the schematic?
<DiffieHellman>
I'm looking on page 18 at the moment
<ZipCPU>
And page 21 shows the connections between the Icestick FPGA and the SPI flash
<ZipCPU>
Looks like all the pin connections are listed there.
<DiffieHellman>
The wiring diagram shows that ADBUS4 is disconnected, although on the actual board, it looks like ADBUS4 is connected to the boards SPI chip?
<DiffieHellman>
Oh, read ACDUS as ADBUS
<ZipCPU>
Are we talking connections from FTDI to iCE FPGA? Or iCE FPGA to SPI flash?
<DiffieHellman>
FTDI to on board SPI and FTDI to off board SPI, attached via the FGPA
<ZipCPU>
Are you planning on doing FTDI or FPGA programming?
<DiffieHellman>
I'm planning on doing the insane task of using a FGPA to simulate wires from a FTDI chip to a SPI chip.
<ZipCPU>
(I still haven't seen any "CSGPIO1-3" pins on the schematic ...)
<ZipCPU>
Why "simulate"?
<ZipCPU>
Why not just drive the SPI chip?
<DiffieHellman>
Since I don't really want to solder wires directly from the FTDI, as the FGPA is the only thing that can drive the external pins.
<ZipCPU>
It's ... not really all that hard to do ...
<DiffieHellman>
Okay, looks like ADBUS6 is connected to iCE_CDONE, so lets try that.
<ZipCPU>
Well, sure, but why "simulate" the FTDI? Why not just drive the lines yourself, and do it your own way?
<DiffieHellman>
assign ext_sck = ftdi_sck; assign ext_mosi = ftdi_mosi; assign ftdi_miso = ext_miso; assign ext_cs = ftdi_cs; is the 4 lines I use to simulate wiring.
<DiffieHellman>
>ERROR: package does not have a pin named '65' (on line 7) Oh come on.
<ZipCPU>
You mean, the iCE_CDONE pin isn't a user pin? It rarely is.
<pepijndevos[m]>
dang. so I'm trying to update the vendor primitives and it seems like they have a tsim file with timing specifications but they are all zero
<pepijndevos[m]>
And I vaguely remember sitting down with lofty and manually adding the timing info from their database, so I guess I'll just have to copy those over
dormito has quit [Quit: WeeChat 3.6]
<lofty>
pepijndevos[m]: you did, yes
<lofty>
[10:44:33] pepijndevos[m]: Also does Yosys currently use any timing specifications for anything? <--- ABC9 is the main user
<pepijndevos[m]>
a right
<pepijndevos[m]>
well here you go it probably doesn't even parse in yosys and github can't even show the diff but it should contain alllll the Gowin primitives
<pepijndevos[m]>
It even has behavioral models for the PLL
<pepijndevos[m]>
See above statement about it probably not even parsing
<pepijndevos[m]>
It uses cool things like primitive and realtime
DiffieHellman has quit [Ping timeout: 255 seconds]
DiffieHellman has joined #yosys
snip is now known as sneep
sneep has joined #yosys
sneep has quit [Changing host]
<Sarayan>
Is configuring and communicating with ddr ram black magic, or it's just complex but well documented?
peeps has joined #yosys
peeps[zen] has quit [Ping timeout: 255 seconds]
peeps[zen] has joined #yosys
peeps has quit [Ping timeout: 268 seconds]
peepsalot has joined #yosys
peeps[zen] has quit [Read error: Connection reset by peer]
peeps[zen] has joined #yosys
peepsalot has quit [Ping timeout: 268 seconds]
peeps has joined #yosys
peeps[zen] has quit [Ping timeout: 268 seconds]
peeps[zen] has joined #yosys
peeps has quit [Ping timeout: 268 seconds]
peeps has joined #yosys
peeps[zen] has quit [Ping timeout: 252 seconds]
peepsalot has joined #yosys
peeps has quit [Ping timeout: 255 seconds]
peeps[zen] has joined #yosys
DiffieHellman has quit [Remote host closed the connection]
DiffieHellman has joined #yosys
peepsalot has quit [Ping timeout: 268 seconds]
<ZipCPU>
Sarayan, marex: Yes, that's my blog
<ZipCPU>
Sarayan: Black magic.
<knielsen>
Is it really not documented? (But then, it's kinda black magic anyway even if documented ;-)
<ZipCPU>
Sure, DDR SDRAMs are very well documented
<knielsen>
I know the DDR controllers in eg. PC chipsets are supposed to be without available documentation, but I remember reading some detailed docs about the (analog really) interface on the DDR bus. Might have been proprietary docs though I suppose...
<ZipCPU>
The issues with them are well known, and solutions have been demonstrated.
<ZipCPU>
But the hardware doesn't match them well ...
<ZipCPU>
FPGA hardware, that is, doesn't map nicely to DDRx decoding
<knielsen>
no, the DDR (SDRAM) interface is kindof more analog than digital, you need some controller to control it from digital logic, true. So yes, practically speaking...
<knielsen>
but still facinating to see how they work. For example, you measure the delay on each data line individually towards each DIMM, and program delay lines in the DDR controller to match
<bjonnh[m]>
that's also why each trace has wavy patterns on the PCBs to try to limit those delays
<ZipCPU>
The challenge, IMHO, is and has always been the return data strobe (DQS) signal
<ZipCPU>
Deal with that and everything else falls into place.
<Sarayan>
ok
<Sarayan>
so analyzing what Intel does in the cyclone v and documenting it could be useful?
<ZipCPU>
to ... DDR handling?
<bjonnh[m]>
the cyclone has a DDR controller inside doesn't it?
<twix>
having the ddr controller in hardware makes it much easier and more performant than "bitbanging" it in the FPGA, but it is still possible
<twix>
<knielsen> no, the DDR (SDRAM) interface is kindof more analog than digital <-- what do you mean? that the signal integrity and the timing is critical here? Thats true. You need to match the timing of your bits somehow. In Hardware Memorycontrollers usually have some, but limited capabilities to synchronize the timings of the signals, so you need to do some length matching on the PCB. But in theory you could do that all with buffers, queues or what ever completly