I recently attempted to use an SV class with parameters. Simple parameters seem to work fine. You can templatize a class based on type or size. But that's about all you can do.
The limitations of how parameters work within a class are disappointing. As you may be aware, a parameter in a module or interface allows you the flexibility of generating different code for different parameter values. But as another example of the lack of uniformity throughout SystemVerilog they chose to not allow generate statements in a class. So the paramters look the same, but they can't be used the same way.
Another disappointment.
Saturday, February 4, 2012
Saturday, January 21, 2012
SystemVerilog, Cadence, Exporting a module task
I have recently been writing a lot of verification code with Cadence's tools. I use Incisive for RTL simulations. After using the tools for a while there are definitely limitations that are frustrating. But overall, the tools are very stable and support a large portion of SV, and support it really well. Kudos to Cadence for giving decent error messages on most occasions. That is really a huge plus even if the error is SV legal, but not yet supported.
Tip for calling tasks from a module using SV with Cadence's Incisive:
There are 2 ways, without using Verilog standard probing, to access tasks from within a module.
1. Create an interface. Declare a modport for the module with an exported task. Let the module define the exported task.
Cadence doesn't support this yet.
2. Create a class with the desired task declaration. Extend that class from within the module. Output an instance of the extended class for use elsewhere.
This method works fine with Cadence's tools.
Most people are satisfied with probing. In a small testbench, probing works OK. But when creating a large testbench with many identical modules (or modules with similar functionality), it is much nicer to have an array of class instances to work with. They lend themselves to more modular test designs.
About: System Verilog, Cadence Incisive, ncsim, ncvlog, export task, extends, exported tasks, extended classes, inherited classes, inheritance
Tip for calling tasks from a module using SV with Cadence's Incisive:
There are 2 ways, without using Verilog standard probing, to access tasks from within a module.
1. Create an interface. Declare a modport for the module with an exported task. Let the module define the exported task.
Cadence doesn't support this yet.
2. Create a class with the desired task declaration. Extend that class from within the module. Output an instance of the extended class for use elsewhere.
This method works fine with Cadence's tools.
Most people are satisfied with probing. In a small testbench, probing works OK. But when creating a large testbench with many identical modules (or modules with similar functionality), it is much nicer to have an array of class instances to work with. They lend themselves to more modular test designs.
About: System Verilog, Cadence Incisive, ncsim, ncvlog, export task, extends, exported tasks, extended classes, inherited classes, inheritance
Saturday, December 31, 2011
Rant about SystemVerilog
Why does SystemVerilog need so many constructs? There is too much overlap.
An interface could almost be a module if you don't need any module instantiations inside. A task or function can exist in classes, interfaces, or modules. Which should they exist in? Call a task from a module or use an interface to control the IOs of the interface? Output an inherited class from the module and call the class' tasks? Use a typed or untyped mailbox? How about using nested classes? Should they be nested or just in a hidden package? Classes in packages or classes at the top-level with include files? What sounds right to you?
An interface could almost be a module if you don't need any module instantiations inside. A task or function can exist in classes, interfaces, or modules. Which should they exist in? Call a task from a module or use an interface to control the IOs of the interface? Output an inherited class from the module and call the class' tasks? Use a typed or untyped mailbox? How about using nested classes? Should they be nested or just in a hidden package? Classes in packages or classes at the top-level with include files? What sounds right to you?
Friday, October 14, 2011
Remote desktop & tscon
tscon is the most useful little command that I only recently learned about. It allows you to switch a remote desktop session back to the local console.
I use this to log onto my compute remotely and then switch it back to console when I'm done.
I also used this to get around a FlexLM requirement that wouldn't let me open an application while I was logged on remotely. I wrote a short script that switched back to console and then opened the application. Once I logged back on remotely, the application was open.
anyhow use this:
tscon rdp-tcp#0 /dest:console
If this doesn't work, use:
query session
and then use the rdp session as listed there.
This will switch the desktop back to the console.
I use this to log onto my compute remotely and then switch it back to console when I'm done.
I also used this to get around a FlexLM requirement that wouldn't let me open an application while I was logged on remotely. I wrote a short script that switched back to console and then opened the application. Once I logged back on remotely, the application was open.
anyhow use this:
tscon rdp-tcp#0 /dest:console
If this doesn't work, use:
query session
and then use the rdp session as listed there.
This will switch the desktop back to the console.
Wednesday, August 31, 2011
Actel and Libero IDE
I have been using the SmartFusion FPGA for a while now. The advantage is a built-in Cortex M3. the disadvantage is Actel and their tools.
Actel has violated a rule in design. They over-engineered Libero IDE. Libero attempts to automate constraints. Here-in lies one class of problems.
Libero determines all of your clock constraints from the MSS setup. Those constraints are then hard wired into the Designer project. There is no pdc file to edit for the clock constraints. These constraints can't be edited using Designer's constraint editor because the automatic constraints are read-only.
Why is this bad?
Libero has a bug where it sets the constraint incorrectly if you set the divider of GLx to a non power of 2. Divide GLA by 3 and the constraint is set as if it was divided by 2.
In general, over-engineering complicates both users' and developers' lives. I am referring to customers as the users and the Actel employed programmers as the developers. Over engineering creates for confusion as nothing is intuitive anymore. It also opens the door to many more bugs.
Xilinx is an example of a high quality company that doesn't over-engineer (from what I recall). Their tools are not great, but they leave all of the configuration in your hands. Even if they tried to automate something, they still let you override whatever it is.
Another frustrating problem is how Libero splits constraints into 2 places. I recently configured an MSS I/O to route to the FPGA. I did this because I needed Schmitt Triggers. What is overly confusing is how the default constraints file located under component/work//.pdc is no longer the file for these constraints. What is even more strange is that if you edit that pdc file in the I/O Attribute Editor, you see the MSS I/Os and they offer to enable Schmitt Triggers. Why is that bad? Because they don't work! The moment you attempt to compile in Designer, you get a strange error message telling you how you can't modify these IO settings!
The solution? Under the MSS configurator there is a middle tab for I/O Attributes. Use that tab. That's not all folks! Now you must add a new pdc file to the Designer project. I imagine that if you hit the Designer button in Libero it will add the new pdc file to the Designer project, but as I rarely hit that button, b/c Designer is already open, I can't say whether this is true. But not only must you add this file, you must also remove any reference to the incorrectly placed constraints from the original pdc file. The MSS I/Os must only appear under the MSS pdc file.
Folks at Actel seem to have forgotten what simple and intuitive means. They should refresh their memory.
Actel has violated a rule in design. They over-engineered Libero IDE. Libero attempts to automate constraints. Here-in lies one class of problems.
Libero determines all of your clock constraints from the MSS setup. Those constraints are then hard wired into the Designer project. There is no pdc file to edit for the clock constraints. These constraints can't be edited using Designer's constraint editor because the automatic constraints are read-only.
Why is this bad?
Libero has a bug where it sets the constraint incorrectly if you set the divider of GLx to a non power of 2. Divide GLA by 3 and the constraint is set as if it was divided by 2.
In general, over-engineering complicates both users' and developers' lives. I am referring to customers as the users and the Actel employed programmers as the developers. Over engineering creates for confusion as nothing is intuitive anymore. It also opens the door to many more bugs.
Xilinx is an example of a high quality company that doesn't over-engineer (from what I recall). Their tools are not great, but they leave all of the configuration in your hands. Even if they tried to automate something, they still let you override whatever it is.
Another frustrating problem is how Libero splits constraints into 2 places. I recently configured an MSS I/O to route to the FPGA. I did this because I needed Schmitt Triggers. What is overly confusing is how the default constraints file located under component/work/
The solution? Under the MSS configurator there is a middle tab for I/O Attributes. Use that tab. That's not all folks! Now you must add a new pdc file to the Designer project. I imagine that if you hit the Designer button in Libero it will add the new pdc file to the Designer project, but as I rarely hit that button, b/c Designer is already open, I can't say whether this is true. But not only must you add this file, you must also remove any reference to the incorrectly placed constraints from the original pdc file. The MSS I/Os must only appear under the MSS pdc file.
Folks at Actel seem to have forgotten what simple and intuitive means. They should refresh their memory.
Tuesday, June 14, 2011
More on metastability
I spoke with the layout guy today, and I've once again had to re-evaluate my understanding. Seems like gates don't propagate metastability. Since gates are railed to VCC and GND, and they don't have internal feedback like flip-flops, metastability is unlikely to propagate through them. This includes regular gates, and buffers, and I'm sure other stuff too.
This means that metastable oscillation is pretty unlikely. Unless of course the output of one flip flop is tied back to its input without going through buffers, or gates.
I guess the only likely issue with metastable flops is the uncertainty of the output. Oh well. I'd still be careful.
This means that metastable oscillation is pretty unlikely. Unless of course the output of one flip flop is tied back to its input without going through buffers, or gates.
I guess the only likely issue with metastable flops is the uncertainty of the output. Oh well. I'd still be careful.
Sunday, June 12, 2011
Metastability - what logic and research has led me to believe
A long time ago I began learning about hardware design. This was at a time when I was primarily doing software development. Without formal training, I was relying on the explanations of others, logic, and experimentation. It has been years, and I've advanced quite a ways.
When I started designing, the ideas of synchronization were explained to me. Always double or triple sample signals from external sources, or from other clock domains. As it was explained to me, each flop reduced the chances of metastability by a very large factor. 2 samples were considered enough to lower the chances of metastaibility to almost nothing. 3 flops were even better.
As I got more experience, I got used to only using 2 flops to move between clock domains, or to bring an external signal in. But what was really going on?
There are 2 reasons for synchronization flops.
1. Metastable oscillation. This requires an explanation of metastability.
Metastability is a state whereby a flip-flop will sample an input signal on a clock edge, but the input signal is in a state of transition. This is a common situation when sampling from another clock domain or from an external signal. When a flip-flop samples an input signal that is not stable high or stable low, the flip-flop's output is undefined. Suffice it to say that an undefined output means that the output does not rise or fall as would be expected. The output wavers and takes a while to settle in one state or another.
A metastable flop will settle after a while. The assumed time it takes for a metastable flop to settle is a complete clock period. While a flop-flop is metastable, any flop sampling the metastable flop's output could also go metastable.
A second synchronization flop guarantees a full clock period of time for the output of the first metastable synchronization flop to settle and arrive at the second synchronization flop. As a rule of synchronization, there can be no combinatorial logic between the first and second flops.
Metastable oscillations can occur if there is a path whereby metastability can loop around. This can occur with a single flop, or with a sequence of flops. The simplest example of metastable oscillation can be with one flop. A single flop whose input comes from a mux that has a select signal to choose between an external signal and the flop's own output is prone to metastable oscillation. The flop can be used to sample an input signal, and then hold that value using the select of the input mux. But since the output of this flop is driven back to it's input using a mux, there may not be enough time for the output to settle before it is sampled back into itself.
2. Indeterminate input. When an output from another clock domain or an external signal is input into multiple flops at the same time, there is no guarantee that each flop will settle with the same input value. There are also the risks of metastability propagating through the sampling flops.
Subscribe to:
Posts (Atom)