- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think I'm going crazy... I created a simple project for MAX3000A (schematic file, part of the schematic is attached) and tried to simulate in ModelSim - SE.
https://www.alteraforum.com/forum/attachment.php?attachmentid=8560 What I got I can't explain at all - the counter counts without any reason ! It's clearly visible on the attached wave picture - signal 53 goes to '1' before 53clk changes ! https://www.alteraforum.com/forum/attachment.php?attachmentid=8561 Any ideas ? Thank you in advance !Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By the way, looks like the problem does exist with Max3000/Max7000 only - changing a device setting to MaxII solves the problem.
I would very appreciate if someone can suggest something - I'm completely ran out of ideas...- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Modelsim SE doesn't understand Altera schematic entry. Which RTL netlist are you simulating?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Modelsim SE doesn't understand Altera schematic entry. Which RTL netlist are you simulating? --- Quote End --- To be honest, I'm completely confused by this... I use Quartus II 13.0 SP1 Web edition, Windows 7.0 After compilation go Tools -> Run simulation tool -> Gate level simulation ModelSsim Altera Starter Edition 10.1d starts and I do the simulation there... This exact sequence (including usage of schematic design with ModelSim) was described in several Quartus tutorials...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Gate level simulation is very slow. It has to compile the design into a netlist (a list of low level gates and registers) and then simulates that. An RTL simulation simulates the code directly, and runs much much faster. If you have altera schematics these need to be converted to HDL before RTL simulation can occur. This can be done via file -> conversion -> HDL file.
Be wary of this though, as you create two copies of the same thing. Forgetting to do a conversion when you update the schematic means the two are no longer matching. Much safer to have the whole design in an HDL (VHDL or Verilog).- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
O.K., a gate level simulation. In this case you'll inspect the RTL and gate level netlist and try to understand why the design is behaving as shown.
I know that Quartus CPLD synthesis hat some weaknesses in the past. MAX II in contrast uses FPGA synthesis tools. A gate level simulation without time scale is meaningless, by the way. It might be a simple timing violation problem.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- In this case you'll inspect the RTL and gate level netlist and try to understand why the design is behaving as shown. --- Quote End --- Of course, I have looked at the design using netlist viewer . But the design is extremely simple – we are talking, basically, about one-bit counter that starts counting before the clock comes… I couldn’t see anything suspicious in the netlist. And changing the device to Max II (without changing schematics) eliminates this issue. Grounding counter’s reset instead of connecting it to the reset circuit helps as well, but, of course, in this case the logic is not working in the required way… Unfortunately, I have to stick with MAX3000/7000 for several reasons. And I’m just starting, don’t have enough HDL knowledge to use it for the design – just need to re-create existing schematics using CPLD. P.S. Thanks a lot to all replied !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You didn't answer the timescale question. In addition the "53clk" in your design is apparently a generated clock, the gate level netlist may look considerably different from the RTL.
Can you post a quartus archive of your design, including the testbench?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry I forgot to answer about possible timing issues - I don't think it's a problem here. The clock is the signal from external pin with 100 ns period - I'm pretty sure it's more than slow enough for this design/device.
I'm attaching the archive here. Unfortunately, I have not learned how to create testbenches yet - with this project I'm just overwriting the signal clk with 100 ns period... Thank you very much for spending your time on my problem !- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you review the gate level netlist (Technology Map Viewer), you'll notice that the design is implemented slightly different from the RTL, e.g. DD3-3 is clocked directly by p41. This explains some unexpected results in simulation.
Secondly you get warnings about hold time violations which can be related to the ripple clock topology. There are possibly some oddities of the CPLD synthesis engine contributing to the problem, but essentially it's the bad design topology.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- the design is implemented slightly different from the RTL, e.g. DD3-3 is clocked directly by p41. --- Quote End --- Yes, I can see this now, thanks... I completely agree the design is not the greatest, but it works very well in real hardware. I expected that implementing this schematics in CPLD is going to be pretty easy, but now I have no idea what can I do if the software does things I have not asked for... Do you have any suggestion how should I fight this problem realistically ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Looked at the gate level design more carefully - the explanation does not look so simple... Even if we assume the counter DD3-3 is clocked by wrong edge of the clock (being connected directly to p41 instead of clk53), this does not explain why the counter DOES count with ANY input...
And I think the gate level netlist is correct - p41 signal being inverted inside of lpm_counter2 and does not require separate invertor inst12... Of course, I can be wrong...- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I didn't say that the counter is controlled by a wrong edge, just with less propagatipn delay. And I don't see the counter counting without input edge. I'm not sure if you are looking at the right signals.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think it's very clearly visible in the simulation window - signal 53 switches to '1' before anything happens with the clock signal - 53clk, am I wrong ???
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't see it my simulation. Isn't it a different circuit? There's no signal "53" in the present design.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Because I discovered that HDLs don't like wire names starting with numbers, I added "p" letter in a front of all signals (and renamed 53clk to clk53 etc).
After I did these changes I checked - nothing changed in the simulation. Also I checked with older Quartus 9.0 - the same... Can attach the simulation with new names, but a bit later - away from my computer now (and again - it's absolutely identical to the simulation I already attached - except a slight change in signal names)...- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, there is updated picture. As you can see, the very first change of p53 (underlined with yellow marker) happens without any visible reason.
https://www.alteraforum.com/forum/attachment.php?attachmentid=8574- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think the reason of the strange (as I thought before) behavior is very simple - I don't set initial values of the counters, and they are behaving differently for different CPLD families. After I added initial reset, everything started working in the expected way.
Yes - I need to learn a lot of things...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page