You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have a small exchange memory mapped both in the Microblaze and host address spaces to hold configuration data. The size of this memory is limiting, e.g. some users might need much more memory than others. To enable user-configurable and potentially very large exchange memory, we could read configuration from PLRAM. Performance implications must be considered.
The text was updated successfully, but these errors were encountered:
The READ_LATENCY [...] attribute [...] sets the number of pipeline stages between memories cascaded in depth [...] A good rule of thumb is to pick a read latency of depth/2 + 2.
The depth is calculated from the total PLRAM memory depth divided by the primitive depth (URAM or BRAM). So for a 8K-deep memory in URAM, READ_LATENCY should be 3.
right now to go back and forth to the exchange meme implemented in BRAM
to enque 16 spares it takes 3430 clock cycles. 3 reads and 2 write x16 = 42 cc each access on average
Currently we have a small exchange memory mapped both in the Microblaze and host address spaces to hold configuration data. The size of this memory is limiting, e.g. some users might need much more memory than others. To enable user-configurable and potentially very large exchange memory, we could read configuration from PLRAM. Performance implications must be considered.
The text was updated successfully, but these errors were encountered: