What is basic purpose of a layered testbench for verification when we can write all functionality in simple one program block. I know reusability is one purpose but what apart from it makes unique.
It depends on how big is your design. If your design is very small, one program block probably works fine. (BTW, I strongly discourage the use of program block, use a top module instead. There are known issues in thread scheduling with program block in big 3 EDA's simulators)
However if you are design is huge and you have to test it by divide any conquer, then you have to build your testbench in layers that matches the division of labor. If you don't layer your testbench probably, you will not able to reuse your block level code in the system level environment.
Related
I know that Verilog has an arithmetic add operator. If I'm building an adder, should I make my own or use that? Which will perform better in my processor?
For simulation, the add operator will behave according to the standard and should be fine to use unless you have a reason to simulate a specific adder implementation.
For synthesis, what you get depends on your synthesis tool and final hardware platform. For example, FPGAs usually have dedicated logic for adds and using the Verilog add operator should take advantage of that automatically.
If you need extreme performance on your hardware, it's possible you could do better by using the available primitives directly. Though add is a very common operation and synthesis should be able to handle it well for most use cases.
I am wondering how it SMT/HyperThreading being added to a Verilog HDL design?
The planned design(something similar):
http://www.fpga4student.com/2017/01/verilog-code-for-single-cycle-MIPS-processor.html
I am wondering, is there any special kind of syntax to add the SMT function, and if so, where?
I haven't tried anything so far, because I don't know where to start and google doesn't help!
Thanks!
You're not just adding Hyper-Threading "functions". You design your cpu in a way that allows simultaneous execution of multiple instructions on multiple/independent execution units. Typically that means pipelined design, which is not the case for single-cycle processor.
For processors as simple as that single-cycle, it's easier to instantiate multiple CPUs (SMP) and design a way to share resources (memory, peripherals, etc).
I know that that when you make multiple instances of a module, separate hardware is created for each instance. But what about functions. What exactly happens when I call the same function from different parts of a code?
Synthesizable verilog functions will be inferred to a combinational circuit usually as a series of multiplexers.
Basically, the function will be 'inlined' each time it is called. What happens afterwards is up to the synthesis software. It is possible that some of these instances will be redundant and will be removed. It is possible that some that are not entirely redundant can be combined by inserting multiplexers. Logic path length, complexity, timing requirements, etc. will all affect the result.
This sort of optimization can take place across modules. Synthesizers can be very good about removing or even duplicating logic as necessary to reduce the overall size and to meet timing constraints.
Say I have a vehicle model, the chassis will be used as a master FMU, its engine, transmission, tires, etc are from 3rd parties and I want to used them as slave FMUs. I want to parallel the model in this way, the master FMU is put on the main thread, and fork everything else on other threads.
I want to know if this simple idea is achievable by using FMUs exported from Dymola...
If possible, is it worthwhile doing it? I wander if the parallel model is as efficient as as a sequential one at the physics level. (I understand that a badly paralleled program is slower than a sequential one, but I just need to know if it is physically slower or faster)
The latest Dymola has built in the openMP features, has anyone ever used it? What does it look like?
I found a paper about this: Master for Co-Simulation Using FMI http://www.ep.liu.se/ecp/063/014/ecp11063014.pdf
I think it can make perfect sense to launch several FMU in parallel if they can do their job separately. What is difficult in co-simulation is to understand when the simulators must be synchronized (for instance to exchange information). These synchronization should be minimal to increase efficiency but enough to avoid track back the simulator states (when possible). Also, it has chance to work when you have causal relations between your FMUs. If you have acausal relations, this is a different story...
technically, I would say:
for 1), you can always launch a FMU in a thread if you want, no problem with that
for 2), it mainly depends on the number and frequency of the synchronizations required between the different FMUs
for 3) I do not know but I think you should distinguish between launching different FMU in parallel and making one FMU parallel...
my two cents
SystemVerilog introduced some very useful constructs to improve coding style. However, as one of my coworkers always says, "You are not writing software, you are describing hardware." With that in mind, what features of the language should be avoided when the end result needs to be synthesized? This paper shows what features are currently synthesizable by the Synopsys tools, but to be safe I think one should only use the features that are synthesizable by all of the major vendors. Also, what constructs will produce strange results in the netlist which will be difficult to follow in an ECO?
In summary: I like compact and easy to maintain code, but not if it causes issues in the back end. What should I avoid?
Edit: In response to the close vote I want to try to make this a bit more specific. This question was inspired by this answer. I am a big fan of using the 'sugar' as Dave calls it to reduce the code complexity, but not if some synthesis tools are going to mangle signal names and make the result difficult to deal with. I am looking for more examples like this.
Theoretically, if you can write software that is synthesized into machine code to run on a piece of hardware, that software can be synthesized into hardware. And conversely, there are hardware constructs in Verilog-1995 that are not considered synthesizable simply because none of the major vendors ever got around to supporting it (e.g. assign/deassign). We still have people using //synopsis translate on/off because it took so long for them to support `ifdef SYNOPSYS.
Most of what I consider to be safe for synthesis in SystemVerilog is what I call syntactic sugar for Verilog. This is just more convenient ways of writing the same Verilog code with a lot less typing. Examples would be:
data types: typedef, struct, enum, int, byte
use of those types as ports, arguments and function return values
assignment operators: ++ -- +=
type casting and bit-streaming
packages
interfaces
port connection shortcuts
defaults for function/tasks/macro arguments, and port connections
Most of the constructs that fall into this category are taken from C and don't really change how the code gets synthesized. It's just more convenient to define and reference signals.
The place it gets difficult to synthesize is where there is dynamically allocated storage. This would be class objects, queues, dynamic arrays, and strings. as well as dynamically created processes with fork/join.
I think some people have a misconception about SystemVerilog thinking it is only for Verification when in fact the first version of the standard was the synthesizable subset, and Intel was one of the first users of it as a language for Design.
SystemVerilog(SV) can be used both as a HDL (Hardware Description Language) and HVL (Hardware Verification Language) and that is why it is often termed an "HDVL".
There are several interesting design constructs in SV which are synthesizable and can be used instead instead of older Verilog constructs, which are helpful in optimizing code and achieving faster results.
enum of SV vs parameter of Verilog while modelling FSM.
Use of logic instead of reg and wire.
Use of always_ff, always_comb, always_latch in place of
single always blocks in Verilog.
Use of the unique and priority statements instead of Verilog's
full and parallel case statements.
Wide range of data types available in SV.
Now what I have discussed above are those constructs of SystemVerilog which are used in RTL design.
But, the constructs which are used in the Verification Environment are non-synthesizable. They are as follows:
Dynamic arrays and associative arrays.
Program Blocks and Clocking blocks.
Mailboxes
Semaphores
Classes and all their related features.
Tasks
Chandle data types.
Queues.
Constrained random features.
Delay, wait, and event control statements.