Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #28360 > unrolled thread

Makefile or not?

Back to article view | Back to comp.arch.embedded

Contents

  Makefile or not? pozz <pozzugno@gmail.com> - 2018-12-03 09:18 +0100
    Re: Makefile or not? David Brown <david.brown@hesbynett.no> - 2018-12-03 11:06 +0100
      Re: Makefile or not? pozz <pozzugno@gmail.com> - 2018-12-03 12:13 +0100
        Re: Makefile or not? David Brown <david.brown@hesbynett.no> - 2018-12-03 12:57 +0100
          Re: Makefile or not? pozz <pozzugno@gmail.com> - 2018-12-03 23:29 +0100
      Re: Makefile or not? Grant Edwards <invalid@invalid.invalid> - 2018-12-03 15:39 +0000
        Re: Makefile or not? Theo Markettos <theom+news@chiark.greenend.org.uk> - 2018-12-03 15:49 +0000
          Re: Makefile or not? Dave Nadler <drn@nadler.com> - 2018-12-03 09:41 -0800
          Re: Makefile or not? David Brown <david.brown@hesbynett.no> - 2018-12-03 21:31 +0100
    Re: Makefile or not? Grant Edwards <invalid@invalid.invalid> - 2018-12-03 15:30 +0000
      Re: Makefile or not? DJ Delorie <dj@delorie.com> - 2018-12-03 14:05 -0500
        Re: Makefile or not? Grant Edwards <invalid@invalid.invalid> - 2018-12-03 19:36 +0000
          Re: Makefile or not? Clifford Heath <no.spam@please.net> - 2018-12-04 09:30 +1100
            Re: Makefile or not? Grant Edwards <invalid@invalid.invalid> - 2018-12-03 23:19 +0000
              Re: Makefile or not? raimond.dragomir@gmail.com - 2018-12-03 22:02 -0800
              Re: Makefile or not? David Brown <david.brown@hesbynett.no> - 2018-12-04 12:18 +0100
                Re: Makefile or not? Grant Edwards <invalid@invalid.invalid> - 2018-12-04 15:46 +0000
                  Re: Makefile or not? Theo Markettos <theom+news@chiark.greenend.org.uk> - 2018-12-04 20:22 +0000
            Re: Makefile or not? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-12-03 15:38 -0800
          Re: Makefile or not? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-12-04 21:25 -0500
            Re: Makefile or not? Grant Edwards <invalid@invalid.invalid> - 2018-12-05 03:22 +0000
            Re: Makefile or not? David Brown <david.brown@hesbynett.no> - 2018-12-05 09:06 +0100
          Re: Makefile or not? George Neuner <gneuner2@comcast.net> - 2018-12-05 11:37 -0500
          Re: Makefile or not? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-12-05 15:37 -0500
            Re: Makefile or not? Grant Edwards <invalid@invalid.invalid> - 2018-12-05 22:34 +0000
              Re: Makefile or not? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-12-05 14:56 -0800
                Re: Makefile or not? Grant Edwards <invalid@invalid.invalid> - 2018-12-05 23:50 +0000
                  Re: Makefile or not? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-12-05 16:27 -0800
                    Re: Makefile or not? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-12-05 17:47 -0800
                      Re: Makefile or not? Theo Markettos <theom+news@chiark.greenend.org.uk> - 2018-12-06 08:12 +0000
                        Re: Makefile or not? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-12-06 10:17 -0800
                          Re: Makefile or not? gtwrek@sonic.net (gtwrek) - 2018-12-06 18:35 +0000
                          Re: Makefile or not? Theo Markettos <theom+news@chiark.greenend.org.uk> - 2018-12-06 18:39 +0000
              Re: Makefile or not? David Brown <david.brown@hesbynett.no> - 2018-12-06 09:22 +0100
              Re: Makefile or not? Theo Markettos <theom+news@chiark.greenend.org.uk> - 2018-12-06 18:46 +0000
                Re: Makefile or not? David Brown <david.brown@hesbynett.no> - 2018-12-06 21:51 +0100
                  Re: Makefile or not? Dave Nadler <drn@nadler.com> - 2018-12-06 13:47 -0800
                    Re: Makefile or not? David Brown <david.brown@hesbynett.no> - 2018-12-06 22:48 +0100
                      Re: Makefile or not? Dave Nadler <drn@nadler.com> - 2018-12-06 14:01 -0800
                    Re: Makefile or not? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-12-07 14:54 +0200
      Re: Makefile or not? David Brown <david.brown@hesbynett.no> - 2018-12-03 21:34 +0100
    Re: Makefile or not? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-12-03 11:06 -0500
      Re: Makefile or not? Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2018-12-03 22:05 +0100
        Re: Makefile or not? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-12-04 21:19 -0500
    Re: Makefile or not? queequeg@trust.no1 (Queequeg) - 2018-12-07 13:45 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#28384

On 2018-12-05, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

> In defence of Eclipse, it does do a much better job of humanizing gdb 
> than the other things I've used, such as ddd.

Ah, I remember ddd from decades back.  It always seemed about 70%
finished.

Is it still a thing?

... there appears to be a Gentoo ebuild:

  # emerge --search ddd
  [ Results for search key : ddd ]
  Searching...

  *  dev-util/ddd
        Latest version available: 3.3.12-r4
        Latest version installed: [ Not Installed ]
        Size of files: 5,554 KiB
        Homepage:      https://www.gnu.org/software/ddd
        Description:   Graphical front-end for command-line debuggers
        License:       GPL-3 LGPL-3 FDL-1.1

  [ Applications found : 1 ]

However, it looks like 3.3.12 was released 10 almost years ago.

The TCL/Tk based GUI that sort of "came with" gdb for a while about
10-15 years ago wasn't too bad (can't remember it's name).  But, for
the most part I prefer the gdb command line -- though I sometimes use
gdb-mode in emacs.

Most of the embedded stuff I work on isn't amenable to interactive
breakpoint/step/examine/resume type debugging anyway.  Milliseconds
after you hit a breakpoint, all sorts of hardware and protocols will
start to timeout, overflow, underflow, and generaly get upset.  Once
you stop, you can't expect to step/resume and get useful behavior.

Non-embedded stuff I do in Python, and don't need a debugger. ;)

--
Grant

[toc] | [prev] | [next] | [standalone]

#28385

On 05/12/18 03:25, Phil Hobbs wrote:
> On 12/3/18 2:36 PM, Grant Edwards wrote:
>> On 2018-12-03, DJ Delorie <dj@delorie.com> wrote:
>>> Grant Edwards <invalid@invalid.invalid> writes:
>>>> I use Emacs, makefiles, and meld.
>>>
>>> +1 on those.  My memory isn't good enough any more to remember all
>>> the byzantine steps through an IDE to re-complete all the tasks my
>>> projects require.
>>>
>>> Especially since each MCU seems to have a *different* IDE with
>>> *different* procedures to forget...
>>>
>>> And that's assuming they run on Linux in the first place ;-)
>>
>> The most important rule to remember is:
>>
>> Never, ever, use any software written or provided by the silicon
>> vendor.  Everytime I've failed to obey that rule, I've regretted it.
>>
>> I've heard rumors that Intel at one time wrote a pretty good C
>> compiler for x86.
> 
> I've used it, circa 2006-7, and for my application (highly multithreaded
> 3D electromagnetic simulation on a SMP) it was amazing--it blew the
> doors off both Visual C++ and gcc under cygwin.  (For sufficiently
> permissive values of 'amazing', that is, i.e. 1.5-1.8x on the same
> hardware.) ;)

Intel's C (and C++) compiler is still very much a major choice for the
x86 platform, with good support for the latest standards and a fair
degree of gcc compatibility (inline assembly format, attributes, etc.).
 It is generally considered to be the best choice for automatic vector
SIMD code generation, and has support for parallelising code using
multiple threads.  But it is also well known for making code that is
particularly poor on non-Intel x86 processors.

> 
>>
>> However, having used other development software from Intel, I find
>> that impossible to believe.  [Acually, Intel MDS-800 "blue boxes"
>> weren't bad as long as you ran CP/M on them insteaod of, ISIS.]
>>
>> And don't get me started on compilers and tools from TI, Motorola, or
>> various others either...
>>
>> Some of them have put some effort into getting good Gnu GCC and
>> binutils support for their processors, and that seems to produce good
>> results.  If only they had realized that's all they really needed to
>> do in the _first_ place...
> 
> In defence of Eclipse, it does do a much better job of humanizing gdb
> than the other things I've used, such as ddd.
> 

Agreed - Eclipse + gdb is a perfectly solid debugger.  It is not always
perfect, but no debugger I have ever used is always reliable or works as
you expect.  Certainly it is fine for most debugging purposes.

In the past, I have used both ddd and gvd (which later became part of
gps, the GNAT Programming Studio) as front ends.  There are plenty of
other gdb front-ends available - those with a strong sense of irony
might like to try using MS Visual Studio.

[toc] | [prev] | [next] | [standalone]

#28386

On Mon, 3 Dec 2018 19:36:50 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:

>I've heard rumors that Intel at one time wrote a pretty good C
>compiler for x86.
>
>However, having used other development software from Intel, I find
>that impossible to believe.  [Acually, Intel MDS-800 "blue boxes"
>weren't bad as long as you ran CP/M on them insteaod of, ISIS.]

Actually it was an excellent compiler: it was the absolute best for
highly optimized code through the 80's and 90's.  It was, however,
persnickety and infamous for its barely decipherable errors and
warnings.  I think the word "difficult" sums it up.

Intel's compiler STILL is the best on x86 for floating point and for
auto vectorizing to use SIMD.  In recent years GCC has taken the lead
for integer code.


For a long time Microsoft acknowledged that Intel's compiler was
superior: it is an open secret that Windows itself through NT was
built using Intel's tool chain, and that the OS kernel continued to be
built using Intel up through XP.  Vista was the first Windows built
entirely on Microsoft's own tool chain.

Through several major versions, Visual Studio included a configuration
switch that directed it to use Intel's tools rather than Microsoft's.
This always was possible anyway using foreign tool settings, but for a
long time Intel's tools were supported directly.

George

[toc] | [prev] | [next] | [standalone]

#28387

On 12/3/18 2:36 PM, Grant Edwards wrote:
> On 2018-12-03, DJ Delorie <dj@delorie.com> wrote:
>> Grant Edwards <invalid@invalid.invalid> writes:
>>> I use Emacs, makefiles, and meld.
>>
>> +1 on those.  My memory isn't good enough any more to remember all
>> the byzantine steps through an IDE to re-complete all the tasks my
>> projects require.
>>
>> Especially since each MCU seems to have a *different* IDE with
>> *different* procedures to forget...
>>
>> And that's assuming they run on Linux in the first place ;-)
> 
> The most important rule to remember is:
> 
> Never, ever, use any software written or provided by the silicon
> vendor.  Everytime I've failed to obey that rule, I've regretted it.

How about for FPGAs? ;)

Cheers

Phil Hobbs

-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

[toc] | [prev] | [next] | [standalone]

#28388

On 2018-12-05, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:
>
>> Never, ever, use any software written or provided by the silicon
>> vendor.  Everytime I've failed to obey that rule, I've regretted it.
>
> How about for FPGAs? ;)

I spent some time working with a NIOS2 core on an Altera
Cyclone-something-or-other.  In the beginning, somebody got conned
into using the Altera tools for doing software development.  As
expected, they were horrendous.  It was Eclipse with a bunch of
plugins.

IIRC, there were Eclipse plugins that called scripts written in bash
that called Perl scripts that called Java apps that generated TCL that
got fed to other scripts that generated header files... and on and on
and on.  The tools required more RAM that most of our development
machines had.  And it appeared to re-generate everything from scratch
everytime you wanted to build anything.

After fighting what that for a few months we threw it all out and
started from scratch with the gnu toolchain, makefiles, and our own
header files we wrote with info gleaned from the above mess.

There was also some sort of gdb-server executable that we extracted
from deep within the bowels of of the Altera IDE.  We had to write
some sort of wrapper for that to get it to run stand-alone and talk to
the USB byte-blaster thingy.

Once we ditched the massive pile of Altera's garbage IDE, things went
much smoother.  [Until, as the project neared completion, it became
obvious that the performance of the NIOS2 was nowhere near what was
promised, and the whole thing was abandoned.]

The hardware guys were, of course, chained to the Altera VHDL IDE
software for the duration -- presumably for heinous sins committed in
a previous life.

-- 
Grant Edwards               grant.b.edwards        Yow! Kids, don't gross me
                                  at               off ... "Adventures with
                              gmail.com            MENTAL HYGIENE" can be
                                                   carried too FAR!

[toc] | [prev] | [next] | [standalone]

#28389

On 12/5/18 2:34 PM, Grant Edwards wrote:
> On 2018-12-05, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:
>>
>>> Never, ever, use any software written or provided by the silicon
>>> vendor.  Everytime I've failed to obey that rule, I've regretted it.
>>
>> How about for FPGAs? ;)
> 
> I spent some time working with a NIOS2 core on an Altera
> Cyclone-something-or-other.  In the beginning, somebody got conned
> into using the Altera tools for doing software development.  As
> expected, they were horrendous.  It was Eclipse with a bunch of
> plugins.
> 
> IIRC, there were Eclipse plugins that called scripts written in bash
> that called Perl scripts that called Java apps that generated TCL that
> got fed to other scripts that generated header files... and on and on
> and on.  The tools required more RAM that most of our development
> machines had.  And it appeared to re-generate everything from scratch
> everytime you wanted to build anything.
> 
> After fighting what that for a few months we threw it all out and
> started from scratch with the gnu toolchain, makefiles, and our own
> header files we wrote with info gleaned from the above mess.
> 
> There was also some sort of gdb-server executable that we extracted
> from deep within the bowels of of the Altera IDE.  We had to write
> some sort of wrapper for that to get it to run stand-alone and talk to
> the USB byte-blaster thingy.
> 
> Once we ditched the massive pile of Altera's garbage IDE, things went
> much smoother.  [Until, as the project neared completion, it became
> obvious that the performance of the NIOS2 was nowhere near what was
> promised, and the whole thing was abandoned.]
> 
> The hardware guys were, of course, chained to the Altera VHDL IDE
> software for the duration -- presumably for heinous sins committed in
> a previous life.
> 

Nah, you can get out of the IDE there too.  You wind up having to write 
Makefiles that write and call Tcl scripts that communicate with a 
jtag-server executable that you extract from deep within the bowels of 
the IDE.  It's deeply unpleasant, and still preferable for production 
code to using the IDE.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

[toc] | [prev] | [next] | [standalone]

#28390

On 2018-12-05, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:
> On 12/5/18 2:34 PM, Grant Edwards wrote:
>
>> Once we ditched the massive pile of Altera's garbage IDE, things went
>> much smoother.  [Until, as the project neared completion, it became
>> obvious that the performance of the NIOS2 was nowhere near what was
>> promised, and the whole thing was abandoned.]
>> 
>> The hardware guys were, of course, chained to the Altera VHDL IDE
>> software for the duration -- presumably for heinous sins committed
>> in a previous life.
>
> Nah, you can get out of the IDE there too.  You wind up having to write 
> Makefiles that write and call Tcl scripts that communicate with a 
> jtag-server executable that you extract from deep within the bowels of 
> the IDE.  It's deeply unpleasant, and still preferable for production 
> code to using the IDE.

Can you avoid using the IDE to compile the VHDL and build the various
formats of bitstream files?

-- 
Grant Edwards               grant.b.edwards        Yow! My NOSE is NUMB!
                                  at               
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#28391

On 12/5/18 3:50 PM, Grant Edwards wrote:
> On 2018-12-05, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:
>> On 12/5/18 2:34 PM, Grant Edwards wrote:
>>> The hardware guys were, of course, chained to the Altera VHDL IDE
>>> software for the duration -- presumably for heinous sins committed
>>> in a previous life.
>>
>> Nah, you can get out of the IDE there too.  You wind up having to write
>> Makefiles that write and call Tcl scripts that communicate with a
>> jtag-server executable that you extract from deep within the bowels of
>> the IDE.  It's deeply unpleasant, and still preferable for production
>> code to using the IDE.
> 
> Can you avoid using the IDE to compile the VHDL and build the various
> formats of bitstream files?
> 

Mostly.  You (practically) have to use the IDE to configure the settings 
file, the .qsf, which tells it what bitstreams to make, what the sources 
files are, etc.  Once that file is correct (and it's text, so it's 
VCSable), you can just run make.

See below, one of my team's Quartus makefiles.  We're doing the same in 
Xilinx Vivado these days, which was again a tedious and awful process to 
get going.  I have no idea why no FPGA vendor believes that repeatable 
build control is something that matters to their customer base; left to 
my own devices we'd be doing CI on the version control server.

########################################################################

# This is the makefile to build 22C230B, the FPGA for the V230 Analog

# Input Module.  It builds rbf 22C230B.rbf to be used by the 22E230

# for programming on an EP3C5F256.

#

# The default target builds the necessary image.  Other targets are:

#   reg_map : Builds the register map files.

#   clean : Removes all build products.

#

# Karla Vega, Highland Technology, Inc.

# 29-May-2014

########################################################################



########################################################################

# Tools and binary locations

########################################################################



SHELL   ?= /bin/bash

QUARTUS ?= $(QUARTUS_ROOTDIR)



IS_CYGWIN := $(findstring CYGWIN,$(shell uname))



ifneq "" "$(IS_CYGWIN)"

   QUARTUS_BIN := $(shell cygpath "$(QUARTUS)")/bin

else

   QUARTUS_BIN := $(QUARTUS)/bin

endif



quartus_map := $(QUARTUS_BIN)/quartus_map

quartus_fit := $(QUARTUS_BIN)/quartus_fit

quartus_asm := $(QUARTUS_BIN)/quartus_asm

quartus_sta := $(QUARTUS_BIN)/quartus_sta

quartus_sh  := $(QUARTUS_BIN)/quartus_sh



########################################################################

# Project configuration.

########################################################################



PROJECT         := 22C230

REV             := B

DRAFT           := 0

DEVICE_FAMILY   := "Cyclone III"

DEVICE          := EP3C5F256

DEVICE_SPEEDGRADE := 8

FINAL := 22C230$(REV)$(filter-out 0,$(DRAFT))



# Bring in sources.mk, which is autogenerated from the Quartus project file.

ifeq "$(findstring $(MAKECMDGOALS),clean)" ""

   include sources.mk

endif



ASSIGNMENT_FILES = $(PROJECT).qpf $(PROJECT).qsf

OUTPUT_DIR  := output

CORE_DIR    := src/cores

REG_MAP_DIR := src/reg_map

VHDL_DIR    := src/vhdl



# Composite source list

SOURCES = $(22C230_SOURCES)



# Destination list

RBF_FILE := $(OUTPUT_DIR)/$(FINAL).rbf



########################################################################

# Phony targets

########################################################################



.PHONY: all reg_map



all: $(ROM_FILE) $(OUTPUT_DIR)/$(PROJECT).asm.rpt 
$(OUTPUT_DIR)/$(PROJECT).sta.rpt



clean:

     rm -rf db incremental_db $(OUTPUT_DIR) *.chg sources.mk



########################################################################

# Rules

########################################################################



# No implicit rules, they won't do us any good.

.SUFFIXES:



# Quartus forces us to keep the list of all the source files in the .qsf

# file.  In the interest of avoiding redundancy, we have a Tcl script to

# rip these out and turn them into the sources.mk file that we include

# earlier on.  Therefore, if the .qsf file changes, or if the SOPC_TARGET

# needs rebuilding (which changes the .qip file which changes the file

# dependency list), we'll rebuild the sources.mk file.

#

sources.mk: $(ASSIGNMENT_FILES)

     $(quartus_sh) -t list_files.tcl $(PROJECT)



# Quartus build process from the --help=makefiles option.

STAMP := echo done >



$(OUTPUT_DIR)/$(PROJECT).map.rpt: map.chg $(SOURCES)

     $(quartus_map) $(MAP_ARGS) $(PROJECT)

     $(STAMP) fit.chg



$(OUTPUT_DIR)/$(PROJECT).fit.rpt: fit.chg $(OUTPUT_DIR)/$(PROJECT).map.rpt

     $(quartus_fit) $(FIT_ARGS) $(PROJECT)

     $(STAMP) asm.chg

     $(STAMP) sta.chg



$(OUTPUT_DIR)/$(PROJECT).asm.rpt $(RBF_FILE): asm.chg 
$(OUTPUT_DIR)/$(PROJECT).fit.rpt

     $(quartus_asm) $(ASM_ARGS) $(PROJECT)



$(OUTPUT_DIR)/$(PROJECT).sta.rpt: sta.chg $(OUTPUT_DIR)/$(PROJECT).fit.rpt

     $(quartus_sta) $(STA_ARGS) $(PROJECT)



$(OUTPUT_DIR)/smart.log: $(ASSIGNMENT_FILES)

     $(quartus_sh) --determine_smart_action $(PROJECT) > 
$(OUTPUT_DIR)/smart.log



###################################################################

# Project initialization

###################################################################



map.chg:

     $(STAMP) map.chg

fit.chg:

     $(STAMP) fit.chg

sta.chg:

     $(STAMP) sta.chg

asm.chg:

     $(STAMP) asm.chg



-include local.mk



And the referenced list_files.tcl

# list_files.tcl
#
# Extracts all of the source file names from the Quartus project
# settings file, and writes them into sources.mk so that they can
# be pulled into the makefile.
#
# Rob Gaddi, Highland Technology.
# 15-May-2013

set source_files {VHDL_FILE VERILOG_FILE QIP_FILE}

set projname [lindex $argv 0]
project_open $projname

set hOut [open {sources.mk} {WRONLY CREAT}]
puts -nonewline $hOut "[string toupper $projname]_SOURCES := "

foreach ftype $source_files {
   foreach_in_collection dat [get_all_global_assignments -name $ftype] {
     set fn [lindex $dat 2]
     puts $hOut "$fn \\"
   }
}
puts $hOut ""
close $hOut
project_close


-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

[toc] | [prev] | [next] | [standalone]

#28392

On 12/5/18 4:27 PM, Rob Gaddi wrote:
> On 12/5/18 3:50 PM, Grant Edwards wrote:
>> On 2018-12-05, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:
>>> On 12/5/18 2:34 PM, Grant Edwards wrote:
>>>> The hardware guys were, of course, chained to the Altera VHDL IDE
>>>> software for the duration -- presumably for heinous sins committed
>>>> in a previous life.
>>>
>>> Nah, you can get out of the IDE there too.  You wind up having to write
>>> Makefiles that write and call Tcl scripts that communicate with a
>>> jtag-server executable that you extract from deep within the bowels of
>>> the IDE.  It's deeply unpleasant, and still preferable for production
>>> code to using the IDE.
>>
>> Can you avoid using the IDE to compile the VHDL and build the various
>> formats of bitstream files?
>>
> 
> Mostly.  You (practically) have to use the IDE to configure the settings 
> file, the .qsf, which tells it what bitstreams to make, what the sources 
> files are, etc.  Once that file is correct (and it's text, so it's 
> VCSable), you can just run make.
> 
> See below, one of my team's Quartus makefiles.  We're doing the same in 
> Xilinx Vivado these days, which was again a tedious and awful process to 
> get going.  I have no idea why no FPGA vendor believes that repeatable 
> build control is something that matters to their customer base; left to 
> my own devices we'd be doing CI on the version control server.
>
 > [snip]

In related news, https://hdlmake.readthedocs.io seems to have come along 
quite a way since the last time I looked in on it.  Might have to give 
it a try out on my next project.


-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

[toc] | [prev] | [next] | [standalone]

#28393

Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:
> In related news, https://hdlmake.readthedocs.io seems to have come along 
> quite a way since the last time I looked in on it.  Might have to give 
> it a try out on my next project.

We have a fully Makefile-based FPGA toolchain, which is critical for
continuous integration builds, but generally projects are begun and tweaked
from the GUI - typically it's not a one-way street (so you can open the
project files used by the Makefile build in the GUI).  While in principle
all the tools can be driven from tcl, by the time you've worked out the
hundred tcl statements you needed you might as well have used the GUI.

I had a play with hdlmake as we have increasing need to do Intel and Xilinx
builds from the same codebase.  It handles some basic stuff, like pin
assignments, but anything of complexity (eg instantiating vendor IP cores)
are going to need the vendor tools.  hdlmake does avoid having to know the
incantations to call Intel/Xilinx/etc parts of the build system and replaces
with a single command, but that's not the biggest problem.

(my current issue is Xilinx IP Integrator's idea of schematic capture from
the 1980s, complete with a mush of overlapping wires, and am trying to work
out whether I can build complex SoCs entirely from tcl - in this case I
think the GUI is so awful anything is better)

Theo

[toc] | [prev] | [next] | [standalone]

#28395

On 12/6/18 12:12 AM, Theo Markettos wrote:
> with a single command, but that's not the biggest problem.
> 
> (my current issue is Xilinx IP Integrator's idea of schematic capture from
> the 1980s, complete with a mush of overlapping wires, and am trying to work
> out whether I can build complex SoCs entirely from tcl - in this case I
> think the GUI is so awful anything is better)
> 

I actually like the graphical interface for putting complex top-level 
blocks together (at least until VHDL-2018 comes out with interfaces), 
and you can make it write bad but sufficient Tcl that you can lock down 
for CI.

But have you run into the fact yet that, while the synthesis engine 
supports VHDL-2008, IP Integrator doesn't.  You can't even write a thin 
wrapper, any VHDL-2008 anywhere in your design poisons the whole thing 
such that IPI can't work with it.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

[toc] | [prev] | [next] | [standalone]

#28396

In article <pubp3l$plq$1@dont-email.me>,
Rob Gaddi  <rgaddi@highlandtechnology.invalid> wrote:
>On 12/6/18 12:12 AM, Theo Markettos wrote:
>> with a single command, but that's not the biggest problem.
>> 
>> (my current issue is Xilinx IP Integrator's idea of schematic capture from
>> the 1980s, complete with a mush of overlapping wires, and am trying to work
>> out whether I can build complex SoCs entirely from tcl - in this case I
>> think the GUI is so awful anything is better)
>> 
>
>I actually like the graphical interface for putting complex top-level 
>blocks together (at least until VHDL-2018 comes out with interfaces), 
>and you can make it write bad but sufficient Tcl that you can lock down 
>for CI.
>
>But have you run into the fact yet that, while the synthesis engine 
>supports VHDL-2008, IP Integrator doesn't.  You can't even write a thin 
>wrapper, any VHDL-2008 anywhere in your design poisons the whole thing 
>such that IPI can't work with it.

We have a fairly straightforward build process (makefiles, and TCL)
for our Xilinx FPGAs using non-project mode TCL.  We do nightly builds
on all our FPGAs - the current build list is ~40 FPGAs.

For Xilinx IP we struggle up front to use the F#@#$F IP integrator or
other GUIs to generate an example project.  Then we reverse engineer the
RTL that's usually under the covers, and use that directly.  Everything
else is thrown out.  We've typed up a "Just the RTL" document which
we've given to Xilinx to explain why we do this. 

After the time spent on the up-front reverse engineering, things work fine -
never having to open the darned Xilinx IDE again.

This thread gives make me nod my head (in a misery-loves-company sort of
way) in that I see you software folks are basically doing the same
thing.  

The absolute WORST part of the Xilinx flows is in their MPSoC designs
and configuring boot-loaders and rootfs images.  Here one must use their
awful 80s style schematic capture code to configure the bootloader, and
initial images.  Yes, schematic capture to design software.

They even crypto-sign the intermediate files (HDF) to prevent engineers from 
trying to create a more sane flow.  Absolute insanity...

Regards,

Mark

[toc] | [prev] | [next] | [standalone]

#28397

Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:
> I actually like the graphical interface for putting complex top-level 
> blocks together (at least until VHDL-2018 comes out with interfaces), 
> and you can make it write bad but sufficient Tcl that you can lock down 
> for CI.

That aspect is useful, however the idea that inputs go on the left and
outptus on the right is a braindead hangover from analogue schematics. 
Typically a module has several interfaces - eg a bridge has an AXI
slave, its clock and reset, and an AXI master with its clock and reset. 
That's two groups of each of AXI/clock/reset.  So why put the
clock/reset inputs on the left and the associated AXI master on the right?
Why are there always wires crossing from one side of the component to the
other?

It's fine on a small design, but it's a nightmare on a complicate design.
My current Intel Qsys design has about 40 components (mostly a lot of
bridges of various kinds) in 4 levels of hierarchy, which would be a
complete mess to represent in a inputs=left, outputs=right fashion.

> But have you run into the fact yet that, while the synthesis engine 
> supports VHDL-2008, IP Integrator doesn't.  You can't even write a thin 
> wrapper, any VHDL-2008 anywhere in your design poisons the whole thing 
> such that IPI can't work with it.

I'm mostly composing generated IP, so avoid at least this problem...

Theo

[toc] | [prev] | [next] | [standalone]

#28394

On 05/12/18 23:34, Grant Edwards wrote:
> On 2018-12-05, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:
>>
>>> Never, ever, use any software written or provided by the silicon
>>> vendor.  Everytime I've failed to obey that rule, I've regretted it.
>>
>> How about for FPGAs? ;)
> 
> I spent some time working with a NIOS2 core on an Altera
> Cyclone-something-or-other.  In the beginning, somebody got conned
> into using the Altera tools for doing software development.  As
> expected, they were horrendous.  It was Eclipse with a bunch of
> plugins.
> 
> IIRC, there were Eclipse plugins that called scripts written in bash
> that called Perl scripts that called Java apps that generated TCL that
> got fed to other scripts that generated header files... and on and on
> and on.  The tools required more RAM that most of our development
> machines had.  And it appeared to re-generate everything from scratch
> everytime you wanted to build anything.
> 

If you think that is fun, just imagine doing it on Windows - with all
the TCL and perl running under Cygwin.

It is a long time since I used the Nios, and I only did so very briefly
(the project was cancelled for many reasons).  But I seem to remember
there being a lot of extra building going on due to the interaction
between the software and the hardware.  On the one side, the software
for the Nios was made into a ROM component for the FPGA design, and thus
meant at least a partial FPGA rebuild (and incremental builds were only
in the expensive version of the tools, not the free ones).  On the other
side, a build in the FPGA side could mean changes to the automatically
generated include files for the peripheral registers and addresses,
triggering a software rebuild.

But it certainly /was/ possible to separate software and hardware
development.  Typically you only have such tight integration for a small
part of the software - a boot rom - that sets up memory and loads the
real program from external flash.  That program can be developed
independently.  (And again, separate makefiles are more efficient - but
the IDE with plugins can make debugging nicer.)

It is also worth noting that Eclipse has got far better since the early
days of the NIOS2.  It used to be a serious memory and processor hog,
with few features to justify the weight.  These days it still takes a
fair chunk of memory, but it is a far lower fraction of the typical
workstation.  (My main Linux system generally has at least three or four
distinct instances of Eclipse running at any one time, in different
workspaces, for different projects.)  And I find it to be the best
choice for bigger projects in C, C++, and Python - as well as convenient
for LaTeX and other coding.  (But with external makefiles!).

> After fighting what that for a few months we threw it all out and
> started from scratch with the gnu toolchain, makefiles, and our own
> header files we wrote with info gleaned from the above mess.
> 
> There was also some sort of gdb-server executable that we extracted
> from deep within the bowels of of the Altera IDE.  We had to write
> some sort of wrapper for that to get it to run stand-alone and talk to
> the USB byte-blaster thingy.
> 
> Once we ditched the massive pile of Altera's garbage IDE, things went
> much smoother.  [Until, as the project neared completion, it became
> obvious that the performance of the NIOS2 was nowhere near what was
> promised, and the whole thing was abandoned.]
> 
> The hardware guys were, of course, chained to the Altera VHDL IDE
> software for the duration -- presumably for heinous sins committed in
> a previous life.
> 

[toc] | [prev] | [next] | [standalone]

#28398

Grant Edwards <invalid@invalid.invalid> wrote:
> I spent some time working with a NIOS2 core on an Altera
> Cyclone-something-or-other.  In the beginning, somebody got conned
> into using the Altera tools for doing software development.  As
> expected, they were horrendous.  It was Eclipse with a bunch of
> plugins.

It wasn't just any Eclipse, it was a fork of Eclipse from 2005.  Eclipse
itself got a lot better, Altera's didn't.

I inherited a teaching lab which used Altera Eclipse on NIOS2, but I'd find
I'd always have to revert to the command line to work out what was actually
going on.  When I rewrote the lab (and we moved away from NIOS to RISC-V), I
junked the IDE and went with terminals and Makefile-based development - on
the basis that it's something that students should be exposed to at some
point in their careers, and it makes debugging their code a lot more sane
from our point of via.  They still drive Quartus via the GUI (because
students start not knowing what an FPGA is, and it's easier for them to
understand what's happening via the GUI) but Modelsim they mostly drive
through pre-supplied scripts, given Modelsim's non-intuitive GUI.

Theo

[toc] | [prev] | [next] | [standalone]

#28399

On 06/12/2018 19:46, Theo Markettos wrote:
> Grant Edwards <invalid@invalid.invalid> wrote:
>> I spent some time working with a NIOS2 core on an Altera
>> Cyclone-something-or-other.  In the beginning, somebody got conned
>> into using the Altera tools for doing software development.  As
>> expected, they were horrendous.  It was Eclipse with a bunch of
>> plugins.
> 
> It wasn't just any Eclipse, it was a fork of Eclipse from 2005.  Eclipse
> itself got a lot better, Altera's didn't.

Yes, manufacturers' IDE's used to be done that way.  They'd take a fork 
of Eclipse and modify it to fit their uses.  And that meant you always 
had an old version of Eclipse, and often one that didn't work with other 
useful plugins (such as for version control systems).  It also often 
meant that you were stuck on Windows.

These days, they are invariably organised as plugins for standard 
Eclipse.  That means that updates are much more regular - each release 
of the tools usually builds on a relatively new version of Eclipse.

> 
> I inherited a teaching lab which used Altera Eclipse on NIOS2, but I'd find
> I'd always have to revert to the command line to work out what was actually
> going on.  When I rewrote the lab (and we moved away from NIOS to RISC-V), I
> junked the IDE and went with terminals and Makefile-based development - on
> the basis that it's something that students should be exposed to at some
> point in their careers, and it makes debugging their code a lot more sane
> from our point of via.  They still drive Quartus via the GUI (because
> students start not knowing what an FPGA is, and it's easier for them to
> understand what's happening via the GUI) but Modelsim they mostly drive
> through pre-supplied scripts, given Modelsim's non-intuitive GUI.
> 
> Theo
> 

[toc] | [prev] | [next] | [standalone]

#28400

On Thursday, December 6, 2018 at 3:51:46 PM UTC-5, David Brown wrote:
> These days, they are invariably organized as plugins for standard Eclipse.  

Except Microchip ;-(

[toc] | [prev] | [next] | [standalone]

#28401

On 06/12/2018 22:47, Dave Nadler wrote:
> On Thursday, December 6, 2018 at 3:51:46 PM UTC-5, David Brown wrote:
>> These days, they are invariably organized as plugins for standard Eclipse.
> 
> Except Microchip ;-(
> 

Yes - they have NetBeans (with plugins) for PIC, and I presume they 
still have Atmel's MSVS-based Visual Studio.

[toc] | [prev] | [next] | [standalone]

#28402

On Thursday, December 6, 2018 at 4:48:50 PM UTC-5, David Brown wrote:
> On 06/12/2018 22:47, Dave Nadler wrote:
> > On Thursday, December 6, 2018 at 3:51:46 PM UTC-5, David Brown wrote:
> >> These days, they are invariably organized as plugins for standard Eclipse.
> > 
> > Except Microchip ;-(
> 
> Yes - they have NetBeans (with plugins) for PIC, and I presume they 
> still have Atmel's MSVS-based Visual Studio.

To ensure chaos, do Microsemi (now owned by Microchip) tools use Eclipse?
https://www.investors.com/news/technology/microchip-stock-microsemi-inventory/

[toc] | [prev] | [next] | [standalone]

#28404

On 6.12.18 23:47, Dave Nadler wrote:
> On Thursday, December 6, 2018 at 3:51:46 PM UTC-5, David Brown wrote:
>> These days, they are invariably organized as plugins for standard Eclipse.
> 
> Except Microchip ;-(


Right - after buying Atmel, there's Atmel studio, which
should disappear the way of dinosaurs. It forces the whole
Microsoft IDE environment, and it is a PITA for us non-
Windows users.

Eclipse is actually pretty flexible, if it is used with
standard GNU makefiles, written by the programmer and not
the IDE.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web