UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor jhinkle
Visitor
604 Views
Registered: ‎06-07-2012

What's the best way to check if poor coding style has resulted in extra FF being implemented

Jump to solution

I'm using verilog to design.

Can't use schematic - design is too big.  Side question - is there a way to look at how sub-modules are implemented viewing a schematic?  When I tried - it always went down to the gate level and I was hoping to see several layers up?

I'm OK with the part utilization but I would like to see how bad I did and how many extra FF were injected?

Any insight welcome.

Thanks.

Joe

 

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
531 Views
Registered: ‎01-23-2009

Re: What's the best way to check if poor coding style has resulted in extra FF being implemented

Jump to solution

To keep the hierarchy in ISE use the XST option "-keep_hierarchy true".

As for the rest of your question, it doesn't really make a lot of sense... When we code in Register Transfer Language (RTL) we are explicitly coding the Registers (and the Transfers between them using the Language). So your code directly describes the registers; if a reg is assigned a value in an always @(posedge clk) block (and it is not only used as a temporary value within the process) then it will infer a register - the inference is pretty explicit.

The tools will not "inject" any registers other than the ones inferred by your RTL code (as described above) - with the exception of register replication which can be done by the tools to fix timing problems.

So, given that, there isn't any real way to answer this question - the tool infers the registers you described - pretty much period. If your description is wrong, then you may get registers that you didn't expect, but that's just a coding error. So, one would argue that the best way to find these is through simulation - if your design is coded in RTL and it operates the way you expect it to (in simulation), then one can assume that the registers that are there are the ones that you described (and hence inferred).

Avrum

0 Kudos
6 Replies
Historian
Historian
595 Views
Registered: ‎01-23-2009

Re: What's the best way to check if poor coding style has resulted in extra FF being implemented

Jump to solution

Your question is puzzling...

The schematic viewer in Vivado is very powerful - you can definitely generate schematics of sub-modules alone, and even make custom schematics by adding cells to the schematic one by one (or even deleting them, moving them, etc...). Based on your question, I wonder if you have the synthesis setting of -flatten_hierarchy set to "full" - with this option, the design is completely flattened - all hierarchy is removed and all cells primitive cells are placed at the top of the design.

Avrum

0 Kudos
Visitor jhinkle
Visitor
584 Views
Registered: ‎06-07-2012

Re: What's the best way to check if poor coding style has resulted in extra FF being implemented

Jump to solution

I'm using ISE.

I bet it is flattened - do you know how to un-flatten in ISE?

Thanks.

 

Joe

0 Kudos
Visitor jhinkle
Visitor
554 Views
Registered: ‎06-07-2012

Re: What's the best way to check if poor coding style has resulted in extra FF being implemented

Jump to solution

I figured out how to un-flatten it.

Is viewing the schematic the best way to check for injected FF's?

Thanks.

Joe

0 Kudos
Historian
Historian
532 Views
Registered: ‎01-23-2009

Re: What's the best way to check if poor coding style has resulted in extra FF being implemented

Jump to solution

To keep the hierarchy in ISE use the XST option "-keep_hierarchy true".

As for the rest of your question, it doesn't really make a lot of sense... When we code in Register Transfer Language (RTL) we are explicitly coding the Registers (and the Transfers between them using the Language). So your code directly describes the registers; if a reg is assigned a value in an always @(posedge clk) block (and it is not only used as a temporary value within the process) then it will infer a register - the inference is pretty explicit.

The tools will not "inject" any registers other than the ones inferred by your RTL code (as described above) - with the exception of register replication which can be done by the tools to fix timing problems.

So, given that, there isn't any real way to answer this question - the tool infers the registers you described - pretty much period. If your description is wrong, then you may get registers that you didn't expect, but that's just a coding error. So, one would argue that the best way to find these is through simulation - if your design is coded in RTL and it operates the way you expect it to (in simulation), then one can assume that the registers that are there are the ones that you described (and hence inferred).

Avrum

0 Kudos
Moderator
Moderator
352 Views
Registered: ‎03-16-2017

Re: What's the best way to check if poor coding style has resulted in extra FF being implemented

Jump to solution

Hi @jhinkle,

Let us know if you have further queries on it, else please close the thread by marking it as accepted solution.

 

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.
0 Kudos
Visitor jhinkle
Visitor
333 Views
Registered: ‎06-07-2012

Re: What's the best way to check if poor coding style has resulted in extra FF being implemented

Jump to solution

avrumw

I was using the term extra FF implemented to identify those inferred by poor coding of a case statement.

I have some big FSMs and my reading on the subject says that if proper care is not used in case based FSMs that FFs may be inferred when not required.

I'm an old fart and attempting to learn this as a hobby.  Since I do not have access to knowledgeable people in this area, I learn by attempting to understand mistakes I make.  Since multiple books speak at length on this subject, I was just asking is there was a way to help identify if my implementation may have inadvertenly included any un-needed FF.

Thank you for the direction on enabling hierarchy - I can now better view and understand the synthesized results.

Joe

0 Kudos