search

lowRISC / opentitan

OpenTitan: Open source silicon root of trust
https://www.opentitan.org
Apache License 2.0
2.58k stars 775 forks source link

Connect UART to IOC3/IOC4 rather than IOC10/11 #8355

Closed mundaym closed 2 years ago

mundaym commented 3 years ago

Right now the standard configuration (assumed by the test boot ROM, smoke tests, Verilator etc.) is that pins IOC10 (RX) and IOC11 (TX) are UART connections. For the mask ROM we will need to use IOC3 (RX) and IOC4 (TX) as the UART.

I'm wondering how arbitrary the existing IOC10/11 assignments are. Should we continue to support IOC10/11 as well or could we just switch everything to IOC3/4?

mundaym commented 3 years ago

@tjaychen @sriyerg any opinions?

mundaym commented 3 years ago

Using IOC3/4 as the UART is probably going to mean reconfiguring Verilator to use different pins as GPIO. I'm fairly certain that IOC10/11 were chosen because there are 32 GPIO pins and IOC10 and IOC11 are the first two pins following that allocation, pins 32 and 33 respectively.

tjaychen commented 3 years ago

@timothytrippel / @sriyerg i think we talked some time ago (although we've not actualized this yet) that DV, verilator etc would primarily support the most stressful use case we have. In all of our use cases so far we denote 3/4 as the native UART, so I think it is reasonable to switch to them as well.

sriyerg commented 3 years ago

Pinmux is sufficiently verified with FPV, which, in conjunction with top level connectivity obviates the need to test for example, UART0 IO can be connected to every single pin.

We decided that our pinmux config for all usecases (CrOS, TI, etc.) will be extracted from a corresponding HJSon which will capture the configuration for that usecase, and we will only stick to that limited set, rather than randomly switch the pinmux assignments at runtime. Since that configuration comes from the HJSon, the SW running on the device AND the host should automatically adhere to it. As such, this should be transparent to all of our simulation platforms.

timothytrippel commented 3 years ago

Pinmux is sufficiently verified with FPV, which, in conjunction with top level connectivity obviates the need to test for example, UART0 IO can be connected to every single pin.

We decided that our pinmux config for all usecases (CrOS, TI, etc.) will be extracted from a corresponding HJSon which will capture the configuration for that usecase, and we will only stick to that limited set, rather than randomly switch the pinmux assignments at runtime. Since that configuration comes from the HJSon, the SW running on the device AND the host should automatically adhere to it. As such, this should be transparent to all of our simulation platforms.

+1, as @sriyerg stated, this won't matter in the long run since it will be transparent to each platform so assign how you need them.

We have a doc describing this, it just has not been actualized yet as you stated @tjaychen.

tjaychen commented 3 years ago

sorry quick question, in the top level dv TB though, won't we have to physically connect the uart agents to IOC3/4?

On Fri, Sep 24, 2021 at 4:33 PM Timothy Trippel @.***> wrote:

Pinmux is sufficiently verified with FPV, which, in conjunction with top level connectivity obviates the need to test for example, UART0 IO can be connected to every single pin.

We decided that our pinmux config for all usecases (CrOS, TI, etc.) will be extracted from a corresponding HJSon which will capture the configuration for that usecase, and we will only stick to that limited set, rather than randomly switch the pinmux assignments at runtime. Since that configuration comes from the HJSon, the SW running on the device AND the host should automatically adhere to it. As such, this should be transparent to all of our simulation platforms.

+1, as @sriyerg https://github.com/sriyerg stated, this won't matter in the long run since it will be transparent to each platform so assign how you need them.

We have a doc describing this, it just has not been actualized yet as you stated @tjaychen https://github.com/tjaychen.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/opentitan/issues/8355#issuecomment-926969760, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH2RSQ2MJ2C3ZJMXSBQNCDUDUDF7ANCNFSM5EV43B5A . 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.

sriyerg commented 3 years ago

sorry quick question, in the top level dv TB though, won't we have to physically connect the uart agents to IOC3/4?

Agreed, but that is trivial.

tjaychen commented 3 years ago

o yes agreed, i just meant in my original reply that's the "change" dv should make to match.

On Fri, Sep 24, 2021 at 5:30 PM Srikrishna Iyer @.***> wrote:

sorry quick question, in the top level dv TB though, won't we have to physically connect the uart agents to IOC3/4?

Agreed, but that is trivial.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/opentitan/issues/8355#issuecomment-926981258, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH2RSWRW3CNQCTR4LDC3ATUDUJ2LANCNFSM5EV43B5A . 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.

sriyerg commented 3 years ago

o yes agreed, i just meant in my original reply that's the "change" dv should make to match.

Right - that should be ok. Once those pinmux config HJSons are ready, we will extract that info into an SV data structure which the TB top can use to know which port to connect the UART (and all the other) agents to.

tjaychen commented 3 years ago

@timothytrippel sorry can you remind me, do we have an issue to track those hjson's already? if we do, feel free to add me to it, and i can look into creating it since I really want to deprecate the sheet we're using to maintain things now.

timothytrippel commented 3 years ago

@timothytrippel sorry can you remind me, do we have an issue to track those hjson's already? if we do, feel free to add me to it, and i can look into creating it since I really want to deprecate the sheet we're using to maintain things now.

We did not, but I just created one: #8380.

tjaychen commented 3 years ago

thank you Tim!

On Mon, Sep 27, 2021 at 11:20 AM Timothy Trippel @.***> wrote:

@timothytrippel https://github.com/timothytrippel sorry can you remind me, do we have an issue to track those hjson's already? if we do, feel free to add me to it, and i can look into creating it since I really want to deprecate the sheet we're using to maintain things now.

We did not, but I just created one: #8380 https://github.com/lowRISC/opentitan/issues/8380.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/opentitan/issues/8355#issuecomment-928156052, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH2RSQHV7GS6MIEQJHUVUTUECYYXANCNFSM5EV43B5A . 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.