0
\$\begingroup\$

I hope it's okay to ask about specific programs here.

  1. I have successfully created a test bench with HDL designer, and I use Modelsim to simulate. By pressing the Modelsim icon and selecting "through components" I can simulate my design. My question is about changing small things about my test bench. If I for example change a bit of a signal (be it in the test bench code or one of my design blocks), is there a faster way to update my simulation other than pressing the icon mentioned above (in HDL designer) again and waiting for Modelsim to update?

  2. My current design is synthesized using Precision. After that, my design is programmed into the FPGA using Quartus. After finishing simulation I would like to test my design using Quartus signalTap, but I have two problems with that:

a. I can not see my state machine states, so I cannot know which state i'm in.

b. When trying to insert some nodes into SignalTap and then programming the FPGA I get an error saying some signals I inserted are missing source.

I assume both problems (a and b) can be solved by using some preserve attribute (as the Precision synthesizer is probably "killing" those signals), but how can I use this attribute if I'm using the graphical tool to create state machines?

If this isn't the solution, then what is?

Thank you!

\$\endgroup\$
1
\$\begingroup\$

Caveat : Most of my HDL Designer use was when it was still called Renoir. I imagine it's improved, but probably not as much as one would like.

The key to the answer is probably to realise that HDL Designer is a great aid to creating a good first pass at a design, but not ideal (as you observe) for day to day low level manipulation while debugging.

At this stage (testing in simulation, trial synthesis, and investigation using SignalTap or Xilinx Chipscope) I would recommend you forget about HDL designer ... for now ... and learn how to use the underlying tools (edit HDL files, Modelsim GUI, synthesis, Quartus to build bitstream and insert probes etc.

So, freeze the current HDL Designer output (tag the commit "Initial", etc, and start a new "debug" branch if you're using Git Flow or whatever) and learn to get on with the underlying tools, without letting HDL Designer get in the way.

Once you have a result, it is up to you how you proceed, but there are two basic approaches.

1) Move forward from your current point (a working debugged design, that has diverged from HDL Designer in ways that may be difficult to back-port into "Initial") - effectively abandoning HDL Designer for the remainder of this project

2) Diff your current point against "Initial" and apply all the source code changes at once in HDL Designer (but not the dead ends, experiments, debugging hooks etc) and move forward keeping HDL Designer as the primary design tool. In other words, don't worry how to get quick experiments through HDL Designer; come back to it once you have answers.

Which approach is better depends on context : 1) is simpler for a short lived project, 2) is probably cleaner in the long run because it gives an opportunity to clean up technical debt.

With regard to 2a) and 2b), you are probably right that synth attributes may "fix the problem" but you're usually (not always!) better off improving the testbench to observe the same in simulation instead.

\$\endgroup\$
  • \$\begingroup\$ Thank you! That's a lot to process. Doing what you suggested with git would be hard though. We use HDL designer at work and I don't have the time to learn how to do what you suggested (also I don't think my boss would approve very much). Also, I think you said that already (but in other words), that if I start using Modelsim standalone and then try to go back to HDL designer - Modelsim integration it would be hard, so I don't think I should try doing that yet. \$\endgroup\$ – Eran Sep 27 '19 at 17:13
  • \$\begingroup\$ What I did want to comment on was the last line of your answer. While improving the test bench sounds good in theory, I am basically controlling a flash memory component that is sending data back, and it is not easy simulating it's responses. I know that having a test bench before SignalTap is a must, but I am currently in a position where basic simulation (not all cases have been covered) seems to work fine and I really want to move ahead. For that I need to observe the state machine states as it would be much clearer to me where I'm at. \$\endgroup\$ – Eran Sep 27 '19 at 17:16
  • \$\begingroup\$ @Eran Some memory suppliers have fairly accurate VHDL device models, downloadable for free, on their website.They are not always top quality (I remember one with three absolute howlers in one small section of code) but usually a good start. Failing that, developing a good model starting from the datasheet is usually worthwhile. You have a point : when basic simulation works, proceed. However when lab results show problems in a specific area, come back to the sims in that area. (For example I am not above hacking a "backdoor" into a vendor model to let the testbench flip bits, to test ECC.) \$\endgroup\$ – Brian Drummond Sep 28 '19 at 12:07
  • \$\begingroup\$ Also, if you don't have time to learn how to use the process, you really don't have time to debug things the hard way. This is how projects get deeper into trouble. If you find yourself wasting a day or so getting nowhere with Signaltap, you may have to explain this to your manager. \$\endgroup\$ – Brian Drummond Sep 28 '19 at 12:13
  • \$\begingroup\$ Can you explain your last comment? To me it seems you're saying I should have a good basis in Modelsim simulation before even touching SignalTap, am I correct? I guess I should cover all cases, even edge cases, before going to SignalTap. \$\endgroup\$ – Eran Sep 28 '19 at 12:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.