bluespec.com Forum Index bluespec.com
Bluespec Forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Hint of synchronous reset signal for netlist synthesis

 
Post new topic   Reply to topic    bluespec.com Forum Index -> Tools: Other
View previous topic :: View next topic  
Author Message
wychen



Joined: 06 Nov 2007
Posts: 35

PostPosted: Fri Jul 11, 2008 8:33 pm    Post subject: Hint of synchronous reset signal for netlist synthesis Reply with quote

I used design compiler to synthesize a high-speed design written in Bluespec, but the generated netlist was problematic and cannot pass testbench. The cause was that design compiler didn't move the reset signal to the mux closest to the register, thus causing RTL/gate-level mismatch. Although the generated netlist still work after fabrication, it is desirable to be able to simulate the design before taping out.

In this paper (http://ens.ewi.tudelft.nl/Education/courses/et4351/CummingsSNUG2003Boston_Resets.pdf) , on page 11, a synopsys directive can be used to resolve this issue.
We used a script to insert the following directive to all the modules generated by bsc, and the problem was solved.
Quote:
// synopsys sync_set_reset "RST_N"


Since it is harmless and doesn't change the RTL behavior, that paper suggests adding this directive to all the modules using synchronous reset. It would also be nice if bsc add this as well, so it's more ASIC-friendly.
Back to top
View user's profile Send private message
SteveA



Joined: 03 May 2007
Posts: 32

PostPosted: Fri Jul 11, 2008 8:57 pm    Post subject: Reply with quote

I agree.. This is a good idea, and we should add this directive to our library elements.. In the meantime, you can add this to your local library verilog elements in ...bluespec/lib/Verilog for the elements that use sync reset...
_________________
Steve Allen
Senior Consulting Engineer
Bluespec, Inc
Back to top
View user's profile Send private message
SteveA



Joined: 03 May 2007
Posts: 32

PostPosted: Fri Jul 11, 2008 9:15 pm    Post subject: Reply with quote

One more tidbit. Adding this to all the library elements that are synchronous (I counted 20ish), should be all you need to do. Since users general don't fiddle with reset directly (unless you import verilog using import bvi), having the directive in the library elements should be all you need.
_________________
Steve Allen
Senior Consulting Engineer
Bluespec, Inc
Back to top
View user's profile Send private message
wychen



Joined: 06 Nov 2007
Posts: 35

PostPosted: Sat Jul 12, 2008 9:28 am    Post subject: Reply with quote

Adding the directive to the library is part of the solution. The other part is to add this directive to all the generated modules having synchronous reset signal, like top-level module and modules with (* synthesize *) directive.
In my project, some RTL/gate-level mismatches come from generated verilog files, not just from the verilog library.
Back to top
View user's profile Send private message
ShepSiegel



Joined: 14 Aug 2007
Posts: 41

PostPosted: Sat Jul 12, 2008 10:19 am    Post subject: Reply with quote

This is not a bad idea, but please be careful of the "slippery slope"...

We see value from BSV in the technology-agnostic pure RTL output. (Me likes to refer to the RTL output from bsc a byte-code). Decorating the RTL with pragmas may be seen as a first step towards specialization for a specific synthesis or technology route. Please exhaust all ways to communicate by way of the IEEE Verilog byte code, before resorting to pragmas.

First it's this, then there may be register and memory hinting for this ASIC lib or that FPGA lib, next you know BSV codes can no longer "travel". That is my worry of this "slippery slope".

-Shep
Back to top
View user's profile Send private message
SteveA



Joined: 03 May 2007
Posts: 32

PostPosted: Sat Jul 12, 2008 1:15 pm    Post subject: Reply with quote

wychen wrote:
Adding the directive to the library is part of the solution. The other part is to add this directive to all the generated modules having synchronous reset signal, like top-level module and modules with (* synthesize *) directive.
In my project, some RTL/gate-level mismatches come from generated verilog files, not just from the verilog library.


I see this also potentially varies depending on how you flatten your design. It seems to me that this shouldn't even be a pragma, it should be a dc_shell command line option.. But none the less...

I'm learning towards agreeing that this should be left to the users of a project, not a decision bsv makes for the customer. It's easy enough to add the pragma to a customers library and post process into verilog if they want, and additionally, this is certainly not likely to be the only pragma/addition customers will want. Hence, it's probably better for us to stay out of the pragma business, since even synopsys doesn't automatically "do the right thing" for this case: That's why they have a pragma to begin with rather than just always pulling reset closer to the FF.

_________________
Steve Allen
Senior Consulting Engineer
Bluespec, Inc
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    bluespec.com Forum Index -> Tools: Other All times are GMT - 4 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
bluespec.com topic RSS feed 


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP