Author Topic: Books on Verilog/VHDL  (Read 17154 times)

0 Members and 1 Guest are viewing this topic.

Offline UnixonTopic starter

  • Frequent Contributor
  • **
  • Posts: 398
Books on Verilog/VHDL
« on: May 05, 2014, 05:06:11 am »
In the meantime I was looking for a good reading on Verilog/VHDL and found a few interesting books.
In particular, "Digital Design (Verilog)" and "Digital Design (VHDL)" by Peter J. Ashenden and "ASIC and FPGA Verification" by Richard Munden.

What do you think about these? What would you suggest?

I believe there are lot of worthy reading, but really good books are quite costly and not easy to get.
A desired coverage is either (a) encyclopedic reference; or (b) good design approaches and practices; or (c) implementation of different blocks from relatively basic logic up to complex stuff like modern CPU/GPU/DSP, buses, interfaces, controllers, etc. A set of explained examples ordered by complexity would be very appreciated.

I've read through some related sites on the web with entry-level stuff and that was fine, but then I noticed a huge gap between these and like, say, proven implementations from opencores.org which I couldn't fill with any appropriate information. This gap between very basic and quite complex stuff is probably obvious, but this gap is exactly what I want fill somehow.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Books on Verilog/VHDL
« Reply #1 on: May 05, 2014, 10:35:05 pm »
I am just a hobbyist, so professionals are more than welcome to beat me up about these comments.

The deep "HDL language reference" books are giving you tools you never will use, unless you are writing very sophisticated test benches.  All the HDL constructs used in a project can fit on the back of a postcard (well, maybe an A4 quick reference, if you include data type conversions).

Unlike software, where code reuse and encapsulation is a priority, designing in HDL is about partitioning a design into small logical chuncks. It should pretty much follow any sensible block diagram of the system, and the requirements for verification (each sub-unit should be able to function as a stand-alone module for testing). If you can't draw out your block diagram before you touch a HDL then you want to read up on that subject (e.g. CPU Architecture, DSP),  reading a book focused on a HDL isn't going to help.

Most of the really complex stuff (DSP blocks, memory controllers) has migrated into dedicated blocks on the FPGA, so the best reference is usually the vendor's documentation.  They are usually pretty interesting to read, far more so than reading S/W API documentation, and hint at interesting non-obvious use-cases (e.g. using block RAM as a high speed FSM). So spend some time reading the user guides - they are surprisingly interesting and while building projects you will think something like "Oh, I could use my block RAM as a 16k x 1-bit wide ROM, and use that to drive the CMD signals of the SD card, rather than building a huge state machine..."

When it comes to interfacing with off-chip devices (e.g. SDRAM, DACs, Codec, cameras) you are pretty much on your own unless your vendor provides reference designs. It is just going to be sitting down with datasheets, reading them 20 times, debugging, and then out of the end will pop a few pages of HDL, with probably a small book's worth of thinking & experience behind them. You won't however find the book "How I interfaced my FPGA with a brand X CMOS camera" - why would somebody spend days/weeks writing what would be interest to a dozen people? (however I've recently helped quite a few students get their projects working...)

It is going to be much like riding a bike or juggling - you just have to build up experience. Pick a project and aim higher than you think you will reach -  it really isn't that hard when you have a deep understanding of the problem, and you might as well work on something that really interests you then building "yet another VGA controller".

Take for example my FM SOS transmitter (http://hamsterworks.co.nz/mediawiki/index.php/FM_SOS). It is about 20 lines of actual code - however if I was to describe actually how it works it would take many pages...



« Last Edit: May 05, 2014, 11:00:04 pm by hamster_nz »
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 
The following users thanked this post: sean0118

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8517
  • Country: us
    • SiliconValleyGarage
Re: Books on Verilog/VHDL
« Reply #2 on: May 05, 2014, 10:57:19 pm »
Bhaskers Verilog for synthesis is a very good base language primer.

as fro good examples ... opensores is about as far away from what you want to use as refernce.  some of the code is ok but there is a lot of very bad code out there.

oh, and something very important : learn the principle of scheduling in logic synthesis (part of the IEEE standard ). it will help you tremendously to make write very clear , first time right logic.

i just wrote a block that is more than 2000 lines of verilog. apart from some dyslectic typing errors it compiled first time right and does exactly what it was intended to do. i didn't even bother to simulate it. plonked it in the fpga and ran it.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 
The following users thanked this post: sean0118

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Books on Verilog/VHDL
« Reply #3 on: May 05, 2014, 11:03:22 pm »
oh, and something very important : learn the principle of scheduling in logic synthesis (part of the IEEE standard ). it will help you tremendously to make write very clear , first time right logic.

Googling for "principle of scheduling in logic synthesis" - 0 hits. :(

Any chance of tossing me a link?
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline Dongulus

  • Regular Contributor
  • *
  • Posts: 232
  • Country: us
Re: Books on Verilog/VHDL
« Reply #4 on: May 05, 2014, 11:16:28 pm »
The deep "HDL language reference" books are giving you tools you never will use, unless you are writing very sophisticated test benches.  All the HDL constructs used in a project can fit on the back of a postcard (well, maybe an A4 quick reference, if you include data type conversions).


I agree with this. I'm a fairly new professional, but I have been cranking out a lot of VHDL in the last couple of months. From what I have put together and from all of the HDL I have been staring at, I have not yet encountered the need for any constructs more complicated than state machines and selected signal assignments. Granted, this is a relatively simple design, but it's still beyond the scope of a hobbyist project.
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13748
  • Country: gb
    • Mike's Electric Stuff
Re: Books on Verilog/VHDL
« Reply #5 on: May 05, 2014, 11:25:51 pm »
You definitely want something specifically aimed at FPGAs, as a general HDL book will have a ton of stuff you'll never use.
I found "VHDL for Programmable Logic" by Kevin Skahill quite good.
Although published by Cypress, and quite old,  it isn't manufacturer specific.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: Books on Verilog/VHDL
« Reply #6 on: May 06, 2014, 12:08:15 am »
The deep "HDL language reference" books are giving you tools you never will use, unless you are writing very sophisticated test benches.  All the HDL constructs used in a project can fit on the back of a postcard (well, maybe an A4 quick reference, if you include data type conversions).


I agree with this. I'm a fairly new professional, but I have been cranking out a lot of VHDL in the last couple of months. From what I have put together and from all of the HDL I have been staring at, I have not yet encountered the need for any constructs more complicated than state machines and selected signal assignments. Granted, this is a relatively simple design, but it's still beyond the scope of a hobbyist project.
I'd like to add that the complex VHDL constructs can be major time savers. Just translating logic into VHDL takes a lot of time and typing while VHDL offers many elegant ways to solve a problem with a little bit of code.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Books on Verilog/VHDL
« Reply #7 on: May 06, 2014, 06:11:56 am »
Ashenden's "The Designer's Guide to VHDL" is a pretty good reference IMO.

Offline UnixonTopic starter

  • Frequent Contributor
  • **
  • Posts: 398
Re: Books on Verilog/VHDL
« Reply #8 on: May 06, 2014, 09:55:32 am »
It's true that we can leave the description language alone and think about the architecture first. So, the next question follows.

Are there any books/papers/web sites/whatever that explain the design of something like a modern AVR/PIC/ARM type micro-controller with all its built-in peripheral interfaces block-by-block? Even the code itself is easily available for some parts, but not the explanation why it is so.

I think the proper question would be not about the Verilog/VHDL, but about the architecture of whatever you can find in digital ICs nowadays in connection to description languages. Does anything like that exist out there?
 

Offline jeremy

  • Super Contributor
  • ***
  • Posts: 1079
  • Country: au
Re: Books on Verilog/VHDL
« Reply #9 on: May 06, 2014, 11:11:37 am »
It's true that we can leave the description language alone and think about the architecture first. So, the next question follows.

Are there any books/papers/web sites/whatever that explain the design of something like a modern AVR/PIC/ARM type micro-controller with all its built-in peripheral interfaces block-by-block? Even the code itself is easily available for some parts, but not the explanation why it is so.

I think the proper question would be not about the Verilog/VHDL, but about the architecture of whatever you can find in digital ICs nowadays in connection to description languages. Does anything like that exist out there?

+1 for this
 

Offline Rigby

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: us
  • Learning, very new at this. Righteous Asshole, too
Re: Books on Verilog/VHDL
« Reply #10 on: May 06, 2014, 01:23:12 pm »
Have any FPGA-knowledgable C devs looked at any of the emulated processors in the MAME & MESS source code tree to see if they could be used to produce better FPGA CPU or DSP implementations?  I am fairly certain that some of those emulated processors are very feature complete.

The MAME & MESS source code is well beyond my understanding, and it looks (again, to my ignorant eyes) that there are some very odd things being done to make implementation of new hardware easier.  Maybe one of you C devs can figure it out though, and make something useful on an FPGA.

I'm not suggesting that anyone implement an FPGA-based MAME or MESS system (while that would be incredibly awesome) I am just suggesting another option when looking for implementing an older CPU on an FPGA, or even just understanding how they work.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: Books on Verilog/VHDL
« Reply #11 on: May 06, 2014, 01:25:58 pm »
It's true that we can leave the description language alone and think about the architecture first. So, the next question follows.

Are there any books/papers/web sites/whatever that explain the design of something like a modern AVR/PIC/ARM type micro-controller with all its built-in peripheral interfaces block-by-block? Even the code itself is easily available for some parts, but not the explanation why it is so.

I think the proper question would be not about the Verilog/VHDL, but about the architecture of whatever you can find in digital ICs nowadays in connection to description languages. Does anything like that exist out there?
Such a book would have 'digital systems design' in it's title or description. Did you try to look at amazon.com? Most books have a couple of reviews. Read the reviews to see what people think of the book and why it is good or bad. The bad reviews are the most interesting ones. Sometimes a bad review means someone bought the wrong book for their purpose. It may be the right book for your purpose.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Rigby

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: us
  • Learning, very new at this. Righteous Asshole, too
Re: Books on Verilog/VHDL
« Reply #12 on: May 06, 2014, 02:25:30 pm »
why do reviewers do that?  "I ordered the wrong book" or "this book isn't what I thought it was going to be, so I'll give it 2 stars."  It's not the book that's the problem, dude, it's your expectations of the book that were the problem.

review the book on the merits of the book, don't review the book based on your own skill at guessing which book to buy.

sorry for the o/t posts...
 

Offline UnixonTopic starter

  • Frequent Contributor
  • **
  • Posts: 398
Re: Books on Verilog/VHDL
« Reply #13 on: May 06, 2014, 03:25:58 pm »
Such a book would have 'digital systems design' in it's title or description. Did you try to look at amazon.com?
Yes, I did. Actually, I saw more interesting books on different aspects of electronics design than I can buy. Here's why I'm asking questions now. Maybe someone already has something on his bookshelf and can personally recommend it. According to my experience, you never know if it's a good book for you unless you get it and check what's inside. I've done this with local web shops and the ratio of good books to all books that seemed good for a purpose is about 20%. Doing the same thing with Amazon would consume too much of a budget.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: Books on Verilog/VHDL
« Reply #14 on: May 06, 2014, 03:37:48 pm »
why do reviewers do that?  "I ordered the wrong book" or "this book isn't what I thought it was going to be, so I'll give it 2 stars."  It's not the book that's the problem, dude, it's your expectations of the book that were the problem.
I don't know why reviewers do that but I find it very helpful to learn from other people's mistakes  >:D
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline nowlan

  • Frequent Contributor
  • **
  • Posts: 649
  • Country: au
Re: Books on Verilog/VHDL
« Reply #15 on: May 06, 2014, 03:52:43 pm »
Can always try books.google.com to get a look inside the books. See if it covers the topics you're interested in.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8517
  • Country: us
    • SiliconValleyGarage
Re: Books on Verilog/VHDL
« Reply #16 on: May 06, 2014, 04:37:07 pm »
oh, and something very important : learn the principle of scheduling in logic synthesis (part of the IEEE standard ). it will help you tremendously to make write very clear , first time right logic.

Googling for "principle of scheduling in logic synthesis" - 0 hits. :(

Any chance of tossing me a link?

you will find almost no links to this. it is mentioned in the IEEE standard for verilog in paragraph 5.4.1 under Determinism

" The standard guarantees a certain scheduling order -snip-
Statements within a begin-end block shall be exceuted in the order in which they appear ... -snip- ....
in no case shall the statements be executed in any order other than that in which they appear. "

" non blocking statements shal be executed in the order they appear "

here is an example of this mechanism in action
Code: [Select]

always @(posedge clock)
   if (reset) count <=0;
   else
      if (enable) begin
         if preset count <=data_in;
         else 
            if(updown) count <=count +1;
            else count <= count -1;
     end
end

simple up down counter with parallel load and reset.
reset works always
preset and count only work when enabled. preset has priority over counting operation

using the principle of scheduling this thing becomes much simpler to write and maintain

Code: [Select]

always @(posedge clock)
   
     if (enable) begin

         if(updown) count <=count +1;
         else count <= count -1;
   
         if preset count <=data_in;
   
     end
     if (reset) count <=0;
end

the block inside the if(enable) only runs if enable is true.
checking reset always runs. as this is the last operation in the list it has the most 'power'
i don't care what was done by all previous operations. if reset is active count goes to zero.

same for the preset operation. i dont care that the counter has been modified 'before' . if preset is active the counter gets loaded.

here is why this works the way it works : it has to do with HOW a synthesizer builds logic. it doesnt matter if you are using VHDL or Verilog they ALL work like that as it is part of the standard. any synthesizer out there needs to do it this way to be compliant to the standard.

we humans write a sequential list of operations and the synth needs to 'parallelise this'. how is this done ? by creating mux-chains.

lets take this step by step.

The synthesizer starts reading my code. grabs a clock, creates a bunch of flipflops for 'count' and ties the clock to those flipflops. Now it hits the if (enable) statement. an if construction is basically a multiplexer.  ((AX) + (BXn))
if enable is high then A goes through , if enable is low then B goes through.
So the outputs of the flipflops go to B (enable low) the input A is left open.

Note : the standard says that for any multiplexer input where there is NO specific clause given the current output will be applied. this means you never have undefined operations ! you only need to specify the 'changes'. anything you did not define does not happen and the registers don't change state. a nice side effect is that you never get that dreaded latch inferral or undefined pathways in state machines.

Now, we hit another multiplexer controlled by updown. so we tie input A of the first multiplexer to a new one , under control of UPDOWN. input A gets count-1 , input B gets count+1.

this pathway is now closed.

The next line says if (reset). the synthesizer wil now do the following : it will take EVERYTHING it has already generated and INSERT a multiplexer between that block and the register. so that whole block if enable if updown.. get shifted to the left and a multiplexer is inserted under control of reset.

If reset is active then 0 is sent through to the registers, if not then whatever was in effect goes through (and that is all the code that was generated up till now )

that is how synthesizers work and build logic multiplexers are very simple boolean operations and chains of multiplexers can be minimised very compact resulting in the fastest possible logic.

using this principle i could have written this code even differently

Code: [Select]
always @(posedge clock)
  if(updown) count <=count +1;     // this is the default operation
  else count <= count -1;
  if (preset) count <=data_in;     // unless preset is active then this line overrides.
  if (enable == 0) count <=count;  // unless enable is false then we do not alter 'count'
  if (reset) count <=0;            // unless reset is active then we make count zero
end

the advantage of using this principle is that you squash complex if then else constructs to a few lines.

reading such code and understanding its exact behavior is also very simple. the last line has most 'weight'
if someone gives me this :

Code: [Select]
always @(posedge clock)
  if (shift) value <= value <<1;
  else value <= value >>1;
  if (sample) value <=data_in;     // unless preset is active then this line overrides.
  if (enable == 0) value <= value;  // unless enable is false then we do not alter 'count'
  if (reset) value <=0;            // unless reset is active then we make count zero
end

reading and understanding is now easy. :

depending on 'shift' we shift left or right.
unless sample is active then we latch in new parallel data.
unless enable is zero, in which case value does not change.
unless reset is active in which case we clear.

If i now tell you that preset needs priority over reset. you simply swap the position of two lines.

There is now certainly a bunch of people that will growl on this as it is not 'proper' VHDL or Verilog. and they are right and wrong at the same time.

This is verilog for SYNTHESIS. meaning we will make actual logic with this.
you will rarely encounter this kind of code in the wild because of two reasons :
1 - most code is written by code monkeys that follow textbooks . textbook written by people who don't understand how a synthesizer works and never read the IEEE standards.
2 - most people code for FPGA and have no idea how their 'ramblings' impact actual mapping. just take a larger fpga if it doesn't fit.

Go to the industry (and i mean the semiconductor business where asics are made ) and you will see this kind of code.
- it promotes first time right
- it avoids undefined pathways
- it synthesizes the combinatorial cloud to the smallest equations possible.
- easy to understand easy to maintain easy to alter.

Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: Books on Verilog/VHDL
« Reply #17 on: May 06, 2014, 04:52:38 pm »
Code: [Select]
always @(posedge clock)
  if (shift) value <= value <<1;
  else value <= value >>1;
  if (sample) value <=data_in;     // unless preset is active then this line overrides.
  if (enable == 0) value <= value;  // unless enable is false then we do not alter 'count'
  if (reset) value <=0;            // unless reset is active then we make count zero
end

reading and understanding is now easy. :
- easy to understand easy to maintain easy to alter.
No it is not. It is obscure code which makes it very hard for novices (or people who work with FPGA off and on) to understand what is going on. It is a perfect way to always be the person to work on a certain project while you want to move on doing more interesting things.

Code should be written in a way it describes what it does. If there are too many if statements use a switch/case instead. Or even better: concatenate control signals into a single signal (let's say operation). What is easier to understand than (pseudo code):

case operation is
  reset=> counter<=0;
  count_up => counter<=counter+1;
  load=> counter <= some_value;
etc, etc.

edit: which operation preceeds over the other is sorted out when creating the 'operation' signal.
« Last Edit: May 06, 2014, 05:48:42 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Books on Verilog/VHDL
« Reply #18 on: May 06, 2014, 09:36:07 pm »

Code should be written in a way it describes what it does. If there are too many if statements use a switch/case instead. Or even better: concatenate control signals into a single signal (let's say operation). What is easier to understand than (pseudo code):

case operation is
  reset=> counter<=0;
  count_up => counter<=counter+1;
  load=> counter <= some_value;
etc, etc.

edit: which operation preceeds over the other is sorted out when creating the 'operation' signal.

I find that concatenation of control signals to be dangerous... there are three control signals, so you have eight options. Are you going to enumerate them all?

I much prefer
Code: [Select]
process(clk)
begin
  if rising_edge(clk) then
    if load = '1' then
       counter <= some_value;
    elsif count_up = '1' then
       counter <= counter + 1;
    end if;

    if reset = '1' then
      counter <= x"00"
    end if;
  end if;
end process;

Why do i prefer it?
  • It clearly seperates out the reset state from the 'usual flow'.
  • The reset only involves assignment of constants
  • It clearly shows the priority of the control signals
  • All the expressions are "if this is asserted then do this".
I hate code where it is "do this" but when this isn't asserted then reassign the signal. Here's soemthing that is perfectly valid, but I hate:

Code: [Select]
process(clk)
begin
  if rising_edge(clk) then
    counter <= counter + 1;  -- default to what we really want to do
    if reset = '1' then
      counter <= x"00" -- reset it to zero when reset is asserted
    else
       if count_up = '0' then
         counter <= counter;    -- unless count_up isn't assserted
      end if;
      if load = '1' then
         counter <= some_value;  -- load the value
       end if;
    end if;
  end if;
end process;

I try to code so that even if the reader knows nothing about delayed assignment of singals they still get the same answer - basically never use a signal on the right hand side of an assignment after it has been assigned. And I really hate it when people use VHDL variables...
« Last Edit: May 06, 2014, 09:45:14 pm by hamster_nz »
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Books on Verilog/VHDL
« Reply #19 on: May 06, 2014, 09:55:10 pm »
Have any FPGA-knowledgable C devs looked at any of the emulated processors in the MAME & MESS source code tree to see if they could be used to produce better FPGA CPU or DSP implementations?  I am fairly certain that some of those emulated processors are very feature complete.

Apart from finding out about undocumented features within a chip set, or to get memory space layout for a given game the MAME & MESS sources are next to useless. The sources are a serial description (usually tuned for performance) of how move bits around in memory to make it look as if they were being manipulated by a Z80 CPU. It has nothing about bus timings, video hardware and other things that are needed to recreate the functionality of the old hardware inside an FPGA, clocked at the original clock speed.

If you want to look at some old schematics, have a look at https://www.mikesarcade.com/arcade/manuals.html, if you want to have a look at a modern take on a Z80 system in an FPGA, have a look at socz80 - http://sowerbutts.com/socz80/. It's a Z80 CPM system with 8MB of SDRAM, support for SD cards, clocks at 120+MHz.

Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline Rigby

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: us
  • Learning, very new at this. Righteous Asshole, too
Re: Books on Verilog/VHDL
« Reply #20 on: May 06, 2014, 11:20:38 pm »
Have any FPGA-knowledgable C devs looked at any of the emulated processors in the MAME & MESS source code tree to see if they could be used to produce better FPGA CPU or DSP implementations?  I am fairly certain that some of those emulated processors are very feature complete.

Apart from finding out about undocumented features within a chip set, or to get memory space layout for a given game the MAME & MESS sources are next to useless. The sources are a serial description (usually tuned for performance) of how move bits around in memory to make it look as if they were being manipulated by a Z80 CPU. It has nothing about bus timings, video hardware and other things that are needed to recreate the functionality of the old hardware inside an FPGA, clocked at the original clock speed.

If you want to look at some old schematics, have a look at https://www.mikesarcade.com/arcade/manuals.html, if you want to have a look at a modern take on a Z80 system in an FPGA, have a look at socz80 - http://sowerbutts.com/socz80/. It's a Z80 CPM system with 8MB of SDRAM, support for SD cards, clocks at 120+MHz.

Well there are far more than the Z80 in there.  My understanding is that the poor code in MAME/MESS is not really emulating, but rather doing as you describe, and that the good sets are proper emulators, doing everything the emulated physical CPU can do and no more by actually implementing the CPU in code.

That said, I am very much not an expert in C or in the MAME/MESS codebase, and I can only vouch for my understanding as of a year ago.  I do know that the mamedev team is very keen on proper emulation, whatever that means. If you haven't looked at the code in the past year or so, I would greatly appreciate an opinion on a recent version of the code from someone who knows both C and VHDL/Verilog.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Books on Verilog/VHDL
« Reply #21 on: May 07, 2014, 12:17:35 am »
That said, I am very much not an expert in C or in the MAME/MESS codebase, and I can only vouch for my understanding as of a year ago.  I do know that the mamedev team is very keen on proper emulation, whatever that means. If you haven't looked at the code in the past year or so, I would greatly appreciate an opinion on a recent version of the code from someone who knows both C and VHDL/Verilog.

I have read through the MAME code while considering converting Crystal Castles to an FPGA implementation. It was next to useless compared with the service guide and schematics, and VHDL components from the now defunct FPGAarcade.com.

Some members of the MAMEdev team have dogma issues that I don't understand / can't make sense off. They want 'cycle accurate' emulation, but the primary outputs (CRT and audio) are nothing like what it was like in the original hardware. Their interperatation of "cycle accurate" seems to be that the contents of memory and CPU registers should be identical to that of the actual hardware, when presented with the same changes in external inputs. How they allow for the latency involved with usb connected joysticks, audio buffering and frame buffer updates is beyond me.

They are not "preserving the past" but making the digital equivilent of replica kit cars.

Even in an 'cycle accurate' FPGA implementation you can't/shouldn't do internal tri-state buses, and memories like DRAM has now been superceeded by newer tech requiring quite a bit of glue to make it all work. Oh, and re-implementing old-school on-chip audio filters and ring modulators is a pain.


Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: Books on Verilog/VHDL
« Reply #22 on: May 07, 2014, 12:31:57 am »

Code should be written in a way it describes what it does. If there are too many if statements use a switch/case instead. Or even better: concatenate control signals into a single signal (let's say operation). What is easier to understand than (pseudo code):

case operation is
  reset=> counter<=0;
  count_up => counter<=counter+1;
  load=> counter <= some_value;
etc, etc.

edit: which operation preceeds over the other is sorted out when creating the 'operation' signal.

I find that concatenation of control signals to be dangerous... there are three control signals, so you have eight options. Are you going to enumerate them all?

I much prefer
Code: [Select]
process(clk)
begin
  if rising_edge(clk) then
    if load = '1' then
       counter <= some_value;
    elsif count_up = '1' then
       counter <= counter + 1;
    end if;

    if reset = '1' then
      counter <= x"00"
    end if;
  end if;
end process;

Why do i prefer it?
  • It clearly seperates out the reset state from the 'usual flow'.
  • The reset only involves assignment of constants
  • It clearly shows the priority of the control signals
  • All the expressions are "if this is asserted then do this".
I still don't like the reset. It forces the person working on your code to spend time on thinking why that would work. Just like in C where you can do 'if (variable) a=1;'. Is the condition true when variable is zero or non zero? I don't want to think about that sort of stuff.

The example is a bit limited but the problem goes much deeper: why are there 3 different control signals to begin with? In many cases it is better to have one signal (vector) which says what the state is. Sometimes you see it in software as well. A multitude of variables and if statements 'if a=1 but b=29 and if c=pi then do this only if d=-1'. That is much better solved by using one variable which contains the state. In programmable logic reset is often a special case but for other signals there are better ways if people think about it in the design stage.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: Books on Verilog/VHDL
« Reply #23 on: May 07, 2014, 01:11:11 am »
Have any FPGA-knowledgable C devs looked at any of the emulated processors in the MAME & MESS source code tree to see if they could be used to produce better FPGA CPU or DSP implementations?  I am fairly certain that some of those emulated processors are very feature complete.

The MAME & MESS source code is well beyond my understanding, and it looks (again, to my ignorant eyes) that there are some very odd things being done to make implementation of new hardware easier.  Maybe one of you C devs can figure it out though, and make something useful on an FPGA.

I'm not suggesting that anyone implement an FPGA-based MAME or MESS system (while that would be incredibly awesome) I am just suggesting another option when looking for implementing an older CPU on an FPGA, or even just understanding how they work.

It's been done, google P.A.C.E "Programmable Arcade Circuit Emulation"
But their forum is broken at the moment.  I'm porting it to two new dev boards at the moment.
 

Offline Rigby

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: us
  • Learning, very new at this. Righteous Asshole, too
Re: Books on Verilog/VHDL
« Reply #24 on: May 08, 2014, 12:56:43 am »
It's been done, google P.A.C.E "Programmable Arcade Circuit Emulation"
But their forum is broken at the moment.  I'm porting it to two new dev boards at the moment.

ooh neat.  can you PM me your progress? I'd rather not derail this thread further...
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf