Hi everyone,

STEPS TO LOGIN TO UNIX ACCOUNT:

1. Go to Cadence LAB E289 or E291.

2. Login id:XXXXXXXXX@sjsuad.sjsu.edu
XXXXXXXXX is a SJSU ID for example: 010123456@sjsuad.sjsu.edu
The password is the one you use to login in SJSU PeopleSoft or Canvas.
3. Cancel Prompts if any and you should be able to see blue screen fedora OS Desktop.
4. If you are not able to login try different PCs and repeat above steps. If you are still not able to
login email me your details ID and name during so that I can forward it to admin.
For further assistance on anything related to the subject, You may contact me during my office hours or
send me an email on priyansh.bhimani@sjsu.edu. Thank you.

Office Hours:
Tuesday & Thursday
16:00 to 18:00
ROOM E289/E291

Thanks,
Priyansh Bhimani

STEPS TO REMOTE ACCESS LAB:

1. Download Cisco Anyconnect SMC Software using http://its.sjsu.edu/services/internet-
connectivity/vpn/ (Links to an external site.)Links to an external site. and install it.
2. Open Cisco Anyconnect SMC and put "vpn.sjsu.edu" and connect to VPN.
3. It will ask for your user id and password. Put your SJSU id for example 010123456 and Password is
the one you use to login in SJSU PeopleSoft or Canvas.
3. Once you successfully connect to VPN, open Remote Desktop Connection from start menu on your
Windows PC.
4. Put "coe-ee-cad##.sjsuad.sjsu.edu". Here ## is a PC ID put any number ranging from 27 to 50.
5. In Remote Desktop Connection go to Show Options, click on Display tab. Set Display
Configuration to 1024 by 768 pixels and colors to True colors (24 bits).
6. press CONNECT. The numbers of users are limited to a particular system. Change the PC number
in step-4 if you fail to connect.
7. It will ask for your user id and password again. Put you SJSU id for example
010123456 and Password is the one you use to login in SJSU PeopleSoft or Canvas.
8. Cancel Prompts if any and you should be able to see blue screen fedora OS Desktop.

STEPS TO RUN VERILOG CODE SIMULATION AND SYNTHESIS:

1. Open terminal and enter following command "csh"
2. To further set up an environment use following command:
" source /apps/design_environment.csh "
3. type " which vcs "
you should get " /apps/synopsys/I-2014.03-2/bin/vcs "
which means that your environment is now set.
4. Do steps 1 & 2 every time you move from bash to csh.

5. Create your Verilog files using gvim or gedit and save it. compile your design files using " vcs +v2k
design.v testbench.v "
6. simulate using " ./simv "
7. synthesize using " dc_shell -xg -f synthesis.script | tee synres.txt "
8. post-simulate using " ncverilog -y /apps/toshiba/sjsu/verilog/tc240c +libext+.tsbvlibp +access+r
testbench.v design_netlist.v "

For further assistance regarding the subject, You can meet me during my office hours or email me your
doubts.

Office Hours:
Tuesday & Thursday
17:00 to 19:00
LAB 289/291
Links to an external site.
Thanks,
Priyansh Bhimani
(669)-225-8937

ISSUE: COPY FILES TO AND FROM LOCAL PC TO SERVER

SOLUTION:
USE WINSCP SOFTWARE
Here is a link:
https://winscp.net/eng/download.php (Links to an external site.)Links to an external site.
You can simply connect to host coe-ee-cad##.sjsuad.sjsu.edu, using port number 22, SJSU ID as a
Username and password is SJSUOne password. Change File protocol field to SCP and hit connect. You
can directly drag and copy files to and from host PC.
NOTE:
## is a LAB PC number as mentioned in the previous announcement.

I have attached a screenshot of WinSCP Software for your reference here.

Regards,
Priyansh Bhiman
Hi everyone,
I am listing some common mistakes I find in project codes. Make sure you avoid them in your HDL
coding.

1. Inside always block on the left-hand side never use wire. Only assign values to reg inside always
block.
Eg. Consider this
reg [3:0] answer_reg;
always @* begin
answer_reg = a + c;
end
OR
wire [3:0] answer_wire;
assign answer_wire = a + c;

2. Never use the same reg on both sides (Left & Right) inside always @ (*) block.
WRONG WAY: This will lead simulator to race as right side count+1 updates the left side count value
which triggers the * block again and keeps going. It will result in infinite loop and simulation stuck.
always @ (*)
begin
if (pushin)
count = count +1;
if (count)
$display("Hi");
end

THIS IS CORRECT WAY TO USE COUNTER:

always @ (*)
begin
count_d=count; // This part work as a else part for if (pushin1), important to make sure no latches
created
if(pushin1) begin
count_d= count+1;
end
if (count)
$display("Hi");
end
always @ (posedge clock)
begin
count <= #1 count_d;
end
3. Always write $finish statement in your testbench if you are dumping signals on .vcd or .vpd file.
This is good practice as sometimes your simulator races as I discussed in above example. It creates a
massive database for your waveform file and blocks all allocated memory resources given to you. You
may result in disk quota exceed if you are not careful. Always write $finish statement in the testbench.

4. Never use reg on left side in assign statement. You can only use wire for assigning values using
assign statement which results in a combinational logic for your wire.

5. Use always @ (*) block for combinational logic and use blocking statements in always @ (*)
blocks. Use always @ (posedge clock) for sequential part of the design (Flip-Flop) with non-blocking
statements.

6. Do not use blocking and non-blocking both assignments for a particular signal at different places.
Bad coding practice. It results in hardware ambiguity.

7. Avoid multiple driver errors. Avoid driving the same signal in two different always blocks. It
results in racing when one tries to simulate code. One never knows which block will execute first
during simulation.
BAD CODING:
always @ ( posedge clock)
a <= #1 0;
always @ ( posedge clock)
a <= #1 1;

8. Default data type is wire: this means that if you declare a variable without specifying reg or wire, it
will be a 1-bit wide wire.

9. Always use #1 delay in always @ (posedge clock) block for easy debug and better waveform view.
You can clearly see where exactly the signal gets sampled. It reduces debug efforts a lot.
GOOD WAY:
always @ (posedge clock)
D <= #1 Q;
10. Never call module inside always or initial blocks. Module calls must be outside any procedural
blocks.
WRONG WAY:
module conditional_adder(input wire [31:0] a_input,input wire [31:0] b_input,input wire cin,output
wire [31:0]
sum_out,output wire carry_out);
wire [31:0] a;
wire [15:0] b;
always @ (posedge clock)
bit2_adder x1(.a(a_input[1:0]), .b(b_input[1:0]),.cin(cin), .sum(a[1:0]), .cout(b[0]));
assign sum_out = a;
assign carry_out = b[(`BITS/2)1];
endmodule

CORRECT WAY:
module conditional_adder(input wire [31:0] a_input,input wire [31:0] b_input,input wire cin,output
wire [31:0]
sum_out,output wire carry_out);
wire [31:0] a;
wire [15:0] b;
bit2_adder x1(.a(a_input[1:0]), .b(b_input[1:0]),.cin(cin), .sum(a[1:0]), .cout(b[0]));
assign sum_out = a;
assign carry_out = b[(`BITS/2)1];
endmodule

11. always @ (posedge clock1, posedge clock2, negedge reset) this may simulate but does not
synthesize. There is no Hardware (Flip-flop) which has two or multiple clocks in Toshiba synthesis
library. you may use any of the followings in your HDL:
always @ (posedge clock)
always @ (negedge clock)
always @ (posedge clock or negedge reset)
always @ (posedge clock or posedge reset)
always @ (negedge clock or negedge reset)
always @ (negedge clock or posedge reset)

There are FFs with preset though if you want to use preset signal, you can include it in.

12. Try to avoid using different clock edge (posedge and negedge) in same design. It makes STA and
SCAN difficult to perform. Either use only always @ (posedge clock) or only always @ (negedge
clock) everywhere in your design.

13. Make sure you understand the concurrent behavior of Verilog. Always write synthesizable code.
Make sure you work on synthesis as early as possible. Do not synthesize entire design at once at the
end of the whole design. Synthesis small partition of design as you write over the time to make sure
that you are writing correctly. If you will write entire code and later try to synthesize you may find it
difficult to make it synthesizable at the end. Synthesis as early as possible and always after you add a
small-small portion of HDL code in your design. Always remember we are writing HDL, synthesis has
a lot more importance over simulation. You should see the evolving circuit behind every line of Verilog
you add. No one is perfect!

14. Make sure you have no latches in your design. There should be only Flip-flops and combinational
hardware in your design. You may use always_ff instead always to make sure that you are getting
desired hardware from synthesis.

15. There is nothing like always @ (posedge clock and posegde reset), you can not use and keyword
in this sense in always block. There is just or keyword. Make sure you know how to write code to make
correct FFlop hardware for any sequential circuits.
16. If you are using a loop, for example for loop in your code make sure it has fix numbers on
iteration at compile time as you can not keep variable numbers of iterations as it does not result in
hardware. A number of loop iterations must be fixed values to make sure that it synthesize.
Think about how that loop might be implemented, given that the hardware doesn't know how loops
work. Because of that, loops get unrolled completely - if you have ten loop iterations, VCS will
produce ten copies of the hardware within the loop. If in your code you have an unknown number of
iterations (varying or infinite #'s of iterations), It can not produce a fixed hardware.

I hope this documentation will help you write good HDL code. For any further doubts regarding this
topic, you may meet me during office hours. Thank you,

Regards,
Priyansh Bhimani
Hi everyone,
I see few students did not follow coding guidelines. I gave it in previous announcements. I want to
give reminder that the announcement coding guideline is too important to avoid mistakes while
writing HDL. I want everyone to understand each point from coding guideline and closely follow them
in your designs. Please go through previous announcements and look for coding guidelines.
Additional information:
1. Always reset your DUT with reset signal at first. Your design should assign default value on reset
only.
WRONG WAY:
module addbit (
...
);
...
reg a = 5; // declaration
...
endmodule
RIGHT APPROACH:

module addbit (
...
);
...
reg a; // declaration
...
always @ (posedge clock)
begin
if (reset)
begin
a <= 5; // Correct Way
 end
else
begin
// Regular assignments
end
end
endmodule
2. Do not include wait statements or # delays in design file. Do not include
initial blocks anywhere in your design file. Synthesizer will throw away all delays
while making hardware. You may end up getting correct Pre-synthesis simulation but
wrong Post-synthesis simulation.
Avoid using:
@(signal) // Blocking Waits
OR
#10 // Fix Delays
OR
initial // Initial Blocks
begin
...
end
3. If your designs is entirely combinational circuits (NO FFs in design) in this
project, then make sure you flop all inputs and output by adding Flip-Flops on each
IO of module. We need to see what max frequency can your design run at. Path we
will constrained with a clock, try to achieve slack 0 or +ve. If your design has
state-machine still I recommend to add IO FFs.
4. Also show analysis in project report which adder is faster (less clock time
period).
5. Simulation results are important but synthesis and gate-level post-synthesis
simulation is most important in the HDL. Always remember it is HDL, Hardware
Description Language. Aim is to make correct functioning Hardware block not just a
simulation model.
Regards,
Priyansh Bhimani