Problem trying to simulate in Modelsim.

[BrianHGinc]

(Note that I program in SystemVerilog, not VHDL)
Hello,

I'm trying to simulate your 'ym2149_audio.vhd' in ModelSim. Your core appear to properly receive my command and the PCM out does change to it's first new value, but, gets stuck there as well as the 3 channels out plus the mix staying stuck at 0.

During simulation, Modelsim does properly compile your core without warnings or errors, but, when the simulation runs, these 6 warnings are reported:

 ** Warning: NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0
    Time: 0 ns  Iteration: 0  Instance: /psg_tb/PSG
 ** Warning: NUMERIC_STD."<": metavalue detected, returning FALSE
    Time: 0 ns  Iteration: 0  Instance: /psg_tb/PSG
 ** Warning: NUMERIC_STD."<": metavalue detected, returning FALSE
    Time: 0 ns  Iteration: 0  Instance: /psg_tb/PSG
 ** Warning: NUMERIC_STD."<": metavalue detected, returning FALSE
    Time: 0 ns  Iteration: 0  Instance: /psg_tb/PSG
 ** Warning: NUMERIC_STD."<": metavalue detected, returning FALSE
    Time: 0 ns  Iteration: 0  Instance: /psg_tb/PSG
 ** Warning: NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0
    Time: 0 ns  Iteration: 0  Instance: /psg_tb/PSG

Now, you code appears to work within Quartus to a dumb direct parallel DAC, but, we need a simulation to follow the output through a filtered resampling chain we are working on for an industry standard 48Khz I2S output. I'm hoping that the 'metavalue' can be corrected with a type/form of cast, but without any VHDL knowledge, I wouldn't know where to start.

If you have Modelsim, you can download my testbench setup here:
https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/?action=dlattach;attach=1548325
Originating forum post here:
https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg4320403/#msg4320403

To run in Modelsim, select 'File / Change Directory', and select the directory of the contents of the .zip file. Then in the 'transcript' window, type:
do setup_psg.do

For a quick recompile and re-run of the sim, in the transcript window, type:
do run_psg.do

Line 6 in my 'psg_tb.sv' file contains the stop-time for the simulation. Multiply by another 10 to simulate 0.01 seconds in real time. Multiplying further will make the simulation take a very long time. The other solution is to shrink the divisor in line 11 from 56 to 5 to accelerate the PSG ~11 fold.

Thx for your time,
BrianHG & Nockieboy.

[dnotq]

(Note that I program in SystemVerilog, not VHDL)

Note: I describe hardware with VHDL, and avoid any kind of Verilog whenever possible (and absolutely for my hobby work.)

The metavalue at 0ns is just simulation being noisy, it will resolve in the first time iteration when simulation starts. I went ahead and added a default for the combinatorial signal that seemed to be the cause of the message, however this has nothing to do with your simulation not working.

I also added a simple testbench and a screen-shot of the output waveforms to show the output changing. Make sure you are programming the chip correctly in your simulation, and that your timing is correct.

This core is modeled on the real chip, so you have to treat it like the real chip.

[wilsondr9999]

I'm in the same boat as Brian, I am getting the same warning messages in ModelSim. Part of the problem is that the testbench file you uploaded to the repository appears to be for a different version of the ym2149_audio.vhd file. The port definitions do not match, specifically the ym2149_audio.vhd file has a sel_n_i signal which the testbench file does not have, and the testbench file references a signal en_clk_io_i which does not correspond to a port in ym2149_audio.vhd.

This caused an endless series of compile errors, but I managed to modify the testbench file enough to get it to compile. (My apologies, but like Brian, all of my work has been done in Verilog, and I'm completely unfamiliar with VHDL syntax).

Once I got it compiled, my results are the same -- the 6 warning messages and no changes in any of the outputs or PCM.

I have no doubt that this code works, but I cannot seem to get it set up properly in ModelSim. FYI, ModelSim is the simulation tool provided with Lattice's iCEcube2 FPGA design software, so I'm stuck using that.

One other issue that I ran into is that the Lattice synthesis engine (Synplify) does not seem to like the register file initialization on lies 497-512 of ym2149.vhdl. The error reported was that "MF682: Initial values are not supported for RAM reg_file_ar[7:0] which includes a global reset. MF683 Initial values found on one or more RAMs with global reset." I assume this means that the synthesis engine is mapping the register file to one of the RAM blocks in the device that has a global reset, and that's not allowed. This is probably device-specific, as devices that have RAM blocks without global resets wouldn't be affected. The fix should be straightforward, in that there is probably a directive that can be put in the code that would place the register file in a different RAM block that doesn't have a global reset, but as the code is VHDL, I don't know how to do that. I commented those lines out and got it to compile, but obviously that would affect the device operation.

On a side note, I got the Lattice software to compile this successfully for an ICE40LP1K-CB121 device, which sells for less than $7.00. This is actually less expensive that what you can get the real YM2149 chip for if you buy from a reputable seller ($14.99 from Unicorn Electronics, and that's actually for the AY-3-8910, not the YM2149). I can probably get it to compile for an even smaller device from Lattice if I remove the individual output channels and leave only the sum and/or PCM outputs, as that reduces the IO pins needed.

Anyway, sorry this got longer than I wanted, but if you have any advice on the testbench file or the register file issue, it would be most appreciated.

[wilsondr9999]

OK, got past the register initialization issue. Lattice's iCEcube2 software actually has two synthesis engines available, Synplify (default) and the new Lattice Synthesis Engine, which is their own design. Apparently, the LSE has more knowledge of the device specifics, and when I switched to this engine, it recognizes that it needed to assign the register file to a different RAM block that didn't have a global reset, and it successfully synthesized the ym2149_audio.vhdl file as written.

[dnotq]

Thanks for pointing out that the testbench did not match the core, I copied an older testbench file when I created the repo. That is fixed now.

I also added initialization for the combinatorial signals that simulation was complaining about at 0ps.

The reason the outputs were not changing in the testbench is because the PSG was not being progammed to generate any tones. My initial testbench was very basic to just help me verify the operation, it was not designed to run full tests or set up the PSG tone channels (I used real hardware for that, it is much easier to hear sounds than to look at simulation results).

As for the problem with the reg_file_ar signal, as you discovered that is an issue with your tool, not the HDL. The HDL is not FPGA specific and relies on the tools to infer the correct structures. In the case of ref_file_ar, it is so small and used in a way that the tool should have implemented it with flip-flops/logic, and not with any kind of Block-RAM. I'm glad you got it to work using the other synth engine. I'm not a fan of Lattice (crappy business practices) and avoid their FPGAs.

Replacing a real legacy IC with an FPGA is not so simple, and you will have to deal with the 5V I/O of the retro host computer, which is a problem for most modern FPGAs. You will soon find that adding the necessary regulation and level shifters quickly complicates the design to the point where it is much more expensive than the original IC. Also, a drop-in electrical replacement has a pile of other problems. Finally, you will need to put an asynchronous interface in front of the core.

(My apologies, but like Brian, all of my work has been done in Verilog, and I'm completely unfamiliar with VHDL syntax)

No comment, other than to say, like Brian, you should really consider learning VHDL, it is way easier and better than Verilog. Verilog is full of foot-guns and very hard to read (IMO), especially the way people are writing with it these days. VHDL is better in almost every aspect when it comes to describing hardware, again, my opinion.

[wilsondr9999]

Thank you for updating the testbench file. I will sync the repo and give it a try in the next day or two.

I did extend my testbench that I had modified to initialize all of the proper registers to get a tone out of channel A, but it still did not work. That may very well be because I didn't modify the testbench correctly, so I'll try again with your new testbench, and I'll extend it the same way to write to all the registers correctly to get a tone.

I read up on some of the options in the Lattice synth engine and there is a way to force it to implement the register file as DFF vice block RAM, so I may turn that option on given that the register file is small.

I agree with you that Lattice may not be the best choice as a company, but as Xilinx and Altera have been purchased by AMD and Intel respectively, they seem to have dropped a lot of support for small devices that a hobbyist might use. Furthermore, all of their current production devices are BGAs, which are nearly impossible for a hobbyist to use, whereas Lattice has some TQFP packages that can be hand-soldered. I'm solely a hobbyist who messes with this stuff for fun, my day job is IT, not EE, even though my degree is EE. As such, my personal projects are cost sensitive, and the cheap devices, free software, and usable packages from Lattice fit my needs much better.

From my programmer's perspective, I totally agree with you that the formality and specificity of VHDL is superior to Verilog. However, at least in the US, the preferred HDL is highly dependent on what manufacturing sector you're working in. Most universities here teach Verilog, and as such most EE graduates are familiar with it and not VHDL. VHDL is used primarily in the large enterprise, government, and defense/military areas, whereas hobbyists, educators, and consumer electronics generally gravitate towards Verilog. As a hobbyist, I need to use a lot of freeware and open source tools to reduce costs, and the vast majority of those work with Verilog. Only a minority work with VHDL.

Given that this project's target audience would be hobbyists / retro computer builders / retro gaming, I would imagine that this audience would be vastly more familiar with Verilog than VHDL.

Nevertheless, thank you again both for creating the project and for keeping it updated. I'll post back here with my results.

[dnotq]

I waffled a lot on whether to implement the registers discretely or as a small memory. The Xilinx tools implemented the design as intended, so I left it that way. The design could be modified to use discrete registers of the exact size, which would more accurately model the real IC, but so far no one has submitted a pull-request for the change.

This is totally hobby stuff for me as well, however, IMO that just means things cost more (hobbies are always expensive). When I design a board, I easily spend way more than I would for some equivalent electronics. For example, my F18A board will always cost way more than something like a $25 Chinese video-converter board or a $3 RPi. Such is the way of hobbies.

For sure Xilinx and Altera are focusing on the higher end FPGAs, but most of the world is moving towards smaller packages and lower voltages. Even the cheap FPGAs from Lattice and Efinix are mostly BGA packages, which is certainly a PITA for hobbyists. However, PCB capabilities are also available to the hobbyist that were not before, and you can make a 4-layer board with 5/5mil trace/space tracks and have 5 boards assembled and shipped for under $20 + BOM cost. This is a game-changer for hobbyists, and opens a lot of possibilities. Still, the smallest and cheapest FPGAs are BGA with 0.4mm (or 0.35mm) pitch, and I won't touch those as a hobbyist.

Rant-on:
As for Verilog vs VHDL, I learned both and much prefer VHDL. As a hobbyist I am not very concerned about what other people prefer, and I'm sad to see Verilog taking such a foothold in academia and the hobby FPGA scene. Probably my biggest objection is the way people are describing hardware with Verilog. Since Verilog looks more like a "programming language", and hobbyists getting into FPGAs tend to be software programmers, the HDL reflects a software-centric view of solving a problem, which is not what is going on in hardware. They have no idea what hardware they are describing, and certainly could not explain their design in the form of electronics. I was the same way when I started, and I like to think I have evolved and learned. It was a mental shift in thinking, and HDL make so much more sense when you let go of a sofware-view for solving a problem. Software devs are arrogant these days, plugging big blocks together and thinking they can solve all the world's problems with an app, or that they understand everything because they can image how they might do something in software. This is seeping over to FPGAs, and I totally blame Verilog for the migration of bad software-like HDL into the FPGA space. I have yet to see what I would consider good Verilog, and until the quality of HDL being written in Verilog improves, I'll stick with VHDL (and by using VHDL you indirectly learn Ada too, which is awesome IMO).
Rant-off:

Xilinx makes their tools available for free at the level of FPGA that I can afford. Their documentation is fantastic, they have a support forum with engineers who answer questions (sometimes candidly which is nice), there are tons of application notes and examples for Xilinx FPGAs, and I have always been able to do what I need with Xilinx FPGAs. While harder to find, the Spartan-3E and Spartan-6 have not discontinued and when supply issues let up they remain mostly affordable. An alternative I am looking into is the Efinix Trion family.

Thanks for the feedback, I'm glad you are able to use the core.

[BrianHGinc]

If you want to take a look, I adapted a complete YM2149 audio system here:
https://github.com/BrianHGinc/YM2149_PSG_system
It includes a dual YM2149 option, stereo sound, programmable channel independent volume mixer, bass and treble settings, resampled I2S stereo 16 bit audio output at 48KHz or 44.1KHz, and a complete Modelsim test-bench with tones and oscilloscope visualizations.

[wilsondr9999]

I was able to successfully compile the core and simulate it in ModelSim with your new testbench file. I'm still getting the warnings, but the simulation is working properly. I modified the testbench with a few modifications:

1. Changed the wait statements with constants of 150ns and 300ns to wait statements with clock_in * 3 and clock_in * 6 respectively. This was necessary for the registers to properly latch data.
2. Changed some registers to produce a straight A-minor chord (A = 440Hz, C and E notes).

This ran properly in ModelSim:

http://www.thedanzone.net/images/ModelSim-Working-AMinor.png
http://www.thedanzone.net/images/ModelSim-Working-RegisterSetup.png

I ordered and received today a Lattice iCE40UP development board, and I may try to implement this in the FPGA soon.

Thank you again for creating the project!