zamyers
commented
4 years ago Thanks for catching this. I think I may relaunch place to resolve a few hotspots (depending on how routing goes over the next hour). If I feel I am going to do that (within the next 30 minutes or so), I will correct this in the mflowgen_sgh branch (unless you want to correct the master directly) and redo synthesis.
-Zach
From: Steven Herbst notifications@github.com Sent: Wednesday, May 20, 2020 1:20 PM To: StanfordVLSI/dragonphy2 dragonphy2@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [StanfordVLSI/dragonphy2] Bug -- en_bypass_ctl only controls PI 0 (#99)
Was poking around and found that we can only directly override the PI control code for PI 0. Now, the PI control codes can be manipulated in a different way (en_ext_max_sel_mux + ext_max_sel_mux + ext_pi_ctl_offset), so this is not necessarily a loss of functionality -- as long as we validate that we can set all codes for all PIs through the alternate path.
Details
dcore_debug_intf.en_bypass_ctl is 4 bits wide: https://github.com/StanfordVLSI/dragonphy2/blob/d24bf881f7eb6608f14fb2eb3fd95b19d57f1977/vlog/new_chip_src/digital_core/dcore_debug_intf.sv#L9 but the corresponding register is only 1 bit wide (as defined herehttps://github.com/StanfordVLSI/dragonphy2/blob/master/md/dcore_intf.md) As a result, when this assignment happens: https://github.com/StanfordVLSI/dragonphy2/blob/d24bf881f7eb6608f14fb2eb3fd95b19d57f1977/vlog/new_chip_src/jtag/jtag.sv#L142 dcore_debug_intf.en_bypass_ctl[0] is set to the value of the register en_bypass_ctl, and dcore_debug_intf.en_bypass_ctl[3:1] are all set to zero.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/StanfordVLSI/dragonphy2/issues/99, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACY6NPGPACJEPEC4RBXO4ODRSQ3SFANCNFSM4NGI7BYQ.
sgherbst
Was poking around and found that we can only directly override the PI control code for PI 0. Now, the PI control codes can be manipulated in a different way (
en_ext_max_sel_mux+ext_max_sel_mux+ext_pi_ctl_offset), so this is not necessarily a loss of functionality -- as long as we validate that we can set all codes for all PIs through the alternate path.Details
dcore_debug_intf.en_bypass_ctlis 4 bits wide: https://github.com/StanfordVLSI/dragonphy2/blob/d24bf881f7eb6608f14fb2eb3fd95b19d57f1977/vlog/new_chip_src/digital_core/dcore_debug_intf.sv#L9 but the corresponding register is only 1 bit wide (as defined here) As a result, when this assignment happens: https://github.com/StanfordVLSI/dragonphy2/blob/d24bf881f7eb6608f14fb2eb3fd95b19d57f1977/vlog/new_chip_src/jtag/jtag.sv#L142dcore_debug_intf.en_bypass_ctl[0]is set to the value of the registeren_bypass_ctl, anddcore_debug_intf.en_bypass_ctl[3:1]are all set to zero.