1. Home
  2. Field-Programmable Gate Arrays
  3. Altera Avalon Bus VHDL stop error?

Altera Avalon Bus VHDL stop error?

To all,

I've develped a Master peripheral to connect to the Avalon Bus which interfaces a custom slave peripheral. The Master writes to the slave peripheral some data using the "writedata" line and by deasserting the "write_n" signal and asserting "read_n". The Master is a FSM, which has the following sequence; the first state was a read-mode state in which I was requesting something from the slave and then the following state is where I would like to write to the same slave peripheral some data:

STATE#1 write_n = '1' read_n = '0'

STATE#2 write_n = '0' read_n = '1'

The Avalon Bus VHDL code generated by SOPC builder with produces a VHDL stop error called: "vosq0_fifo_logic_avalonM_writedata did not heed wait";

where vosq0_fifo_logic is the name of the Master peripheral.

I have extracted the segment of the VHDL code from within the generated SOPC builder file to show exactly where this comes from. See below.

process (active_and_waiting_last_time, vosq0_fifo_logic_avalonM_writedata, vosq0_fifo_logic_avalonM_writedata_last_time) VARIABLE write_line3 : line; begin if std_logic'((active_and_waiting_last_time AND to_std_logic(((vosq0_fifo_logic_avalonM_writedata /= vosq0_fifo_logic_avalonM_writedata_last_time))))) = '1' then write(write_line3, now); write(write_line3, string'(": ")); write(write_line3, string'("vosq0_fifo_logic_avalonM_writedata did not heed wait!!!")); write(output, write_line3.all); deallocate (write_line3); assert false report "VHDL STOP" severity failure; end if;

end process;

I am trying to figure out what this actually means and don't understand why this error was generated. Anyone have any idea what this means?

Regards Pino

Reply to
pinod01
Loading thread data ...

It means that the master changed the state of the Avalon 'writedata' output (even if only a glitch) while the 'waitrequest' input was still active....can't do that, address, command (i.e. read and write) and writedata must all remain stable if waitrequest coming in is active

KJ

Reply to
KJ

Thanks KJ. I looked over the VHDL block of code for the Master and you are correct that I do change the writedata in the next state. However, I have corrected the slave side as well not to assert the 'waitrequest' signal as I know for sure that the 'writedata' appears after one clock cycle, therefore it was redundant for me to do this and also created this issue.

Regards P> > To all,

Reply to
pinod01

I'm not quite sure but I take it that there is still a problem....and I'll repeat myself here by saying the error is reported when the master changes 'writedata' even though the input signal 'waitrequest' is asserted. Take a look at the waitrequest input at the master when the error is being reported.

You seem to also be making some incorrect assumptions about how the Avalon bus is working when you say "I have corrected the slave side as well not to assert the 'waitrequest' signal as I know for sure that the 'writedata' appears after one clock cycle". Look at the Avalon specification, the only time that 'writedata' going into a slave (or out of a master for that matter) is when the write signal is active. There is no 'one clock cycle later' if by 'later' you mean one clock cycle after 'write' has been asserted. If a slave needs more than one clock cycle to complete the write (or read) it must set waitrequest active on the same clock cycle that it receives the write signal. If it does not then the write (or read cycle) completes and there are no guarantees about what the slave will see on writedata on the next clock cycle.

Also, remember that the master and slave do not talk directly to each other. They talk to the 'Avalon fabric' which in turn is what talks to the master and slave. So even if the slave is not setting the 'waitrequest' output that does not imply that the 'waitrequest' input to the master is not set. Drill down into your master device at the point where you get the error and I think you'll see that the waitrequest input to the master is indeed set. If the slave device that you're talking to at that point does NOT have it's waitrequest output set at this time as well, then Avalon is generating the waitrequest input to the master...and it will do this based on PTF settings in the slave component. Take a look at the PTF file for the slave and see if how wait states are defined. If the slave has a waitrequest output then that setting should be set to something like 'peripheral_controlled' (or something to that effect). If the slave has a waitrequest output then what you should not see is some integer number (like '2') since this would mean that the slave device requires exactly 2 wait states and that there is no waitrequest output. If on the other hand the slave has no explicit waitrequest output then you would expect to see a fixed number in the PTF file for the number of wait states since that is what Avalon will use to generate the waitrequest input to the master.

One last thing to keep in mind is that you make changes to the class.ptf file for a component you pretty much have to delete the component from the SOPC Builder design and re-instantiate it (and then of course re-connect everything). If you don't you'll run into the situation where the component's class.ptf file says one thing but the system.ptf file from SOPC Builder has something else Since the system.ptf file is what gets used to actually generate the final logic you'll be hosed. For a 'simple' change, and only if you're comfortable understanding the PTF file format, the other way is to simply edit both the component's class.ptf file and the system.ptf file.

KJ

Reply to
KJ

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.