verilog versus vhdl

I think that's Janick Bergeron's line originally, but it gets my vote!

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
 Click to see the full signature
Reply to
Jonathan Bromley
Loading thread data ...

I have some semi-abstract reference code below that has been synthesized successfully on everything except DC. I would appreciate it if you could give it a go on DC with and without map_to_entity.

Thanks.

-- Mike Treseler

formatting link

Reply to
Mike Treseler

Thanks ... interesting reference point!

Any mappings to Virtex-5 fat lut's yet? Best case hand design for comparison?

Reply to
fpga_toys

It's a client's software, I'm afraid, so no can do. It's also worth more than I make in a year.

'map_to_entity' is a pragma that you enter in the source code, together with your behavioural function/procedure. All it says is that, during synthesis, the subprogram call should be replaced with an instantiation of the named entity (in other words, it's not something that you can try running with or without; you have to write the code).

Evan

Reply to
Evan Lavelle

No. Try it and let me know. I'll add the stats to the table at the end of the file.

After looking at the Quartus RTL view

formatting link
I don't think I could make much less area. Anyway, life's too short :)

-- Mike Treseler

Reply to
Mike Treseler

It *costs* more that a year's pay, but its worth is open for discussion.

Hmm. Do-it-yourself synthesis.

There was a Far Side cartoon that depicted one cave dweller holding a single round stone in his hand with another cave dweller holding a 'tool box' full of more of the same round stones. The first guy holding the single stone exclaims: "I asked for a hammer, A HAMMER! This is a crescent wrench...... Well, maybe it's a hammer. DAMN these stone tools!"

-- Mike Treseler

Reply to
Mike Treseler

Following the links in Mike's posting proved to be interesting, as it references indirectly this great piece, which makes the same arguments about why you don't want to let hardware designers avoid a high level of design abstraction, as they will dig the same deep unmaintainable hole that assembly language provides for programmers, and their employers.

formatting link

And clearly, the bottom line is well stated by this articles introductory "Scope" section.

Having to work with some horrible "concise and clear" VHDL, I have to disagree. Job security by obscurity in a botched VHDL design that LACKS reasonable high level abstraction is exactly why in my mind that TTL designers should not be allowed to write TTL designs in VHDL/Verilog. That those constructs need to be removed from a production language that is general use, to specifically force mantainable coding standards, that improve productivity and maintainability over the long term.

Reply to
fpga_toys

Exactly, least possible change to the language but to allow wires bits fields to be truly arbitrarily large, Verilog allows 16M bit width if needed. perhaps we should be using Fortran or APL as base languages. Using C++ overloading operators and hence SystemC doesn't do it for me either. A base language that can do huge math ops in a few symbols is something we had 40 years ago. It is a pity N.Wirth didn't do more for HDLs beside Lola.

By concurrency I refer to the CSP model and the occam language which looks alot lke hardware design. Ofcourse HandelC evolved out of occam from the U Oxford work a decade ago in synthesizing occam processes as hardware. I don't know about the other xyzCs or FpgaC and will wait till they have been around a while. I do remember though before I became interested in FPGAs some 10 years ago several commercial ASIC HDL C and I recall that they all failed miserably in the market as "nobody wants this stuff". With FPGAs and systems guys, there is perhaps more room for using HDL C but it has to be a FREE language and preferably standardized.

Really wIll have to look into FpgaC some time esp if its gets more traction and more references by others.

snipping

I think there needs to be a combination of Verilog (maybe VHDL) and a subset of C++ so that processes can be described in a common language that might run as conventional software on a single or massively threaded cpu or might also be synthesized onto hardware. It should still allow for bitwise low level hardware design if need be but should also allow higher lever synthesis too. That should be a boon to those Opteron systems with FPGA coprocessors .

I find myself moving further & further away from C++, leave as much of it as possible out of the loop. Perhaps Lisp would or should be the ticket.

Well I am not the worlds brightest spark either but what I can see is a mess all around me where ever I look, most of it as a result of too much idiotic complexity and too many parties. I yearn for the simplicity of years past. I have 4 different computers around the office house and every one of them is really crap, and some of it is pretty new crap. This one won't run that OS, that OS or mobo don't like that HD, those 2 HDs from same vendor can't be on same ribbon. Its really endless list of incompatibles. Give me a system based on something like SpaceWire links for everything and lots of throughput processors and no Memory Wall!

FWIW I always say that Verilog is closer to Pascal than C, C only supplies the arithmetic expression operators while Pascal supplies the module structure. A parser for C is far more complex than for Verilog even though on the surface C is supposed to be simpler.

John Jakson transputer guy

Reply to
JJ

10 years ago the price performance of FPGA's really was marginal. A decade of Moore's Law, and we are just now finding the price performance of FPGA's to be very competitive ... without the proper tools.

I agree that open source FPGA tools are critical .... and something that the big vendors haven't realized yet. I can still remember the posturing and standards problems that plagued the software industry 30 years ago ... till UNIX leveled the playing ground, and create a cooperative competitive environment the benifited all. Once reconfigurable computing starts to take off, the large computer vendors will mandate it. And leave those closed shops behind.

Standards really make the difference ... it's why a C HDL really needs to be ANSI C, with as FEW changes as possible (IF any at all). It's actually quite possible to design with ANSI C, and leave the changes in the back end tools. Restricting bit field declarations to structures isn't really a problem, and allows portability. A few pragma's are a bit deal either. Everything else should be portable, standards based. It's the problem I had with TMCC (the starting source code for FPGA), and Handel-C. It was a hard call not to start from scratch, rather than use the subset TMCC. The evolution of TMCC to an ANSI C in the FpgaC project has been slow, but steady progress. And even as a subset, with so-so synthesis, is amazingly useful. A few more good hardware/software people working on it, and it could be really "done" in a few months.

The most disappointing part of the project, has been the kids that arrive gungho, and discover it's actually some difficult learning and relatively challenging work as a programmer to do hardware tools. I'd hoped a few more computer engineering students would find the project.

Reply to
fpga_toys

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.