Low Cost PCB's Low Cost Components

Author Topic: VHDL Tools ?  (Read 1839 times)

0 Members and 1 Guest are viewing this topic.

Offline tja

  • Contributor
  • Posts: 14
VHDL Tools ?
« on: August 11, 2017, 12:23:22 AM »
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
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 2566
Re: VHDL Tools ?
« Reply #1 on: August 11, 2017, 01:17:02 AM »
is it horrendously difficult to understand existing VHDL projects?

If you start with complex projects ...
DDR-ish is assumed "advanced".
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 2566
Re: VHDL Tools ?
« Reply #2 on: August 11, 2017, 01:25:45 AM »
I'd expect to be able to generate some form of structure diagram

like Scitools dot com Understand (C/C++) ?

compare exactly languages like C and VHDL

Sigasi helps you to write your code, but it's like Eclipse (autocomplete, hashing, ...).
It's not like SciTools-Understand. If that was your question.

I mean ModelSim is *THE* tool. You can integrate it inside ISE.
Never tried on Vivado.
 

Online stmdude

  • Frequent Contributor
  • **
  • Posts: 356
  • Country: se
Re: VHDL Tools ?
« Reply #3 on: August 11, 2017, 02:39:04 AM »
Even if you start with a _much_ simpler design than a DDR-controller, (in my experience) you'll have issues reading other peoples code.

First off, call-graphs and static analysis doesn't really makes sense in an HDL context, as everything is concurrent. There's no calls, functions etc...

Also, HDL languages seem to have gotten stuck somewhere in the 80s. None of the modern niceties of a modern language is present. No namespaces, structs, etc.  All of this is implementable in a HDL (as it has no bearing on the outputted code), but it makes it _much_, _much_ easier to organize ones code and make it more readable.

Since it pretty much is impossible to write clean and understandable HDL once you get up to scale, understanding other peoples projects will be difficult.

In the end, I pretty much adapted the strategy "I'll write something just like this module, and I'll copy the sh*t of out of it" (copyrights be damned). Once I got along a bit, I started to understand the original much better, and I could discontinue my own version, and use the original instead..
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 12440
  • Country: nl
    • NCT Developments
Re: VHDL Tools ?
« Reply #4 on: August 11, 2017, 05:15:00 AM »
Even if you start with a _much_ simpler design than a DDR-controller, (in my experience) you'll have issues reading other peoples code.

First off, call-graphs and static analysis doesn't really makes sense in an HDL context, as everything is concurrent. There's no calls, functions etc...

Also, HDL languages seem to have gotten stuck somewhere in the 80s. None of the modern niceties of a modern language is present. No namespaces, structs, etc.  All of this is implementable in a HDL (as it has no bearing on the outputted code), but it makes it _much_, _much_ easier to organize ones code and make it more readable.
I guess you missed VHDL which can do all that!
More on topic: there is Sigasi (both standalone and Eclipse plugin) but they only offer a node locked subscription model. For Eclipse there is also the free/open source Veditor plugin which helps to deal with large VHDL projects.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline tja

  • Contributor
  • Posts: 14
Re: VHDL Tools ?
« Reply #5 on: August 11, 2017, 06:48:17 AM »
While VHDL executes concurrently, the source code is still structured (or can be structured) in a nested (for want of a better word) fashion, and some kind of structure diagram still makes sense if you are trying to make sense of a large codebase. The DDR example I am trying to understand is nested at least 6 deep (as in component instantiations).

Stuck in the 80's? Totally agree. While the hardware maybe moving forward in leaps and bounds, the software is decades behind - or at least the Xilinx stuff. (Newer VHDL standards may be more capable, but don't tell me - tell Xilinx). And decades behind in terms of the most basic best practice - formatting, naming standards, comments|O

Haven't tried Sigasi - looks like all the best features are paid for, but I ought to at least try the free version. Certainly looks the most professional VHDL specific offering.

Couldn't get veditor to install on my Eclipse (Mars) - looks like they haven't kept up with the latest installations standards.

Tried SVeditor (IIRC) - totally oriented towards System Verilog (as the name suggests!) - VHDL functionality is very basic.

I have resorted to rolling my own Python regular expression code (heavily based on VHDL Analyser) to provide some (pretty crude) cross ref and structure analysis, which is helping me understand this code base.
 

Online NorthGuy

  • Frequent Contributor
  • **
  • Posts: 420
  • Country: ca
Re: VHDL Tools ?
« Reply #6 on: August 11, 2017, 07:07:26 AM »
... and some kind of structure diagram still makes sense if you are trying to make sense of a large codebase.

I guess that would be schematics.
 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 1184
  • Country: nz
Re: VHDL Tools ?
« Reply #7 on: August 11, 2017, 07:21:19 AM »
Everybody loves to blame the tools, but IMO difficulty to understand behavioral HDL is an inherent problem.

(single-threaded) Procedural code tells a story, and has relatively isolated context - you can look at small bits in isolation, and you know exactly what is going on, and how it achieves its result. And you can also make a whole lot of assumptions too - however with SMP or parallel systems (or even signals and interrupts) it can get a little more complex quite quickly.

HDL code is the blueprint for a machine, and like any other machine, a machine made of simple bits. If I hand you an cog from an automatic transmission and ask "what exactly does this do?" it is a very hard question to answer (unless you are a transmission expert). You know it is a cog, and it might be 200mm and have 50 teeth, but to understand what it does and how it does it relies on context and the fine detail of its iteration with other parts in the system.

If it isn't a standard design pattern that you recognize (f.e. "oh that is the idler thrust plate switcher cog") , or you can't find enough documentation (e.g. comments in VHDL) then you really need to watch it in action to see how it works - hence why simulating HDL modules is usually required for understanding in tricky cases.

As you get to the higher levels it tends to get easier to put everything in context, as you work at a more structural level - just as understanding how a car works is far easier than an automatic transmission works.
 

Offline agehall

  • Regular Contributor
  • *
  • Posts: 72
  • Country: se
Re: VHDL Tools ?
« Reply #8 on: August 11, 2017, 02:48:49 PM »
@tja - you are thinking too much in terms of software. HDLs is not software, it's hardware. The sooner you stop thinking of it in terms of software, the sooner you'll understand it.
 

Offline dgtl

  • Regular Contributor
  • *
  • Posts: 100
  • Country: ee
Re: VHDL Tools ?
« Reply #9 on: August 12, 2017, 03:28:24 AM »
Vivado has a very good schematics viewer. After synthesis or implementation, you can visualize the results. You can start from whatever node in structure and go from there: select some signal in the structure list and press f4 (afaik it was in right-click menu, too). The schematics viewer shows only that node up to the hierarchy boundary. When double-clicking the interface at the boundary, the view is expanded (double click on the side you want to expand to). This is a very powerful feature to track down signals in very large projects and to verify that the synthesizer understood the code the same way you intended to write it (I always write code by thinking at the synthesis result and then later verify that it matches). In case of targeting very high clock frequencies, the result must be considered while writing the code. For Xilinx 7-series, you have to understood the details about 6-LUTs and then try to pipeline the code to fit in usually 1 LUT between registers and worst case 2 LUTs to reach the highest clock frequencies possible for the chip. For a large component, it gets quite tricky (my last work is a massively parallel 25-stage pipelined module having >10k LUT, a lot of blockram and distram and has to run at 300MHz for Artix7 -1 speed grade).

I'm using SVEditor for editing my SystemVerilog sources on Eclipse Neon (Linux host). I have used veditor and it did work on Eclipse Neon, but when by mistage a systemverilog file was opened with it and it saw systemverilog syntax (x='{default:'1}), it crapped out so terribly, that eclipse needed a restart - so it is currently uninstalled on my machine.

SystemVerilog has evolved a lot compared to old verilog, but the support on Vivado is terribly buggy. In the last month, I've met a bunch of cases where synthesis just segfaults. Also there are corner cases, where either Vivado synthesis or simulator misunderstands the code and creates something stupid. Sometimes one of them handles things correctly and the other messes up and sometimes vice versa. So a lot of time is spent on tracking down Vivado bugs and then working around them. For systemverilog, the things to avoid are streaming operator (pack/unpack) and +: and -: indexing of arrays. Also it is good to use a lot of intermediate signals as the tools tend to mess up when a lot of different operations are on one line.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 3001
  • Country: us
Re: VHDL Tools ?
« Reply #10 on: August 12, 2017, 07:00:04 AM »
I don't think I would start my VHDL career with MIG and DDR<anything>.  Like everything else in life, you have to crawl before you walk before you run.

Blinking an LED is trivial but it does prove that the toolchain, board and user are all on the same page.

Go through a VHDL book that discusses what I think of as 'patterns'.  There is a pattern for describing just about everything.  Gates, registers, decoders, multiplexers, priority trees and finite state machines.  Given these building blocks, design something.  Maybe a simple CPU - nothing major, perhaps an elementary machine like BLUE (Computer Architecture - Caxton C Foster 1971).  This machine can be built without an FSA because it uses a LOT of timing slots.  It also uses a bus architecture (open collector type stuff) and you may want to omit that and use a MUX where appropriate.

Once you have written several thousand lines of code and gotten a couple of projects running, come back to the MIG project and see what you think.  I always have trouble reading other people's code and when I see 90% of code is variable assignments and not signals, I know I am out of my league.  Same with Verilog - I just don't quite 'get it'.  Probably because I have never spent the time to learn.  I started with VHDL and that is where I'll stay.

Seriously, it's all about 'patterns'.  You look at an FSA and you immediately know how it's going to work.  It may have 100+ states spread over pages and pages of code but it still fits the 'pattern'.
 

Offline julian1

  • Frequent Contributor
  • **
  • Posts: 270
  • Country: au
  • http://blog.julian1.io
Re: VHDL Tools ?
« Reply #11 on: August 12, 2017, 10:37:20 AM »
Never tried them, but some alternatives are, 

  - Chisel which is embedded in scala https://chisel.eecs.berkeley.edu/
  - Bluespec proprietary, apparently similar to Haskell https://en.wikipedia.org/wiki/Bluespec
  - Clash, functional/haskell inspired, http://www.clash-lang.org/

They synthesize/generate a verilog/vhdl target, in order to interoperate with a hardware vendor's tools.

 

Offline mac.6

  • Regular Contributor
  • *
  • Posts: 58
  • Country: fr
Re: VHDL Tools ?
« Reply #12 on: August 14, 2017, 04:46:33 AM »
There is also spinalHDL, quite close to chisel but with nice differences.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 3001
  • Country: us
Re: VHDL Tools ?
« Reply #13 on: August 14, 2017, 05:42:37 AM »
So, if I were to go somewhere and get a job working with FPGAs, which tools would I be compelled to use?  I'd be willing to bet it will be one of the main vendor tools.  None of the obscure tools are going to be used in industry.

With that thought in mind, I would look at the Xilinx, Altera and Lattice toolchains and leave all the other stuff for the academics.

Beyond synthesis and simulation, tools need a detailed understanding of the FPGA fabric and the vendors aren't going to supply it for IP reasons.  Place and route is certainly chip specific and with more complex chips, the logic of P&R gets even more difficult.  Even the pin IO structure is complicated and not at all standardized.

Here is an interesting article that delves into why there aren't going to be any non-vendor toolchains in use:

http://www.eejournal.com/article/20161004-opensource/

Just be happy that there are free versions of the vendor tools.  Sure, they're limited, but they get you started and are quite capable of creating fairly large projects.


 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 12440
  • Country: nl
    • NCT Developments
Re: VHDL Tools ?
« Reply #14 on: August 14, 2017, 05:59:56 AM »
So, if I were to go somewhere and get a job working with FPGAs, which tools would I be compelled to use?  I'd be willing to bet it will be one of the main vendor tools.  None of the obscure tools are going to be used in industry.

With that thought in mind, I would look at the Xilinx, Altera and Lattice toolchains and leave all the other stuff for the academics.
You have to split between doing the synthesis, p&r etc and editing / managing HDL. Editing / managing HDL is better left to IDEs which specialise in that. In case of Xilinx you can do use ISE only for the synthesis etc bit or even do entirely without ISE and use makefiles / scripts for the build process. Personally I'm using Eclipse + veditor to edit/manage VHDL and only use ISE for the synthesis etc.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 2566
Re: VHDL Tools ?
« Reply #15 on: August 14, 2017, 06:53:05 AM »
open source FPGA code will be difficult for all the reasons pointed out in this article

no mater anyway
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 2566
Re: VHDL Tools ?
« Reply #16 on: August 14, 2017, 06:54:44 AM »
use makefiles / scripts

Modelsim scripts here  :D
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 2566
Re: VHDL Tools ?
« Reply #17 on: August 14, 2017, 09:20:38 AM »
What is annoying is that, according to VHDL specification, the predefined attribute e.g. 'left can be applied to integer type, but apparently this isn't supported by some synthesis tools and simulators.

In Xilinx ISE webpack is not supported  :palm: :palm: :palm:
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 2566
Re: VHDL Tools ?
« Reply #18 on: August 14, 2017, 09:23:31 AM »
Code: [Select]
  constant counter0_right    : integer := 15;       
  constant counter1_right    : integer := 7; 
  signal counter0            : integer range 0 to counter0_right:=0;   
  signal counter1            : integer range 0 to counter1_right:=0;

...
    elsif rising_edge(in_clock) then     
        if (counter1 < counter1_right) then
          counter1   <= counter1 +1;
        else
...

have to work around it
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 12440
  • Country: nl
    • NCT Developments
Re: VHDL Tools ?
« Reply #19 on: August 14, 2017, 09:26:01 AM »
I guess the problem is that the number of bits of an integer is undefined so the signal cannot be translated to real hardware.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 1184
  • Country: nz
Re: VHDL Tools ?
« Reply #20 on: August 14, 2017, 10:06:20 AM »
What is annoying is that, according to VHDL specification, the predefined attribute e.g. 'left can be applied to integer type, but apparently this isn't supported by some synthesis tools and simulators.

In Xilinx ISE webpack is not supported  :palm: :palm: :palm:

X'high      The upper bound of X
X'low      The lower bound of X
X'left      The leftmost bound of X
X'right      The rightmost bound of X

Does the idea of 'leftmost' and 'rightmost' apply to integer's range? I guess it should, but depends on 'to' or 'downto' being used in the range....

Maybe 'high' and 'low' will work as desired?
« Last Edit: August 14, 2017, 10:09:52 AM by hamster_nz »
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 2566
Re: VHDL Tools ?
« Reply #21 on: August 14, 2017, 10:53:46 AM »
X'high      The upper bound of X
X'low      The lower bound of X
X'left      The leftmost bound of X
X'right      The rightmost bound of X

Modelsim says it's OK, it accepts the code and the simulation goes fine
ISE claims that object prefix must be an array, which is not correct according to vhdl definition

If you define something as integer, no matter if you resize the range, types all come with a left and right border.
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 2566
Re: VHDL Tools ?
« Reply #22 on: August 14, 2017, 10:56:14 AM »
number of bits of an integer

number of bits has nothing to deal with a language type's range.

 

Online legacy

  • Super Contributor
  • ***
  • Posts: 2566
Re: VHDL Tools ?
« Reply #23 on: August 14, 2017, 11:13:02 AM »
Code: [Select]
subtype col_t is std_logic_vector(number_of_cols-1 downto 0);

function get_ones_in_column(inp: col_t)
...
for i in inp'range loop
...

this works as expected on both ISE and Modelsim, anyway  :-//
 

Online NorthGuy

  • Frequent Contributor
  • **
  • Posts: 420
  • Country: ca
Re: VHDL Tools ?
« Reply #24 on: August 14, 2017, 03:01:55 PM »
Here is an interesting article that delves into why there aren't going to be any non-vendor toolchains in use:

http://www.eejournal.com/article/20161004-opensource/

I think it's much simpler. There's no demand for non-vendor tools. If there was a demand, it wouldn't be so difficult to reverse-engineer bitstreams, gather timing information etc. p&r algorithms are rather straightforward and there must be simple open-source implementations already if you search well.

But, people seem to be content with vendor-provided tools. Vivado is bloated, slow, and buggy. However, people do not revolt. They rather perceive that Vivado deals with tasks of enormous complexity and therefore it is understandable that it takes long time for synthesis and/or p&r. No need for anything else.

 

Online legacy

  • Super Contributor
  • ***
  • Posts: 2566
Re: VHDL Tools ?
« Reply #25 on: August 14, 2017, 07:40:59 PM »
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.
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 2566
Re: VHDL Tools ?
« Reply #26 on: August 14, 2017, 08:19:18 PM »
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  :D

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  :palm:
 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 1184
  • Country: nz
Re: VHDL Tools ?
« Reply #27 on: August 14, 2017, 08:53:03 PM »
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...)

 

Online NorthGuy

  • Frequent Contributor
  • **
  • Posts: 420
  • Country: ca
Re: VHDL Tools ?
« Reply #28 on: August 15, 2017, 12:08:00 AM »
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.

 

Online NorthGuy

  • Frequent Contributor
  • **
  • Posts: 420
  • Country: ca
Re: VHDL Tools ?
« Reply #29 on: August 15, 2017, 12:16:24 AM »
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  ..."
 

Offline Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 681
  • Country: us
Re: VHDL Tools ?
« Reply #30 on: August 15, 2017, 04:14:24 AM »
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.
Never trust a government that doesn't trust you.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 3001
  • Country: us
Re: VHDL Tools ?
« Reply #31 on: August 15, 2017, 06:11:46 AM »
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!

 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 1184
  • Country: nz
Re: VHDL Tools ?
« Reply #32 on: August 15, 2017, 10:00:13 AM »
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... :)
 

Offline jefflieu

  • Contributor
  • Posts: 35
  • Country: au
Re: VHDL Tools ?
« Reply #33 on: August 15, 2017, 05:54:11 PM »
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.
i love Melbourne
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 2566
Re: VHDL Tools ?
« Reply #34 on: August 16, 2017, 05:49:04 AM »
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.
 

Online NorthGuy

  • Frequent Contributor
  • **
  • Posts: 420
  • Country: ca
Re: VHDL Tools ?
« Reply #35 on: August 16, 2017, 06:13:50 AM »
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.

 

Online legacy

  • Super Contributor
  • ***
  • Posts: 2566
Re: VHDL Tools ?
« Reply #36 on: August 16, 2017, 06:16:04 AM »
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  :-//
« Last Edit: August 17, 2017, 09:26:30 PM by legacy »
 

Online NorthGuy

  • Frequent Contributor
  • **
  • Posts: 420
  • Country: ca
Re: VHDL Tools ?
« Reply #37 on: August 16, 2017, 06:40:12 AM »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf