VHDL Tools ? - Page 1
Forum section: electronics / general

author: tja
author_rank: Contributor
timestamp: August 10, 2017, 02:23:22 pm
content: 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?CheersTim

author: legacy
author_rank: Super Contributor
timestamp: August 10, 2017, 03:17:02 pm
content: Quote from: tja on August 10, 2017, 02:23:22 pmIf you start with complex projects ...DDR-ish is assumed "advanced".

author: legacy
author_rank: Super Contributor
timestamp: August 10, 2017, 03:25:45 pm
content: Quote from: tja on August 10, 2017, 02:23:22 pmlike Scitools dot com Understand (C/C++) ?Quote from: tja on August 10, 2017, 02:23:22 pmSigasi 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.

author: stmdude
author_rank: Frequent Contributor
timestamp: August 10, 2017, 04:39:04 pm
content: 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..

author: nctnico
author_rank: Super Contributor
timestamp: August 10, 2017, 07:15:00 pm
content: Quote from: stmdude on August 10, 2017, 04:39:04 pmI 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.

author: tja
author_rank: Contributor
timestamp: August 10, 2017, 08:48:17 pm
content: While VHDLexecutesconcurrently, 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 mostbasicbest practice - formatting, naming standards,comments!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.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 10, 2017, 09:07:26 pm
content: Quote from: tja on August 10, 2017, 08:48:17 pmI guess that would be schematics.

author: hamster_nz
author_rank: Super Contributor
timestamp: August 10, 2017, 09:21:19 pm
content: 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.

author: agehall
author_rank: Frequent Contributor
timestamp: August 11, 2017, 04:48:49 am
content: @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.

author: dgtl
author_rank: Regular Contributor
timestamp: August 11, 2017, 05:28:24 pm
content: 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.

author: rstofer
author_rank: Super Contributor
timestamp: August 11, 2017, 09:00:04 pm
content: 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'.

author: julian1
author_rank: Frequent Contributor
timestamp: August 12, 2017, 12:37:20 am
content: Never tried them, but some alternatives are,- Chisel which is embedded in scalahttps://chisel.eecs.berkeley.edu/- Bluespec proprietary, apparently similar to Haskellhttps://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.

author: mac.6
author_rank: Regular Contributor
timestamp: August 13, 2017, 06:46:33 pm
content: There is also spinalHDL, quite close to chisel but with nice differences.

author: rstofer
author_rank: Super Contributor
timestamp: August 13, 2017, 07:42:37 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: August 13, 2017, 07:59:56 pm
content: Quote from: rstofer on August 13, 2017, 07:42:37 pmYou 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.

author: legacy
author_rank: Super Contributor
timestamp: August 13, 2017, 08:53:05 pm
content: open source FPGA code will be difficult for all the reasons pointed out in this articleno mater anyway

author: legacy
author_rank: Super Contributor
timestamp: August 13, 2017, 08:54:44 pm
content: Quote from: nctnico on August 13, 2017, 07:59:56 pmModelsim scripts here

author: legacy
author_rank: Super Contributor
timestamp: August 13, 2017, 11:20:38 pm
content: 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

author: legacy
author_rank: Super Contributor
timestamp: August 13, 2017, 11:23:31 pm
content: Code: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) thenif (counter1 < counter1_right) thencounter1 <= counter1 +1;else...have to work around it

author: nctnico
author_rank: Super Contributor
timestamp: August 13, 2017, 11:26:01 pm
content: I guess the problem is that the number of bits of an integer is undefined so the signal cannot be translated to real hardware.

author: hamster_nz
author_rank: Super Contributor
timestamp: August 14, 2017, 12:06:20 am
content: Quote from: legacy on August 13, 2017, 11:20:38 pmX'high The upper bound of XX'low The lower bound of XX'left The leftmost bound of XX'right The rightmost bound of XDoes 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?

author: legacy
author_rank: Super Contributor
timestamp: August 14, 2017, 12:53:46 am
content: Quote from: hamster_nz on August 14, 2017, 12:06:20 amModelsim says it's OK, it accepts the code and the simulation goes fineISE claims that object prefix must be an array, which is not correct according to vhdl definitionIf you define something as integer, no matter if you resize the range, types all come with a left and right border.

author: legacy
author_rank: Super Contributor
timestamp: August 14, 2017, 12:56:14 am
content: Quote from: nctnico on August 13, 2017, 11:26:01 pmnumber of bits has nothing to deal with a language type's range.

author: legacy
author_rank: Super Contributor
timestamp: August 14, 2017, 01:13:02 am
content: Code: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

author: NorthGuy
author_rank: Super Contributor
timestamp: August 14, 2017, 05:01:55 am
content: Quote from: rstofer on August 13, 2017, 07:42:37 pmI 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.

author: legacy
author_rank: Super Contributor
timestamp: August 14, 2017, 09:40:59 am
content: Quote from: NorthGuy on August 14, 2017, 05:01:55 amsure, 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.Quote from: NorthGuy on August 14, 2017, 05:01:55 amReally? So, show me where we can find.

author: legacy
author_rank: Super Contributor
timestamp: August 14, 2017, 10:19:18 am
content: What I really like about Modelsim is the capability to check sources, and tell youif variables are in safe usageif variables read contradictionif the scope is correct... a lot of these checks to be sure that the description is deterministic for hardwaree.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 checkCode:priority_encoder:process (din) isbegindout<=(others=>'0');for i in din'range loopdout<=conv_std_logic_vector(i,dout'length);exit when (din(i)='1');end loop;end process;Thanks to Mentor GraphicsWell, 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

author: hamster_nz
author_rank: Super Contributor
timestamp: August 14, 2017, 10:53:03 am
content: This paper is interesting:"Analyzing the Divide between FPGA Academic and Commercial Results"http://plato.fea.ugent.be/firw/files/P115.438.pdfTLDR: 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 flowsDepends 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...)

author: NorthGuy
author_rank: Super Contributor
timestamp: August 14, 2017, 02:08:00 pm
content: Quote from: legacy on August 14, 2017, 09:40:59 amTry this website:http://www.google.comThen 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 14, 2017, 02:16:24 pm
content: Quote from: hamster_nz on August 14, 2017, 10:53:03 am"... who would fardels bear,To grunt and sweat under a weary life,But that the dread of something ..."

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 14, 2017, 06:14:24 pm
content: Quote from: NorthGuy on August 14, 2017, 05:01:55 amIt 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.

author: rstofer
author_rank: Super Contributor
timestamp: August 14, 2017, 08:11:46 pm
content: Quote from: Sal Ammoniac on August 14, 2017, 06:14:24 pmI 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!

author: hamster_nz
author_rank: Super Contributor
timestamp: August 15, 2017, 12:00:13 am
content: Quote from: NorthGuy on August 14, 2017, 02:16:24 pmDamn! I never knew that Shakespeare used Vivado...

author: jefflieu
author_rank: Contributor
timestamp: August 15, 2017, 07:54:11 am
content: Quote from: tja on August 10, 2017, 02:23:22 pmI 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 :sI 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.

author: legacy
author_rank: Super Contributor
timestamp: August 15, 2017, 07:49:04 pm
content: Code:svn co https://torc-isi.svn.sourceforge.net/svnroot/torc-isi/trunk torccd srcmakeCode:OrangeCube src $ makecc -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.cppIn 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 followingi686-pc-linux-gnu-4.4.7i686-pc-linux-gnu-4.9.3As expected .... once again Opensource is making people to waste A LOT of time in order to have things working in a decent wayThis 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 15, 2017, 08:13:50 pm
content: Quote from: legacy on August 15, 2017, 07:49:04 pmThis 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.

author: legacy
author_rank: Super Contributor
timestamp: August 15, 2017, 08:16:04 pm
content: Code:/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 inputFrankly, 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

author: NorthGuy
author_rank: Super Contributor
timestamp: August 15, 2017, 08:40:12 pm
content: Quote from: legacy on August 15, 2017, 08:16:04 pmI completely agree. I never waste my time with other people's code for exact these reasons.