Up to 64 SDL instances, each can be enabled or disabled individually.
Each SDL instance can have a state machine with up to 64 states.
Each SDL instance has two auto decrementing 40 bits counters, each controlled independently.
There can be no more than 8 expressions (or IF statements) in each state.
In emulation modes that enable stopping the clocks, the emulator clock will pause if the buffer becomes full before the workstation has a chance to read it. In LA or Dynamic Target mode, if the rate of writing into the buffer is higher than the rate at which the workstation reads it, then some messages are lost.
The total number of different arguments (, , ...) that can be used in all DISPLAY statements depends on the width of the display buffer in the hardware. The width of the display buffer can be increased at compile time using compiler option sdlDisplayWidth.
SDL has an inherent limit on the maximal number of IF statements in each state, which is mostly unrelated to how these IF statements are nested. The limit depends on the presence of counter conditions in the expressions inside the IF statements. Without counter conditions, the rule is simple: there can be no more than 8 expressions (or IF statements) in each state. There is no limit on the number of expressions constructed exclusively of counter conditions. If an expression contains both counter conditions and signal names, the SDL compiler tries to convert the expression into several sub-expressions that are either counter conditions, or expressions based on signal names. The resulting number of sub-expressions based only on signal names add up towards the maximal limit of 8. These restrictions do not apply to IF statements in the global or instance definition sections, and it also does not apply to IF statements that do not control directly any actions. Example:
IF (exp1) {
IF(exp2) { GOTO nxt; increment counter1;}
}
In the above example, IF(exp1) does not control any action directly, therefore exp1 is not counted towards the maximum of 8 expressions.
Messages from DISPLAY statements are buffered in the memory of the emulator. While the emulator is running, the buffer contents are dumped into the workstation several times each second, formatted and sent to the console and/or a file. In emulation modes that enable stopping the clocks, the emulator clock will pause if the buffer becomes full before the workstation has a chance to read it. In LA or Dynamic Target mode, if the rate of writing into the buffer is higher than the rate at which the workstation reads it, then some messages are lost. This is called an overflow condition. You can increase the depth of the buffer during compilation using compiler option sdlDisplayDepth to address the overflow issue. The total number of different arguments (, , ...) that can be used in all DISPLAY statements depends on the width of the display buffer in the hardware. If the same signal appears as an argument in more than one DISPLAY statement in the SDL program, that signal is counted only once for the purpose of calculating the required buffer width. The width of the display buffer can be increased at compile time using compiler option sdlDisplayWidth.
- Both of them needs HW resource, which can be increased at backend compile phase
- DRTL doesn't have obvious limitation on state and expression.
- The user could define their counter with verilog in DRTL.
- Currently, DRTL has the same limitation of the total bit number in $DISPLAY, which can be increased by the compiler option sdlDisplayWidth.
- DRTL can be enhanced continuely, so it will have better features in future.