| *** tpb <[email protected]> has joined #yosys | 00:00 | |
| cr1901 | New Jersey, USA | 00:14 |
|---|---|---|
| *** Max-P <Max-P!thelounge@thelounge/maintainer/Max-P> has left #yosys | 00:58 | |
| *** bl0x <[email protected]> has joined #yosys | 02:12 | |
| *** bl0x_ <[email protected]> has quit IRC (Ping timeout: 255 seconds) | 02:14 | |
| *** rowanG337 <rowanG337!~rowan.goe@2a02-a451-eb05-1-f4fa-3a28-8a77-f868.fixed6.kpn.net> has quit IRC (Quit: Leaving) | 02:21 | |
| *** citypw <citypw!~citypw@gateway/tor-sasl/citypw> has joined #yosys | 02:58 | |
| *** FabM <[email protected]> has joined #yosys | 08:03 | |
| *** bitterlollipop <[email protected]> has joined #yosys | 08:13 | |
| *** bitterlollipop <[email protected]> has quit IRC (Quit: system sleep - ZZZzzz...) | 08:36 | |
| *** sugarbeet <sugarbeet!~barbas@2a00:d880:3:1::df17:eb0c> has quit IRC (Ping timeout: 256 seconds) | 08:37 | |
| *** sugarbeet <sugarbeet!~barbas@2a00:d880:3:1::df17:eb0c> has joined #yosys | 08:38 | |
| *** rowanG337 <[email protected]> has joined #yosys | 08:59 | |
| *** singham <singham!~singham@2405:201:f:1e5a:f53d:213e:e018:d1cb> has joined #yosys | 10:53 | |
| singham | A small rookie question | 10:53 |
| singham | In SoCs, there are addresses like 0x004000 is for ram, 0x840000 if for uart, etc. | 10:54 |
| singham | What does this exactly mean? These are connected by a bus I guess | 10:55 |
| jn | singham: those are usually "physical" addresses on the memory bus connected to the CPU | 11:22 |
| jn | and when the CPU performs a load or store on address 0x4000, the bus interconnect will decode the address and forward the load/store to the RAM | 11:23 |
| bl0x | singham: for a very simplistic example, you can take a look at step 17 of Bruno Levy's learnFpga course. This is about memory mapping peripherals in a soc. Look for isRAM and isIO signals. | 11:39 |
| * singham is back | 11:50 | |
| singham | So the pins are connected to adresses? | 11:51 |
| singham | Physical addresses are pins right? | 11:51 |
| jn | no, physical addresses (as the term is used in the context of CPUs) are not at all the same as pins on a chip | 11:56 |
| jn | the word "physical" is in distinction to "virtual" addresses, that appear when you introduce an MMU | 11:57 |
| singham | I think this must be a need since in unix, everything is a file so, everything must have to be mapped to a hex address? | 11:58 |
| singham | So say /dev/ttyS0 will be mapped to 0x005400 and all signals would be sent to that address? | 11:59 |
| jn | unix's file abstraction isn't really relevant to this, memory-mapped I/O exists without the concept of files | 11:59 |
| jn | files (including device files like /dev/ttyS0) are a software concept, MMIO addresses like 0x840000 are a hardware concept | 12:00 |
| jn | the two things are connected throught the OS's UART driver, but not in a trivial way, there is some code involved | 12:01 |
| singham | hmmmm, very interesting | 12:19 |
| singham | So a memory address may refer to either a portion of physical RAM, or instead to memory and registers of the I/O device. | 12:20 |
| singham | That is a fantastic statement from wiki of mmio | 12:21 |
| singham | solves many of my doubts | 12:21 |
| singham | So basically all memory elements of all devices are mapped to hex codes | 12:21 |
| jn | not every bit of memory in every peripheral has to be mapped through MMIO, but other than that: yep | 12:26 |
| jn | and MMIO registers can act very different to RAM sometimes | 12:29 |
| singham | So the unmapped memory can be accessed with 0x00C000 + delta , right? | 12:29 |
| jn | such as only permitting reads, or only permitting writes, or not allowing to read back the value that was previously written | 12:30 |
| jn | singham: what do you mean by unmapped memory? | 12:30 |
| singham | You said not every bit of memory in every peripheral has to be mapped | 12:31 |
| singham | I was talking about the unmapped memory | 12:31 |
| jn | ah. no, there's no general rule on how to access hidden memory | 12:31 |
| jn | it depends on the particular peripheral | 12:31 |
| jn | for example, a UART might contain a FIFO with some memory to store incoming/outgoing characters, but you can't access the FIFO elements arbitrarily, you can only access the next element according to the First-In/First-Out discipline | 12:37 |
| singham | So just the last memory element of FIFO stack is mapped? | 12:41 |
| singham | In that case? | 12:41 |
| *** bitterlollipop <[email protected]> has joined #yosys | 12:42 | |
| jn | kind of, yes | 12:44 |
| jn | (the details of how a FIFO is often implemented, as a ring buffer, makes the "last element" a moving target though) | 12:45 |
| *** bitterlollipop <[email protected]> has quit IRC (Quit: system sleep - ZZZzzz...) | 13:05 | |
| *** nak <nak!~nak@yosys/nak> has quit IRC (Ping timeout: 255 seconds) | 13:06 | |
| *** nak <nak!~nak@yosys/nak> has joined #yosys | 13:08 | |
| * singham thanks jn and bl0x for this great explanation. | 13:44 | |
| jn | glad to help :) | 13:44 |
| *** sugarbeet <sugarbeet!~barbas@2a00:d880:3:1::df17:eb0c> has quit IRC (Ping timeout: 248 seconds) | 13:53 | |
| bl0x | Yes, you're welcome. I'm also just at the beginning of my journey. Or so it seems with all the wondrous new things being made! | 13:53 |
| *** rowanG337 <[email protected]> has quit IRC (Quit: Leaving) | 13:59 | |
| *** sugarbeet <sugarbeet!~barbas@2a00:d880:3:1::df17:eb0c> has joined #yosys | 14:02 | |
| *** singham <singham!~singham@2405:201:f:1e5a:f53d:213e:e018:d1cb> has left #yosys | 14:04 | |
| *** citypw <citypw!~citypw@gateway/tor-sasl/citypw> has quit IRC (Ping timeout: 255 seconds) | 14:53 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 16:28 | |
| *** nelgau <[email protected]> has joined #yosys | 16:57 | |
| *** so-offish <[email protected]> has joined #yosys | 17:33 | |
| josuah | hello! I am composing a .pcf for an upcoming dev board (FYI it has an RP2040 and an iCE40UP5k https://pico-ice.tinyvision.ai/ ). | 17:54 |
| tpb | Title: pico-ice - pico-icepico-ice | An devboard featuring both an RP2040 and an iCE40SearchMenuExpandDocument(external link) (at pico-ice.tinyvision.ai) | 17:54 |
| josuah | It uses PMODs for everything, I thought it could be nice to give pin names the PMOD names like PMOD1_SDA or PMOD0_MOSI or PMOD0_COPI etc. | 17:55 |
| josuah | But doing so would clash in the .pcf, because of this: https://github.com/YosysHQ/nextpnr/blob/master/common/place/placer1.cc#L171 (also like that at other places) | 17:56 |
| josuah | any idea if there are flags to allow "aliases"? Or should it be done in verilog + vhdl + amaranth + ... | 17:56 |
| josuah | An alternative would be having very long names including all the alternative signal names :P or simply let the user pick which section he is interested in to build its own PCF file | 17:57 |
| *** peeps <peeps!~peepsalot@openscad/peepsalot> has joined #yosys | 17:59 | |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 268 seconds) | 18:02 | |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #yosys | 18:04 | |
| *** peeps <peeps!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 246 seconds) | 18:06 | |
| josuah | hmm, I do not see anywhere in the PCF parser source some method to define aliases | 18:15 |
| josuah | I'll just offer users the data and let them copy-paste what they want in: low-tech high-flexibility! | 18:16 |
| *** so-offishul <so-offishul!~so-offish@2610:148:610:2b10::7> has joined #yosys | 18:31 | |
| *** so-offish <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 18:31 | |
| *** so-offishul <so-offishul!~so-offish@2610:148:610:2b10::7> has quit IRC (Quit: Leaving) | 18:42 | |
| *** nelgau <[email protected]> has quit IRC (Remote host closed the connection) | 18:57 | |
| *** nelgau <[email protected]> has joined #yosys | 18:57 | |
| *** nelgau <[email protected]> has quit IRC (Remote host closed the connection) | 18:58 | |
| *** nelgau <[email protected]> has joined #yosys | 18:58 | |
| gatecat | josuah: multiple references to the same pin in the pcf (with -nowarn so the unused ones don't cause problems) should be fine, so long as only one of them is actually used in the hdl design | 19:10 |
| gatecat | did you actually test that and hit that erorr or were you just speculating? | 19:10 |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has quit IRC (Quit: Leaving) | 19:25 | |
| *** so-offish <so-offish!~so-offish@2610:148:610:2b10::7> has joined #yosys | 19:25 | |
| *** bjorkintosh <bjorkintosh!~bjork@2600:1700:5400:c80:f5c6:b95a:a160:aa09> has joined #yosys | 19:29 | |
| *** bitterlollipop <[email protected]> has joined #yosys | 19:35 | |
| *** nelgau <[email protected]> has quit IRC (Remote host closed the connection) | 19:36 | |
| *** nelgau <[email protected]> has joined #yosys | 19:36 | |
| *** nelgau <[email protected]> has quit IRC (Remote host closed the connection) | 19:36 | |
| *** nelgau <[email protected]> has joined #yosys | 19:37 | |
| *** bitterlollipop <[email protected]> has quit IRC (Quit: system sleep - ZZZzzz...) | 19:55 | |
| *** bitterlollipop <[email protected]> has joined #yosys | 20:48 | |
| *** bitterlollipop <[email protected]> has quit IRC (Client Quit) | 20:50 | |
| *** so-offish <so-offish!~so-offish@2610:148:610:2b10::7> has quit IRC (Quit: Leaving) | 21:21 | |
| josuah | gatecat: I encountered the error, but maybe I explained it wrong | 22:10 |
| josuah | showing the actual situation might be best :) https://pico-ice.tinyvision.ai/pinout.html#pmod0-ice40-only | 22:11 |
| tpb | Title: Pinout - pico-icePinout | pico-iceSearchMenuExpandDocument(external link) (at pico-ice.tinyvision.ai) | 22:11 |
| josuah | I will try to make a reproducer... | 22:11 |
| josuah | thank you for your answer! | 22:12 |
| josuah | oh wait that is right! | 22:12 |
| josuah | I was using multiple of them at once on the same top.v | 22:13 |
| josuah | that is great news! \o/ | 22:13 |
| josuah | I deduced a limitation from a bug on my side, sorry for the noise then! | 22:16 |
| *** nonchip <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 23:09 | |
| *** nonchip <[email protected]> has joined #yosys | 23:09 | |
| *** so-offish <so-offish!~so-offish@2610:148:610:2b10::7> has joined #yosys | 23:16 | |
| so-offish | Hi everyone! Is there a way to pass -sv to synth_ecp5? | 23:16 |
| so-offish | Nevermind I found a different way to do it | 23:26 |
| so-offish | Drop into yosys, read the file with the correct command, then do synth_ecp5 and use -run and coarse:json | 23:26 |
| josuah | at the step read_verilog -sv I guess, you were faster than me | 23:27 |
| josuah | oh wait ,that's not exactly what I thought | 23:27 |
| josuah | ah yes "correct command" | 23:27 |
| josuah | there is definitely more flexibility to yosys than I thought, quite the toolbox here | 23:30 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!