0down votefavorite
i want to make a design for AMBA 3 AHB-Lite Protocol i have the design for master and slave but i have a problem when i make the test bench the value of the HRDATA is do not care ,on the other hand the slave design return the correct value for HRDATA but the master does not, is there a special method to connect the master and slave together ???
i attached the codes for master, slave and test bench
Hi fatima,
This could be a difficult one to debug as I'm not sure where to start.
Looking just at the inputs and outputs on your "slave_ahb" component, there are lots of illegal input sequences being signalled by the "master", so you could start there.
For example, on HTRANS we see illegal sequences of IDLE-BUSY (BUSY can only be used during a burst of transfers, so at least after a NONSEQ), and IDLE-SEQ (SEQ is the continuation of a burst, so cannot follow IDLE which indicates no burst ongoing).
I also see your first read access being signalled as a SEQ, so as explained above this would have to be a NONSEQ if starting a new burst.
HBURST seems to signal 3'h7 (INCR16) whenever you are signalling NONSEQ or SEQ. You can only signal a defined length burst if you will perform that many transfers, so for an INCR16 you must have a NONSEQ followed by 16 SEQ transfers, possibly with BUSY transfers at some points between the SEQ accesses), and during a burst all control signals (HWRITE, HSIZE, etc) cannot change.
So if you can correct the master behaviour so that you have legal stimulus for the slave, that might simplify the problems at the slave.
Once you do get to looking at the slave, I'd guess the issue will likely be related to how you are driving the HREADY signals, and I can already see that you have an issue with the "hready_i" input to the slave, where it is tied to 1'b1 in the "master.v" file at line 84.
Slaves have 2 HREADY ports, an output to allow the slave to signal wait states, and an input so that the slave can see the HREADY output from another slave if that other slave is being accessed. Slaves use the HREADY input to decide when to start their own data transfers.
Once your slave is selected, your slave's HREADY output is the one the master sees, and then this HREADY value should be reflected back as this slave's HREADY input.
By tying the HREADY input to your slave to 1'b1, I would expect most slave designs to fail as they wouldn't know when to sample inputs or when the master would have sampled this slave's outputs.
So try fixing your master stimulus to the slave, and the HREADY connections, and that might then limit your problem solving to the slave are to understand why the HRDATA value you expect to be sampled by the master isn't seen.
JD
thank you , I will check master and slave code again .
I want to ask if it necessary to use multiplexer between the AHB-3 master
and slave ( i did not use it because i have only
one master and one slave ) ????
2016-06-13 17:05 GMT+03:00 jd_ <community@arm.com>:
AMBA 3 AHB-Lite Protocol master and slave connection reply from jd_ <https://community.arm.com/people/jd_?et=watches.email.thread> in *ARM
AMBA 3 AHB-Lite Protocol master and slave connection
reply from jd_
<https://community.arm.com/people/jd_?et=watches.email.thread> in *ARM
You still need to replicate the behaviour of the MUX even when you have just one slave, but this is simply routing the HREADYOUT from your slave to the master's HREADY input, and also looping it back to the slave's HREADY input.
At all times the slaves should see on their HREADY inputs the wait states being signalled by the currently selected slave, so usually selected by a MUX when you have multiple slaves, or by a direct feedback loop connection when there is only one slave to be selected.
The illegal HTRANS sequences and incorrect driving of HREADY back to the slave might not be the causes of the problem in your simulation, but by removing all incorrect stimulus you can then focus on what remains.