So, it seems that's what synplify is doing here. And then the tools can pick whatever value they like during synthesis if it can simplify the logic. At any rate, all signals that are not explicitly initialized do not start at 0, they start at X (indeterminate logic level).
And as a result, synplify handles initial blocks and inline initializers differently from FPGA tools - specifically, it mostly ignores them, even if it causes strange, unexpected behavior. For ASICs, it's common to not initialize anything, ever, and instead use explicit resets. Synplify is intended for synthesizing designs for ASICs, not FPGAs, and as a result is rather opinionated. The Go Board uses an external crystal for the clock.
#Synplify pro reviews full
The full project is actually up on GitHub.ĮDIT 2: I also understand that a PLL Lock signal could be used as a power-on reset, but unfortunately the HX1K does not have any PLLs. And because Lattice can only initialize registers to 0, I want to use a power-on reset signal to set X/Y to non-zero values. I'd like the ball to start in the middle of the screen, not at (0, 0). The reason it does this is because ball_absolute has a pair of X/Y registers for the ball's position on the screen. The o_rst of this reset_generator component is hooked up to another component at a higher level like this: wire w_reset So why does the first version get optimized out? And why does adding an initial value that gets ignored change the behavior? Is this just a quirk of iCEcube2 and/or Synplify Pro?ĮDIT 1: I'm using a power-on reset because Lattice can only initialize registers to zero, and I'd like some to start off with non-zero values. This warning also implies that initial values are 0. Now it no longer is getting optimized out and works as expected, but iCEcube2 shows this warning: : reset_generator.v(13) | User-specified initial value defined for instance reset_gen.rst_count is being ignored. However, if I explicitly set rst_count to 0, like this: reg rst_count = 0 I thought all registers were initialized to 0, so I'm not sure why it thinks rst_count is always 1. ICEcube2 outputs this warning: : reset_generator.v(13) | Register bit rst_count is always : reset_generator.v(6) | Input i_clk is : ball_absolute_mv_vga_top.v(19) | Removing instance reset_gen (in view: work.ball_absolute_mv_vga_top(verilog)) of type view:work.reset_generator_4s(verilog) because it does not drive other instances.Īnd I can verify that the o_rst signal is indeed never set to 1. If I write the the module like this, it is getting optimized out: `default_nettype none I am synthesizing using Lattice iCEcube2 + Synplify Pro targeting an iCE40 HX1K on the Nandland Go Board. It does not store any personal data.I am trying to write a Verilog module that generates a power-on reset signal for a few clock cycles.
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. The cookie is used to store the user consent for the cookies in the category "Performance". This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. The cookies is used to store the user consent for the cookies in the category "Necessary". The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". The cookie is used to store the user consent for the cookies in the category "Analytics". These cookies ensure basic functionalities and security features of the website, anonymously. Necessary cookies are absolutely essential for the website to function properly.
0 kommentar(er)
