Design works on Quartus 7.1 but not 4.2

[Altera_Forum]

Hello! 

 I have a problem with the two Quartus Versions 7.1 and 4.2.   I have a very simple design that only contains one UART which is transmitting steadily a constant byte. The design consists of 4 entities (I am using VHDL).  The top-level-entity contains the UART-entity which contains the transmitter- and receiver-entities -> very simple . . . .   Now, I compile it with Quartus II V7.1 Web Edition and it works fine without any problems on my EP1S10 device. Later on, I want to run my design on a much bigger device (EP1S25) which is not supported in the Web Edition. We have a fill licensed Version of Quartus 4.2. I want to use this to compile my design for the bigger FPGA. Now, the design didn't work after compiling with 4.2. After a lot of error seeking, I came to the simple design I described above.  I compile exactly the same four VHDL files on Quartus II V7.1 (Web) and on Quartus II V4.2 (Full). It works on the EP1S10 device when I compiled with 7.1 but it does not work on the same device when I compile with 4.2. What is the difference?  Strange is also, that if I just let toggle some LEDs on my board, it works with both Quartus Versions. But not my UART design . . . . . .  Can somone help me please?  Greets, Maik

[Altera_Forum]

Hi Maik: 

 I'm not a VHDL expert, I work in Verilog, however, I know both the VHDL and Verilog languages have changed since version 4.2.   Without seeing the code, it's hard to say, but one problem is you might be using new syntax that the older version of quartus doesn't understand. (IE: VHDL93 versus 200X).  It's a place to start anyway. At what point is it failing: Is it failing compile and synthesis, or is it completing, but just not functioning properly on the board?  If' it's failing compile, I but it's a syntax issue, and you'll have to re-write part of the cold to work with the VHDL93 standard.  Pete

[Altera_Forum]

Hello anakha! 

 Thanks for your reply!  I'm sorry that I didn't express myself clearly in the first post.  It compiles in both versions correctly (no syntax errors). During compiling I got the same messages in both Quartus Version. Even the warnings are the same and tell me that some bits of my databyte stuck to ground as I ever send the same byte via the uart and it has some zero bits in it. The problem is, that the Quartus 7.1 .sof file works as expected, and the Quartus 4.2 .sof-file does not work on one and the same FPGA. . . .   Well, if you want to see the code, I put it in in the attached zip-File. If you (or someone else) want to compile it on your Quartus Version, I would be happy if you send the .sof file here, so that I can try it on my boards.  For the EP1S10F780C6ES device, my pin assignments are: clk - K17, txd - U21, rxd - Y28 For the EP1S25F672C7 device, my pin assignments are: clk - B12, txd - F25, rxd - K24  Unused pins have to be 'input tri-stated', as it is an development board I am using.  My clk frequency is 50MHz in both cases.  Still, I have no idea, why it just don't work with Quartus 4.2 and would be happy if you can help me.  Greets, Maik

[Altera_Forum]

I run into these quite a bit(although it's usually in the other direction, when someone upgrades to a new version and something stops working). Most of the time it's a timing issue, where the user didn't have IO timing constraints, they had recovery/removal issues, an asynchronous transfer was done incorrectly, etc. My two recommendations are: 

1) Enter timing constraints for the entire design(all clocks, all clock transfers, all I/Os). 2) Debug this from the perspective that the design doesn't work, and to a certain degree ignore that it works in Q7.1.  I've seen people spend weeks doing crazy things to figure out what could be different between the two projects. They export VQMs back and forth to take out synthesis, they study .qsfs and try all sorts of settings. They try to back-annotate logic, etc. In the end, it's almost always easier to just debug the problem like you would any other problem(use signaltap to capture failures, then work your way back to the source of the error, scope the IO, etc.). This is almost always much faster, and usually when you find it, you'll knock yourself in the head and realize it makes sense. I've had two users who were convinced Q7.2 broke their design, but when they finally figured it out(wasting a lot of time comparing the two, and finally going to traditional debug methodologies), they found one was an unconstrained path, and another was due to a code change(that wasn't supposed to affect anything).

[Altera_Forum]

Hi Maik: 

 I didn't see anything definite in the code, but again, I'm use verilog as my default language, so I may miss something in VHDL.  But since you seem to be using only the 50 MHz clock, and the slower UART Baud rate is done by a clock enable, I thing you should be ok for most of the issues RSYNC described, unless the 50 MHz clock was not defined and for some reason Quartus 4.2 was compiling the design to run very slowly. (unlikely).  On thing I do see however, is on the RX data path, you are using the RX input directly without double registering it. This could cause metastability issues, because the setup/hold to the 50 MHz would be violated. Is this the cause of your problem? Probably not, but it's something worth fixing.  Pete

[Altera_Forum]

Pete: You are right, the design is not perfect at all, BUT why does it work (sends the constant data byte via the serial line) if compiled with Quartus 7.1 and why does it not work (but compiles correctly) under 4.2?!? As you can see, I do not demand much of the device with my design, but it does not work . . . . . 

 Rysc: Yes, maybe debugging is the right way. Unfortunatly I do not have much time and absolutly no experience with timing constraints and signaltap. About timing constraints: Why do I have to set constraints? I thought that Quartus knows the constraints of the choosen device by itself as they are from Altera and they have all the constraints data for their devices? Or do I understand something wrong?  Besides that, it seems as if we will purchase a new Quartus liscence for a modern version . . . .   Greets Maik

[Altera_Forum]

Timing constraints tell Quartus how to optimize placement, routing, delay chains, etc. Now, in the simple case you might answer "as fast as possible", but it can be much more complex than that. If you have more than one clock, then there may be decisions that trade off performance in one domain for another, and accurate timing constraint reflect that. IO constraints can be even trickier. For example, on your input side, you need the data to get ther before the latching clock, but you also need to be careful of the flip-side, when the data gets there before the launching clock edge(a hold violation). Users often say, I'm running my design very slow, it should work, but hold violations are valid even at 1Hz.  

If you're using the Classic Timing Analyzer(which you'd have to be in Q4.2), just by a global clock constraint and a tight Tsu/Tco constraint(say 5ns). It may not pass, but having the best Tsu/Tco is probably the solution that would solve the largest number of designs(I have no idea if it's what's affecting yours). The bottom line is that nobody can really diagnose the issue without knowing what's wrong(at a lower level then Q4.2 doesn't work). As I mentioned, some of the things I've seen are things no one but the actual designer could have ever resolved, because they were very design specific.

[Altera_Forum]

--- Quote Start ---  About timing constraints: Why do I have to set constraints? I thought that Quartus knows the constraints of the choosen device by itself as they are from Altera and they have all the constraints data for their devices?  --- Quote End ---    Quartus knows the actual timing of your design in the device (for example, it can run at up to 49.5 MHz). If you don't tell Quartus with timing constraints, though, it has no idea what the required timing is (it must be able to run at least as fast as 50.0 MHz). The difference between the actual timing and required timing is the margin, and you might have negative margin without knowing it if you don't have timing constraints. Even at a slow frequency like 50 MHz, you might have a path with many levels of logic that won't consistently run that fast if you don't tell Quartus to optimize for that requirement.  Without constraints you could look at the reported actual timing and manually compare that to the requirements, but you'd have to do that after every compile. With constraints, you get obvious red highlight in the GUI when something violates the timing requirements.  Rysc is completely correct that a design should have its timing fully constrained. It is proper design practice regardless of frequency. Even if the reported actual timing happens to meet your requirements and you don't mind manually verifying that, having the requirements in the Quartus project documents what those requirements are for someone maintaining the design later. Some of the timing requirements are independent of frequency. As Rysc mentioned, even a slow design with easy-to-meet setup requirements might have challenges with hold (this includes clock hold internal to the device, not just th at the input pins).     --- Quote Start ---  ... why does it work (sends the constant data byte via the serial line) if compiled with Quartus 7.1 and why does it not work (but compiles correctly) under 4.2?!? As you can see, I do not demand much of the device with my design, but it does not work . . . . .  --- Quote End ---    Even with the synchronous part fully constrained with no timing violations, there could be something asynchronous in the design (perhaps unintentionally asynchronous) that will have different timing from compile to compile and potentially even more different timing from one Quartus version to another. For something asynchronous, the timing might happen to work sometimes but not other times.  Rysc mentioned recovery and removal. Doing that analysis will catch some asynchronous problems with resets and asynchronous loads. It might also have lots of timing violations for things where the design is set up such that the reported failing paths don't really matter (like a register for which it doesn't matter whether it comes out of reset at the same clock cycle that another register does).  The Design Assistant can find some problems with asynchronous design as well as other potential causes of your hardware failures. If you run that, do it in version 7.1 in case it has been improved since 4.2. You just want to run the best design rule checker you can. The design itself is independent of Quartus version, so you don't have to run Design Assistant with the same Quartus version that has hardware failures.

[Altera_Forum]

Rysc and Brad, 

 thanks for your usefull hints!  Today, I printed the Quartus manual chapter about Signal Tap II in order to read it during the weekend. I agree, that I have to dive a little deeper into design, debugging and constraints for FPGA development.  In my big design (the one I currently work on to finish soon), I set my clock constraints to 50MHz. And you are right, that Quartus informs me about paths that do not fit this constraint. It shows some parts of my design which are not able to run at 50MHz but at say 35-45 MHz. Now, all these paths Quartus marked red, they actually don't have to run at 50 MHz but they have to have their states stable every second clock which would mean they only have to run at 25MHz. One day, I tried to tell Quartus this in its constraint settings but I failed due to my weak knowledge about this stuff. Seems that I have to print out the constraint parts of the manual next weekend ;)   But when Quartus says that there are paths that only can run at max 35MHz and I only need them to run at 25MHz, then everything should be OK, right?  Nevertheless, that has nothing more to do with the post topic. It seems that I have to expand my knowledge boundarys . . . Usefull hints and explanations as yours above are allways welcome.  Regards, Maik

[Altera_Forum]

--- Quote Start ---  ... It shows some parts of my design which are not able to run at 50MHz but at say 35-45 MHz. Now, all these paths Quartus marked red, they actually don't have to run at 50 MHz but they have to have their states stable every second clock which would mean they only have to run at 25MHz...  But when Quartus says that there are paths that only can run at max 35MHz and I only need them to run at 25MHz, then everything should be OK, right?  --- Quote End ---     If you did the divide-by-2 with a clock enable, then you can use a multicycle setup of 2 to tell the timing analyzer that 2 clock cycles are allowed. For a clock enable divide-by-2, you also need a multicycle hold of 2 with the Classic Timing Analyzer (which you probably have by default if you are using that analyzer) or a multicycle hold of 1 with TimeQuest (which is not the default with that analyzer).  There are ways other than a clock enable for the multicycle to be appropriate, but it must be a method that guarantees that the input to the destination registers will not be changing at the clock active edges where you don't want the registers to update their value. The clock enable signal makes the register D input be completely ignored at those clock edges.  If you don't have time to figure out right away how to do the multicycle constraints, then it is OK to manually check that the paths that are allowed 2 clock cycles are actually fast enough.