Mity CPU Platforms » MitySOM-A5

Hi Maxim,

Thanks for sending the project along, that made this much easier to answer.

On fpgaregister.h. Yes, it works for the full HPS to FPGA bridge. There is nothing in that header that is specific to the Lightweight bridge, it just memory maps a physical address through /dev/mem. As long as you point it at the right physical address it does not care which bridge is behind it.

One caveat to be aware of: the constructor takes a uint32_t base address, so it can only reach the first 4 GB of physical address space. That is not a problem for what you are doing here (more on that below), but if you ever need the upper FPGA windows you would have to widen that to a 64-bit type.

On the address. This is where I think the problem is. On Agilex 5 the two bridges land in different places in the HPS address map:

• Lightweight HPS to FPGA: base 0x2000_0000
• HPS to FPGA: first window at base 0x4000_0000 (1 GB)

(There are two more HPS to FPGA windows higher up, at 0x4_4000_0000 and 0x44_0000_0000, but you do not need those for your test case.)

In both cases the physical address is the bridge base plus your Platform Designer offset. So an IP at Qsys address 0x0 on the Lightweight bridge is at 0x2000_0000, and an IP at Qsys address 0x0 on the HPS to FPGA bridge is at 0x4000_0000.

Looking at your design, your hps2fpga_mm_bridge_0 is at Qsys base 0x0 with a 22 bit byte address, so it occupies 0x4000_0000 to 0x403F_FFFF. Your two registers in a5e_top.sv decode at byte offsets 0x1000 and 0x2000, which puts them at:

• Write register (drives debug_led): 0x4000_1000
• Read register (debug_pb plus your signature): 0x4000_2000

If you read 0x4000_2000 you should get back roughly 0xCAFECB00 with the low two bits reflecting your pushbuttons, since s_h2f_mm_in[31:2] is hardcoded to 30'h32BF_B2C0. That is a nice value to confirm against.

You do not need to rebuild your application to try this, memtool is already on the target and will read the address directly. For example:

memtool 0x40002000 1

That reads one 32 bit word at your read register, and you should see 0xCAFECB0x come back.

My guess is you were poking an address that never reached the bridge at all, which would explain both the missing SignalTap triggers and the unexpected readouts.

The reference for all of this is the Agilex 5 Hard Processor System Technical Reference Manual, see the Address Map chapter:

Agilex 5 Hard Processor System Technical Reference Manual

One other thing I noticed while looking through a5e_top.sv. You tie waitrequest deasserted, so every read gets accepted, but you only assert readdatavalid when the address is 0x2000. Avalon-MM expects exactly one readdatavalid for every read it accepts, so a read to any other address in your 4 MB window will be accepted and then never complete, which will hang the HPS access. I would assert readdatavalid on every read and just return 0 for addresses you do not decode. Your write path also ignores byteenable, which is fine for 32 bit accesses at those two offsets but worth knowing if you widen this later.

If you want the full details on the handshake, it is all in the Avalon Interface Specifications. Section 3.2 defines what each signal means, and section 3.5.4.1 covers the pipelined read handshake specifically:

• 3.2. Avalon Memory Mapped Interface Signal Roles
• 3.5.4.1. Pipelined Read Transfer with Variable Latency

Let me know if you have any questions!

- Mike

Hello Mike,

Thanks a lot for your reply.
We used this offset 0x4000_0000 (1 GB) and we got the expected reply from/to our registers!!!
Thanks for your refferal to memtool. We tested memtool, but need our application as well.

Thanks,
Max