[SOLVED] Assign statements dependency on clock

[anusha vasanta]

Hi all,
does assign statements depends on clk during our module execution. As we will never include our assign statements inside an always block.if they don't depend on clock is they are advantageous in increasing our design speed??

thanx in advance

 

[sharath666]

Assign statements are what the name means i.e. assign one entity to another. You are only allowed to assign wires.
You can imagine connecting two points on a PCB with a wire. That is what this command does.
That is why you will not require an always block and that is why this operation is allowed only on verilog wires.

 

[anusha vasanta]

then the assign statements will never depend on clk right. then using this our code will get optimised or else more assign statements will make our netlist not efficient.
Here what i want to say is that i can implement my logic using always block as well as assign statement what is the one i can follow now to optimise my code and which is better??

 

[sharath666]

Using either will result in the same hardware. So it's not that using one of the constructs results in optimized hardware.
When you have to assign to wires use the 'assign' construct. When you have to assign to registers use the 'always' block.

 

[anusha vasanta]

thank you. i understood that my doubt is we can reduce our clk cycles right using assign statement ??
here i had some 24 bytes of data i had to pad some 3 bytes of zeros to this 24 bytes of data to make it a 27 bytes of data. i can implement this by taking my 27 bytes as (data_new) of wire (or) wire. if i take it as a wire i can use assign statement otherwise i need to represent in always block if i take it some reg.

 

[sharath666]

U can solve your issue using any approach..

 

[mrflibble]

Using assign statements is not a magic method to reduce latency. You could make the exact same thing with an always block.

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
wire in_a;
wire in_b;
wire output_of_the_day;
wire yet_another_output;
 
// unregistered AND gate
assign output_of_the_day = a & b;
 
// the exact same boring unregistered AND gate
always @(*) begin
    yet_another_output = a & b;
end

---

If you no coding habit yet, I suggest you go with the always flavor. Why? Because while in verilog-1995/2001 there is no real advantage that I can tell, in systemverilog there is. And in verilog country things are slowly but surely moving in the direction of systemverilog. So you would be future proofing your code habits.

---

Code Verilog - [expand]
1
2
3
4
5
wire output_sv_style; // More properly you'd use a "logic" and not a "wire", but lets keep it simple.
// the exact same boring unregistered AND gate
always_comb begin
    output_sv_style = a & b;
end

---

Case in point, I am used to using assign statements for simple combinational logic. And now when doing some systemverilog I find I still have that habit, and have to stamp it out (grrr). And then replace it with a proper always_comb. So if your neural paths are still fresh and in mint condition, might as well cement the correct pathway while you still have the chance. ;-)

As for assigns and reduced latency... An assign results in combinational logic. That is a blob of logic, where the output is NOT put into a clocked register. That lack of register may reduce latency, but it also may reduce functionality and increase pain. What I mean is, you have to use combinational logic for a specific reason, not just "because less latency is good". If that reasoning worked we'd all be making designs without any clocks whatsoever. Somehow that never quite works. And as I said, nothing magic about an assign statement, you can make the exact same thing with an always @(*) in old verilog or with an always_comb in systemverilog.

 

[ads-ee]

Another thing to think about is I've seen a few papers on simulator performance and from what I've read (though hardly definitive) is that having a lot of assigns (continuous assignments) in a Verilog simulation as opposed to the equivalent combinational always will adversely impact simulator performance. I haven't tried to verify any of this with any kind of profiling, so take it or leave it.

The best paper I found about this was actually written by an employee at one company that basically documented what they found to be "best practice" with their tool suite to improve simulation performance and memory usage (I've been searching for quite some time off and on looking for that paper, I wish I had sent that link to my personal email ). That paper also mentioned that the `timescale directive had some interesting behaviors. Namely: 1ns/1ps used more memory and ran slower than both 1ns/1ns and 1ps/1ps. From their performance testing they discovered that 1ns/1ns and 1ps/1ps exhibited similar performance.

- - - Updated - - -

And in verilog country things are slowly but surely moving in the direction of systemverilog. So you would be future proofing your code habits.

slowly!?

I would term it glacially. If you've just graduated from school maybe just maybe the FPGA vendors tools might be fully 2012 SV compliant by the time your retire. ;-)

 

[mrflibble]

I was being polite. I would term almost all development in the HDL field as bloody frozen over and kept at a breezy 4 millikelvin. Even stuff in the SV standard that are already outdated concepts (IMO) still have to be implemented by chippie vendors like xilinx/altera. But hey, compared to some of the pain you get when limited to verilog-2001 it (SV) is a lot better already.

A major gripe is not having a synthesizable subset of class implementation. And that lack would not have been so bad, if only they had defined a somewhat wider definition for struct. But nooooo. Now we have a limited struct (way better than what we had, but still room for improvement) that can be synthesized, and a fairly decent class that cannot be synthesized no matter how limited your class. Oh. Well.

As for continuous assignment versus always resulting in different simulator performance, that's interesting. How would that even work? I would have guessed that an assign statement pretty much would be translated to an equivalent always @(*) behind the scenes. But apparently not. Mmmh, the question then becomes: "is there an assignment statement that cannot be translated into an always @(*) equivalent?".

- - - Updated - - -

Maybe tri-state outputs? So far I have always done those with an assign. That is one area where I can maybe sorta kinda see a difference. Maybe.

- - - Updated - - -

Bah, I see that I mixed up in_a/in_b and a/b signals in my example code. And cannot edit it because some stupid monkeys have abused the edit function in the past. Curse you stupid monkeys, curse yooooouuuuuuuuu.

 

[ads-ee]

Bah, I see that I mixed up in_a/in_b and a/b signals in my example code. And cannot edit it because some stupid monkeys have abused the edit function in the past. Curse you stupid monkeys, curse yooooouuuuuuuuu.

I think I remember those monkeys as being the ones that just joined then came back and deleted the entire content of their original post after it was answered.

I really think it would be better to allow post editing based on your level minus any leveling based on length of time you've been signed up, or perhaps based on your Helped level. I've come back to some of my posts and thought to myself that it would be an improvement to add something or modify the wording. The most recent issue is not being able to fix my ASIC waveform that gets displayed incorrectly for every browser other than IE (it originally displayed fine using Chrome) I'm told it's the font I used.

 

[mrflibble]

Indeed. I get the reason why the mods removed the edit functionality. Because threads that suddenly don't make sense are annoying, and make the board less of a useful resource. But, I do NOT get the chosen response to address the problem. Okay great, you prevent the stupid monkeys from behaving like egocentric first-letter-of-the-alphabet holes. But you also prevent everyone else from making meaningful edits to their posts. There's loads of different ways to handle this, all depending somewhat on what functionality the forum software offers you. Rate limit on edits. Edits only after a minimum post count, helped count, points, membership date, etc. Post count obviously has drawbacks for this particular scenario, but membership date neatly fixes the hit & run posse. No 100% fix, but cheap way to mitigate the risk of that happening.

And another way is poster habit. If you as a poster want to prevent that sort of thing from happening then you simply quote the OP. Have fun editing/deleting your posts Mr OP, you have already been quoted.

 

[ads-ee]

Problem with just length of membership is there are quite a few newbie posters who have been members for a very long time that return intermittently. I think helped count would be more appropriate as they is no way the hit-n-run poster will ever have enough helped points to allow them to edit posts. I truly believe the only posters that might need the ability to update posts would be those that answer posts in a helpful way.

 

[mrflibble]

I know it's not perfect. For all reasonable solutions I can think of ways to break them. The reason why join date is a good fit to solve the hit & run? The hit and run --B holes are egotistic batardo's with a need for instant gratification. Their one redeeming quality is their lack of patience, which will ensure they don't set their alarm clock to 3 month later to come back and delete their posts. Helped count would also work, but that potentially gets you into other types of discussions that are 1) totally predictable 2) totally boring and 3) are neatly sidestepped by the fairly reasonable minimum time elapsed since join date. But I'm fine with either solution. As long we get that edit button back.