Stats

  • Locked Locked
  • Replies 2
  • Subscribers 91
  • Views 13963
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Problems with synthesis using RTL compiler and PKS

Renee

I used both PKS and RTL compiler to synthesize a verilog file, then used the .v file to do place and route with soc encounter. When I do post-layout simulation, I find that the routing result file using .v file generated by PKS produced the right result, while the one using .v file generated by RTL compiler cannot produce the right result, because the synthesis result from RTL compiler contained:

  assign SelExt = IR[15];
  assign SelV0 = SelC0;
  assign SelZ0 = SelC0;
  assign SelZ = SelC;
  assign SelV = SelC;

Then after routing, when I do extraction, there are only SelZ, SelZ0 and SelExt signals left, while SelC, SelC0, SelV and SelV0 are deleted as being the same nets, so it caused problems of not matching the IO list of the module when I simulate.

 Then I tried with another behavioural design, similarly the routing result using PKS as synthesis tool produced the right result, while the one using RTL compiler failed to pass the simulation. But this time, it did not have the same nets problem, just not being able to produce the right result.

 I don't understand. Is that possible that using PKS and RTL compiler synthesize the same design while the files did not have the same function? Or I made mistakes? (I used the same process to do place and route and except the .v file, the two designs have the same other files)

  Thank you!

 

Parents

  • Hi Renee,

    I'm not sure I follow everything you've said completely, but It sounds like PKS is removing assign statements whereas RTL Compiler is not and it is causing problems downstream.

    The first thing I'd do as a test is to ask RTL Compiler to remove assign statements prior to writing out a .v.  I'm not an RTL Compiler user, but I *think* the command is "remove_assigns".  I'll check with an RTL Compiler expert whether this is the recommended approach.

    The next thing to be aware of is that SoC-Encounter has a few different ways of dealing with assign statements.  The "setDoAssign" command influences this behavior (which is stored as "rda_Input(assign_buffer)" in your SoC-Encounter .conf file.  Have a look at the FE Text Command Reference for this command to see what each option does.  In short, when problems like these arise I find it expedient to:

    1. Remove assign statements in synthesis. -or-
    2. Remove assign statemetns by way of buffer insertion in SoC-Encounter (ie, "setDoAssign on -buffer <buffer_name>")

    Hope this helps,
    Bob

Reply

  • Hi Renee,

    I'm not sure I follow everything you've said completely, but It sounds like PKS is removing assign statements whereas RTL Compiler is not and it is causing problems downstream.

    The first thing I'd do as a test is to ask RTL Compiler to remove assign statements prior to writing out a .v.  I'm not an RTL Compiler user, but I *think* the command is "remove_assigns".  I'll check with an RTL Compiler expert whether this is the recommended approach.

    The next thing to be aware of is that SoC-Encounter has a few different ways of dealing with assign statements.  The "setDoAssign" command influences this behavior (which is stored as "rda_Input(assign_buffer)" in your SoC-Encounter .conf file.  Have a look at the FE Text Command Reference for this command to see what each option does.  In short, when problems like these arise I find it expedient to:

    1. Remove assign statements in synthesis. -or-
    2. Remove assign statemetns by way of buffer insertion in SoC-Encounter (ie, "setDoAssign on -buffer <buffer_name>")

    Hope this helps,
    Bob

Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.