Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Dual data rate in Xilinx WebPACK 7.1

Reply
Thread Tools

Dual data rate in Xilinx WebPACK 7.1

 
 
Ben Jones
Guest
Posts: n/a
 
      03-02-2006

"Rafal Pietrak" <(E-Mail Removed)-geek.com> wrote in message
news(E-Mail Removed)-geek.com...
> Couldn't help it Gave it another thought.... HDL semantics (or may be
> just WebPACK synthesizer implementation) look even stranger to me, now.


That is usually a sign of progress.

> The point is, that following your advice: if I were *reading* the HDL
> code, I'd imagine a 'priority decoder':
> 1) when reset_active --> do something...
> 2) when *it's*not*, but rising_edge(clk) occur --> do something else ...
> 3) when this isn't happening either, but there is a falling_edge() --> do
> yet another thing.
> Priority encoders do exist.


Granted. However, there's a world of difference between edges and levels
when it comes to synthesis. A priority encoder is a bit of combinatorial
logic that works as you describe above, but it works on levels, not edges:

if reset = '1' then
output <= "00";
elsif heads = '1' then
output <= "01";
elsif tails = '1' then
output <= "10";
else
output <= "11";
end if;

The difference is that combinatorial logic can be imagined as executing in
zero time, whereas rising_edge() and falling_edge() immediately imply some
notion of the passing of time. When a synthesis tool wants to build a piece
of combinatorial logic, it can basically use any combinatorial building
block that it wants. However, the synchronous building blocks in FPGAs (and
most digital systems) are rather more limited.

The task "transfer the value of signal A to signal B on the rising edge of
signal Clk" requires a register element - nothing else can do the job. If
you add to that "unless reset = '1', in which case assign '000' to signal
B", then a synchronous reset of that register is required. If instead you
prepend "if reset = '1' then B <= '000' else", then an asynchronous reset of
that register is required. If you go asking for
resets/sets/clears/clock-enables that aren't available, then the tool will
either try to emulate them (e.g. by adding AND gates) or will give up. The
same is true if you try to describe a transparent latch, or a double-edged
register, when such a thing isn't available in the technology.

> So it looks like I have to be *very* *very* cautious when writing HDL.


Don't be too cautious - you'll never get any work done! Mostly, it comes
down to learning the necessary idioms of the language (in this case,
synthesizable VHDL). Once you've written, simulated and synthesized a few
circuits you'll wonder what you ever thought was hard about it...

Cheers,

-Ben-


 
Reply With Quote
 
 
 
 
Brian Drummond
Guest
Posts: n/a
 
      03-04-2006
On Wed, 01 Mar 2006 11:34:24 +0100, Rafal Pietrak
<(E-Mail Removed)-geek.com> wrote:

>My final comment would be: I think that I've misinterpreted what VHDL
>'process' is. I thought of it as an 'abstract expression' of a 'circuit
>functionality' (as opposed to 'entity', which would be: a hardware
>component description/reference) ...


> /**-------------------------------------------------**/
>In other words: I tried to write an "HDL sentence" that describes circuit
>with *two* D-FF connected in series... and I ended up with a sentence
>describing a *single* D-FF but with dual-edge clock sensitivity. My
>lesson here is: a single 'process' does NOT describe an interconnect with
>two FFs.
>
>That's what I find surprising - first read (ok, first browse of VHDL
>textbook does not give that interpretation, really.


This is quite a good observation...

VHDL can describe those abstract expressions very well ... and a good
simulator like Modelsim will implement them correctly. Which is useful
for testbenches among other things - for example, you can express your
intent at the highest or cleanest level and verify its function.

But it's not so useful for actually implementing the design in hardware,
if the synthesis tool doesn't have a means of physically realising the
design. There, you need to transform the design into a lower level
description, which IS physically realisable.

The higher level description is still valuable - one use for it is to
run both implementations in parallel in a testbench, with a comparator
across their outputs to highlight any errors in the low level
implementation.

I have to agree that VHDL texts often highlight only one of these
aspects of VHDL - either the low-level aspect (so some people don't
realise VHDL has pretty good abstraction mechanisms) or the programming
language aspects - so others don't realise the compromises that have to
be made when targetting hardware...

I recommend a "VHDL synthesis guide" from your FPGA vendor of choice as
a starting point on the lower level aspects.

- Brian



 
Reply With Quote
 
 
 
 
Brian Drummond
Guest
Posts: n/a
 
      03-04-2006
On Thu, 02 Mar 2006 12:03:50 +0100, Rafal Pietrak
<(E-Mail Removed)-geek.com> wrote:

>Couldn't help it Gave it another thought.... HDL semantics (or may be
>just WebPACK synthesizer implementation) look even stranger to me, now.
>
>The point is, that following your advice: if I were *reading* the HDL
>code, I'd imagine a 'priority decoder':
>
>1) when reset_active --> do something...
>2) when *it's*not*, but rising_edge(clk) occur --> do something else ...
>3) when this isn't happening either, but there is a falling_edge() --> do
>yet another thing.


[...]

>So it looks like I have to be *very* *very* cautious when writing HDL.


Not *very* cautious.

The synthesiser will be pretty reliable at (a) delivering a reliable
hardware implementation of your design OR (b) informing you of something
it can't implement.

IMO it's not actually *wrong* to express your design at an abstract
level and in many ways it's actually a good thing - VHDL the _language_
can indeed "work like software". But be aware that VHDL the hardware
implementation tool often doesn't; it can either fail to implement the
design (which is good because it will report the error) or implement
something sub-optimal - far too large or far too slow - which is less
good.

Then you have to learn what to do different.

The "RTL" approach is a good safe way of expressing a hardware design in
VHDL, and in some cases it is necessary. I'd second the suggestion you
learn it, as a useful tool.

- Brian

 
Reply With Quote
 
Rafal Pietrak
Guest
Posts: n/a
 
      03-04-2006
On Sat, 04 Mar 2006 13:44:53 +0000, Brian Drummond wrote:
>
>>So it looks like I have to be *very* *very* cautious when writing HDL.

>
> Not *very* cautious.


Well. From the two weeks exposure to HDL, that I currently have, I'd stick
with the *very*

One reason is, that I don't have access to a simulator, so I try to build
*simple* circuits and then look at the RTL schematics I get from
synthesizer - most often then not, I get interconnects I didn't expected
So at least for now, I have to be cautious.

> The synthesiser will be pretty reliable at (a) delivering a reliable
> hardware implementation of your design OR (b) informing you of something
> it can't implement.


I think, that my current problem is, that I cannot reliably 'speak' to
synthesizer (in VHDL). Although the synthesizer is probably very reliable,
I've only started to learn how to control it. You probably don't remember
cases when you've started with HDL, but I assure you, that at my stage of
learning, even 'innocent' synthesizer warning makes you dug into RLF
schematics looking for errors. And even in cases when I cannot find
errors, I worry if the synthesize was correct. Even today I've created
another thread with a call for help on one such case (RAM block).

So again, sticking with *very*, for now.

> IMO it's not actually *wrong* to express your design at an abstract
> level and in many ways it's actually a good thing - VHDL the _language_
> can indeed "work like software". But be aware that VHDL the hardware
> implementation tool often doesn't; it can either fail to implement the
> design (which is good because it will report the error) or implement
> something sub-optimal - far too large or far too slow - which is less
> good.


Well, in that case, VHDL does not look too promising (at least from my
infant experience). If in real life (that is: in real designs) the
"abstract_description v.s. real_hardware" 'duality' is an omnipresent
engineer task, I'd expect HD-language to have at least minimal provisions
for conditional synthesize (or like font descriptions have hinting for
low-resolution rendering cases), but I haven't spotted it on my first
read of VHDL textbook. Are there any?

-R
 
Reply With Quote
 
Allan Herriman
Guest
Posts: n/a
 
      03-05-2006
On Sat, 04 Mar 2006 18:02:21 +0100, Rafal Pietrak
<(E-Mail Removed)-geek.com> wrote:

[snip]
>...I don't have access to a simulator...


There are open source, free or cheap simulators available for a number
of platforms.
You really should use one, as not using a simulator will make it next
to impossible to create working designs of any complexity.

http://www.vhdl.org/comp.lang.vhdl/FAQ3.html#sstuff

Allan.
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      03-05-2006
Rafal Pietrak wrote:
>
> My final comment would be: I think that I've misinterpreted what VHDL
> 'process' is. I thought of it as an 'abstract expression' of a 'circuit
> functionality' (as opposed to 'entity', which would be: a hardware
> component description/reference) ... surprisingly, synthesizer treats the
> 'process' as a single hardware box, too; Just written down in different
> words (different HDL sentences). Natural consequence is, that synthesizer
> *tries*to*map* my 'process' to existing FPGA 'component', instead of
> *building* something, according to my 'process specs' .... from FPGA
> resources, like couple of D-FF.


You will get lots of opinions on this subject,
but mine is that the average design entity
ought to have exactly *one* synchronous process
composed of an if statement separating
initialization, update, and output procedures.

See the reference design here for an example of this style.

http://home.comcast.net/~mike_treseler/

Only with this style can 'abstract expression' be used
effectively for synthesis, because this requires multiple
process variables with entity scope.

I agree with you, that using multiple processes makes the same
block diagram as using multiple entities. In both cases
multiple instances are wired together. This fits the
schematic orientation that many designers prefer, but
outside the blocks, all is a netlist.

-- Mike Treseler
 
Reply With Quote
 
Rafal Pietrak
Guest
Posts: n/a
 
      03-05-2006
On Sun, 05 Mar 2006 12:25:03 +1100, Allan Herriman wrote:
> There are open source, free or cheap simulators available for a number
> of platforms.
>
> http://www.vhdl.org/comp.lang.vhdl/FAQ3.html#sstuff
>
> Allan.


!!

Oh, that will help!

Any recommendations on which one to try first? ... based on assumption,
that I've made my first steps using Xilinx WebPACK and I'd really love to
get back from MS-Windows to Linux (WebPACK fails to install on Debian).

-R
 
Reply With Quote
 
Allan Herriman
Guest
Posts: n/a
 
      03-05-2006
On Sun, 05 Mar 2006 11:57:05 +0100, Rafal Pietrak
<(E-Mail Removed)-geek.com> wrote:

>On Sun, 05 Mar 2006 12:25:03 +1100, Allan Herriman wrote:
>> There are open source, free or cheap simulators available for a number
>> of platforms.
>>
>> http://www.vhdl.org/comp.lang.vhdl/FAQ3.html#sstuff
>>
>> Allan.

>
>!!
>
>Oh, that will help!
>
>Any recommendations on which one to try first? ... based on assumption,
>that I've made my first steps using Xilinx WebPACK and I'd really love to
>get back from MS-Windows to Linux (WebPACK fails to install on Debian).


It might be worth staying with Windows if you are interested in the
low cost tools.

I can recommend Simili:
http://www.symphonyeda.com/editions.htm
You can run it in 'free' mode which doesn't require a license, but is
crippled.

The crippled versions of Modelsim also work (to a degree). These are
available from Xilinx and Altera as part of low cost packages.

Modelsim is also available in a native Linux version, but I don't
believe there is any way of getting that at less than full price (some
thousands of dollars for a time limited license).


If you're serious about designing with HDL, it's worth paying for a
simulator. You will use this tool more than any other (except for
your text editor).

Regards,
Allan
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      03-05-2006
Allan Herriman wrote:

> It might be worth staying with Windows if you are interested in the
> low cost tools.


Simili is available for linux or windows here:
http://www.symphonyeda.com/proddownloads.htm

Either will run unlicensed in a slow, restricted mode,
but this is good enough to learn with, and it is free.
You can fully license either for $300 per year,
which is the cheapest usable linux vhdl simulator that I know of.

> The crippled versions of Modelsim also work (to a degree). These are
> available from Xilinx and Altera as part of low cost packages.


For a low-cost windows version, I would recommend the modelsim version
that comes with Quartus. For functional simulation, there is really
nothing Altera-specific about it.

> Modelsim is also available in a native Linux version, but I don't
> believe there is any way of getting that at less than full price (some
> thousands of dollars for a time limited license).


That's the SE version. Many many thousands I'm afraid.
But worth the money for commercial use.

> If you're serious about designing with HDL, it's worth paying for a
> simulator. You will use this tool more than any other (except for
> your text editor).


True. Trial and error synthesis is very tedious,
and I can't even remember how the logic analyzer
works anymore.

-- Mike Treseler
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      03-06-2006
Mike,

I've seen your template, and although I prefer not to split everything
out into separate procedures for init, update, and output, I really
like the concept of a single process, even/especially for combo
outputs.

However, if there are storage elements that you do not want/need to
reset (like clb rams that cannot be reset), leaving them out of the
"init" process/clause will result in a clock disable on reset (using
synplicity at least) for those elements, which is seldom wanted either.
Synplicity warns you when this happens, but it cannot be avoided in
your template. Note that the clock disable is required to generate
hardware that behaves like the RTL in such cases, since if the reset is
active, the clocked clause will not execute.

I have found that, putting the init code at the end of the process, in
its own if-then clause, allows you to specify only those storage
elements that need reset, without the clock disable on those elements
left unreset. For example:

process (reset, clock) is
....
begin
if rising_edge(clock) then
update; -- update internal variables (regs or combos)
end if;
if reset then
init; -- reset desired flops
end if;
output; -- assign output signals
end process;

Note that you don't get a friendly reminder during synthesis that you
dropped a register from your init clause, but at least it works without
the clock disable.

Andy Jones

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
limitations on xilinx webpack Dave VHDL 1 06-12-2006 06:01 AM
Xilinx WebPack 8.1i "desoptimization" Rafal Pietrak VHDL 5 04-12-2006 05:01 PM
Xilinx ISE Webpack problem u_stadler@yahoo.de VHDL 1 02-13-2006 06:05 AM
Xilinx Webpack mep VHDL 10 09-30-2004 09:13 PM
xilinx webpack Urban Stadler VHDL 4 08-18-2004 08:44 PM



Advertisments