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
This started as a comment to Tranche 3 but requires more investigation to help clarify both the code/mechanisms and the documentation around it.
So to track I open this.
Objectives
Explain the eject process, so 100% manual configuration can be achieved by the designed. So Mem is used but the designer wants to take complete control over attributes and output HDL to ensure their flow has the correct memory created.
Check my understanding of their being a default device NONE and the impact.
Ensure all code / Phases that make use of knowing the device or device-family, upon seeing that is it NONE, emit a log message pointing into documentation and details of automatic support. This provides awareness to the user 'this situation looks like one we have help with available here read the docs'
Check my understanding of configuring to a Device() and the impact on attributes.
Confirm if the auto insertion is disabled if one or more manually provided attributes is present. Consider log message:
Log message: INFO At MyCode.scala:123 the Mem[name] instance for device-family Xilinx device xgt123-1202g did not have automatic addAttribute("special-memory-mode, "foobar") applied due to one or more existing attributes present. See documentation at https://spinalhdl.github.io/path/to/page
Consider an attribute type that means, this instance do not perform automatic insertion of attributes that.addAttribute(InhibitAutomaticAttributes)
Try to document some known forms of memory with well-known vendors. This sounds like a new page, with section per vendor and memory types.
This leads into blackboxing modes and any simulation/elaboration differences.
The text was updated successfully, but these errors were encountered:
Check my understanding of their being a default device NONE and the impact.
The device thing isn't a very developped feature.
Mostly, when None is selected, SpinalHDL target maximal compatibility, including for instance enforcing mem.readAsync port to have the ram_style attribute set to distributed in verilog / VHDL to ensure proper read/write conflict handeling.
I use the term eject to mean disable any automatic insertion of attributes.
That maybe globally or it maybe in an instance basism hence the suggestion for that.addAttribute(InhibitAutomaticAttributes).
This would work with any setDevice() setting and override it.
auto insertion
What is it ?
The code in the Phase emitters that insert attributes. The insertion of an attribute based on setDevice() and other settings is auto insertion (of HDL attributes).
Maybe trying to create a browsable (online) catalogue of sample input SpinalHDL snippets and output HDL covering many scenarios, would help observe/document what occurs.
The work on making CI more incremental helps towards this goal, so lots of Ci can be run and results collated from re-creatable parallel builds. Much improvement exists here already (for me) I expect to schedule commits in pull requests after the current SpinalDoc-RTD push.
This started as a comment to Tranche 3 but requires more investigation to help clarify both the code/mechanisms and the documentation around it.
So to track I open this.
Objectives
Mem
is used but the designer wants to take complete control over attributes and output HDL to ensure their flow has the correct memory created.The text was updated successfully, but these errors were encountered: