VHDL Tools ?

[legacy]

I think it's much simpler

sure, it's simpler: have you ever done something similar? I guess No, because if you had done, you would have known how many plugs in the basket it gives.

buddy, it's very very difficult to reverse-engineer bitstreams, and it's even more difficult to obtain silicon information since they are closed into IP and Vendors don't want to release anything.

p&r algorithms are rather straightforward and there must be simple open-source implementations already if you search well.

Really? So, show me where we can find.

[legacy]

What I really like about Modelsim is the capability to check sources, and tell you

if variables are in safe usage
if variables read contradiction
if the scope is correct

... a lot of these checks to be sure that the description is deterministic for hardware


e.g. the following code aims to be the HDL description of a Priority Encoder whose implementation uses loop and exit statements. It looks generic, and well done, but it doesn't pass the check

Code: [Select]

priority_encoder:
  process (din) is
  begin
    dout<=(others=>'0');
    for i in din'range loop
      dout<=conv_std_logic_vector(i,dout'length);
      exit when (din(i)='1');
      end loop;
  end process;

Thanks to Mentor Graphics 

Well, frankly I would had been surprised if it had not catch the mistake (for the money it costs, I mean), but .. well, a lot of vhdl tools simply doesn't care about these checks (e.g. TINA's HDL-companion doesn't catch it), and you might (if even ISE doesn't catch it) get strange behaviors once the bugged-code gets synthesized 

[hamster_nz]

This paper is interesting:

"Analyzing the Divide between FPGA Academic and Commercial Results"
http://plato.fea.ugent.be/firw/files/P115.438.pdf

TLDR: Commercial tools on average use 5% less resources, have 224% higher FMAX, and take 46% of the time to run compared to Academic P+R flows

Depends wildly on the benchmark set though, so it is always easy to find a counter-example, but on the whole the vendor tools are pretty good at what they do.

However, I must say that the Project IceStorm flow (http://www.clifford.at/icestorm/) is superb. small, light fast. But can you trust it to implement important stuff?

(If I was doing FPGAs for a job, I would be tempted to use Icestorm as the main R&D toolchain, and then vendor tools for release runs...)

[NorthGuy]

p&r algorithms are rather straightforward and there must be simple open-source implementations already if you search well.

Really? So, show me where we can find.

Try this website: http://www.google.com

Then you can find this: http://torc-isi.sourceforge.net/
They have placer and router and they made a good progress understanding the structure of Xilinx bitstreams to the point that they generate their own bitstreams.

Or this: http://rapidsmith.sourceforge.net/
This one appears to be a complete toolchain.

But they seem to be dying from the lack of attention. Like I said - there's no demand.

[NorthGuy]

But can you trust it to implement important stuff?

"... who would fardels bear,
To grunt and sweat under a weary life,
But that the dread of something  ..."

[Sal Ammoniac]

Vivado is bloated, slow

It does tend to be that, but if you have a fast machine, it isn't too bad. When I started working with FPGAs a little over a year ago, I upgraded my development machine to speed up Vivado. I replaced the hard drive with an M.2 NVME SSD and upped the memory to 32GB. Now Vivado runs much faster and isn't so much a slowpoke.

[rstofer]

Vivado is bloated, slow

It does tend to be that, but if you have a fast machine, it isn't too bad. When I started working with FPGAs a little over a year ago, I upgraded my development machine to speed up Vivado. I replaced the hard drive with an M.2 NVME SSD and upped the memory to 32GB. Now Vivado runs much faster and isn't so much a slowpoke.

I just finished assembling a machine built with the specific intent of picking up the pace with Vivado.  I7 7700K, 4.2-4.5 GHz and 32 GB or 4133 MHz DDR4 along with a 1 TB M.2 SSD 3.2GB/sec read and 1.9 GR/s write.  It is much faster than my older I7 860.

OTOH, there are only a couple of processes that actually load up the CPU.  One of them is when compiling the block design.  Even though I select 8 tasks, I really only get 2 for most of the build process.  There is no reason to go for 10 cores 20 threads, Vivado (at least the WebPack) won't use them.

I haven't done any step by step timing comparison.  The new machine is much faster but I don't want to do a post mortem and figure what those minutes saved cost in term of minutes per dollar.

One of the Digilent tutorials states that the build from block design to a completed bitfile can take between 5 and 60 minutes depending on your machine.  I want to be on the 5 minute end of the deal.  Short attention span!

[hamster_nz]

But can you trust it to implement important stuff?

"... who would fardels bear,
To grunt and sweat under a weary life,
But that the dread of something  ..."

Damn! I never knew that Shakespeare used Vivado...

[jefflieu]

I am trying to learn VHDL, specifically in a Xilinx ISE / Spartan 6 environment. Am I missing something here, or is it horrendously difficult to understand existing VHDL projects?
I have generated code to access DDR2 memory using the Xilinx MIG, and I am trying to understand the example design. In a project written in a mainstream language (C for example) I'd expect to be able to generate some form of structure diagram (what calls what etc), a cross reference listing, showing what variables are accessed by what modules and so on. These types of reports are incredibly useful when you are trying to get your head around an unknown codebase.
As I say, unless I'm missing something, it is not possible to obtain this type of information for a VHDL codebase (and I realise that one cant compare exactly languages like C and VHDL, but the principle of using tools to analyse and cross reference etc still applies).

So, experienced VHDL hackers out there, when faced with understanding a new VHDL codebase of non-trivial size (>2000 LOC), what process / tools / magical incantations would you use?

Cheers

Tim

I personally feel HDL is not meant to be read to understand the design.
It's always a pain reviewing HDL code or understanding legacy code.
It drives you mad when you have a few processes interacting, and a few modules interacting with each other :s
I think the cache/memory in my brain is not enough to hold the concurrent information and signals, cycle after cycles.
My method is : understanding the design first, what it's supposed to do, then run the test bench provided, if it works ... yay! .if it's broken --> trace and fix it, having the waveform plotted in front of you is billion times better.

[legacy]

Code: [Select]

svn co https://torc-isi.svn.sourceforge.net/svnroot/torc-isi/trunk torc
cd src
make


Code: [Select]

OrangeCube src $ make
cc -x c++ -g -Wall -Werror -I./ -I/usr/bin/include   -c -o /root/hdl/torc/src/.//torc/placer/Placement.o /root/hdl/torc/src/.//torc/placer/Placement.cpp
In file included from /root/hdl/torc/src/.//torc/placer/Placement.cpp:19:
./torc/placer/Placement.hpp: In constructor 'torc::placer::Placement::Placement(torc::placer::DeviceWrapper&, torc::physical::DesignSharedPtr)':
./torc/placer/Placement.hpp:131: error: 'cout' is not a member of 'std'
./torc/placer/Placement.hpp:138: error: 'cout' is not a member of 'std'
./torc/placer/Placement.hpp:165: error: 'cout' is not a member of 'std'
./torc/placer/Placement.hpp:169: error: 'cout' is not a member of 'std'
./torc/placer/Placement.hpp:172: error: 'cout' is not a member of 'std'
./torc/placer/Placement.hpp:201: error: 'cout' is not a member of 'std'
./torc/placer/Placement.hpp: In member function 'void torc::placer::Placement::initialPlacement()':
./torc/placer/Placement.hpp:212: error: 'cout' is not a member of 'std'
./torc/placer/Placement.hpp:236: error: 'cout' is not a member of 'std'
./torc/placer/Placement.hpp:241: error: 'cout' is not a member of 'std'
./torc/placer/Placement.hpp:256: error: 'cout' is not a member of 'std'
./torc/placer/Placement.hpp:266: error: 'cout' is not a member of 'std'
./torc/placer/Placement.hpp:270: error: 'cout' is not a member of 'std'
./torc/placer/Placement.hpp: In member function 'void torc::placer::Placement::writePlacementToDesign()':
./torc/placer/Placement.hpp:285: error: 'cout' is not a member of 'std'
./torc/placer/Placement.hpp: In member function 'void torc::placer::Placement::updateCostFull(bool)':
./torc/placer/Placement.hpp:308: error: 'cout' is not a member of 'std'

It tried and failed with both of the following

i686-pc-linux-gnu-4.4.7
i686-pc-linux-gnu-4.9.3

As expected .... once again Opensource is making people to waste A LOT of time in order to have things working in a decent way

This is the point: you have to waste a lot of time on the tool, to make things working, instead of using the tool to develop something.


And I am sure that even if compiled it won't work out of the box and it will require much much much more time.

Fanatics are happy to see news online, anyway.

[NorthGuy]

This is the point: you have to waste a lot of time on the tool, to make things working, instead of using the tool to develop something.

This is how open source works. If you like to use it, you work on it, advance it and contribute your changes back. If there's enough contributors, it grows and becomes useful at some point. If there's no demand, it dies. You can still watch the code if you wish.

[legacy]

Code: [Select]

/root/hdl/torc/src/.//torc/common/UnitTestMain.cpp: In member function 'virtual void RegressionFilter::test_suite_finish(const boost::unit_test::test_suite&)':
/root/hdl/torc/src/.//torc/common/UnitTestMain.cpp:93:16: error: 'const class boost::unit_test::test_suite' has no member named 'p_enabled'
    inTestSuite.p_enabled.set(false);
                ^
/root/hdl/torc/src/.//torc/common/UnitTestMain.cpp: At global scope:
/root/hdl/torc/src/.//torc/common/UnitTestMain.cpp:104:46: error: invalid use of incomplete type 'class boost::unit_test::test_tree_visitor'
 class DebugFilter : public boost::unit_test::test_tree_visitor {
                                              ^
In file included from /usr/include/boost/test/tree/observer.hpp:16:0,
                 from /usr/include/boost/test/unit_test_log.hpp:18,
                 from /usr/include/boost/test/tools/old/impl.hpp:19,
                 from /usr/include/boost/test/test_tools.hpp:46,
                 from /usr/include/boost/test/unit_test.hpp:18,
                 from /root/hdl/torc/src/.//torc/common/UnitTestMain.cpp:25:
/usr/include/boost/test/detail/fwd_decl.hpp:27:8: error: forward declaration of 'class boost::unit_test::test_tree_visito '
 class  test_tree_visitor;
        ^
/root/hdl/torc/src/.//torc/common/UnitTestMain.cpp: In member function 'virtual void DebugFilter::visit(const boost::unit_test::test_case&)':
/root/hdl/torc/src/.//torc/common/UnitTestMain.cpp:111:14: error: 'const class boost::unit_test::test_case' has no member named 'p_enabled'
   inTestCase.p_enabled.set((enabled.find(inTestCase.p_name.get()) != std::string::npos));
              ^
/root/hdl/torc/src/.//torc/common/UnitTestMain.cpp: In constructor 'TestFixture::TestFixture()':
/root/hdl/torc/src/.//torc/common/UnitTestMain.cpp:160:4: error: 'traverse_test_tree' is not a member of 'boost::unit_tes '
    boost::unit_test::traverse_test_tree(boost::unit_test::framework::master_test_suite(),
    ^
In file included from /usr/include/boost/config.hpp:61:0,
                 from /usr/include/boost/test/test_tools.hpp:17,
                 from /usr/include/boost/test/unit_test.hpp:18,
                 from /root/hdl/torc/src/.//torc/common/UnitTestMain.cpp:25:
/root/hdl/torc/src/.//torc/common/UnitTestMain.cpp: At global scope:
/root/hdl/torc/src/.//torc/common/UnitTestMain.cpp:166:1: error: expected initializer at end of input


Frankly, even making source compiled, I am not sure at this point that P&R algorithms are well done. I suspect some bug there (as usual), and more of MY time needs to be involved in sorting out stuff.

edit:
so, there are a few problems:

first, it requires lib_Boost but it's not clear WHICH? one.
When it was brutally given all-* from the repository, and it sorted out.
Not a good way to fix problems, but sources are a mess and I can't spent too much time on them.

Second, it requires to relax -Werror because the C++ code style is not well done.
I sorted out removing the flag.

Sources are compiled with  C++98, which means it's a very very very old-code-style 

[NorthGuy]

Frankly, even making source compiled, I am not sure at this point that P&R algorithms are well done. I suspect some bug there (as usual), and more of MY time involved in sorting out stuff.

I completely agree. I never waste my time with other people's code for exact these reasons.