VHDL works only with xilinx

[Altera_Forum]

Hi, 

 I wrote a vhdl code that interface with a module through SPI communication protocol my code was done in FSM with next state logic, it worked perfectly with my spartan 3AN board but when i try it on ALTERA DE0-nano baord it didnt work at all although its pure VHDL what i understand is that vhdl is suitable for any FPGA, so can any body please explain to me whats happinig.another thing if i didnt use global reset for the code does it make difference ?

[Altera_Forum]

What specifically doesn't work?

[Altera_Forum]

it doesnt work at all dead

[Altera_Forum]

Maybe You've connected reset wrongly? Isn't the module synthesized out?

[Altera_Forum]

every thing is connected in the good way what i want to know why the vhdl code works with xilinx only is there a reason ? is there a special coding style for altera ?

[Altera_Forum]

No, only dumb mistakes left by designer. Something is bad with Your design.

[Altera_Forum]

so in this case why it works with xilinx ?

[Altera_Forum]

Because Xilinx synthesizer is buggy too :) 

 I'd offer to attach SignalTap and watch what's happening to the FSM and all the signals. Upload the module code to pastebin if You can, so someone could revise it.

[Altera_Forum]

ok if it works with xilinx because xilinx synthesizer is buggy:confused: then why quartus synthesizer dont give me even one single error?

[Altera_Forum]

It probably gives You a warning. Maybe something synthesized out..? Post a module source code.

[Altera_Forum]

ok i attached this code please tell me if you figured out anything

[Altera_Forum]

Sorry, that code has no identiations and basically it's impossible to read. I wonder why it's not working... Use SignalTap for debug, it's Your only option.

[Altera_Forum]

if warning tells me that there are missed signals from the senstivity list is it a cause of problem ?

[Altera_Forum]

I would recommend that you have a real reset in your design instead of relying on signal power up initialization. This may or may not work depending on tools. The line I'm talking about is: " signal prsnt_state,nxt_state:state:=s1;". Resets in state machines are most critical.  

 Second I would recommend having a default case in your state machine since you may end up in an undefined state otherwise. This could cause hangups.   /Boris

[Altera_Forum]

First, your coding style is inconsistent in many places. there are _n/_p suffixed pairs for next/present state signals, but others are named nxt_/prsnt_ as a prefix or a suffix. This is not good. Another issue of coding style is that you sometimes initialize the counter values straight before starting a loop, i.e. on the transition into the loop, in other cases you rely on the value was cleared after the last loop run somewhere else. This can bring you into trouble some day and doesn’t make reading the code easier. You have some different commands to send over the interface, but three of them are named as such (CMD, CMD_READFAT, CMD_ROOT) while the others (reset, init, writesector) have different naming and are initialized differently, e.g. they don’t use the constant CRC to reflect the trailing x"95" pattern. 

 Your way of walking the states also looks too low-level to me. I mean, it’s always the same procedure with only slight variations: output data at SCK==0, wait, switch SCK==1, wait, eventually fetch data at SCK==0, wait, switch SCK==1, wait, and so on. This could be either placed into a separate, smaller state machine that is triggered and parametrized by your bigger one, or you could at least put these repetitive operations into a procedure. This would clean up the code significantly. While enhancing readability it will reduce the chance of doing something inconsistently between the different but similar states.  Something more severe is that your main state entity outputs (CS, SCK, SDI) are combinatorial outputs of the state. This is no no no good, you will have spikes on the wires after most clock edges, which will be problematic especially for your SCK wire. You should at least route those signals through registers, but it will affect your output timing. The easiest way of doing this without losing too much time on the path outside would be a falling_edge() triggered FF for each of these signals on the way out from the internal combinatorial state machine assignments to the entity pins. If this reduces achievable clock speed too much, it would have to be a rising_edge() FF then, but keep an eye on your expected timing.  Your ram/axes might not be synthesizable into block ram wasting quite some registers and/or logic, reducing your clock speed, too (but I haven’t run synthesis on your code). I would re-write it to better reflect the operation of a block ram and allow such an inferral by the tool. I would only enable wr_enbl for 1 cycle when data is really ready to write. I would keep RAM size at powers of two, even if there are two CRC bytes added. Just store those into separate registers. Maintain your addresses in the proper range, say 0 to 511 and just add proper wraparound or limiting functionality to the code. Counters may run, for example, from 0 to 513 if this is beneficial, but it just gives you headaches for addresses and RAM sizes. I would also recommend to use an up-counting range for the memory arrays as this typically better reflect the understanding of a memory dump. Please group your memory initialization into proper sets of, say, 16 values per line and use your ENTER key.  Another thing which might not bring any trouble to you for a long time is the absence of any metastability reduction methodology on the input signal SDO. While in most cases it is just fed into a shift register, in s25 it is used directly to form the count_n/_p and prsnt_/nxt_state signals. If SDO changes right at the time the clock edge appears, some of the bits of count_p and prsnt_state will have been updated while the others have not, leading to an inconsistent state that might not be covered by your VHDL code at all. You might seriously deadlock, depending on the synthesis result. The easiest way of handling metastability issues is to place a two-stage preserved and non-duplicated register pipeline on your signal input. This, again, will change the timing on your interface.  Three previous statements I want to comment: You don’t need a ‘when others=>’ clause for your encoded or enumerated states, at least it doesn’t solve all your problems with invalid states. Adding such a clause will just result in warnings for enumerated states (that have been completely decoded). Second, not adding reset input and handling and relying on proper signal initialization is not bad per se. You just have to watch the warnings telling you which registers could not be implemented with the instructed reset level by the synthesis tool. And, of course, once you hang or need to restart operation after some event, there is no means to restart your block without some rather global means (power off/on, GSR or similar). Third, warnings about missing signals on the sensitivity list are typically only relevant when simulating the code. If you synthesize in absence of wait statements, the sensitivity list is not important, but simulation might lead to a different result if the simulator follows spec regarding the sensitivity list.  Does the reported maximum clock rate fit your needs? Did you constrain that in any way?  Do you use the same clock speed as on the Xilinx part? Does your SD card support these frequencies?  – Matthias

[Altera_Forum]

'when others=>' should be used since you normally don't control how the enumerated state variable is encoded in hardware. Most synthesizers, by default, will use the one-hot encoding and therefore you will end up with many undefined states. Therefore 'when others=>' is needed. Atleast it should be your practice as a good habit. This prevent any possible hangups in an undefined state.  

 As far as the reset goes. On most circuits you don't really need a reset since the initial state will be clocked through in a few clock cycles and you get to a known state. However, in a state machine you need to explicitly tell the state machine where to start and not rely on the specific tool to implement it the way it wants to. Otherwise it is a setup for having different simulation/synthesis result.   Not including signals in the sensitivity list will result in latches which in most cases are undesirable

[Altera_Forum]

‘when others=>’ is a beast by itself. As VHDL was not designed specifically for synthesis of binary logic but for behavior simulation of hardware, ‘when others=>’ just means: any of the official states not yet mentioned. There is no notion of: any unencoded state the implemented registers might take. I would call this a ‘when unencoded_state =>’ – a feature of VHDL still to be specified. 

 So, currently, if you have an enumerated type with, say, 5 states, and the state is encoded as 3 registers, and you have all 5 states already checked with matching ‘when s1|s2|s3|s4|s5 =>’, then a final ‘when others =>’ will formally be a NOP. And, although formally allowed, this superfluous statement will typically raise a warning when compiling for simulation. Remember: Superfluous warnings are *bad*.  There are, however, synthesis tools which do their own special interpretation of ‘when others =>’ for the developer’s good, trying to mimic the missing ‘when unencoded_state =>’ feature. Set up for this behavior, they take a written ‘when others =>’ as an unwritten ‘when others | unencoded_state =>’. So they would decode the 3 unencoded states – or even the 27 unencoded states if one-hot encoding was used – and help mitigating such detected soft errors.  Contrary, the coding style, which I adhere to, states: never use a ‘when others=>’. This is for requiring the programmer to always decode all (official) states explicitly in the case’s when list. If any element from the enumerated type is missing, simulation and synthesis will error out. This is *good*. Hiding an actually missing element by using ‘when others=>’ is *bad*. It will take you ages to find out why one case was missing the new when check, while in absence of ‘when others=>’ you are quickly pointed to code that still needs adaption. This is no silver bullet, though.  So what I’d like to see is the ‘when unencoded_state =>’ feature added to VHDL. This way I could write code like the following, assuming state is of an enumerated type (s1, s2, s3, s4, s5):  case state is when s1 => something; when s2|s3 => something_different; when s4|s5 => also_needed; -- fallback for invalid/unexpected states, request reset. no when others needed. when unencoded_state => state <= s1; request_reset <= '1'; end case; BTW: Most applications might be happy by just detecting an invalid transition into an invalid state. But if you consider carefully, there are most likely quite some invalid transitions possible that lead to another valid state. Still, the transition is invalid and, by no means, ‘when others=>’ will be able to help you with those. You can only detect them by some register duplication or checksumming, and mitigation might require something like register-based TMR. Still one should consider that most faults in digital design are designed-in, like inter-statemachine race conditions and faults propagating into the design from the external interfaces. Once you have done your best to avoid design-time faults, you can think over long-term stability and handling of unadvertantly entered states. Taking ‘when others=>’ as a silver bullet just hides the fact that you have no clue how to deal with inadvertant state changes to valid states.  About the reset: Have you mentioned that register initialization actually works with some current FPGA synthesis tools? So even without a reset pin your design will start in a defined state, without the assumption of an initial ripple state initialization. It’s just the case that sometimes the synthesis tool is just not able to initialize the register in the requested way, so you have to watch out for related warnings.  Not including signals on the sensitivity list will typically not harm your design at all, but this depends on the ‘intelligence’ of the synthesis tool. Only simulation will show the behavior of a latch, while synthesis tools assume all signals to be on the sensitivity list. But I agree, it is best practice to put all related signals on the sensitivity list if you want to have the same behavior in simulation and after synthesis. Just found that (http://vhdlguru.blogspot.com/2010/04/process-sensitivity-list-vs-synthesis.html). BTW, huge numbers of discrete signals within a single architecture and on its entity’s interfaces sooner or later lead to this missing signal problem. The answer to this problem space is, again, coding style, and I would strongly recommend reading (and adhering to) this (http://www.gaisler.com/doc/vhdl2proc.pdf).  OTOH, here is a theoretical counter example: if there’ll ever be a synthesis tool capable of synthesizing something like a dual-edged flip-flop – which could already exist if the functionality was mitigated over some added logic and two alternately-clocked flip-flops per register – one could write code like the following:   process(clk) r_prsnt <= r_next; end process; This code is perfectly describing a dual-edge triggered flip-flop. If the synthesis tool would not honor the sensitivity list – especially when adding r_next to it – the result would be a straight wire connection. In this case one would be able to restore the behavior by explicitly requiring rising/falling edges:   process(clk) if rising_edge(clk) or falling_edge(clk) then r_prsnt <= r_next; end if; end process; – Matthias  Edit:fixed link

[Altera_Forum]

--- Quote Start ---   There is no notion of: Any unencoded state the implemented registers might take. I would call this a ‘when unencoded_state =>’ – a feature of VHDL still to be specified.  --- Quote End ---   You can set a 'Safe State Machine' in the Analysis & Synthesis Advanced settings. This does about what you want? It detects an illegal state and then transitions to the reset state, but without telling anybody :)    --- Quote Start ---   Remember: Superfluous warnings are *bad*.  --- Quote End ---   I hope that stepmother Altera reads this, its IP spits out loads of them ...    --- Quote Start ---  The answer to this problem space is, again, coding style, and I would strongly recommend reading (and adhering to) this.  --- Quote End ---   Unfortunately this link is not working.

[Altera_Forum]

--- Quote Start ---  Unfortunately this link is not working.  --- Quote End ---   Thanks, fixed.

[Altera_Forum]

--- Quote Start ---  You can set a 'Safe State Machine' in the Analysis & Synthesis Advanced settings. This does about what you want? It detects an illegal state and then transitions to the reset state, but without telling anybody :)   --- Quote End ---   In theory this would be a nice feature, but since you cannot control other registers and especially not output signals, it’s worthless and most likely makes things worse than better. What you need es explicit control over what should happen in such a case.  But, again, you cannot detect inconsistencies beyond this single signal, so if something in the same architecture or even in another entity is expected to run synchronized to your state machine, this will still be out of sync and you need a very high level of redundancy and state monitoring to properly detect reset conditions.  Additionally, such monitoring of unexpected inconsistencies can be combatted by the optimizer which might see opportunities for register collapsing if redundant or similar state machines are not properly constrained.  – Matthias

[Altera_Forum]

Matthias, 

 I did read the paper by Jiri Gaisler in the past, but I have never tried that type of structure. I do like the concepts in the paper. How well does it work?  /Boris