RFC: does this make any sense?

[Paul Taylor]

Hi,

I have been playing around with a HDL + associated tools, and want some
feedback. I have designed the HDL to be relatively terse but still
hopefully clean and clear.

Basically what I want to know is, from a viewpoint of people who know
vhdl, does the following code make any sense? i.e. do all the contructs
look impenetrable, or can you hazard a guess at what they are doing? The
code below is in fact based on the vhdl code found here:

ftp://ftp.xilinx.com/pub/applications/xapp/xapp199.zip

(in the vhdl_selfchecking directory of the zip)


#
# @Title Stopwatch
# @Description A stopwatch with tenths, seconds, and tens of seconds.
# @Port tenths Tenths of seconds, inverted one-hot decoded
# @Port ones Seconds decoded to drive a seven segment display
# @Port tens Tens of seconds decoded to drive a seven segment display
#
module StopWatch() {
inport clk, reset, clk100ms; nStartStop;
outport tens[%7], ones[%7], tenths[%10];

node startStop = !nStartStop;

reg sm[] = { # controlling state machine
0 when reset;
: tenthsCount.rst = 1; onesCount.rst = 1; tensCount.rst = 1; next;
: next when startStop;
LOOP: tenthsCount.inc = 1 when clk100ms; next when !startStop;
: tenthsCount.inc = 1 when clk100ms; next when startStop;
: next when !startStop;
: LOOP when startStop;
}

reg tenthsCount[%4] = {
node rst, inc, rollOver;
0 when rst;
0 when inc & (tenthsCount == 9) with rollOver = 1;
next when inc;
}

reg onesCount[%4] = {
node rst, rollOver;
0 when rst;
0 when tenthsCount.rollOver & (onesCount == 9) with rollOver = 1;
next when tenthsCount.rollOver;
}

reg tensCount[%4] = {
node rst;
0 when rst;
0 when onesCount.rollOver & (tensCount == 5);
next when onesCount.rollOver;
}

const SEVEN_SEG_DECODE[10] = { 0x79, 0x24, 0x30, 0x19, 0x12, 0x02, 0x78,
0x00, 0x10, 0x08 };
tens = SEVEN_SEG_DECODE[0 .. 9] when tenthsCount == 0 .. 9;
ones = SEVEN_SEG_DECODE[0 .. 9] when onesCount == 0 .. 9;
node tenthsDec[%10] = 1 << 0 .. 9 when tenthsCount == 0 .. 9;
tenths = !tenthsDec:
}


Thanks + regards,

Paul.

 

[backhus]

Hi Paul.
No, to VHDL-people that code makes no sense at all.
Because it's verilog

And I really doubt, that you got it from the vhdl_selfchecking directory
of the zip file you mentioned.

My guess is, that you played around with the StateCad-tool, and forgot
to set the Language to VHDL while generating your HDL Export.

You probably work with the ISE8.x Tools. They just love verilog and have
to be beaten to use VHDL
The ISE 9.1 version has a "Prefered HDL" property that can be set for
the project.

Have you made any Schematics yet? Well, take a look into your
directories. Have they been converted to *.vhf (VHDL) or *.vf (verilog)?

A little hint:
If you are using CAE tools, remember that they need to be bash-ed from
time to time. ;-)

Best regards
Eilert

Paul Taylor schrieb:

Hi,

I have been playing around with a HDL + associated tools, and want some
feedback. I have designed the HDL to be relatively terse but still
hopefully clean and clear.

Basically what I want to know is, from a viewpoint of people who know
vhdl, does the following code make any sense? i.e. do all the contructs
look impenetrable, or can you hazard a guess at what they are doing? The
code below is in fact based on the vhdl code found here:

ftp://ftp.xilinx.com/pub/applications/xapp/xapp199.zip

(in the vhdl_selfchecking directory of the zip)


#
# @Title Stopwatch
# @Description A stopwatch with tenths, seconds, and tens of seconds.
# @Port tenths Tenths of seconds, inverted one-hot decoded
# @Port ones Seconds decoded to drive a seven segment display
# @Port tens Tens of seconds decoded to drive a seven segment display
#
module StopWatch() {
inport clk, reset, clk100ms; nStartStop;
outport tens[%7], ones[%7], tenths[%10];

node startStop = !nStartStop;

reg sm[] = { # controlling state machine
0 when reset;
: tenthsCount.rst = 1; onesCount.rst = 1; tensCount.rst = 1; next;
: next when startStop;
LOOP: tenthsCount.inc = 1 when clk100ms; next when !startStop;
: tenthsCount.inc = 1 when clk100ms; next when startStop;
: next when !startStop;
: LOOP when startStop;
}

reg tenthsCount[%4] = {
node rst, inc, rollOver;
0 when rst;
0 when inc & (tenthsCount == 9) with rollOver = 1;
next when inc;
}

reg onesCount[%4] = {
node rst, rollOver;
0 when rst;
0 when tenthsCount.rollOver & (onesCount == 9) with rollOver = 1;
next when tenthsCount.rollOver;
}

reg tensCount[%4] = {
node rst;
0 when rst;
0 when onesCount.rollOver & (tensCount == 5);
next when onesCount.rollOver;
}

const SEVEN_SEG_DECODE[10] = { 0x79, 0x24, 0x30, 0x19, 0x12, 0x02, 0x78,
0x00, 0x10, 0x08 };
tens = SEVEN_SEG_DECODE[0 .. 9] when tenthsCount == 0 .. 9;
ones = SEVEN_SEG_DECODE[0 .. 9] when onesCount == 0 .. 9;
node tenthsDec[%10] = 1 << 0 .. 9 when tenthsCount == 0 .. 9;
tenths = !tenthsDec:
}


Thanks + regards,

Paul.

 

[Paul Taylor]

Hi Eilert,

Thanks for response.

I should have made it clearer in my original post - the code isn't verilog
either - it's a HDL that I have made up (although of course it is
influenced by other programming languages). I have written some tools
(although they are in no way complete) that include a compiler (to VHDL),
a simulator, designed a test bench language (which the simulator runs),
and also have done some work getting a general purpose scripting language
to work with the simulator. It is all just something that I am playing
around with - nothing too serious.

However, I was looking for some feedback on the HDL constructs that I'm
using, hence questions in original post.

The link to the zip file is a VHDL version of a stopwatch. The HDL code
that I posted is essentially the same in terms of functionality, but
different in terms of language constructs.

Regards,

Paul.

 

[Mike Treseler]

Paul Taylor wrote:

However, I was looking for some feedback on the HDL constructs that I'm
using, hence questions in original post.

It is an understandable structural description like AHDL.
I suppose a casual logic designer might be interested
if the simulator and vhdl synthesis worked.

However for anyone already using vhdl or verilog
for design *and* simulation, learning two more
languages makes no sense at all.

-- Mike Treseler

 

[Paul Taylor]

Hi Mike,

Thanks for response.

On Sat, 10 Feb 2007 09:11:39 -0800, Mike Treseler wrote:

It is an understandable structural description like AHDL.

Good - I was hoping it wouldn't be considered totally alien.

I suppose a casual logic designer might be interested
if the simulator and vhdl synthesis worked.

My aims are for a simple language that may be used for less complex FPGA
designs. The simulator + vhdl synthesis doesn't fully work at the moment.
It's a work in progress (and of course may never get finished).

However for anyone already using vhdl or verilog for design *and*
simulation, learning two more languages makes no sense at all.

Points taken. Again though, the aim is simplicity (without sacrificing
too much power). Below is an example of one of my testbenches (that
generates stimulus for a UART transmitter):

test lib.serial.UartTransmitter() {
run * c;
run * bc;
wait loadData;
wait 12 bc; # 12 bit clocks, enough to tx packet

sequence c { clk = 1; wait 50; clk = 0; wait 50; }
sequence bc { bitClk = 1; wait c; bitClk = 0; wait 15 c; }
sequence loadData { data = 0xa5; ld = 1; wait c; }
}

The testbench language also has asserts, which aren't shown in the above.
That's it for the testbench language - as simple as it gets really. If
you wanted to do more, (e.g. program flow control, file load/save etc)
then the testbench language is no good. But, for those cases I plan to
have a general purpose scripting language that nicely interfaces to
simulator/test bench runner. Currently I'm using Sleep scripts (a lot like
perl) - although I may change to some other general purpose scripting
language.

Why would anyone want to use it? Well it's just an experiment on my part -
just playing around with the compiler + sim + challenge to come up with an
elegant solution for some types of FPGA designs (e.g. the vhdl code
printed out for the vhdl stopwatch example uses nine pages, mine just one
- generally it will be more like 3:1). Anything complete though might
never see the light of day.

Regards,

Paul.

 

[Mike Treseler]

Paul Taylor wrote:

Thanks for response.
You are welcome.

Why would anyone want to use it? Well it's just an experiment on my part -
just playing around with the compiler + sim + challenge to come up with an
elegant solution for some types of FPGA designs

Simulation and compact sequential descriptions
are a problem for hardware guys new to HDL,
so don't let me rain on your parade.

(e.g. the vhdl code
printed out for the vhdl stopwatch example uses nine pages, mine just one
- generally it will be more like 3:1).

If the stopwatch example were collapsed into
a single entity, it would also fit on one page.

Anything complete though might
never see the light of day.

That is true for any project

Have fun.

-- Mike Treseler

 

[Colin Paul Gloster]

Mike Treseler <mike_treseler@comcast.net> wrote:

"[..]

However for anyone already using vhdl or verilog
for design *and* simulation, learning two more
languages makes no sense at all."

Oh, not being at all like Paul Taylor's own language, people who have
proposed e.g. the following (none of which I have used nor read much about)
for hardware descriptions might not agree: Haskell or a language
embedded in Haskell (e.g. Galois's tool or Hawk or Lava); Confluence; HDCaml;
and reFLect.

However, I found statements by Jan Decaluwe on
HTTP://SourceForge.net/mailarchive/message.php?msg_id=13236174
to be interesting:

Jan Decaluwe posted on 2005-10-06 08:09:

"Let me add that I fail to see the point of Confluence itself. It's
one more attempt in a long tradition of non-procedural HDL languages.
The reasoning is that as hardware is parallel, the HDL should *only*
have parallel contructs too. In my opinion, this reasoning is flawed.
The evidence of sucessful HDLs supports my views on this.

It is easy to claim, as Confluence does, that you need much fewer
lines of code for a specific type of block, if you include it as a
primitive in your language. The real point is that there are many
kinds of useful hardware descriptions, including synthesizable ones,
that need procedural constructs, and that therefore simply cannot be
descibed elegantly in a non-procedural language like Confluence."

Clarifications; examples of earlier attempts in the "long tradition of
non-procedural HDL languages"; interlocution; debate; impressions;
etc. are invited.

Regards,
Colin Paul Gloster


Further reading:
WWW.Galois.com/job_FPGAEngineer.php

Per Bjesse, Koen Claessen, Mary Sheeran, Satnam Singh, ``Lava:
hardware design in Haskell'', Proceedings of
the third ACM SIGPLAN international conference on Functional
programming ICFP 1998

WWW.CSE.OGI.edu/PacSoft/projects/Hawk/

WWW.Confluent.org

/
Sava Krstic and John Matthews, "Semantics of the reFLect language",
"Proceedings of the 6th ACM SIGPLAN international conference on
Principles and practice of declarative programming", 2004,
HTTP://portal.ACM.org/citation.cfm?id=1013971&coll=portal&dl=ACM&CFID=14166847&CFTOKEN=24957620

 

[Mike Treseler]

Colin Paul Gloster wrote:

Clarifications; examples of earlier attempts in the "long tradition of
non-procedural HDL languages"; interlocution; debate; impressions;
etc. are invited.

I agree with Jan. Just because hardware feels parallel
does not mean that variables and procedures must
be excluded from its description.

Hardware description from abel to occam to verilog and vhdl
are based on communicating sequential processes.
Each process goes in box that is wired to other boxes.
If I use lots of boxes, the procedures are obscured by wires.
If I use just one box, the wires are are obscured by procedures.

-- Mike Treseler

 

[Andy]

On Feb 12, 9:24 am, Mike Treseler <mike_trese...@comcast.net> wrote:

Hardware description from abel to occam to verilog and vhdl
are based on communicating sequential processes.
Each process goes in box that is wired to other boxes.
If I use lots of boxes, the procedures are obscured by wires.
If I use just one box, the wires are are obscured by procedures.

-- Mike Treseler

Very well said!

Andy

 

[Ben Jones]

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:53bf52F1rdr52U1@mid.individual.net...

Each process goes in box that is wired to other boxes.
If I use lots of boxes, the procedures are obscured by wires.
If I use just one box, the wires are are obscured by procedures.

I'm going to get that tattooed somewhere important.

-Ben-

 

[Mike Treseler]

Ben Jones wrote:

I'm going to get that tattooed somewhere important.

Yikes.
Those things are difficult to edit.
Let me fix up the English here first:

Hardware description is based on communicating sequential processes.
--
Each process goes in a box that is wired to other boxes.
-
If I use lots of boxes, the procedures are obscured by wires.
If I use just one box, the wires are are obscured by procedures.

-- Mike Treseler