bitterlollipop has quit [Quit: system sleep - ZZZzzz...]
sugarbeet has quit [Ping timeout: 256 seconds]
sugarbeet has joined #yosys
rowanG337 has joined #yosys
singham has joined #yosys
<singham>
A small rookie question
<singham>
In SoCs, there are addresses like 0x004000 is for ram, 0x840000 if for uart, etc.
<singham>
What does this exactly mean? These are connected by a bus I guess
<jn>
singham: those are usually "physical" addresses on the memory bus connected to the CPU
<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
<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.
* singham
is back
<singham>
So the pins are connected to adresses?
<singham>
Physical addresses are pins right?
<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
<jn>
the word "physical" is in distinction to "virtual" addresses, that appear when you introduce an MMU
<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?
<singham>
So say /dev/ttyS0 will be mapped to 0x005400 and all signals would be sent to that address?
<jn>
unix's file abstraction isn't really relevant to this, memory-mapped I/O exists without the concept of files
<jn>
files (including device files like /dev/ttyS0) are a software concept, MMIO addresses like 0x840000 are a hardware concept
<jn>
the two things are connected throught the OS's UART driver, but not in a trivial way, there is some code involved
<singham>
hmmmm, very interesting
<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.
<singham>
That is a fantastic statement from wiki of mmio
<singham>
solves many of my doubts
<singham>
So basically all memory elements of all devices are mapped to hex codes
<jn>
not every bit of memory in every peripheral has to be mapped through MMIO, but other than that: yep
<jn>
and MMIO registers can act very different to RAM sometimes
<singham>
So the unmapped memory can be accessed with 0x00C000 + delta , right?
<jn>
such as only permitting reads, or only permitting writes, or not allowing to read back the value that was previously written
<jn>
singham: what do you mean by unmapped memory?
<singham>
You said not every bit of memory in every peripheral has to be mapped
<singham>
I was talking about the unmapped memory
<jn>
ah. no, there's no general rule on how to access hidden memory
<jn>
it depends on the particular peripheral
<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
<singham>
So just the last memory element of FIFO stack is mapped?
<singham>
In that case?
bitterlollipop has joined #yosys
<jn>
kind of, yes
<jn>
(the details of how a FIFO is often implemented, as a ring buffer, makes the "last element" a moving target though)
bitterlollipop has quit [Quit: system sleep - ZZZzzz...]
nak has quit [Ping timeout: 255 seconds]
nak has joined #yosys
* singham
thanks jn and bl0x for this great explanation.
<jn>
glad to help :)
sugarbeet has quit [Ping timeout: 248 seconds]
<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!
rowanG337 has quit [Quit: Leaving]
sugarbeet has joined #yosys
singham has left #yosys [#yosys]
citypw has quit [Ping timeout: 255 seconds]
FabM has quit [Quit: Leaving]
nelgau has joined #yosys
so-offish has joined #yosys
<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/ ).
<tpb>
Title: pico-ice - pico-icepico-ice | An devboard featuring both an RP2040 and an iCE40SearchMenuExpandDocument(external link) (at pico-ice.tinyvision.ai)
<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.
<josuah>
any idea if there are flags to allow "aliases"? Or should it be done in verilog + vhdl + amaranth + ...
<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
peeps has joined #yosys
peeps[zen] has quit [Ping timeout: 268 seconds]
peeps[zen] has joined #yosys
peeps has quit [Ping timeout: 246 seconds]
<josuah>
hmm, I do not see anywhere in the PCF parser source some method to define aliases
<josuah>
I'll just offer users the data and let them copy-paste what they want in: low-tech high-flexibility!
so-offishul has joined #yosys
so-offish has quit [Ping timeout: 252 seconds]
so-offishul has quit [Quit: Leaving]
nelgau has quit [Remote host closed the connection]
nelgau has joined #yosys
nelgau has quit [Remote host closed the connection]
nelgau has joined #yosys
<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
<gatecat>
did you actually test that and hit that erorr or were you just speculating?
bjorkintosh has quit [Quit: Leaving]
so-offish has joined #yosys
bjorkintosh has joined #yosys
bjorkintosh has quit [Changing host]
bjorkintosh has joined #yosys
bitterlollipop has joined #yosys
nelgau has quit [Remote host closed the connection]
nelgau has joined #yosys
nelgau has quit [Remote host closed the connection]
nelgau has joined #yosys
bitterlollipop has quit [Quit: system sleep - ZZZzzz...]
bitterlollipop has joined #yosys
bitterlollipop has quit [Client Quit]
so-offish has quit [Quit: Leaving]
<josuah>
gatecat: I encountered the error, but maybe I explained it wrong