How to check for errors in analysis/elaboration - Revision history

Hoa at 21:00, 29 January 2020

2020-01-29T21:00:16Z

Hoa at 20:13, 29 January 2020

2020-01-29T20:13:00Z

Hoa at 20:12, 29 January 2020

2020-01-29T20:12:16Z

Hoa at 20:07, 29 January 2020

2020-01-29T20:07:24Z

Hoa: Created page with "'''Q:Verific clears the error count at various steps during analysis/elaboration. Is there a way to tell if these processes have errors?''' Verific follows an "optimistic" ap..."

2018-08-24T22:37:11Z

Created page with "'''Q:Verific clears the error count at various steps during analysis/elaboration. Is there a way to tell if these processes have errors?''' Verific follows an "optimistic" ap..."

New page

'''Q:Verific clears the error count at various steps during analysis/elaboration. Is there a way to tell if these processes have errors?'''

Verific follows an "optimistic" approach. It clears the error count at various steps during analysis/elaboration so that the flow can continue as far as possible.

It is possible to change to a "pessimistic" approach in which the flow stops at the first error. But it is not what most users want.

For global error count, there are two APIs:

Message::GlobalErrorCount()
Message::ClearGlobalErrorCount()

To check for error at any point of time, the user needs to call Message::GlobalErrorCount(), which will return the number of errors.

To clear the global error count, the user needs to call Message::ClearGlobalErrorCount() anywhere. This API also clears the normal error count returned by Message::ErrorCount().

← Older revision		Revision as of 21:00, 29 January 2020
Line 14:		Line 14:
	To check for error at any point of time, the user needs to call Message::GlobalErrorCount(), which will return the number of errors.		To check for error at any point of time, the user needs to call Message::GlobalErrorCount(), which will return the number of errors.

−	The GlobalErrorCount is not cleared by Verific's internal processes. To clear the global error count, the user ~~needs to~~ call Message::ClearGlobalErrorCount() anywhere. This API also clears the normal error count returned by Message::ErrorCount().	+	The GlobalErrorCount is not cleared by Verific's internal processes. To clear the global error count, the user can call Message::ClearGlobalErrorCount() anywhere in the user's application. This API also clears the normal error count returned by Message::ErrorCount().

@@ Line 3: / Line 3: @@
 Verific follows an "optimistic" approach. It clears the error count at various steps during analysis/elaboration so that the flow can continue as far as possible.
-For example, during elaboration, if a module has errors, its netlist is still created, but is blackboxed in order for the elaboration to move on and to avoid null pointers. The ErrorCount is cleared before the elaboration continues on with another module.
+For example, during elaboration, if a module has errors, its netlist still is created, but is blackboxed in order for the elaboration to move on and to avoid null pointers. The ErrorCount is cleared before the elaboration continues on with another module.
 It is possible to change to a "pessimistic" approach in which the flow stops at the first error. But it is not what most users want.

← Older revision		Revision as of 20:12, 29 January 2020
Line 14:		Line 14:
	To check for error at any point of time, the user needs to call Message::GlobalErrorCount(), which will return the number of errors.		To check for error at any point of time, the user needs to call Message::GlobalErrorCount(), which will return the number of errors.

−	To clear the global error count, the user needs to call Message::ClearGlobalErrorCount() anywhere. This API also clears the normal error count returned by Message::ErrorCount().	+	The GlobalErrorCount is not cleared by Verific's internal processes. To clear the global error count, the user needs to call Message::ClearGlobalErrorCount() anywhere. This API also clears the normal error count returned by Message::ErrorCount().

← Older revision		Revision as of 20:07, 29 January 2020
Line 2:		Line 2:

	Verific follows an "optimistic" approach. It clears the error count at various steps during analysis/elaboration so that the flow can continue as far as possible.		Verific follows an "optimistic" approach. It clears the error count at various steps during analysis/elaboration so that the flow can continue as far as possible.
		+
		+	For example, during elaboration, if a module has errors, its netlist is still created, but is blackboxed in order for the elaboration to move on and to avoid null pointers. The ErrorCount is cleared before the elaboration continues on with another module.

	It is possible to change to a "pessimistic" approach in which the flow stops at the first error. But it is not what most users want.		It is possible to change to a "pessimistic" approach in which the flow stops at the first error. But it is not what most users want.