*** tpb <[email protected]> has joined #yosys | 00:00 | |
*** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #yosys | 00:56 | |
*** peeps <peeps!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 255 seconds) | 00:59 | |
*** citypw <citypw!~citypw@gateway/tor-sasl/citypw> has joined #yosys | 02:06 | |
*** bl0x_ <[email protected]> has joined #yosys | 02:06 | |
*** bl0x <[email protected]> has quit IRC (Ping timeout: 248 seconds) | 02:07 | |
*** citypw <citypw!~citypw@gateway/tor-sasl/citypw> has quit IRC (Ping timeout: 255 seconds) | 02:56 | |
*** DiffieHellman <DiffieHellman!~Username@user/curve25519chacha> has joined #yosys | 03:09 | |
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? | 03:13 |
---|---|---|
ZipCPU | Not me, sorry. Have you checked the schematic? | 03:24 |
ZipCPU | This thing, right? https://appcodelabs.com/wp-content/uploads/2019/02/lattice-icestick-fpga-evaluation-board.png | 03:25 |
DiffieHellman | Yes. | 03:27 |
ZipCPU | The pins should be listed in a master constraint file that came with the board's documentation | 03:27 |
ZipCPU | You should be able to then cross reference the constraint file with the schematic to find what you need | 03:27 |
ZipCPU | Lattice tends to put their pin lists in their user guides, though, don't they? Not like Xilinx that leaves them as separate files ... | 03:30 |
ZipCPU | So ... I'm looking at the user's guide from this site: https://www.latticesemi.com/icestick | 03:32 |
DiffieHellman | I'm looking on page 18 at the moment | 03:32 |
ZipCPU | And page 21 shows the connections between the Icestick FPGA and the SPI flash | 03:32 |
ZipCPU | Looks like all the pin connections are listed there. | 03:32 |
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? | 03:33 |
DiffieHellman | Oh, read ACDUS as ADBUS | 03:34 |
ZipCPU | Are we talking connections from FTDI to iCE FPGA? Or iCE FPGA to SPI flash? | 03:34 |
DiffieHellman | FTDI to on board SPI and FTDI to off board SPI, attached via the FGPA | 03:35 |
ZipCPU | Are you planning on doing FTDI or FPGA programming? | 03:36 |
DiffieHellman | I'm planning on doing the insane task of using a FGPA to simulate wires from a FTDI chip to a SPI chip. | 03:37 |
ZipCPU | (I still haven't seen any "CSGPIO1-3" pins on the schematic ...) | 03:37 |
ZipCPU | Why "simulate"? | 03:37 |
ZipCPU | Why not just drive the SPI chip? | 03:37 |
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. | 03:38 |
ZipCPU | It's ... not really all that hard to do ... | 03:38 |
DiffieHellman | Okay, looks like ADBUS6 is connected to iCE_CDONE, so lets try that. | 03:39 |
ZipCPU | Well, sure, but why "simulate" the FTDI? Why not just drive the lines yourself, and do it your own way? | 03:39 |
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. | 03:40 |
DiffieHellman | >ERROR: package does not have a pin named '65' (on line 7) Oh come on. | 03:40 |
ZipCPU | You mean, the iCE_CDONE pin isn't a user pin? It rarely is. | 03:41 |
ZipCPU | Well, good luck. | 03:41 |
DiffieHellman | Thanks for your help. | 03:49 |
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Remote host closed the connection) | 04:57 | |
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #yosys | 04:57 | |
marex | ZipCPU: is https://zipcpu.com/blog/2018/07/06/afifo.html this your doing ? If so, thank you ! | 08:09 |
tpb | Title: Crossing clock domains with an Asynchronous FIFO (at zipcpu.com) | 08:09 |
ikskuh | heya o/ | 10:17 |
Sarayan | ohhh, love that blog page | 10:26 |
Sarayan | it's *exactly* the problem I'm having, coupling a framebuffer/tilemap at hdmi clocks with a system with its own clock | 10:27 |
*** DiffieHellman <DiffieHellman!~Username@user/curve25519chacha> has quit IRC (Ping timeout: 255 seconds) | 10:30 | |
*** DiffieHellman <DiffieHellman!~Username@user/curve25519chacha> has joined #yosys | 10:33 | |
pepijndevos[m] | What's the diff between... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/3fc9d2c335a34aa064336e8287fe8e5a1f4ae6b8>) | 10:39 |
pepijndevos[m] | Trying to update the Gowin primitives... | 10:39 |
pepijndevos[m] | Also does Yosys currently use any timing specifications for anything? | 10:44 |
pepijndevos[m] | oh seems like we have STA now! https://github.com/YosysHQ/yosys/pull/2490 | 10:49 |
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 | 10:50 |
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 | 10:51 |
*** dormito <dormito!~dullfire@user/dormito> has quit IRC (Quit: WeeChat 3.6) | 11:10 | |
lofty | pepijndevos[m]: you did, yes | 11:35 |
lofty | [10:44:33] pepijndevos[m]: Also does Yosys currently use any timing specifications for anything? <--- ABC9 is the main user | 11:36 |
pepijndevos[m] | a right | 11:36 |
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 | 11:38 |
pepijndevos[m] | https://github.com/YosysHQ/yosys/pull/3696 | 11:38 |
pepijndevos[m] | It even has behavioral models for the PLL | 11:39 |
pepijndevos[m] | See above statement about it probably not even parsing | 11:39 |
pepijndevos[m] | It uses cool things like primitive and realtime | 11:41 |
*** DiffieHellman <DiffieHellman!~Username@user/curve25519chacha> has quit IRC (Ping timeout: 255 seconds) | 11:46 | |
*** DiffieHellman <DiffieHellman!~Username@user/curve25519chacha> has joined #yosys | 11:49 | |
*** snip is now known as sneep | 12:06 | |
Sarayan | Is configuring and communicating with ddr ram black magic, or it's just complex but well documented? | 12:22 |
*** peeps <peeps!~peepsalot@openscad/peepsalot> has joined #yosys | 12:46 | |
*** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 255 seconds) | 12:49 | |
*** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #yosys | 13:13 | |
*** peeps <peeps!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 268 seconds) | 13:16 | |
*** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #yosys | 13:17 | |
*** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has quit IRC (Read error: Connection reset by peer) | 13:17 | |
*** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #yosys | 13:20 | |
*** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 268 seconds) | 13:23 | |
*** peeps <peeps!~peepsalot@openscad/peepsalot> has joined #yosys | 13:32 | |
*** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 268 seconds) | 13:35 | |
*** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #yosys | 13:45 | |
*** peeps <peeps!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 268 seconds) | 13:48 | |
*** peeps <peeps!~peepsalot@openscad/peepsalot> has joined #yosys | 13:55 | |
*** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 252 seconds) | 13:58 | |
*** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #yosys | 14:06 | |
*** peeps <peeps!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 255 seconds) | 14:08 | |
*** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #yosys | 14:57 | |
*** DiffieHellman <DiffieHellman!~Username@user/curve25519chacha> has quit IRC (Remote host closed the connection) | 14:58 | |
*** DiffieHellman <DiffieHellman!~Username@user/curve25519chacha> has joined #yosys | 14:58 | |
*** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 268 seconds) | 15:00 | |
ZipCPU | Sarayan, marex: Yes, that's my blog | 15:37 |
ZipCPU | Sarayan: Black magic. | 15:38 |
knielsen | Is it really not documented? (But then, it's kinda black magic anyway even if documented ;-) | 15:43 |
ZipCPU | Sure, DDR SDRAMs are very well documented | 15:44 |
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... | 15:44 |
ZipCPU | The issues with them are well known, and solutions have been demonstrated. | 15:44 |
ZipCPU | But the hardware doesn't match them well ... | 15:45 |
ZipCPU | FPGA hardware, that is, doesn't map nicely to DDRx decoding | 15:45 |
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... | 15:46 |
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 | 15:47 |
bjonnh[m] | that's also why each trace has wavy patterns on the PCBs to try to limit those delays | 15:51 |
ZipCPU | The challenge, IMHO, is and has always been the return data strobe (DQS) signal | 15:59 |
ZipCPU | Deal with that and everything else falls into place. | 15:59 |
Sarayan | ok | 16:06 |
Sarayan | so analyzing what Intel does in the cyclone v and documenting it could be useful? | 16:06 |
ZipCPU | to ... DDR handling? | 16:10 |
bjonnh[m] | the cyclone has a DDR controller inside doesn't it? | 16:17 |
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 | 17:35 |
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 | 17:39 |
twix | inside your chip or FPGA ... | 17:39 |
*** peeps <peeps!~peepsalot@openscad/peepsalot> has joined #yosys | 18:01 | |
*** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 255 seconds) | 18:04 | |
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 255 seconds) | 18:09 | |
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #yosys | 18:10 | |
*** sneep <sneep!~stron@user/sneep> has quit IRC (Ping timeout: 252 seconds) | 20:37 | |
*** sneep <[email protected]> has joined #yosys | 20:38 | |
*** somlo_ is now known as somlo | 21:21 | |
*** nonchip <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 23:09 | |
*** nonchip <[email protected]> has joined #yosys | 23:09 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!