Unfortunately there's a bit of a US/Europe split on these langauges. Most US firms are pro Verilog while most European ones are VHDL.

I agree that VHDL is far too verbose but some of what I've see of Verilog syntax has looked a bit odd as well.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I'm not referring to syntax so much as just plain (to my eyes, at least) needless verbosity.

To help communicate that this isn't a typical C-vs-Pascal religious war, I also code in Oberon, a language substantially slimmer compared to Ada (and, hence, VHDL), and which is structured almost identically to Modula-2.

I'm a fan of Verilog and I'm from Europe, so it's no hard and fast rule.

It definitely seems Verilog is more popular among those who started in programming though.

VHDL versus Verilog has the appearance of a religious war - people do get very attached.

Many commercial tools are mixed-language - the Xilinx tools work with either.

I work in Bristol, and all the local startups and at least some of the larger outfits use Verilog. Larger companies might well use VHDL for some projects, certainly they used to.

If you think in bits and bytes, Verilog is going to be easier. If you like strongly typed languages like Java, Ada or Pascal then VHDL might appeal more.

I believe the difference is about whether you hope to get correct designs sooner with enforced disciplines or with low-level expressivity. My opinion: in a very small team, with highly skilled practitioners, a higher level approach might win, but in normal circumstances a low-level language is easier to make progress with.

The evidence(*) is that Verilog takes less effort to 'finish' - I think the only legitimate doubt would be whether a VHDL project which finishes later has fewer residual bugs.

(*) See Bill Fuch's 1995 paper and some of John Cooley's commentary

Speaking of Xilinx tools, I am using schematic entry to program a XC9572 CPLD for simple address decoding ATM. Looking ahead to a bigger project, say entering a schematic copied from a "6502 made from discrete TTL" to go onto maybe a Xilinx Spartan 3, is it possible to do it all by schematic only? Or must one learn one of these languages to get at "the nitty gritty". I am thinking a person like myself who is more familiar with schematics, can input the schematics, but for tighter tolerances will have the modify the generic verilog/VHDL code that the synthesizer comes up with. For instance, I've read you can specify a variable duty cycle clock in verilog/VHDL. When designing with schematics and truth tables all you know is rising edge or falling edge... (As they say, the more you learn, the less you know)

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I think schematics run out of steam when you have a larger team, or a very complex project, or where you want to express yourself at a more abstract level. You can probably stick with schematics for some way yet. Probably you can mix and match, anyhow.

I would advise against tweaking the output of synthesis - even if possible, it's a way to make a lot more work, and to introduce bugs. Much better to control the input. Xilinx tools have a WYSIWYG mode if you really want to design at the gate level: and again, you should be able to do that only in the smallest subset of your design where you really need it.

Big Ed, you started this thread (linked below) awhile back. I was searching through the threads here yesterday for leads on FPGA design, and thought these (Ruud's & yours) threads should be brought to the forefront, even though the opcode mods were made to optimize Forth. LOL. (I can hear Garth now, maybe Dr. Jefyll too; "even though"?!). Heh.... When one looks over their own code and can say, "it would run faster if I just modify the hardware", like do a databus "snoop" for an undefined opcode and then make it do something useful. This is the first true step to designing/redesigning the 6502. I know I am not the only new member interested in modifying maybe just a few non-defined opcodes for use. Maybe this would be the best start, before diving full fledged into a CPU design, i.e. going from step A to Z. I know just by looking at the concept, the discrete TTL can be replaced by even an XC9536, which you can readily find in 5ns speeds even still today, that's over a 100MHz "supervisory power"..

Oh yeah here is the thread, Dr. Jefyll's link is about half way down:(Much respect to the creator of the Kim-1, )
viewtopic.php?t=1465&highlight=fpga

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I read the links, (finally right?). Definately worth reading. Answered my question of Verilog or VHDL straightaway.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Yes, if I manage to do anything like this (beyond talking about it and reading up on what might be done) I will certainly take an incremental approach.

For one thing, the more divergent the CPU the bigger the amount of work in fixing up an assembler (or compiler, or FORTH kernel, etc)

I read somewhere a case of just patching some block-move instructions into some of the text-handling routines of a word processor, for a significant usability gain at minimal effort. I find that kind of thing very appealing.

Actually, porting Forth is usually a rather simple task. Starting with nothing but assembly language, you can reasonably expect to spend about two man-months working on one which includes a screen editor, assembler, multiple vocabulary support, etc. If you're looking for something comparable to cmForth, you can get away with spending less time. This is at least 3x faster than porting Oberon (6 man-months, according to Wirth) and a non-optimizing implementation of C, and probably about 12x faster than porting a reasonably optimizing implementation of C.

In fact, if you write your assembler to use reverse polish notation from the get-go, you have most of Forth's UI implemented already.

That being said, if your Forth system is itself written primarily in Forth, porting can potentially be much simpler. Most Forth systems have only 35 or so basic primitives; the remaining words implemented in terms of those primitives would then benefit from what little porting effort is required. High-performance applications and device drivers would then comprise the bulk of your porting efforts, since these will often use assembly language to gain speed in select places. Even so, Moore himself admits that while working at Forth Inc., he was able to port Forth from one processor architecture to another, often very different, architecture in as little as a few months.

I finally soldered and hooked up my GODIL40 on a breadboard: I can confirm that the power supply pins are freely configurable and therefore compatible with 6502 . I'm going to be proceeding slowly, but the next sub-goal is to get a T65 acting as a 6502.

In this picture I've jumpered the supplies to pins 8 and 21, like a 6502:


40 pins act as a 40-pin DIP, there are 8 more I/Os and 2 more inputs on the two 50-pin headers topside, and then the 9-pin test connector has 7 more I/Os (not entirely general purpose). It's highly usable and 5v compatible, but hasn't as many I/Os as you might get from a different design. We intend to use this module to qualify some designs, and then integrate them in a different incarnation.