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

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/

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.

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 ;-(

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
>

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

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

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

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.