Bit reversal and IRC

[M. Norton]

Howdy,

Two completely unrelated topics in one easy to read USENET post.

1) I've found several examples of bit reversal code / byte reversal
code on the net, and most of them involve a FOR loop. I haven't found
any mention of how synthesizable this is. Anyone have some experience
with this? I'm afraid I rarely use some of the higher level functions
in the language due to synthesizer constraints, but I could be a bit
outdated by now ;-).

2) If anyone is interested, I thought I'd mention that the #vhdl
channel on irc.freenode.net has about 5 to 6 regulars now, and usually
willing to answer questions and talk about VHDL in general (if we're
not working). Couldn't hurt to get more regulars, because then it
might be more lively.

Best regards,
Mark Norton

 

[Mike Treseler]

1) I've found several examples of bit reversal code / byte reversal
code on the net, and most of them involve a FOR loop. I haven't found
any mention of how synthesizable this is.
Very.

Anyone have some experience
with this?

It works fine.

I'm afraid I rarely use some of the higher level functions
in the language due to synthesizer constraints, but I could be a bit
outdated by now ;-).

Yes. If you have a minute, test your synthesis with
this reference design:
http://home.comcast.net/~mike_treseler/uart.vhd
and let me know how it does.

-- Mike Treseler

 

[Remillard]

It works fine.



Yes. If you have a minute, test your synthesis with
this reference design:
http://home.comcast.net/~mike_treseler/uart.vhd
and let me know how it does.

Worked like a charm. Looks like I'm going to have to brush up on some
of my more abstract VHDL skills. I wasn't even sure what I was reading
in the source file. (Procedures are something I've never used much,
usually the most exotic I get are typedefs for state machines.)

For what it's worth, this was Xilinx ISE 7.1 and I just used the device
I had previously been working on, Virtex2 Pro.

=========================================================================
* Final Report *
=========================================================================

Device utilization summary:
---------------------------

Selected Device : 2vp40fg676-6

Number of Slices: 57 out of 19392 0%
Number of Slice Flip Flops: 50 out of 38784 0%
Number of 4 input LUTs: 107 out of 38784 0%
Number of bonded IOBs: 23 out of 416 5%
Number of GCLKs: 1 out of 16 6%


=========================================================================

Best regards,
Mark Norton

 

[Mike Treseler]

Worked like a charm. Looks like I'm going to have to brush up on some
of my more abstract VHDL skills. I wasn't even sure what I was reading
in the source file. (Procedures are something I've never used much,
usually the most exotic I get are typedefs for state machines.)

Thanks for the running the test.
Yes, the code style is a little over the top.
My intent is to provide some evidence
that there is a way to write procedural
logic descriptions using some of
old tools from the shed. The legends
of vhdl and verilog synthesis die hard.

For what it's worth, this was Xilinx ISE 7.1 and I just used the device
I had previously been working on, Virtex2 Pro.

Excellent. I will add your data to source comments.

-- Mike Treseler

 

[Remillard]

old tools from the shed. The legends
of vhdl and verilog synthesis die hard.

Wouldn't be a bad idea to start compiling a list of these things in a
FAQ or wiki someplace. I'm sure there are more things I avoid just
because it was not previously supported at some point in the past.

Excellent. I will add your data to source comments.

A bit of additional data (since I still have the synthesis results
window up), it claims a max frequency of 288 MHz, for whatever it's
worth. Synthesizer timing estimates are kind of wacky sometimes.

Best regards,
Mark Norton

Concept Development, Inc.
http://www.cdvinc.com

 

[Mike Treseler]

A bit of additional data (since I still have the synthesis results
window up), it claims a max frequency of 288 MHz, for whatever it's
worth. Synthesizer timing estimates are kind of wacky sometimes.

Got it, here you go:
http://home.comcast.net/~mike_treseler/

I just discovered, while doing the update,
that if I print to postscript from Modelsim
and tell it I have an E-size sheet, I
can fit some real long waves on one
"page" and the pdf viewer can zoom
all the way in.

-- Mike Treseler

 

[Mike Treseler]

Wouldn't be a bad idea to start compiling a list of these things in a
FAQ or wiki someplace. I'm sure there are more things I avoid just
because it was not previously supported at some point in the past.

Maybe. I'm not convinced that FAQs get read very much.
A search on google groups seems more likely.

-- Mike Treseler

 

[Rafal Pietrak]

Hi All,

For what it's worth, this was Xilinx ISE 7.1 and I just used the device
I had previously been working on, Virtex2 Pro.

=========================================================================
* Final Report *
=========================================================================

Device utilization summary:
---------------------------

Selected Device : 2vp40fg676-6

Number of Slices: 57 out of 19392 0%
Number of Slice Flip Flops: 50 out of 38784 0%
Number of 4 input LUTs: 107 out of 38784 0%
Number of bonded IOBs: 23 out of 416 5%
Number of GCLKs: 1 out of 16 6%


=========================================================================

I've put it through Xilinx ISE-8.1i to synthesize into xc3s50 device. The
result is slightly better:
=========================================================================

Device utilization summary:
---------------------------

Selected Device : 3s50pq208-5

Number of Slices: 44 out of 768 5%
Number of Slice Flip Flops: 50 out of 1536 3%
Number of 4 input LUTs: 84 out of 1536 5%
Number of bonded IOBs: 23 out of 124 18%
Number of GCLKs: 1 out of 8 12%


=========================================================================

But my fingers etched, and I did the same with the original Ian's code
from http://www.designabstraction.co.uk/EXAMPLE/HTML/rtl.htm. This time
I've got:
=========================================================================

Device utilization summary:
---------------------------

Selected Device : 3s50pq208-5

Number of Slices: 60 out of 768 7%
Number of Slice Flip Flops: 51 out of 1536 3%
Number of 4 input LUTs: 113 out of 1536 7%
Number of bonded IOBs: 23 out of 124 18%
Number of GCLKs: 1 out of 8 12%


=========================================================================

.... and the estimated network performance is: 160.873MHz v.s. 199.557MHz.
In favor of Mike's code.

The code is vastly different, and I'm a little lost comparing it. But if
those designs are functionally equivalent, can someone elaborate on what
was so 'straightforward' in Mike's design, that it made ISE create a
so much better device? Those critical 'optimization' hints/style?

BTW, Mike's source wins synthesize into XC9500-family, too.

-R

 

[Mike Treseler]

Rafal Pietrak wrote:

... and the estimated network performance is: 160.873MHz v.s. 199.557MHz.
In favor of Mike's code.

The code is vastly different, and I'm a little lost comparing it. But if
those designs are functionally equivalent, can someone elaborate on what
was so 'straightforward' in Mike's design, that it made ISE create a
so much better device? Those critical 'optimization' hints/style?

The only improvements I know of are the
elimination of all signal declarations and
the v_rst template. Both of these somehow
provide hints to synthesis in some cases.

-- Mike Treseler

 

[Jim Lewis]

old tools from the shed. The legends

Wouldn't be a bad idea to start compiling a list of these things in a
FAQ or wiki someplace. I'm sure there are more things I avoid just
because it was not previously supported at some point in the past.

This is something I have been thinking about too.
It is a necessary thing because just because it
is supported by one tool and it is supported by
1076.6-2004 does not mean that other synthesis
tool vendors support it. It would not be fun to
have a working design and try to port it to another
tool and not have it work - many bosses would not
be too understanding.

Would you prefer a FAQ or a website?
I was thinking a website. To avoid politics,
it may be best to have vendors self-certify
whether they support the coding styles or not.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Remillard]

This is something I have been thinking about too.
It is a necessary thing because just because it
is supported by one tool and it is supported by
1076.6-2004 does not mean that other synthesis
tool vendors support it. It would not be fun to
have a working design and try to port it to another
tool and not have it work - many bosses would not
be too understanding.

Would you prefer a FAQ or a website?
I was thinking a website. To avoid politics,
it may be best to have vendors self-certify
whether they support the coding styles or not.

I believe a website would be best honestly, as it would hook into the
search engines better. If some sort of mixture between users and
vendors could be reached, that would be ideal. If vendor A says
language feature B work, but in the field that doesn't work out in
practice, I'd like to be able to hear about it from someone right on the
page. I'm not sure what they used for CMS, but the PHP manual style
might be good. They've got a section of text above and then individual
user comments and contributed code snippets below pointing out gotchas,
howto's etc.

In the end, I'm not certain the form makes a lot of difference, just the
information dissemination does. The reason these legends of VHDL and
Verilog die hard is due to development cycles. I've got a design I've
got to get done in X days. Am I going to dink around with VHDL language
features that might be cool, but I don't know how (or if) they
synthesize? Probably not, unless by some act of the heavens X is
exceedingly large. I'm going to rely on the mental toolset of things I
know to work well. If there was some repository where I could browse
through and see language features reported to work and some ideas on how
it could be useful in a practical setting, I'd use more of the language.

Anyhow, fun things to think about. Good to see your name again, Jim.
I've still got your VHDL presentation books kicking around from a course
you did at TRW a few years ago. They've been real handy.

Best regards,
Mark Norton
Concept Development, Inc.
Irvine, CA
http://www.cdvinc.com

 

[Mike Treseler]

It is a necessary thing because just because it
is supported by one tool and it is supported by
1076.6-2004 does not mean that other synthesis
tool vendors support it. It would not be fun to
have a working design and try to port it to another
tool and not have it work - many bosses would not
be too understanding.

Yes, and a larger problem is knowing what
styles are available for use on a clean slate,
new design on up-to-date tools.

Would you prefer a FAQ or a website?
I was thinking a website.

I agree, websites are much easier to find.

To avoid politics,
it may be best to have vendors self-certify
whether they support the coding styles or not.

Trust, but verify.
Reference designs with a pass/fail testbench
are a good way to back up such self-certifications.

-- Mike Treseler