search

Origen-SDK / origen

The Origen Semiconductor Developer's Kit core platform
http://origen-sdk.org
MIT License
20 stars 24 forks source link

What will it take to get origen to 1.0.0? #149

Open welguisz opened 6 years ago

welguisz commented 6 years ago

I think we need to get to a version 1.0.0 so Origen starts to have more accountability and just something that is always being tinkering with. I think that the following website gives some good rules for Semantically Versioning Origen.

Semantic Versioning Rules

info-rchitect commented 6 years ago

@welguisz Origen has unit level testing, RFCs, multiple reviewers for every PR and the C.I. process. What is missing? The term 'tinkering' makes it sound like everyone is just pushing to the repo ad-hoc. I haven't seen that at all.

chrisnappi commented 6 years ago

I think what @welguisz means is that we need to have a stable release that people can comfortably build platforms on that will be 'supported', and that any changes to that release to the theoretical next stable will be carefully documented. However I don't think we are quite ready for something like that yet. Maybe in another 3 months..

info-rchitect commented 6 years ago

@chrisnappi I have had no issues building on Origen since I started using it so I can't see this gap. All users should be aware that as Origen's modeling capabilities expand, the new models will start raw and refine naturally over time through use and feedback. That is how open-source works versus a spec'd piece of software. But regarding getting to v1.0 I open to new ideas to help speed this up and make the process more transparent.

chrisnappi commented 6 years ago

Well you have been lucky then. 1.0.0 will mean that until 2.0.0 any changes made will not be breaking API changes. http://semver.org/ (edit: heh missed @welguisz already linked that) It makes sense to try to aim for this. A 1.0.0 release indicates a firm baseline API. I actually think this is more important for testers than base Origen-sdk though.

welguisz commented 6 years ago

@info-rchitect ... First, I might have misspoke with 'tinkering'. We do have good practices with Unit testing, RFCs, and multiple reviewers. @chrisnappi hit the issue on the head with saying we have a firm baseline API. It doesn't mean that new features can't be added, it just means we are more inline with the standards out there.

1.0.0 --- Baseline API 1.0.1 --- Bug Fixes a, b, c 1.0.2 --- More Bug Fixes 1.1.0 -- Added New Class to do y 1.1.1 -- Bug Fixes and more Unit Level Testing 1.2.0 -- Added new public methods to Class B with tests 1.2.1. -- Rewrote Class C to be more unit level tester friendly 1.3.0 -- Put Deprecate method in method ABC ... duplicated by method ALPHA 1.3.1 --- Bug fixes 1.3.2 -- More bug fixes 2.0.0 -- Removed method ABC and no more support for it. ... Continue

welguisz commented 6 years ago

The other reason that I ask this is around Thanksgiving and Xmas, I might have some time to spend working on getting things ready for 1.0.0.

info-rchitect commented 6 years ago

@welguisz i get your point, thanks for clarifying. I think definitely need to follow the RFC process for new models and also get enough timely participation in the RFC process by as many folks as possible.

welguisz commented 6 years ago

I was on PTO away from computer last week ... \<Insert joke here>

info-rchitect commented 6 years ago

@welguisz sorry that wasn't intended at you, it was a general statement that many folks request reviews but we all have day jobs. We will either have to slow down to match a realistic review pace or keep more code on the application side until the RFC is properly reviewed.

welguisz commented 6 years ago

@info-rchitect ... no harm ... I was trying to be funny. I was trying to think about a funny joke, but none of my jokes were appropriate.

ginty commented 6 years ago

This is a good question and discussion, here's my 2c...

I don't really recognize that we are making any breaking changes and agree with @info-rchitect's comments above. As far as I am concerned we are already guaranteeing backwards compatibility in the same way as we would if we were to go to 1.0. Are there any specific examples that people can cite and which you would expect to be better if we called it 1.0?

In my view, neither Origen or OrigenTesters is ready to go to 1.0, though many of the other plugins are and some of them are already at 1.0 and probably quite a few others are ready to go there now.

For anyone who attributes meaning to v1 (and honestly in this space I'm not sure that there are that many anyway), then yes it is a statement of intent that we have a frozen API, but it's also an indication that the project is fairly feature-complete and you should be able to approach it with an expectation that it will be very close to meeting your needs out of the box.

If we look at the amount of stuff that @info-rchitect has had to add and is continuing to add to make Origen support his pilot project, I think that is a very clear indication that any other 3rd party should be made aware that they would be climbing on board something that is still in beta at this point in time.

It's hard to put a timeline or indeed requirements for ticking the v1 box. @chrisnappi mentions 3 months above, but honestly I would put it more like at least a year. Ruby always releases at Christmas, maybe we should put Christmas 2018 as a stake in the ground for when we want Origen and OrigenTesters to be at v1?

As to what we need to get there, some initial items that spring to mind:

Origen:

OrigenTesters:

info-rchitect commented 6 years ago

@ginty I think there was churn regarding the power domains due to my fault that caused @welguisz some lost time. But I am glad he proposed the question anyway because it was needed. Here are some items I think we need to have to get to v1.0:

origen core:

  1. a Document/Report module that uses the Prawn ruby gem. I think this is key to moving Origen further upstream into Design/DFT, and Architecture as well as into PDE. If we want this to be a platform that serves the semiconductor ecosystem we need a reporting module or we will be stuck hand-copying from docs made by closed platforms like Framemaker.

origen testers:

  1. Native levels API
  2. Native timings API
  3. Pre-made templates for pins/channel maps for every supported platform.

In general on origen_testers, there is still way too much hand-created or external script created content to WOW folks. In our case, where we can't do patterns due to an existing tool, the shock and awe of origen for flows (while still lights years ahead of one-off scripts) sometimes doesn't pull enough weight. If I got a shell program, sans patterns, very easily out of the box I would be dancing in the street.

ginty commented 6 years ago

@info-rchitect, fully agree with the comments that generating a more complete program would provide more wow factor.

I don't think either the timing or the levels is hard to do, just needs someone with the bandwidth to tackle it right now. In fact, I'm not even sure that we need much by way of additional APIs, I think its more a question of just tying a few things together and adding the necessary view template.

i.e. the API to define timing already exists, we just need to add an additional generator to OrigenTesters which would look at the DUT during a V93K generation run, and if timing has been defined for it then render the corresponding 93K view of it.

On the levels, I'm not sure if what you have added in terms of power domains covers it or not, but potentially I think we should take a similar approach. i.e. define everything at the model layer, i.e. instead of calling APIs from the program interface, and then just render the appropriate view based on the current DUT attributes at program generation time.

Think that would work?

info-rchitect commented 6 years ago

@ginty I think we are in complete agreement. I am putting the pieces together (specs, power domains, etc.) to be able to write said levels generator for the v93k. I definitely think this is something @arkohler and I can work on together.

welguisz commented 6 years ago

@ginty and @info-rchitect .... Here is an error that a user might see if they were to upgrade from like 0.13.0 to 0.27.0 and cause frustation:

In 0.25.0 and 0.26.0, @typical_voltage could be 'n/a' ... now it can't.

@typical_voltage 'n/a' cannot be converted to a number, exiting...
my_app/.origen/gems/ruby/2.3.0/gems/origen-0.27.0/lib/origen/chip_mode.rb:124:in `validate_args'
my_app/.origen/gems/ruby/2.3.0/gems/origen-0.27.0/lib/origen/chip_mode.rb:23:in `initialize'
my_app/.origen/gems/ruby/2.3.0/gems/origen-0.27.0/lib/origen/model.rb:197:in `new'
my_app/.origen/gems/ruby/2.3.0/gems/origen-0.27.0/lib/origen/model.rb:197:in `add_mode'
my_app/.origen/gems/ruby/2.3.0/gems/my_plugin-version/lib/my_plugin/schemas/worksheets/modes.rb:83:in `add_mode'
info-rchitect commented 6 years ago

@welguisz i agree that would be frustrating but not sure how that behavior difference was due to a recent change. I checked the history for chip_mode.rb and it doesn't show any changes to the validate_args method. I would like to figure this out, can you send more details?

welguisz commented 6 years ago

I think some of it might be due to the following:

lib/origen/model.rb Commit SHA df4e6a8873288

I just upgraded to 0.27.0 in another plugin and get the following:

        NoMethodError:
        undefined method `current_mode' for nil:NilClass
      # ./.origen/gems/ruby/2.3.0/gems/origen-0.27.0/lib/origen/model.rb:182:in `current_mode'
      # ./.origen/gems/ruby/2.3.0/gems/origen-0.27.0/lib/origen/model.rb:182:in `current_mode'
      # ./.origen/gems/ruby/2.3.0/gems/origen-0.27.0/lib/origen/specs.rb:127:in `has_spec?'
      # ./.origen/gems/ruby/2.3.0/gems/origen-0.27.0/lib/origen/specs.rb:89:in `spec'
welguisz commented 6 years ago

@info-rchitect ... ignore above, I was able to figure out the issue.