Skip to content

Conversation

@maass-hamburg
Copy link
Contributor

add read_capable option, so we can
better detect when no read is done.

Signed-off-by: Fin Maaß [email protected]

add read_capable option, so we can
better detect when no read is done.

Signed-off-by: Fin Maaß <[email protected]>
@sbourdeauducq
Copy link
Member

What's the context for this?

@maass-hamburg
Copy link
Contributor Author

What's the context for this?

@sbourdeauducq
first of all it reduces unused code in the generated verilog file

the titanium and topaz from efinix internally have EFX_RAM10 (simple dual port, one port for reading and one port for writing, can be on different clocks) and EFX_DPRAM10 (true dual port, both can read and write at the same time).
Only the EFX_RAM10 supports byte enable/we_granularity, the EFX_DPRAM10 does not and the sythesis tool will automatically use the right type, but will complain and fail if a memory will use a EFX_DPRAM10, that uses byte enable/we_granularity. Because of that in litex FullMemoryWE is used on all memory, that have we_granularity, but it is only necessary for memory, that will use EFX_DPRAM10 and not EFX_RAM10, so i want to detect that and only do the spiting of the memory, where we can't use the EFX_RAM10 with byte enable/we_granularity. For that I need to be able to check if the read part of a port is used. So in the end only one block with 512 x 16 is used, when the we_granularity is 8, instead of two 1024 x 8, when the needed Memory Depth is 512 or less.

@maass-hamburg
Copy link
Contributor Author

under this condition

((global_granularity % 8 == 0) or (global_granularity % 10 == 0)) and len([port for port in orig.ports if port.dat_r is not None]) <= 1 and len([port for port in orig.ports if port.dat_w is not None]) <= 1

in FullMemoryWE, for efinix Titanium/Topaz fpgas the memory don't need to be split.

  • granularity must be dividable by 8 or 10
  • only one or no read port
  • only one or no write port

maass-hamburg added a commit to VOGL-electronic/gw__litex that referenced this pull request Jul 22, 2025
prepare for dat_r of a memory port being None.
could come with m-labs/migen#313

Signed-off-by: Fin Maaß <[email protected]>
maass-hamburg added a commit to VOGL-electronic/gw__litex that referenced this pull request Jul 22, 2025
prepare for dat_r of a memory port being None.
could come with m-labs/migen#313

Signed-off-by: Fin Maaß <[email protected]>
maass-hamburg added a commit to VOGL-electronic/gw__litex that referenced this pull request Jul 22, 2025
prepare for dat_r of a memory port being None.
could come with m-labs/migen#313

Signed-off-by: Fin Maaß <[email protected]>
maass-hamburg added a commit to VOGL-electronic/gw__litex that referenced this pull request Jul 28, 2025
prepare for dat_r of a memory port being None.
could come with m-labs/migen#313

Signed-off-by: Fin Maaß <[email protected]>
@maass-hamburg
Copy link
Contributor Author

@sbourdeauducq ping

maass-hamburg added a commit to VOGL-electronic/gw__litex that referenced this pull request Aug 20, 2025
prepare for dat_r of a memory port being None.
could come with m-labs/migen#313

Signed-off-by: Fin Maaß <[email protected]>
maass-hamburg added a commit to VOGL-electronic/gw__litex that referenced this pull request Sep 1, 2025
prepare for dat_r of a memory port being None.
could come with m-labs/migen#313

Signed-off-by: Fin Maaß <[email protected]>
maass-hamburg added a commit to maass-hamburg/litex that referenced this pull request Nov 11, 2025
for Titanium/Tropaz FullMemoryWE is not
always needed, as EFX_RAM10 supports them,
while EFX_DPRAM10 still don't supports them.

Since m-labs/migen#313
isn't merged we can not really detect if a
memory will be EFX_RAM10 or EFX_DPRAM10
therefore add a option for the user to
en- and disable it completly.
Reducing the use of FullMemoryWE can
decrease blockram usage, as they are not split.

Signed-off-by: Fin Maaß <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants