Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

A new open-source IP core configuration system

Status
Not open for further replies.

ring0

Member level 3
Joined
Nov 10, 2008
Messages
60
Helped
5
Reputation
10
Reaction score
0
Trophy points
1,286
Location
Moscow, Russia
Activity points
1,606
Hello,

I have developed a set of open-source applications that can be used to create configurable Verilog/VHDL IP cores with graphical confuguration interfaces. It includes a preprocessor that can recognize control tags inserted in the Verilog/VHDL (or other) source code. Control tags can be used to generate code that depends on IP core parameters. E.g., the following construct:

Code:
always @(\[COLOR="blue"]if[/COLOR]{edge=="rising"}\[COLOR="blue"]then[/COLOR]{posedge}\[COLOR="blue"]else[/COLOR]{negedge} clk)

when provided the edge="falling" parameter will turn into

Code:
always @(negedge clk)

It is possible to invoke scripts written in Lua programming language that is rather versatile.

The template parameters can be then described in a file with a rather simple syntax to create a configuration GUI (click to enlarge):


Project home page is at http://coretml.sourceforge.net. The distribution includes a couple of simple IP core examples (Hamming code generator and FPGA memory generator).

Is anyone interested in it? Maybe someone has some suggestions?
 

I have some suggestions:
1.) the documentation seems to suggest that the {} tokens cannot be used as printing characters without \{ \}. This is a very bad idea as verilog uses these characters for the concatenation operator. you really don't need high-speed with this, so any type of parser should work. you should work very hard to ensure that the HDL has the same HDL syntax that is expected, and the LUA has the same LUA syntax.
2.) \eval should probably be a "default" operator, eg \{x} would be the same as \eval{x}.
3.) the language should focus on good-practices. For example, keeping HDL constructs out of LUA. This helps at least from a syntax highlighting perspective. Some examples use \script with \write's inside. this is less than ideal, especially if TML eventually can handle code-formatting.
4.) allow for auto-formatting of the code. ideally, something that would do the line break location and indentation the same way a human would. It should be somewhat like LaTeX, where the style is mostly inferred by context and not explicitly set.
 

Hi permute,

thank you for your reply.

1) As the matter of fact, { token can be used without backslash, but } indeed cannot. As TML was designed to be language-neutral, some kind of escape sequences is unavoidable. Maybe an approach similar to Lua long brackets can help? I.e. modify the parser in such a way that the developer can use {==={ instead of just { (with any number of = characters), and the parser would expect the tag to be closed with the same type of bracket (either long or ordinary) as it was begun. In this case, ordinary braces could be used without escape characters. However this doesn't solve a similar problem with a backslash as a special character.

2) Right now it is impossible since \{ means literal {, but maybe it could be done along with the previous improvement.

3,4) As I have said, TML was designed to be language-independent. Even if it haven't been so, it would be an overkill to complement a simple TML parser with full-fledged Verilog and VHDL parsers (and what about SystemC?). I'm pretty well aware that it is important to keep both TML template formatting and output file formatting to be sane. Right now TML includes the so-called "strict formatting" mode that makes parser to ignore line breaks and indents in the template and place them to the output file only when they are explicitly set with corresponding tags (i.e. \x{n} for newline, \x{t} for tabulation indent, \x{s} for space indent). This solution has its drawbacks (it makes the template source somewhat less readable), but it is better than nothing. Maybe providing an interface to an external indentation program or library could improve the situation?
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top