rst_i should not be a required signal

[olofk]

3.4.0 lists rst_i as a required signal for masters and slaves. In practice, the rst_i signal should not always be needed. Even the example in A.7.2 does not include rst_i

(discovered by Alfred M. Szmidt)

[m-kru]

What page, which revision? I struggle to find it.

[ams]

It is rule 3.40, page 34-34 of B4. "As a minimum, ... MUST include the following signals: ... [RST_I], ...".

[m-kru]

Ok, I see. Doesn't it depend on the target FPGA/ASIC? With FPGA you do not need reset to bring the logic to the proper initial state. I am not sure how it is with ASIC nowadays, but more than 20 years ago I guess they needed reset to bring it to the known state after power up?

[rherveille]

It is bad practice to rely on FPGA configuration to set required signals to a known state. Always use a reset. Richard On 18 Sep 2021, at 12:42, m-kru ***@***.***> wrote:  Ok, I see. Doesn't it depend on the target FPGA/ASIC? With FPGA you do not need reset to bring the logic to the proper initial state. I am not sure how it is with ASIC nowadays, but more than 20 years ago I guess they needed reset to bring it to the known state after power up? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#1 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADYKSCN5BOQGFLA6FV2ZEC3UCRUHJANCNFSM4E6DQ2EQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[ams]

Which is why it should be made optional, not a required signal. The example as such is even not compliant with the spec. The WB spec can't really make any guarantees that a core will work in ASIC.

[olofk]

It's not just about FPGA/ASIC. It is fully possible to make some components with wishbone interfaces that are completely stateless (my wishbone multiplexer being such an example https://github.com/olofk/wb_intercon/blob/master/rtl/verilog/wb_mux.v).

Also, compare with e.g. AXI stream where only the tvalid signal is required IIRC. Even tdata and tready are optional because there exist perfectly valid use cases without them

[rherveille]

Yup, agreed. The signal should be optional, but mandatory for IPs with state. Richard On 18 Sep 2021, at 17:09, Olof Kindgren ***@***.***> wrote:  It's not just about FPGA/ASIC. It is fully possible to make some components with wishbone interfaces that are completely stateless (my wishbone multiplexer being such an example https://github.com/olofk/wb_intercon/blob/master/rtl/verilog/wb_mux.v). Also, compare with e.g. AXI stream where only the tvalid signal is required IIRC. Even tdata and tready are optional because there exist perfectly valid use cases without them — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#1 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADYKSCNHNKMNTX65TPTL3ADUCSTQLANCNFSM4E6DQ2EQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[rherveille]

If a core doesn’t work in an ASIC it’s a bad core Richard On 18 Sep 2021, at 16:03, Alfred M. Szmidt ***@***.***> wrote:  Which is why it should be made optional, not a required signal. The example as such is even not compliant with the spec. The WB spec can't really make any guarantees that a core will work in ASIC. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#1 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADYKSCPHV7HVXMSFNR4TZ43UCSLZLANCNFSM4E6DQ2EQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[ams]

If a core doesn’t work in an ASIC it’s a bad core

Such comments are unhelpful and outright hostile to hobbyists that only have access to of the shelf FPGAs but can still write good cores without them working on an ASIC..

Not everyone has the means to try their cores on ASIC.

[m-kru]

@rherveille

It is bad practice to rely on FPGA configuration to set required signals to a known state.

If a core doesn’t work in an ASIC it’s a bad core

You state highly subjective theses without providing any arguments.

[rherveille]

It is bad practice to rely on FPGA configuration to set required signals to a known state. This is just bad practice. It’s asking for failures. Next technology doesn’t (completely) initialize all signals and the design stops working or works intermittently. I have seen this with 3 projects. One required an ASIC reaping and recall of cars to fix the issue. Very expensive and the fix is so simple; reset the signals that must come up in a known state. If a core doesn’t work in an ASIC it’s a bad core IP cores are all about reuse. Certainly there are technology specific cores, but those are usually provided by the vendor. IP cores should be technology agnostic. Richard On 19 Sep 2021, at 18:26, m-kru ***@***.***> wrote:  @rherveille<https://github.com/rherveille> It is bad practice to rely on FPGA configuration to set required signals to a known state. If a core doesn’t work in an ASIC it’s a bad core You state highly subjective theses without providing any arguments. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADYKSCMOPACOIX7U2WZJFH3UCYFJTANCNFSM4E6DQ2EQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[ams]

Let's keep highly subjective and personal comments like this somewhere else.