(V)HDL Toolsets

Jay Jaeger cube1 at charter.net
Thu May 21 11:06:52 CDT 2020


On 5/21/2020 7:41 AM, Peter Corlett via cctalk wrote:
> On Thu, May 21, 2020 at 01:34:09PM +0200, Sytse van Slooten via cctalk wrote:
> [...]
>> So basically what it comes down to is Quartus or Vivado. I’ve kind of
>> implicitly chosen Quartus, because the Altera based development boards tend
>> to be a lot nicer and cheaper than the Xilinx based stuff. I haven’t even
>> followed the upgrades from ISE to Vivado.
> 
> My understanding from when I was looing at FPGAs in ~2013 is that Xilinx make
> better FPGAs than Altera (now Intel), but Altera's tools are better. Having had
> the "joy" of using Altera's Quartus, I dread to think how terrible ISE must be.
>>From a cursory check, Vivado appears to be just an rebranded newer version of
> ISE rather than a fundamental change.

ISE isn't/wasn't so bad, performance-wise.  Vivado has been painful.

> 
> Quartus puts me in mind of the dark days of the 1980s with its expensive,
> closed-source, and generally shoddy software development environments before
> GNU came along and wiped them out. Good riddance do the lot of them.
> 
> Even the HDLs themselves are stuck in the 1980s. Verilog is described as being
> C-like, but that's not exactly a compliment. VHDL is Ada-like or Pascal-like,
> i.e. designed by a committee and/or academics who have definite opinions about
> how other people should write code, but don't do much of it themselves.

The design of my application is such that it should not be difficult to
adapt it to generate whatever kind of HDL one might want.  I learned
both Verilog and VHDL along the way, using the Mano/Kime book "Logic and
Computer Design Fundamentals" - it was a coin flip which I decided to
work with first.  (Prof. Charles Kime was my adviser when I was an ECE
student in the early 1970's).

> 
> There are at least finally some open-source HDLs banging about which have
> incorporated useful ideas from the last four decades of language design and
> thus be easier to create correct code. (Thich is a crucial difference from
> "easier to create something which runs", which is C/Verilog's schtick.)
> Unfortunately, because of the lack of documententation on the FPGA bitstreams,
> the best they can do is be a source-to-source translator piped into the
> proprietary tooling.
> 

That's an interesting idea for later, maybe.

Thanks.

JRJ


More information about the cctech mailing list