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
It would be nice to have some clarity around what a library is, and what one isn't. It may seem obvious, but it can be quite subtle.
Is it a collection of commonly used sub-components hardware?
Is it a collection of commonly used interfaces and the semantics of using them?
Is it a collection of fully generic sub-components that are all-singing and all dancing. By their very nature become large and cumbersome? (e.g a HDMI interface, that includes multi-channel audio, multiple color space support, 3D, and so on, vs something that can display DVI-D in 8 colours)
Is it a collection of simple generic sub-components that can be refined to meet your needs?
Is the interface and implementation of libraries different things, or are the they same?
Do these libraries have unit tests, and validation models, and testing harnesses so you can see if they break (or you are using them inappropriately)?
Do they have simulation models that work like the library should? - e.g. an LCD module that simulates an LCD display on the screen.
How do you debug into a library? Can you do that when implemented in H/W?
Where/how do libraries sit above the actual FPGA primitives? Is it a hardware abstraction layer? How do you merge different physical implementations into a generic library?
The text was updated successfully, but these errors were encountered:
hamsternz
changed the title
What does "libraries" mean in this context of Objectives and guiding principles
What does "libraries" mean in this context of Objectives and Guiding Principles
Jan 24, 2018
I think libraries should encompass all of the above. As is the same with software languages, libraries may provide as little as one function, or as much as an entire suite of capabilities with great modularity, thoughtfulness, and testing. The language itself should not force specific requirements on what a library should be beyond it being valid. The language should provide the features and capabilities necessary for libraries to be written and scale from the very small and minimal library, to very large and comprehensive library.
It would be nice to have some clarity around what a library is, and what one isn't. It may seem obvious, but it can be quite subtle.
Is it a collection of commonly used sub-components hardware?
Is it a collection of commonly used interfaces and the semantics of using them?
Is it a collection of fully generic sub-components that are all-singing and all dancing. By their very nature become large and cumbersome? (e.g a HDMI interface, that includes multi-channel audio, multiple color space support, 3D, and so on, vs something that can display DVI-D in 8 colours)
Is it a collection of simple generic sub-components that can be refined to meet your needs?
Is the interface and implementation of libraries different things, or are the they same?
Do these libraries have unit tests, and validation models, and testing harnesses so you can see if they break (or you are using them inappropriately)?
Do they have simulation models that work like the library should? - e.g. an LCD module that simulates an LCD display on the screen.
How do you debug into a library? Can you do that when implemented in H/W?
Where/how do libraries sit above the actual FPGA primitives? Is it a hardware abstraction layer? How do you merge different physical implementations into a generic library?
The text was updated successfully, but these errors were encountered: