VHDL to schematic converter
Sam Duncan
I'm new to the whole VHDL scene and am developing using Xilinx ISE 4.2. Is
there any way (using Xilinx or other software) to convert VHDL to a
schematic so that the connections between different components can be easily
viewed?
Many thanks
Sam Duncan
--
Mike Treseler
> Hi
>
> I'm new to the whole VHDL scene and am developing using Xilinx ISE 4.2. Is
> there any way (using Xilinx or other software) to convert VHDL to a
> schematic so that the connections between different components can be easily
> viewed?
Leonardo and Synplicity have such viewers as an option.
Worth the money in my opinion.
-- Mike Treseler
Thomas Heller
And are they in the same price range as ISE, or magnitudes
above?
Thomas Heller
Keith R. Williams
the...@python.net says...
> "Mike Treseler" <mike.t...@flukenetworks.com> wrote in message news:3D7784A4...@flukenetworks.com...
> > Sam Duncan wrote:
> >
> > > Hi
> > >
> > > I'm new to the whole VHDL scene and am developing using Xilinx ISE 4.2. Is
> > > there any way (using Xilinx or other software) to convert VHDL to a
> > > schematic so that the connections between different components can be easily
> > > viewed?
> >
> >
> > Leonardo and Synplicity have such viewers as an option.
> > Worth the money in my opinion.
> Are there other benefits as well?
I found the Synplicity viewer very useful learning how to get the
desired output from the synthesizer. It allowed me to:
- see what the synthesizer was inferring from my code.
- see undesired inferred FFs and correct the code before
it bit me further down the line.
- ensure the proper primitives were being generated (SRL16s,
carry chains, RAM/ROM, etc.)
> And are they in the same price range as ISE, or magnitudes
> above?
Synplify is expen$ive, but IMO worth it.
----
Keith
Weng Tianxiang
Hi,
My advice is: NEVER LINK ANY VHDL DESIGN TO ANY SCHEMETICS AS A VHDL
BEGINNER.
You may imagine when the design become larger and larger, and beyond 1
million gates or more, how you can link it to a schemetics
efficiently?
The best way to treat VHDL like writing C++/C as a software engineer.
Weng
Ray Andraka
hardware you want, then write the VHDL to describe that hardware. Treating it a s a software
project is an invitation to disaster. Synplicity, Renior, Aldec ActiveHDL all offer RTL to
schematic viewers. These are invaluable tools, especially for those just starting out with
VHDL so that you can see what your coding is producing.
Weng Tianxiang wrote:
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email r...@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Mike Treseler
Thomas Heller wrote:
> Are there other benefits as well?
Visualization. It can draw you a top level block diagram
from empty entities or show synthesis details of a single block.
> And are they in the same price range as ISE, or magnitudes
> above?
The viewer option price is 1K-2K.
The full-up leo or synplicty is much more.
The cheapest way to get a viewer, if you can tolerate altera parts,
is to buy leo-oem license from altera and a viewer license from mentor.
-- Mike Treseler
Mike Treseler
> My advice is: NEVER LINK ANY VHDL DESIGN TO ANY SCHEMETICS AS A VHDL
> BEGINNER.
I hope you mean by this:
"don't write vhdl code that instances every gate and flop"
which is good advice.
However, I don't see any reason not to look at how the synth
fit the gates and flops for you. This closes the loop
and teaches you synthesis.
> You may imagine when the design become larger and larger, and beyond 1
> million gates or more, how you can link it to a schemetics
> efficiently?
Hierarchy. Click on one block and see 10 more, etc. etc.
-- Mike Treseler
Weng Tianxiang
A VHDL beginner must know:
1. What are the differences between a register and a logic cell and
where and when which one should be used.
2. How to write correct legal statements to produce a register and a
logic cell.
After having control over above 2 points, NEVER RETURN TO LOOK AT ANY
SCHEMETICS, WRITING IN VHDL IS SIMILAR TO WRITING C/C++ and EVEN MUCH
SIMPLER!
This is a segment of my design: An Altera counter call
CSRErrorCountA : lpm_counter generic map(LPM_WIDTH => 8)
port map(
clock => CLK66M,
aclr => LPMReset,
sclr => CSRErrorCountClear, -- when writing, clear it
cnt_en => CSRErrorCountEnable, -- without affecting sload, sset, or
sclr
cout => CSRErrorCountCout,
q => CSRErrorCount
);
This is C liberary "strncpy":
Char* strncpy(char* pTarget, constant char* pSource, int n);
You may conclude that there are no big differences between VHDL and C.
1. Make sure you understand each input parameter's meaning;
2. Make sure inputs parameters are correctly filled and formated;
3. It will do what is designated to do;
THERE IS NEVER A NEED TO REQUIRE DESIGNER TO LOOK AT WHAT IT GENERATES
WHEN USING VHDL.
Weng
Ray Andraka
perhaps true, but it also leaves lots of opportunity for someone to undercut your costs. SInce the prices of
FPGAs are more or less exponential with size, it doesn't take much to reduce the price substantially. The
flip-flops are the easy part for the synthesis, those are pretty much explicitly defined by RTL coding. The
stuff in between is what will kill the density or performance of your design, so knowing what the synthesizer
is producing is very valuable feedback. The key to large designs is not turning them into software problems
(all that does is extends your time in the lab and makes the part more expensive), rather it is making
extensive use of hierarchy. Using hierarchy makes it easier to visualize each part of the design as hardware,
easier to reuse design elements, easier for debug, easier for someone else to grok your design, easier for the
tools to chew on it, and the list goes on.
Writing VHDL should not be like writing C/C++. If it is, you are probably not covering all your bases with
respect to a proper hardware design. Guess what, I'll bet a beer that the designer of that ALtera LPM you
dropped into your design looked at the details of the design, and likely did some structural coding to make
sure that it was at least close to optimal.
Weng Tianxiang wrote:
--
David Rogoff
>
>THERE IS NEVER A NEED TO REQUIRE DESIGNER TO LOOK AT WHAT IT GENERATES
>WHEN USING VHDL.
>
>Weng
I'm glad I wasn't drinking when I read that. It's the funniest thing
I've seen in a long time!
David
Jos De Laender
>
> Mike Treseler <mike.t...@flukenetworks.com> wrote in message news:<3D77E5F...@flukenetworks.com>...
> > Weng Tianxiang wrote:
> >
> >
> > > My advice is: NEVER LINK ANY VHDL DESIGN TO ANY SCHEMETICS AS A VHDL
> > > BEGINNER.
> >
> >
> > I hope you mean by this:
> > "don't write vhdl code that instances every gate and flop"
> > which is good advice.
> >
> > However, I don't see any reason not to look at how the synth
> > fit the gates and flops for you. This closes the loop
> > and teaches you synthesis.
> >
> >
> > > You may imagine when the design become larger and larger, and beyond 1
> > > million gates or more, how you can link it to a schemetics
> > > efficiently?
> >
> >
> > Hierarchy. Click on one block and see 10 more, etc. etc.
> >
> > -- Mike Treseler
>
> A VHDL beginner must know:
> 1. What are the differences between a register and a logic cell and
> where and when which one should be used.
> 2. How to write correct legal statements to produce a register and a
> logic cell.
>
> After having control over above 2 points, NEVER RETURN TO LOOK AT ANY
> SCHEMETICS, WRITING IN VHDL IS SIMILAR TO WRITING C/C++ and EVEN MUCH
> SIMPLER!
> You may conclude that there are no big differences between VHDL and C.
> 1. Make sure you understand each input parameter's meaning;
> 2. Make sure inputs parameters are correctly filled and formated;
> 3. It will do what is designated to do;
>
> THERE IS NEVER A NEED TO REQUIRE DESIGNER TO LOOK AT WHAT IT GENERATES
> WHEN USING VHDL.
Dear,
I guess this statement is going to generate some fuzz ;-)
I basically don't agree, at least not for a beginner.
But I'm going to argument it on the C-language or even
better the C++ language.
In my opinion a lot of code bloat and inefficiency is
generated by people not knowing nor understanding what
their C/C++ compiler is generating from their source code.
I found it in the past _very _ instructive to inspect the
output of my C/C++ compiler in order to get a good
understanding what it is doing with all those source level
constructs. It learned me to how to write algorithms and
codes that are reasonably efficient. Of course the more
one programs, the less he needs to effectively look at the
output. He learned it.
In my opinion, the same is true for hardware design. The
problem is however _bigger_ due to one also having to
understand the massive parallelism of hardware (which is
not there in 'simple' software).
So here I would heavily recommend the beginner to
inspect over and over the output of their synthesizer
(or at least an intermediate format such as Synopsys' GTECH)
until they get a thorough understanding of what all those
VHDL constructs are doing exactly.
When he fully grasped this, it's time to think VHDL only.
Best regards,
Jos
Weng Tianxiang
Half year ago I presented my paper "HDL Code Inefficiency Sources and Its
Solutions" at HDL Conference 2002.
Here "HDL" refers to both VHDL and Verilog.
My paper and presentation files are available to anyone who is
interested in the problems and solutions by email request.
Thank you.
Weng Tianxiang
w...@umem.com
wengti...@yahoo.com
Micro Memory Inc.
9540 Vassar Avenue
Chatsworth, CA 91311
Tel: 818-998-0070
Fax: 818-998-4459
--------------------------------------------------------------------------------
Jos De Laender <Jos.De....@Pandora.Be> wrote in message news:<3D7BA7CE...@Pandora.Be>...
Clyde R. Shappee
Clyde
bulletdog7
I would agree if your goal is to write non synthesizable code, or you do
not care how fast it runs, and/or you do not care how big your die is.
However, I my business, I have to design chips that have high gate
count per pico acre, and run in the 100's of MHz. Every designer that
has ignored what he or she is building and just wrote the code as if it
was C has failed.
They fail because the code doesn't synthesize. They fail because there
are too many gates and the die size increases. They fail because there
are too many signals and the routeable channels grow the die. They fail
because they can not meet timing.
But I do want to thank you. It's opinions like this that keep me
employed... I'm the guy who has to come in and fix it.
Jerry
Jos De Laender
Dear,
_which_ problem ? There is with respect to the subject of this
thread not really a problem.
Learn by experience and careful examination of synthesis results
what a synthesizer does. Then start writing VHDL as an informed
software writer. Not thinking explicitly nor all the time about
the hardware but knowing damned well how your constructs are
going to be synthesized when you need this knowledge.
Regards,
Jos