What is compile in Verilog? - verilog

I'm newbie on Verilog.
In C Programming, build process are roughly as
- preprocessing - compile - assemble - linking
In Verilog, (BOOK : Verilog HDL: A guide to Digital Design and Synthesis), there is described Verilog development and build process are ...
- Design ( and simulation ) - Synthesis (elaboration, apply constraints and so on) - Verification
I think terms "synthesis" is most similar to compile.
But, "Verilog HDL: A guide to Digital Design and Synthesis" describes 'Compiler'(i.e., Compiler directive, `define, `ifdef, etc.)
Compile in Verilog means only for simulation target ?

You're comparing a C build process to elements of the engineering process of a Verilog project, so the terminology isn't going to match up. If you look at just the Verilog build process, it still won't necessarily match because it's quite different. Maybe you could view synthesis as analogous to compiling, mapping to assembling, and linking to placement and routing. But whether that analogy is useful depends on what exactly your goal is with this comparison.

I think you are confusing entirely different concepts. The Design, Synthesis, and Verification are stages representing different points in chronological time of a project. Those steps share a common source description, in this case Verilog HDL.
The compile step is part of a tool's process of reading that source HDL into a form that the tool can act upon. Both simulation and synthesis tool go through the compilation process which create an internal data structure most suitable to the task.

Related

How to synthesis Rocket-Chip on Vivado?

I am trying to synthesis Rocket-Chip on Vivado. I was able to run a simulation on Vivado and get the required results. But, when I synthesis the same design and run the post synthesis simulation I dont get the same results. I used the 2 files generated after running 'make verilog' in vsim directory. For synthesis I defined the variable 'SYNTHESIS'. What are the things I might me missing go get appropriate results?
You should generate Verilog output first, incorporate it into your system or SoC and then pass it to Vivado as usual

Is it possible to fully compile a module and then instantiate it in a testbench separately?

Is it possible to make a fully compiled and standalone version of an RTL module, like a snapshot in Cadence terms, and then later instantiate this compiled module into a testbench?
Ultimately, running another compile step to create a final snapshot which contains the originally delivered snapshot but now instantiated in the testbench.
If so, are there any special considerations when compiling the original snapshot to enable this and how would you instantiate such a compiled object within a testbench?
Yes. But every simulation tool has slightly different approaches to the compilation flow. Most tools break this flow into a number steps: parsing, optimization, elaboration, and initialization (the snapshot you mention is the last step). Not all tools give you access to all the individual steps.
There are several ways to achieve what you ask for, but the choice really depends on why you want to do this, and what limitations you are willing to work with.
You can parse your module's source code into a library and then re-use that same library for compiling many different test benches. But usually the time consuming part is optimization.
Questa provides what you are looking for in what they call the Pre-compiled Design Unit (PDU) flow. You can optimize your RTL module and save it back into a library, and Questa simply choses the optimized module instead of the un-optimized module during elaboration. The special considerations are that you need to preserve any signals from optimization that might have hierarchical references from the testbench.

Query regarding fsim verilog versus Zedboard verilog code of Rocket core

Could someone help explain what the differences are between the verilog code generated from the fsim directory of the rocket core (Top.DefaultFPGAConfig.v, using the default conf files provided) and the verilog code in the Zedboard folder (Top.DefaultFPGAConfig.v)? They are more or less of the same size, and look similar apart from a few changes which i couldnt quite understand the reason behind..
I am trying to synthesize it on a virtex 7 FPGA and not a Zynq based board, but just wanted help to understand what was different between the two sources for my knowledge.
Also, has anyone synthesized the fsim verilog code and run it with the testbench on an FPGA (non-Zynq based)?
The verilog included in the fpga-zynq repo should be the same as what the same config would produce inside fsim within rocket-chip because that is how it was generated. It is possible that if you use a newer version of chisel or rocket-chip to regenerate the verilog, you will get slightly different verilog. This is just a case of not committing to fpga-zynq as often as chisel itself is updated. Some of the updates to chisel tweak its internal passes, so it sometimes results in slightly different verilog output.
We have not tested the verilog on non-Zynq FPGAs. The verilog itself isn't that specialized, so I would expect most of the pain for getting it onto a Virtex 7 would be interfacing with it. I would definitely take a look at rocketchip_wrapper.v to get a feel for the external connections rocket-chip expects.

What SystemVerilog features should be avoided in synthesis?

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.

verilog modelsim fpga

Sorry for Newbish question.
I am trying to learn about FPGA programming.
Before I spend $1K on a FPGA board:
if I just want to learn Verilog, can I run it entirely in Modelsim? (I realize there are some timing issues that only show up in actual chips; but for learning syntax / style of coding / ...)_
Thanks!
You can of course!
However, there are a few things that a simulator will let you away with that the FPGA compiler will not. Have a $FAVOURITE_SEARCH_ENGINE around for keywords like verilog coding styles synthesis.
See Resources for learning Verilog for some info on the differences between HDL programming and computer programming.
You most definitely don't need to splashout on a dev board if you are happy with just learning the language and simulating the results.
You can get the free Xilinx ISE Webpack which includes a basic version of ModelSim.
As you have mentioned simulation and testbenching is one aspect of FPGA design. Actually getting a design to work on real hardware is usually the more challenging part. However, just using software you can learn the language, get to grips with simulation and even synthesize your design to make sure it will meet timing and fit on a target device.
I would also suggest that $1K for your first dev board is quite high. I would start with something like the low-cost Xilinx Spartan-6 board, which is a tad under $300. You'll get a device with a decent amount of logic, memory and DSP slices for that.
If you're trying to learn Verilog there's no need to actually get an FPGA board (though, you can get FPGA development boards for much less than $1000 - you can get Xilinx's kit for $100). You can and should first learn Verilog using a simulator, though if you don't want to spend anything I'd suggest Icarus Verilog which is free (Open Source).
We had a hardware systems course in which some FPGA programming was done using VHDL. I downloaded ModelSim-Altera Software (starter edition available here)
We had FPGA boards in our lab, so it was easy to actually see your model behave. In your case, I would suggest:
Start modeling basic circuits like adder, decoders etc. In ModelSim you can also create and configure(characteristics like frequency of different signals) a test bench to verify (using timing diagrams) your model.
Once you are confident with the syntax and modeling, you can look for a lab around you which will allow you to get your hands dirty.
I hope this helps.
cheers
As others have noted, a simulator will get you a long way. There's nothing quite like flashing some real LEDs on and off though - wiggly waveforms on a screen just aren't the same :)
Many of the starter kits have VGA outputs so you can display your own pictures, which is always gratifying (I've found anyway!) $1000 is a lot to spend, try this Xilinx starter kit for $189 (which does have VGA), or this Altera starter kit (which doesn't).
Everyone above is right. However there is a synthesizable subset of Verilog and VDHL that can be used for actual hardware. For example $display can't be used. Recursion may be supported in some tools, as #Chiggs pointed out below. Keep that in mind when writing your code if it will ever be used in a chip. However the full language can be used in test benches.
No one mentioned www.edaplayground.com to learn SystemVerilog and/or VHDL. 100% free versions of the industry standard tools for simulation from the major vendors. Runs in the cloud. Nothing to download. Need email to register. Don't put your employers code up there; its on someone else's computer. There are example designs on the edaplaygroud site itself. Other sites have code examples that run on edaplayground, so you can run their code examples as a learning lesson by clicking one button. A list of verilog examples here: https://verificationguide.com/verilog-examples/
As others have stated there are aspects of FPGA & ASIC design that you will not learn in the simulation flow, specifically those related physical implementation but you can learn a lot from this approach, and it is very low cost (they want your email).
That being said edaplaygroud also has a synthesis tool.

Resources