You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Actually I would like to write about 4 separate issues, but would like to avoid flooding the issue tracker with questions.
If you think this should be separate issues I can create them.
The use of the falling edge of the clock to synchronize internal operations should be stated more explicitly, since it does not meet some generic expectations.
For example, clock falling edge sensitivity means, that clock duty cycle affects timing.
If a designer decides to reduce the clock frequency to meet read data timing, the added margin is half of what would be if all internal operations were synchronized on the clock rising edge.
I only found the timing in the slide presentation I spent some time looking for it elsewhere, mostly finding old documents.
Could you create a timing diagram to be displayed with the generated report?
Could you write a mapping between values on the diagram and values in generated tables?
The Verilog model is using the blocking assignment operator = for synchronous code, while the non-blocking operator <= should be used.
I can create a patch for this part of the generator without too much trouble, I am just not sure if there are any specific reasons for using the blocking operator (compatibility with some old tool).
I could also rewrite the ports in a more compact Verilog 2001 style. Again I am asking if there are specific reasons for using older Verilog syntax? While I have not used a tool without Verilog 2001 support in a while, it is true many generated netlist files still use ancient syntax.
I would add this change as a separate commit, so you can decide whether to merge it or not.
The text was updated successfully, but these errors were encountered:
It is necessary to measure timing against the negative clock. If we didn't, we would then need to have a separate lib file for each clock frequency since that would be a part of the timing data. We intentionally did this to allow a single lib file.
We are finalizing some other control implementations if you don't like this. These are still being finished though.
We would welcome additional help with documentation.
The Verilog model is a non synthesizable behavioral model. It is intended to actually model the don't care and edge behavior. We use the oldest standard for maximum compatibility. This is also generated code.
We could change the blocking to non blocking but it really doesn't matter since none of the signals are reused in the block. The behavior and result would be the same.
Actually I would like to write about 4 separate issues, but would like to avoid flooding the issue tracker with questions.
If you think this should be separate issues I can create them.
The use of the falling edge of the clock to synchronize internal operations should be stated more explicitly, since it does not meet some generic expectations.
For example, clock falling edge sensitivity means, that clock duty cycle affects timing.
If a designer decides to reduce the clock frequency to meet read data timing, the added margin is half of what would be if all internal operations were synchronized on the clock rising edge.
I only found the timing in the slide presentation I spent some time looking for it elsewhere, mostly finding old documents.
Could you create a timing diagram to be displayed with the generated report?
Could you write a mapping between values on the diagram and values in generated tables?
The Verilog model is using the blocking assignment operator
=
for synchronous code, while the non-blocking operator<=
should be used.I can create a patch for this part of the generator without too much trouble, I am just not sure if there are any specific reasons for using the blocking operator (compatibility with some old tool).
I could also rewrite the ports in a more compact Verilog 2001 style. Again I am asking if there are specific reasons for using older Verilog syntax? While I have not used a tool without Verilog 2001 support in a while, it is true many generated netlist files still use ancient syntax.
I would add this change as a separate commit, so you can decide whether to merge it or not.
The text was updated successfully, but these errors were encountered: