Two hours to code it, two months to simulate it - Page 1
Forum section: electronics / general

author: uncle bit
author_rank: Contributor
timestamp: July 26, 2018, 09:50:37 am
content: Hello everyone,the subject is clearly a sort of joke, but I'm really stuck on the following silly scenario: I'm using VHDL to describe a circuit which has only eight external connections alongside a bunch of 128 internal signals.I'm a senior hardware engineer and firmware programmer with no previous skills on FPGAs, so I grabbed a MACHXO2 from Lattice, fought a few days against Lattice Diamond and Active-HDL, read all the basics of VHDL, then successfully wrote some key entities and a testbench, observing only a small group of signals in the simulation windows.Now I would like to look at all the 128 signals simultaneously, but when I link them to the PORT section of the top VHDL entity, the LSE pin planner sees too many hardware connections and refuses to compile.In order to overcome such a silly tool-related problem, I need some help from who already faced it.I hypothesized to force Active-HDL to include and show signals from non-top VHDL entities, but I didn't find a way to get there, if any.I also thought about telling the LSE pin planner to ignore the signals which appear on the PORT for simulation purposes, but I don't know how to do so.Any suggestions?Thanks

author: Siwastaja
author_rank: Super Contributor
timestamp: July 26, 2018, 10:00:20 am
content: It appears you need a simulator.The definition of the simulator is that it can look any internal signals. Then, you can generate test bench stimulus using the non-synthesizable VHDL structures, such as this:wait for 100ns;test_input <= '1';wait for 100ns;wait until test_output = '1';test_input <= '0';...Haven't heard of Active-HDL (and their website is down), but it claims to be a simulator, so you should be able to probe any internal signal. If not, get a simulator; I have used Mentor Graphics ModelSim, which comes (came?) as a free version with Altera Quartus Web Edition.

author: iMo
author_rank: Super Contributor
timestamp: July 26, 2018, 11:03:54 am
content: There are tools like the ChipScope with Xilinx'es FPGAs, the Lattice has got the Reveal Analyzer.It works like an on-chip Logic Analyzer. It sends data off the chip via jtag.Not sure about your Mach chip, but it works with ICE40UP5k.https://www.eevblog.com/forum/microcontrollers/lattice-radiant-for-ice40up-fpga-series/msg1446562/#msg1446562

author: Siwastaja
author_rank: Super Contributor
timestamp: July 26, 2018, 12:48:45 pm
content: Synthetizable logic analyzers are the last resort when you need to analyze things you cannot simulate (for example, communication with external HW you have no simulation model of).It's too tedious and slow to use as your only means to verify your own logic.A simulator is mandatory to do any practical work.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 26, 2018, 06:13:17 pm
content: The simulator should give you a way to look at all the internal signals without modifying the project or testbench. A simulator which only lets you watch external signals would be useless.

author: uncle bit
author_rank: Contributor
timestamp: July 27, 2018, 02:35:30 pm
content: Let me clarify my question.I actually synthesized and simulated my project using the default environment for Lattice MACHOX2 chips, which is Lattice Diamond (IDE and VHDL synthesis) paired to Active-HDL (a third-party, IMHO very nice, simulator).The default setup of Lattice Diamond provides a SIMULATION WIZARD button to automatically start the simulation, without any provision or panel to manually select which signal are to be observed.The so called wizard operates silently in background to feed Active-HDL all the signals which appear in the PORT section of the top VHDL entity.Such a shortcut has proven great for some debug session, where I tested each sub-entity in its own with a targeted, isolated testbench.The problem did arise only when I tried to group 128 signals in the PORT section of the top entity in order to look at them simultaneously.With such a huge I/O bank, the project won't fit the chip, so the wizard doesn't get started at all.Does anyone know how to bypass the simulation wizard and manually collect all the library data from Lattice Diamond to Active-HDL?

author: rstofer
author_rank: Super Contributor
timestamp: July 27, 2018, 02:49:17 pm
content: I don't use simulation (it wasn't free when I started with Xilinx) and I seldom use the internal logic analyzer in Vivado although it it pretty nice.Looking at 100+ signals trying to find a logic error would be like looking for a specific grain of sand at the beach. Too much information!Modules, individually proven correct, don't suddenly go wrong just because they are wired together.For one of my first projects, I described a 32 bit debug bus which was brought out to a header. Most modules had the ability to put state information on the bus but only one wasn't commented out. Bringing the bus all the way up and out through pins can be a PITA but it worked well for this project. Later on, all references were commented out but the code is still there in case I need to come back to it.I like the internal logic analyzer because I can trigger on a condition. Simulation always seemed painful because I might need to be a million cycles in before I got to my problem spot. I was half way to boot loading the OS and something was going wrong in thousands of lines of assembly code that I didn't write nor necessarily understand.I can also add logic ("Hey, I'm in this state!") and bring that signal out on my debug bus. FWIW, one-hot encoding for FSMs becomes a PITA when there are over 100 states and you really want the state number on the debug bus.

author: uncle bit
author_rank: Contributor
timestamp: July 28, 2018, 10:28:59 am
content: QuoteTrue, but in my specific application I would look at four 32 bit buses, appearing as four strips of hexadecimal decoded values like these < 0x12345678 >< 0x87654321 >, not as 128 strips of square waves.QuoteAlso true, but my goal is ensuring that the four buses actually carry the right data at the right time, and observing them separately would not show a possible skew between them.I just tried to port my Lattice project to another FPGA chip from Altera, where the IDE is named Quartus and the simulator is known as ModelSim.I loved Quartus, which I found more attractive and functional than Lattice Diamond.Almost all the VHDL entities got compiled immediately, with some obvious adjustments for the spcific IP modules, like RAM, PLL and library prefixes.Unlike Active-HDL, ModelSim is not related to a wizard, so I launched it on its own and manually selected every signal to be observed.Unfortunately, ModelSim appeared too ugly and cumbersome, so I decided to pick the best from both worlds and tell Quartus to export its data to Active-HDL.Strangely enough, the idea did work at 95%, until Active-HDL (in its branded edition from Lattice) refused to accept an encrypted IP library from Altera.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 28, 2018, 11:07:43 am
content: The simulator is completely independent from the FPGA vendor. You can also decode the signals to values; ModelSim can even draw a nice analog waveform out of the decoded bus value.

author: uncle bit
author_rank: Contributor
timestamp: July 28, 2018, 02:55:28 pm
content: QuoteI agree, but you know that the simulator must be aware of every finest IP (Intellectual Property) detail of the FPGA chip involved in the final project, otherwise no internal or hidden signal could be effectively worked on.The simulation wizard in Lattice Diamond's toolbar was probably there as a helper, useful to relieve the novice user from manually collect a bunch of library data in order to successfully launch Active-HDL.My first complaint was about the lack of documentation on what to do when you choose to quit the wizard and launch Active-HDL on its own, throwing out all the hidden automation where pathnames, libraries, IP modules, and dozens of other gizmos get bundled together before you even see the welcome banner of the GUI.

author: rstofer
author_rank: Super Contributor
timestamp: July 28, 2018, 04:22:22 pm
content: Before Vivado came along with the Internal Logic Analyzer (ILA) there was often a problem bringing out enough signals to use with a logic analyzer. One idea that came up which I never pursued was using the left over BlockRAM and logic resources to build an internal logic analyzer. Essentially, take the logic from the Sump.org logic analyzer and build it inside the project FPGA, exposing only the serial port to the PC application.https://sump.org/projects/analyzer/As devices get ever increasing chunks of BlockRAM, this idea becomes more and more feasible. It doesn't alter the fact that you have to re-synthesize to change the LA connections but it does bring a lot of flexibility in terms of triggering.At one time, I was working on an FPGA implementation of the PDP11-45 ALU. This is a complicated bit of logic with byte and word operations, flag updating and all the usual stuff. So, I put shift registers as both inputs and output including flags. Then I arranged to shift all of this in and out as a serial stream. I created essentially an SPI based ALU. I used a Blackfin board to interact with the FPGA at the SPI level and fetch test vectors from my Linux box using NFS. The Blackfin would cycle through dozens of test vectors knowing exactly what the results should be. I could test every conceivable operation and compare the hardware result with my expected result. Worked well... Kind of like a poor man's JTAG.I have never used simulation and I have only used the ILA a couple of times. I think the ILA is the way to go but I still don't have a very high comfort level with the attributes file. I need to spend more time with ILA. I see there are some good tutorials available.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 29, 2018, 11:33:45 am
content: Quote from: uncle bit on July 28, 2018, 02:55:28 pmNot at all! I don't know of any such HDL simulator. They always simulate HDL at generic level. Then, it's the task of the synthesizer to transform this generic HDL in the FPGA hardware, and it's the synthesis tool's task toguaranteeit will work logically similar to what you saw in the HDL simulator.The synthesis tool offers additional hardware-level "simulation", such as timing analysis. You need to look at it as well. But these are not waveforms, and have nothing to do with thelogicit provides.But you should first verify thelogicalside of your design by using a generic HDL simulator. It's so much easier, and they offer great visibility to all internals; something a synthesizer cannot do, since it optimizes and changes your logical design into the physical world.And no, you don't need to look at the physical FPGA signals (or you may need to, but it's consideredvery advancedand time-consuming, last-resort task). The synthesis tool guarantees it works within the physical limits of the timing analysis and your electronic design.And if you are having such signal integrity issues, looking at all the internal signals using an integrated logic analyzer is not going to help much. (Been there, done that. You just keep wondering the wrong bit values, but have no idea why.)

author: NorthGuy
author_rank: Super Contributor
timestamp: July 29, 2018, 12:50:02 pm
content: Quote from: Siwastaja on July 29, 2018, 11:33:45 amVivado has two post-implementation simulators.

author: uncle bit
author_rank: Contributor
timestamp: July 30, 2018, 07:38:38 am
content: I apologize for my basic english, but I'm afraid we are talking about two different things.When I say that the simulator must be aware of the internals of the FPGA chip involved, I'm meaning the functional description of the entities you refer to by name as components.One of these components is the so called BlockRAM, but there are PLLs, ROMs, ALUs, DSPs and so on.I understand that a blockRAM is nothing but a bunch of VHDL or Verilog statements written somewhere, but since I don't edit the source code, I think at it as a blackbox named John_Doe, linked to my signals by symbolic names like Clock, Address and Data.The RTL simulator doesn't need to know the physical paths in the physical FPGA hardware, but it surely needs to refer to the description of the item BlockRAM referred to by the name John_Doe.My concern was about the fact that I didn't know where was located a formal description of the BlockRAM, since it might be assembled from smaller entities scattered in dozens of folders and libraries.Furthermore, some FPGA vendors don't distribute sensible proprietary IP in readable form, so I couldn't peek at the source even I knew where browse.In the first IDE I used (Lattice Diamond), the simulation could be started at the touch of a button, and every detail about every specific component like BlockRAM were passed silently to Active-HDL.Unfortunately, such a one-button solution didn't allow me to select which signals include in the simulation window, since the default bahavior was the bare inclusion of the signals listed in the PORT section of the top VHDL entity.The second attempt was about quitting the one-touch solution and launching the simulator on its own.Quitting the one-touch solution allowed me to insert more signals in the simulation window, but it raised the annoying mandatory task of manually state each and every description of those BlockRAM, PLL and ROM, that only one second before were passed silently without my intervention.In order to save time and effort, it would be nice to had a document stating something like this: when you use the BlockRAM, please tell the simulator about the library file X located in the folder Y.Instead, the official documentation was limited to a bare START THE SIMULATION WIZARD by clicking the SIMULATION WIZARD BUTTON

author: Siwastaja
author_rank: Super Contributor
timestamp: July 30, 2018, 01:32:57 pm
content: Oh, you mean the "hard" blocks!Yeah. Guess what - simulation models exist for those. However, actually obtaining them could cost you some serious $$$, which is actually the case with most FPGA tools. The free tools come with very limited licenses anyway.But, there's a catch -Many of these "hard" blocks can be derived from generic VHDL, which is often the "preferred" way. This means, you write a simple-as-hell VHDL entity that works like a RAM. Now, you can definitely simulate it - and when you synthesize it, the compiler magically detects this block: "A-HA, this looks like RAM, I can implement it with the hard block".This has several benefits:- No vendor lock-in: you can change from Altera to Xilinx, for example, and their synthesis tool detects the same structure from the same VHDL- You have the simulation model: basically, this answers to your question. You can do whatever you want in the simulation, and look at the internal signals (because you wrote it)There are cons, as well:- You may need to read manufacturer-specific application notes onhowyou should write the VHDL to ensure that the synthesization tool recognizes it properly- Not all hard blocks are available this way, or they may lack some features. (Basic RAM and ROM obviously are, since they are so simple to describe in VHDL.)- There may be some traps for the young players - when the synthesizer infers a hard block, it mightnotgive you a full guarantee it performs cycle-by-cycle the same as your VHDL!So, in worst case, you may need to "fire up" a synthesizable logic analyzer (such as Altera's SignalTap). But this is considered a last-resort action.I'm sure you can do most of your work in an actual simulator, with no HW-specific information, and see a shitload of internal signals to help your work.

author: legacy
author_rank: Super Contributor
timestamp: August 01, 2018, 08:33:09 pm
content: Quote from: rstofer on July 28, 2018, 04:22:22 pmThe ALU and all the COPs (i.e. the fixed-point Cordic unit, the saturated-ALU) of my Arise-v2 project have been tested on Modelsim with a set of testbench units plus wrappers in python. Wrappers make you able to trigger exactly the condition you want to see, and this way it's very simple and comfortable to find what is wrong with VHDL.