OpenCores

OpenCores

Reset signal recommendation in the

no use

no use

1/1

no use

no use

Reset signal recommendation in the by rdiez2 on Feb 21, 2012			rdiez2 Posts: 3 Joined: Jul 29, 2011 Last seen: Nov 17, 2012
Hi all: I have a few issues with the "OpenCores HDL modeling guidelines" document that I would like to discuss. The first subject is synchronous versus asynchronous reset. This was briefly discussed here: http://lists.openrisc.net/pipermail/openrisc/2012-January/000628.html This is what the guidelines state about the reset signal: -------------------------------- 1. Recommendation: Use asynchronous active high reset. Using asynchronous reset could result in a smaller core. Using an active high reset makes the core compatible with wishbone spec -------------------------------- I wonder if we should change the guidelines on this subject. It is my understanding that on FPGAs a synchronous reset will normally make the design smaller, contrary to that statement. Besides, the Wishbone specification requires a synchronous reset, so making the reset high as recommended is not sufficient. Thanks in advance, R. Diez Hi all: I have a few issues with the "OpenCores HDL modeling guidelines" document that I would like to discuss. The first subject is synchronous versus asynchronous reset. This was briefly discussed here: http://lists.openrisc.net/pipermail/openrisc/2012-January/000628.html This is what the guidelines state about the reset signal: -------------------------------- 1. Recommendation: Use asynchronous active high reset. Using asynchronous reset could result in a smaller core. Using an active high reset makes the core compatible with wishbone spec -------------------------------- I wonder if we should change the guidelines on this subject. It is my understanding that on FPGAs a synchronous reset will normally make the design smaller, contrary to that statement. Besides, the Wishbone specification requires a synchronous reset, so making the reset high as recommended is not sufficient. Thanks in advance, R. Diez

RE: Reset signal recommendation in the by yannv on Feb 23, 2012			yannv Posts: 20 Joined: Feb 6, 2009 Last seen: Jan 14, 2021
On some FPGAs, asynchronous reset does make the logic smaller, especially when it is a common reset. This is because the set/reset nets have dedicated connections, often across the entire chip (GSR) and nearly always shared among groups of registers (such as in slices or LABs), while synchronous resets may have to be implemented using the logic tables. Several devices allow either but not both for a given register. Altera Cyclone IV, for instance, supports both at the LAB level, but has more asynchronous resets than synchronous. Some features, such as block RAM contents and Xilinx SRL16E (using the LUT entries to make a shift register) do not support reset at all. Xilinx block RAM registers require synchronous reset, while Cyclone IV ones are limited to asynchronous. In short, this is technology specific. In practice, I have found converting synchronous resets to asynchronous resets to reduce design size, but this may be because the designs already had the same signal used as asynchronous reset elsewhere. Making all reset signals synchronous may well yield the same gains (and more, if reset logic itself can be simplified). The 42% reduction mentioned in the mail you link is huge, and I would like to see more details. Assuming it's the same comparison mentioned in the thread http://opencores.org/forum,OpenRISC,0,4586 two things stand out: first, it's not a 42% reduction but 30% (the reverse is a 42% increase). Second, we didn't get an apples to apples comparison. There were differences in inferred memories and one design didn't fit. Just moving a memory from block RAM to distributed RAM may require catastrophic replication of signals (with decoding and mux trees all using logic). A look at the code differences, and isolating the memory change from the register resets, might prove quite educational. The Wishbone specification specifies that reset shall be held during at least one cycle (rule 3.05). Combined with recommendation 3.00, to synchronize the deassertion of reset, it is possible to use RST_I as either way. When used asynchronously, however, bus-related state machines and signals should formally still behave as with a synchronous reset. In practice, I've seen fully asynchronous reset used. The general recommendation is to hold reset for at least a cycle length (possibly as long as necessary to reset deeper state like SRL16Es) before synchronizing the release of reset with the clock, so that setup times are not violated when asynchronous reset is used. This synchronization would have to be done per clock domain. Secondly, try not to mix types. Much has been written on this, for instance http://chipverification.blogspot.com/2008/05/asynchronous-and-synchronous-reset.html and http://forums.xilinx.com/t5/PLD-Blog/That-Dangerous-Asynchronous-Reset/ba-p/12856 - but AFAICT they're about paying attention, and do not argue for exclusively synchronous resets. Either way, thanks for calling this aspect of Wishbone to my attention. If Verilog 2005 events are usable as synthesizable ports, the whole point can be made trivial by selecting the event at a central point, but I'm guessing we won't have that much luck. I believe this is the sort of thing ForSyDe was made to fix, but moving just one codebase like OR1200 is a major effort, let alone an industry. On some FPGAs, asynchronous reset does make the logic smaller, especially when it is a common reset. This is because the set/reset nets have dedicated connections, often across the entire chip (GSR) and nearly always shared among groups of registers (such as in slices or LABs), while synchronous resets may have to be implemented using the logic tables. Several devices allow either but not both for a given register. Altera Cyclone IV, for instance, supports both at the LAB level, but has more asynchronous resets than synchronous. Some features, such as block RAM contents and Xilinx SRL16E (using the LUT entries to make a shift register) do not support reset at all. Xilinx block RAM registers require synchronous reset, while Cyclone IV ones are limited to asynchronous. In short, this is technology specific. In practice, I have found converting synchronous resets to asynchronous resets to reduce design size, but this may be because the designs already had the same signal used as asynchronous reset elsewhere. Making all reset signals synchronous may well yield the same gains (and more, if reset logic itself can be simplified). The 42% reduction mentioned in the mail you link is huge, and I would like to see more details. Assuming it's the same comparison mentioned in the thread http://opencores.org/forum,OpenRISC,0,4586 two things stand out: first, it's not a 42% reduction but 30% (the reverse is a 42% increase). Second, we didn't get an apples to apples comparison. There were differences in inferred memories and one design didn't fit. Just moving a memory from block RAM to distributed RAM may require catastrophic replication of signals (with decoding and mux trees all using logic). A look at the code differences, and isolating the memory change from the register resets, might prove quite educational. The Wishbone specification specifies that reset shall be held during at least one cycle (rule 3.05). Combined with recommendation 3.00, to synchronize the deassertion of reset, it is possible to use RST_I as either way. When used asynchronously, however, bus-related state machines and signals should formally still behave as with a synchronous reset. In practice, I've seen fully asynchronous reset used. The general recommendation is to hold reset for at least a cycle length (possibly as long as necessary to reset deeper state like SRL16Es) before synchronizing the release of reset with the clock, so that setup times are not violated when asynchronous reset is used. This synchronization would have to be done per clock domain. Secondly, try not to mix types. Much has been written on this, for instance http://chipverification.blogspot.com/2008/05/asynchronous-and-synchronous-reset.html and http://forums.xilinx.com/t5/PLD-Blog/That-Dangerous-Asynchronous-Reset/ba-p/12856 - but AFAICT they're about paying attention, and do not argue for exclusively synchronous resets. Either way, thanks for calling this aspect of Wishbone to my attention. If Verilog 2005 events are usable as synthesizable ports, the whole point can be made trivial by selecting the event at a central point, but I'm guessing we won't have that much luck. I believe this is the sort of thing ForSyDe was made to fix, but moving just one codebase like OR1200 is a major effort, let alone an industry.

RE: Reset signal recommendation in the by jt_eaton on Feb 23, 2012			jt_eaton Posts: 142 Joined: Aug 18, 2008 Last seen: Sep 29, 2018
The question is not what type of reset should we use but rather who should get to decide what type of reset is used. We now let the component designer make that call rather than the person who is doing the synthesys. That is wrong. We need to make reset style an option so that the chip designer can try it both ways to see which one is best for their technology. John Eaton The question is not what type of reset should we use but rather who should get to decide what type of reset is used. We now let the component designer make that call rather than the person who is doing the synthesys. That is wrong. We need to make reset style an option so that the chip designer can try it both ways to see which one is best for their technology. John Eaton

RE: Reset signal recommendation in the by pekon on Feb 24, 2012			pekon Posts: 29 Joined: Mar 6, 2009 Last seen: Dec 14, 2020
[q]We need to make reset style an option so that the chip designer can try it both ways to see which one is best for their technology. [/q] I agree here.. but then technology, area or timing-delays are just sub-set of parameter which affect the reset strategy. (especially in ASIC designs) I have come across, lot of customer requirements where, architecture implicitly requires a particular reset type.. Example: (1) At-times, If there are actuators (like motors, etc) connected to your chip, then you would want them to be in non-active state as soon as chip goes into reset. This is done for safety reasons. (2) If your clock-source itself gets cut-off by some POR or reset, then synchronous "assertion" resets are of no use. However, synchronous "de-assertion" ia always preferred. There was a similar forum discussion earlier (link posted below).. But, I don't know if there was any conclusion derived out of it. It would be good to revisit it & close it till conclusion. http://opencores.org/forum,OpenRISC,0,4586 with regards, pekon We need to make reset style an option so that the chip designer can try it both ways to see which one is best for their technology. I agree here.. but then technology, area or timing-delays are just sub-set of parameter which affect the reset strategy. (especially in ASIC designs) I have come across, lot of customer requirements where, architecture implicitly requires a particular reset type.. Example: (1) At-times, If there are actuators (like motors, etc) connected to your chip, then you would want them to be in non-active state as soon as chip goes into reset. This is done for safety reasons. (2) If your clock-source itself gets cut-off by some POR or reset, then synchronous "assertion" resets are of no use. However, synchronous "de-assertion" ia always preferred. There was a similar forum discussion earlier (link posted below).. But, I don't know if there was any conclusion derived out of it. It would be good to revisit it & close it till conclusion. http://opencores.org/forum,OpenRISC,0,4586 with regards, pekon

RE: Reset signal recommendation in the by jt_eaton on Feb 24, 2012			jt_eaton Posts: 142 Joined: Aug 18, 2008 Last seen: Sep 29, 2018
[q][q]We need to make reset style an option so that the chip designer can try it both ways to see which one is best for their technology. [/q] I agree here.. but then technology, area or timing-delays are just sub-set of parameter which affect the reset strategy. (especially in ASIC designs) I have come across, lot of customer requirements where, architecture implicitly requires a particular reset type.. Example: (1) At-times, If there are actuators (like motors, etc) connected to your chip, then you would want them to be in non-active state as soon as chip goes into reset. This is done for safety reasons. (2) If your clock-source itself gets cut-off by some POR or reset, then synchronous "assertion" resets are of no use. However, synchronous "de-assertion" ia always preferred. There was a similar forum discussion earlier (link posted below).. But, I don't know if there was any conclusion derived out of it. It would be good to revisit it & close it till conclusion. http://opencores.org/forum,OpenRISC,0,4586 with regards, pekon [/q] You are confusing two separate issues. You have to select whether your reset system is synchronous or asynchronous and then you have to select whether you use flipflops with synchronous or asynchronous style resets. Those two issues are completely independent. You may determine that you need an asynchronous reset system for the issues that you mentioned but you can still build it using flipflops that use synchronous resets. All that you have to do is to put a wrapper around your outputs that force those outputs into their reset state asynchronsly from the assertion of reset till the core is synchronously reset to that same value. You may think that you want to shut off your motors as soon as you can once you see an active reset but the reality is if you do that then you product will go out to lunch any time some one walks across a carpet and touches it. Every product that I have ever worked on has used analog filtering to ensure that only valid reset pulses will be recognized. It typically takes multiple clocks before you can determine that a reset pulse is valid and waiting one more is not going to make any difference. Asynchronous flipflop resets are a real problem in a modern asic core. They require special handling during scan testing and will double the number of end points in synthesys. They are really bad in fpgas where they can really affect your lut count. They made sense for the technologies that we had 30 years ago but not for what we have today. John Eaton We need to make reset style an option so that the chip designer can try it both ways to see which one is best for their technology. I agree here.. but then technology, area or timing-delays are just sub-set of parameter which affect the reset strategy. (especially in ASIC designs) I have come across, lot of customer requirements where, architecture implicitly requires a particular reset type.. Example: (1) At-times, If there are actuators (like motors, etc) connected to your chip, then you would want them to be in non-active state as soon as chip goes into reset. This is done for safety reasons. (2) If your clock-source itself gets cut-off by some POR or reset, then synchronous "assertion" resets are of no use. However, synchronous "de-assertion" ia always preferred. There was a similar forum discussion earlier (link posted below).. But, I don't know if there was any conclusion derived out of it. It would be good to revisit it & close it till conclusion. http://opencores.org/forum,OpenRISC,0,4586 with regards, pekon You are confusing two separate issues. You have to select whether your reset system is synchronous or asynchronous and then you have to select whether you use flipflops with synchronous or asynchronous style resets. Those two issues are completely independent. You may determine that you need an asynchronous reset system for the issues that you mentioned but you can still build it using flipflops that use synchronous resets. All that you have to do is to put a wrapper around your outputs that force those outputs into their reset state asynchronsly from the assertion of reset till the core is synchronously reset to that same value. You may think that you want to shut off your motors as soon as you can once you see an active reset but the reality is if you do that then you product will go out to lunch any time some one walks across a carpet and touches it. Every product that I have ever worked on has used analog filtering to ensure that only valid reset pulses will be recognized. It typically takes multiple clocks before you can determine that a reset pulse is valid and waiting one more is not going to make any difference. Asynchronous flipflop resets are a real problem in a modern asic core. They require special handling during scan testing and will double the number of end points in synthesys. They are really bad in fpgas where they can really affect your lut count. They made sense for the technologies that we had 30 years ago but not for what we have today. John Eaton

RE: Reset signal recommendation in the by pekon on Feb 24, 2012			pekon Posts: 29 Joined: Mar 6, 2009 Last seen: Dec 14, 2020
John, The technique of gating the output of sync-flop via reset signal is not always recommended, because of following reasons: (1) suppose some external event caused reset, but before whole data pipeline could be cleaned, the external event/reset gets de-asserted. This removes the internal gating from output of flop. Then garbage data present in internal pipeline stages will start propagating, and corrupting your output. You would see such problems, when there are multiple reset-domains in ur designs, getting derived from external world. (2) In some safety devices (like air-bag control, power-brakes) or industrial automation devices,(especially running from internal PLL), sanity of clock-source cannot be guaranteed, thus design needs to have asynchronous resetable flop. (3) if you put gating of reset-signal in front every flop, then you add more overhead on timing. You are more knowledgeable in this, than me.. so you understand the pains of meeting delays and timings. Therefore, following two issues MAY NOT be completely independent.. (1) sync-resetable system v/s async-resetable system (2) sync-reset flops v/s async-reset flops.. And similarly choice of "type of flop", along with "type of reset-strategy", is ALSO driven by architecture and use-cases, apart from technology constrains. with regards, pekon John, The technique of gating the output of sync-flop via reset signal is not always recommended, because of following reasons: (1) suppose some external event caused reset, but before whole data pipeline could be cleaned, the external event/reset gets de-asserted. This removes the internal gating from output of flop. Then garbage data present in internal pipeline stages will start propagating, and corrupting your output. You would see such problems, when there are multiple reset-domains in ur designs, getting derived from external world. (2) In some safety devices (like air-bag control, power-brakes) or industrial automation devices,(especially running from internal PLL), sanity of clock-source cannot be guaranteed, thus design needs to have asynchronous resetable flop. (3) if you put gating of reset-signal in front every flop, then you add more overhead on timing. You are more knowledgeable in this, than me.. so you understand the pains of meeting delays and timings. Therefore, following two issues MAY NOT be completely independent.. (1) sync-resetable system v/s async-resetable system (2) sync-reset flops v/s async-reset flops.. And similarly choice of "type of flop", along with "type of reset-strategy", is ALSO driven by architecture and use-cases, apart from technology constrains. with regards, pekon

RE: Reset signal recommendation in the by jt_eaton on Feb 24, 2012			jt_eaton Posts: 142 Joined: Aug 18, 2008 Last seen: Sep 29, 2018
[q]John, The technique of gating the output of sync-flop via reset signal is not always recommended, because of following reasons: (1) suppose some external event caused reset, but before whole data pipeline could be cleaned, the external event/reset gets de-asserted. This removes the internal gating from output of flop. Then garbage data present in internal pipeline stages will start propagating, and corrupting your output. You would see such problems, when there are multiple reset-domains in ur designs, getting derived from external world. ================================================================================== If your design needs a reset with a minimun length of X clock cycles and you drive it from a source that cannot meet this requirement then you are right , it is not going to work. Your reset system designer must first determine the minimum length for reset needed before you will accept it as a valid reset request. You then design a low pass filter that will reject anything shorter than this minimum as if it never occured. It is only then that you will reset the system. If that system needs a minimum number of clocks that the source cannot supply then the reset system designer has to add logic that will work even if the external source goes away. In other words add a internal reset generator counter. ================================================================================== (2) In some safety devices (like air-bag control, power-brakes) or industrial automation devices,(especially running from internal PLL), sanity of clock-source cannot be guaranteed, thus design needs to have asynchronous resetable flop. =================================================================================== Yes, you are right. You do have to have at least two asynchronous resetable flops to work properly. What I am saying is that you don't really need very many more than that and you certainly don't need every flopflip in the chip core with a asynchronous reset. Some reset designers are so determinded to reset every flop that they take the reset signal from a input pad and port it down through combinational logic into an asynchronous reset port on every flop. Thats what they did in the first Star Wars movie on the original death star. Some engineer was so determined that his emergency exhaust system functioned that he put a conduit straight down from the surface into the reactor core. (If you missed the movie that turned out to be a bad idea). The main purpose of the reset system is not to reset the chip when a reset trigger occurs, It is to not reset the chip when a reset trigger has not occured. Theres a big difference. BTW: The reason you need at least two flops is for metastable filtering on the reset signal. =================================================================================== (3) if you put gating of reset-signal in front every flop, then you add more overhead on timing. You are more knowledgeable in this, than me.. so you understand the pains of meeting delays and timings. =================================================================================== Do you know what a "sync-reset pragma" is? If you put reset in front of every flop, synthesise and then try running gate sims then they will not work. Synthesys will have combined the reset logic in with the other mission mode logic and it will no longer appear as a separate gate driving the D pin of a flop. It will be split up and distributed over the entire logic cone. Verilog starts will everything in a X state and even though the reset is asserted it will not be able to resolve that the next state is actually a known state. Your silicon will work fine but your sims wont. If you use a sync-reset pragma then you instruct the synthesys tool to preserve the reset gate so that sims will always run. Whats happening is that you are right, adding reset into the D pathway does slow down your logic. Synthesys will figure this out and fix it by pushing the reset function up the cone until it is no longer on any critical path. At this point reset does not slow down your logic at all. Anyone who uses the sync-reset pragma is detuning their design simply because they do not know how to use a simulator. This is voodoo engineering and we do not do that. The proper way to design a reset system is to only add logic as a last resort. You want to find some mission mode logic that already forces the output into the same state as reset and then piggyback the reset on top of that logic. =================================================================================== John Eaton [/q] John, The technique of gating the output of sync-flop via reset signal is not always recommended, because of following reasons: (1) suppose some external event caused reset, but before whole data pipeline could be cleaned, the external event/reset gets de-asserted. This removes the internal gating from output of flop. Then garbage data present in internal pipeline stages will start propagating, and corrupting your output. You would see such problems, when there are multiple reset-domains in ur designs, getting derived from external world. ================================================================================== If your design needs a reset with a minimun length of X clock cycles and you drive it from a source that cannot meet this requirement then you are right , it is not going to work. Your reset system designer must first determine the minimum length for reset needed before you will accept it as a valid reset request. You then design a low pass filter that will reject anything shorter than this minimum as if it never occured. It is only then that you will reset the system. If that system needs a minimum number of clocks that the source cannot supply then the reset system designer has to add logic that will work even if the external source goes away. In other words add a internal reset generator counter. ================================================================================== (2) In some safety devices (like air-bag control, power-brakes) or industrial automation devices,(especially running from internal PLL), sanity of clock-source cannot be guaranteed, thus design needs to have asynchronous resetable flop. =================================================================================== Yes, you are right. You do have to have at least two asynchronous resetable flops to work properly. What I am saying is that you don't really need very many more than that and you certainly don't need every flopflip in the chip core with a asynchronous reset. Some reset designers are so determinded to reset every flop that they take the reset signal from a input pad and port it down through combinational logic into an asynchronous reset port on every flop. Thats what they did in the first Star Wars movie on the original death star. Some engineer was so determined that his emergency exhaust system functioned that he put a conduit straight down from the surface into the reactor core. (If you missed the movie that turned out to be a bad idea). The main purpose of the reset system is not to reset the chip when a reset trigger occurs, It is to not reset the chip when a reset trigger has not occured. Theres a big difference. BTW: The reason you need at least two flops is for metastable filtering on the reset signal. =================================================================================== (3) if you put gating of reset-signal in front every flop, then you add more overhead on timing. You are more knowledgeable in this, than me.. so you understand the pains of meeting delays and timings. =================================================================================== Do you know what a "sync-reset pragma" is? If you put reset in front of every flop, synthesise and then try running gate sims then they will not work. Synthesys will have combined the reset logic in with the other mission mode logic and it will no longer appear as a separate gate driving the D pin of a flop. It will be split up and distributed over the entire logic cone. Verilog starts will everything in a X state and even though the reset is asserted it will not be able to resolve that the next state is actually a known state. Your silicon will work fine but your sims wont. If you use a sync-reset pragma then you instruct the synthesys tool to preserve the reset gate so that sims will always run. Whats happening is that you are right, adding reset into the D pathway does slow down your logic. Synthesys will figure this out and fix it by pushing the reset function up the cone until it is no longer on any critical path. At this point reset does not slow down your logic at all. Anyone who uses the sync-reset pragma is detuning their design simply because they do not know how to use a simulator. This is voodoo engineering and we do not do that. The proper way to design a reset system is to only add logic as a last resort. You want to find some mission mode logic that already forces the output into the same state as reset and then piggyback the reset on top of that logic. =================================================================================== John Eaton

RE: Reset signal recommendation in the by pekon on Feb 24, 2012			pekon Posts: 29 Joined: Mar 6, 2009 Last seen: Dec 14, 2020
Thanks for educating me about "sync-reset pragma", this was not know to me, im do not have much depth into physical-design point-of-view.. (1) This topic has brought out some good point/guidelines. please try to consolidate all ideas into some PPT, and share over this forum, I'll try the same.. (2) Also, in previous discussion i had raised a approach, would like to feedback from everyone about same, and whether it is doable in current context of or1200 RTL. Please check the last post on http://opencores.org/forum,OpenRISC,0,4586 [q] So, I propose one more implementation format, which will serve both purpose (reduce area hit + no need of wrappers) (1) Use async reset flops for all registered outputs, and last flops on combo outputs or design. (2) Use sync reset flops for any paths which are internal to design. [/q] with regards, pekon Thanks for educating me about "sync-reset pragma", this was not know to me, im do not have much depth into physical-design point-of-view.. (1) This topic has brought out some good point/guidelines. please try to consolidate all ideas into some PPT, and share over this forum, I'll try the same.. (2) Also, in previous discussion i had raised a approach, would like to feedback from everyone about same, and whether it is doable in current context of or1200 RTL. Please check the last post on http://opencores.org/forum,OpenRISC,0,4586 So, I propose one more implementation format, which will serve both purpose (reduce area hit + no need of wrappers) (1) Use async reset flops for all registered outputs, and last flops on combo outputs or design. (2) Use sync reset flops for any paths which are internal to design. with regards, pekon

RE: Reset signal recommendation in the by jt_eaton on Feb 25, 2012			jt_eaton Posts: 142 Joined: Aug 18, 2008 Last seen: Sep 29, 2018
[q] So, I propose one more implementation format, which will serve both purpose (reduce area hit + no need of wrappers) (1) Use async reset flops for all registered outputs, and last flops on combo outputs or design. (2) Use sync reset flops for any paths which are internal to design. [/q] This requires that you know what the output ports are for your design. You might think that these are all the ports driving a pad so you build them using asnc flops. Well in 5 years some body is going to redesign your product and consolidate three IC designs into one. Your outputs are now internal to this new design. You don't want the new designers to have to muck with your code and replace your async flops with sync ones. You should design all core logic with 100% sync resets and let your pad ring tool handle adding the reset wrapper and in some cases registering the data at the pad. That will make your module reusable no matter how big the chip gets. John Eaton So, I propose one more implementation format, which will serve both purpose (reduce area hit + no need of wrappers) (1) Use async reset flops for all registered outputs, and last flops on combo outputs or design. (2) Use sync reset flops for any paths which are internal to design. This requires that you know what the output ports are for your design. You might think that these are all the ports driving a pad so you build them using asnc flops. Well in 5 years some body is going to redesign your product and consolidate three IC designs into one. Your outputs are now internal to this new design. You don't want the new designers to have to muck with your code and replace your async flops with sync ones. You should design all core logic with 100% sync resets and let your pad ring tool handle adding the reset wrapper and in some cases registering the data at the pad. That will make your module reusable no matter how big the chip gets. John Eaton

no use

no use

1/1

no use

no use

© copyright 1999-2025 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.