|
From: Maciej S. <mac...@ce...> - 2014-11-28 13:33:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Steve, The VPI functions to access dynamic arrays are ready to be merged. This is the groundwork that will allow me to write support for functions working with std_logic_vectors of undefined size, that has been my desire for a long time already. The pull request [1] also includes a previously sent branch that introduced type casting in SV. As usual, the new features are demonstrated with tests [2]. I think changes to VPI code deserve some further explanation. I did my best to reuse as much of existing code as possible. As the result, I added __vpiArrayBase type that gathers common traits of both static and dynamic arrays (respectively __vpiArray and __vpiDarray). There are also __vpiArrayIndex, __vpiArrayWord and __vpiArrayIterator that are used by both classes. A few static C functions that were called only by class methods are moved directly to appropriate methods (e.g. grep for vpi_array_var_word_get_value). A bunch of others are transformed to methods, in case they were operating on an instance of a class (see decode_array_word_pointer). As I have written recently, there is one thing left. If vectors are used as the array element type, then there is no way to check the details (2 vs 4-state logic and signedness). Regards, Orson 1. https://github.com/steveicarus/iverilog/pull/49 2. https://github.com/orsonmmz/ivtest/tree/darray_vpi_test -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUeHmTAAoJEBRwGu1hpbJ1NGUH/0JuSTaZNbTOT8u4tz87eE4a D4pZ0iqY6N+fm+e3VZwgyFKRVuZIMwp8lr61T7Xrd9H8UhJyyTpFdaHfn6l4VKez TQGmRNTegKkF+rQDIYvyH5lN4SgqTxQxebztQmltqAMZBWKnvs5YiHlAXPvlWA++ wUeEV/RJFVXj3717npMtp6sKA0+xaGXlYUUQGXtjqrYQOIaMAM9DD8USKJYhnqIM L3srLkjBp9iL0Puh9tQxVy0Sz22eNWRy/19cjK3kv9ODTMHGnuQ2uIdR+J3wGxdd AwlaSCDCb0/gcmkkyEJP+pwFQXVeRdcPdllhM4A4H9LYpYqo7gRpij9Br35C3PQ= =OQ/7 -----END PGP SIGNATURE----- |
|
From: Stephen W. <st...@ic...> - 2014-12-02 19:23:51
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This created some chaos in the vec4-stack branch. Totally not your fault, but it is encouraging me to get my act together and get it merged into the master branch as soon as possible. On 11/28/2014 05:33 AM, Maciej Sumiński wrote: > Hi Steve, > > The VPI functions to access dynamic arrays are ready to be merged. > This is the groundwork that will allow me to write support for > functions working with std_logic_vectors of undefined size, that > has been my desire for a long time already. > > The pull request [1] also includes a previously sent branch that > introduced type casting in SV. As usual, the new features are > demonstrated with tests [2]. > > I think changes to VPI code deserve some further explanation. I did > my best to reuse as much of existing code as possible. As the > result, I added __vpiArrayBase type that gathers common traits of > both static and dynamic arrays (respectively __vpiArray and > __vpiDarray). There are also __vpiArrayIndex, __vpiArrayWord and > __vpiArrayIterator that are used by both classes. > > A few static C functions that were called only by class methods > are moved directly to appropriate methods (e.g. grep for > vpi_array_var_word_get_value). A bunch of others are transformed > to methods, in case they were operating on an instance of a class > (see decode_array_word_pointer). > > As I have written recently, there is one thing left. If vectors > are used as the array element type, then there is no way to check > the details (2 vs 4-state logic and signedness). > > Regards, Orson > > 1. https://github.com/steveicarus/iverilog/pull/49 2. > https://github.com/orsonmmz/ivtest/tree/darray_vpi_test > - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlR+EbwACgkQrPt1Sc2b3ikRrwCfVuQ4Gi8Esyt1BvgZKtV4X/JQ Yf4AnR5n/DSqFP/uCkqzUw+MKV49Z6Xk =dKF3 -----END PGP SIGNATURE----- |
|
From: Maciej S. <mac...@ce...> - 2014-12-02 19:51:48
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Steve, I am sorry - as you know, it was not intentional. I do my best to deliver good quality code, and that includes rebasing my changes on the top of the master branch and running the test suite to be sure that the merge process is going to be as smooth as it can be. I have recently seen posts about the vec4-stack branch. I felt a bit relaxed, thinking that it had been already pushed to the master, but just a moment ago I realized it is not the case. If it is not too late, I can still rebase my changes on the top of vec4-stack - just let me know. Regards, Orson On 12/02/2014 08:23 PM, Stephen Williams wrote: > > This created some chaos in the vec4-stack branch. Totally not your > fault, but it is encouraging me to get my act together and get it > merged into the master branch as soon as possible. > > > On 11/28/2014 05:33 AM, Maciej Sumiński wrote: >> Hi Steve, > >> The VPI functions to access dynamic arrays are ready to be >> merged. This is the groundwork that will allow me to write >> support for functions working with std_logic_vectors of undefined >> size, that has been my desire for a long time already. > >> The pull request [1] also includes a previously sent branch that >> introduced type casting in SV. As usual, the new features are >> demonstrated with tests [2]. > >> I think changes to VPI code deserve some further explanation. I >> did my best to reuse as much of existing code as possible. As >> the result, I added __vpiArrayBase type that gathers common >> traits of both static and dynamic arrays (respectively __vpiArray >> and __vpiDarray). There are also __vpiArrayIndex, __vpiArrayWord >> and __vpiArrayIterator that are used by both classes. > >> A few static C functions that were called only by class methods >> are moved directly to appropriate methods (e.g. grep for >> vpi_array_var_word_get_value). A bunch of others are transformed >> to methods, in case they were operating on an instance of a >> class (see decode_array_word_pointer). > >> As I have written recently, there is one thing left. If vectors >> are used as the array element type, then there is no way to >> check the details (2 vs 4-state logic and signedness). > >> Regards, Orson > >> 1. https://github.com/steveicarus/iverilog/pull/49 2. >> https://github.com/orsonmmz/ivtest/tree/darray_vpi_test > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUfhhaAAoJEBRwGu1hpbJ1x6IIAIEeF9afrDwN4JSaE20hV1cp +R88PLN0PVbUYG7oBs/yS1RR03fTpcUrprnw9XucIIe7hrNhW8uxhLZKgtfkniwd 5wfFR+cO5RgM6v88sfBz090nVl9MkuGxaPkNSTJImR3CLf7zbwBib3XlCeV0E1So jFEWWJPpnOph/7BGwGL4weZZnFFc/rKKXEfLVl7IHJMyTrvJXoge/d9WlnAGpcVL mY3y9nNGh/oCWsVTN5pRA4Y4t6BXop7/hN0VIkYi//d6RJqQIvseGbeYC6t9rERv NEgxcNHqmgNSYVmcfWZU95ZRVop9Ula3aovRzyRJrkiDJg/WeM3BxzEXMSwdy3k= =Uyn0 -----END PGP SIGNATURE----- |
|
From: Stephen W. <st...@ic...> - 2014-12-02 20:25:14
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh, you did nothing wrong. Don't worry about it at this point as the vec4-stack branch is still not merged into master. I am merging master into the vec4-stack branch so that when the merge does happen, it will be free of surprises. So far, the only thing keeping me from merging into master is some performance issues that I think need to be addressed. On 12/02/2014 11:51 AM, Maciej Sumiński wrote: > Hi Steve, > > I am sorry - as you know, it was not intentional. I do my best to > deliver good quality code, and that includes rebasing my changes > on the top of the master branch and running the test suite to be > sure that the merge process is going to be as smooth as it can be. > > I have recently seen posts about the vec4-stack branch. I felt a > bit relaxed, thinking that it had been already pushed to the > master, but just a moment ago I realized it is not the case. If it > is not too late, I can still rebase my changes on the top of > vec4-stack - just let me know. > > Regards, Orson > > On 12/02/2014 08:23 PM, Stephen Williams wrote: > >> This created some chaos in the vec4-stack branch. Totally not >> your fault, but it is encouraging me to get my act together and >> get it merged into the master branch as soon as possible. > > >> On 11/28/2014 05:33 AM, Maciej Sumiński wrote: >>> Hi Steve, > >>> The VPI functions to access dynamic arrays are ready to be >>> merged. This is the groundwork that will allow me to write >>> support for functions working with std_logic_vectors of >>> undefined size, that has been my desire for a long time >>> already. > >>> The pull request [1] also includes a previously sent branch >>> that introduced type casting in SV. As usual, the new features >>> are demonstrated with tests [2]. > >>> I think changes to VPI code deserve some further explanation. >>> I did my best to reuse as much of existing code as possible. >>> As the result, I added __vpiArrayBase type that gathers common >>> traits of both static and dynamic arrays (respectively >>> __vpiArray and __vpiDarray). There are also __vpiArrayIndex, >>> __vpiArrayWord and __vpiArrayIterator that are used by both >>> classes. > >>> A few static C functions that were called only by class methods >>> are moved directly to appropriate methods (e.g. grep for >>> vpi_array_var_word_get_value). A bunch of others are >>> transformed to methods, in case they were operating on an >>> instance of a class (see decode_array_word_pointer). > >>> As I have written recently, there is one thing left. If vectors >>> are used as the array element type, then there is no way to >>> check the details (2 vs 4-state logic and signedness). > >>> Regards, Orson > >>> 1. https://github.com/steveicarus/iverilog/pull/49 2. >>> https://github.com/orsonmmz/ivtest/tree/darray_vpi_test > > > > - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlR+IB8ACgkQrPt1Sc2b3im7IACfSex4f/2ksrLDTe1e7fo+FVcn YB0AoKmPhmKsZfoWfJQqi1SQnC+1hEgK =1g4+ -----END PGP SIGNATURE----- |