Comment Re:A rash of options... (Score 1) 24
Sorry for the really long response...
Excellent question. As I was one of the people on the EV8 team who
drove the decision to adopt Vesta, I can offer my perspective.
I am and was a CVS user. We used CVS for the EV8 performance model.
We used RCS/Make for the EV6 models. We used CMS/MMS (a rev
control/build toolset for VMS) for previous projects. They all had a
set of problems that I decided were not acceptable for the EV8 RTL
(hardware description language and verification) effort.
1. All three provided nearly adequate revision control, but the lack
of an encapsulated build environment caused problems in two (fairly
common) scenarios:
a) Engineer transfers from box X to box Y (from one section of the chip
project to another). Because of the peculiarities of box Y, they use a
slightly different set of environment variables to talk to the various compilers/linkers/verification scripts.
So, he logs in using his old environment, builds a model for box Y that doesn't work quite right.
Yes we can fix that with discipline, but mechanical encapsulation works much better. There are many solutions to the problem that still use CVS. We chose a tool approach.
2) Bob is working on a bug reported against model version 3-15-99. Alice is working on a different bug for the same model. Alice discovers her bug is related to a problem with the RTL compiler. So, she gets the maintainer to ship and install the upgrade.
Bob recompiles with the new compiler and his bug moves (or disappears-- why? did the compiler "fix" it, or did the compiler just hide it. --- we've seen both instances.)
Yes, you can construct multiple "release areas" and select them with environment variables -- that's what we did on some earlier projects. This solution was viewed as somewhat unsatisfactory. (it adds ONE more environment variable/magic switch to keep track of.)
2. Our experience with CVS in the performance model environment indicated that it was difficult to use CVS to manage configurations (as opposed to revisions.) That is, I want to build model A with version 6.5 of unit X, version 6.3 of unit Y -- but someone else wants to build model B with version 6.5 of X and no unit Y, but version 0 of unit Z. We wanted a simple, common, and interchangeable way of representing these builds. Make works, but as experienced users of Make will know, often becomes cryptic when one starts to use it for configuration management.
3. Additionally, CVS version tagging is not as rich as Vesta's build package system. We made significant use of the latter.
4. Finally, to some this will seem a nit and perhaps it is. CVS and RCS rely to some degree on Time-of-Day clocks for revision id. We operated over a huge geographical area in multiple time zones where the systems aren't always synced to a common clock. If I were king, this wouldn't be a problem. Alas, big IT organizations will conspire against us.
As for comparison to the other systems, I'm pretty sure the comparison text was written before these came along. (I haven't seen it, xorian -- was this material taken from the survey that WA wrote back in '98?)
By the way, folks who've used both the CVS/Make approach and the Vesta approach to RTL development are, in general (perhaps universally), of the opinion that Vesta was the correct choice.
Excellent question. As I was one of the people on the EV8 team who
drove the decision to adopt Vesta, I can offer my perspective.
I am and was a CVS user. We used CVS for the EV8 performance model.
We used RCS/Make for the EV6 models. We used CMS/MMS (a rev
control/build toolset for VMS) for previous projects. They all had a
set of problems that I decided were not acceptable for the EV8 RTL
(hardware description language and verification) effort.
1. All three provided nearly adequate revision control, but the lack
of an encapsulated build environment caused problems in two (fairly
common) scenarios:
a) Engineer transfers from box X to box Y (from one section of the chip
project to another). Because of the peculiarities of box Y, they use a
slightly different set of environment variables to talk to the various compilers/linkers/verification scripts.
So, he logs in using his old environment, builds a model for box Y that doesn't work quite right.
Yes we can fix that with discipline, but mechanical encapsulation works much better. There are many solutions to the problem that still use CVS. We chose a tool approach.
2) Bob is working on a bug reported against model version 3-15-99. Alice is working on a different bug for the same model. Alice discovers her bug is related to a problem with the RTL compiler. So, she gets the maintainer to ship and install the upgrade.
Bob recompiles with the new compiler and his bug moves (or disappears-- why? did the compiler "fix" it, or did the compiler just hide it. --- we've seen both instances.)
Yes, you can construct multiple "release areas" and select them with environment variables -- that's what we did on some earlier projects. This solution was viewed as somewhat unsatisfactory. (it adds ONE more environment variable/magic switch to keep track of.)
2. Our experience with CVS in the performance model environment indicated that it was difficult to use CVS to manage configurations (as opposed to revisions.) That is, I want to build model A with version 6.5 of unit X, version 6.3 of unit Y -- but someone else wants to build model B with version 6.5 of X and no unit Y, but version 0 of unit Z. We wanted a simple, common, and interchangeable way of representing these builds. Make works, but as experienced users of Make will know, often becomes cryptic when one starts to use it for configuration management.
3. Additionally, CVS version tagging is not as rich as Vesta's build package system. We made significant use of the latter.
4. Finally, to some this will seem a nit and perhaps it is. CVS and RCS rely to some degree on Time-of-Day clocks for revision id. We operated over a huge geographical area in multiple time zones where the systems aren't always synced to a common clock. If I were king, this wouldn't be a problem. Alas, big IT organizations will conspire against us.
As for comparison to the other systems, I'm pretty sure the comparison text was written before these came along. (I haven't seen it, xorian -- was this material taken from the survey that WA wrote back in '98?)
By the way, folks who've used both the CVS/Make approach and the Vesta approach to RTL development are, in general (perhaps universally), of the opinion that Vesta was the correct choice.
