JOP as SOPC component

Martin Schoeberl wrote:
... snip
>>> Or does the Avalon switch fabric, when registered, take this
>>> information into account for the waitrequest of the master?
>> It does.
> 
> That's a reason to go with fix wait states!
> 
> Or a bus specification that counts down the number of
> wait states ;-)

The problem with both is that it would impose undesirable constraints on 
slaves. Imagine the case of a good SDRAM controller which tracks open 
pages. Read latency depends on what it's currently doing (idle, 
refreshing, busy with another request, etc) and whether the access hit 
on open page. In this case it _could_ perhaps give an early 
"read-data-in-2-cycles" strobe, but dealing with that would be a nasty 
complication for the interconnect structure that has to be able to 
handle any combination of multi-masters and random assortment of slaves.

It is feasible for internal protocols, tailor-made for the parts it 
connects, but IMO not for a generalist interconnect like Avalon.

FWIW, I used to do exactly what you suggest (latch and mux), but it 
didn't scale for me as the interconnection grew and was expensive in 
both resources and cycle time (not to mention the added complication and 
opportunity for bugs). Adopting the Avalon style template (which is 
obvious IMnsHO) freed so many resources (mine and the FPGAs), enabling 
performance improvements elsewhere. Having spent way too much time and 
energy on exactly this point, I'd be very interested in others insights.

> BTW: Did you take a look into the SimpCon idea?

I just did, after writing the above :-), but my point still stands. 
AFAICT, SimpCon doesn't support multiple outstanding requests from any 
one master and therefore doesn't distinguish between being able to 
accept a new request and and being done with a request.

I'm sure SimpCon works for you, but for me it would be not much better 
than Wishbone.

> Dreaming a little bit: Would be cool to write an
> open-source system generator (like SOPC builder) for
> it. Including your suggestion of an open and documented
> specification file format.

Sure, though I suspect writing all this would be trivial compared to 
coming to an agreement on how the interface should work :-)

>>> Again, one more cycle latency ;-)
>> Again, nope not if done correctly.
> 
> I think we finally agreed, did we?

I'm not KJ, but I think the issue is clear.  Following the template 
would incur an extra cycle for you (assuming JOP couldn't be fixed in a 
different way). It definitely possible to do what you suggest and avoid 
that cycle at the expense of extra overhead and logic (the glitch 
doesn't matter for internal deployment).

Tommy

>> Or a bus specification that counts down the number of
>> wait states ;-)
>
> The problem with both is that it would impose undesirable constraints on slaves. Imagine the case of a good SDRAM controller which 
> tracks open pages. Read latency depends on what it's currently doing (idle, refreshing, busy with another request, etc) and 
> whether the access hit on open page. In this case it _could_ perhaps give an early "read-data-in-2-cycles" strobe, but dealing 
> with that would be a nasty complication for the interconnect structure that has to be able to handle any combination of 
> multi-masters and random assortment of slaves.

If the interconnction of multiple masters gets too complicated
the information can still be ignored. Than it's the same as with
a single ready signal. However, there is a benefit for single
master accessing a varibale latency slave (your SDRAM example).

> FWIW, I used to do exactly what you suggest (latch and mux), but it didn't scale for me as the interconnection grew and was 
> expensive in both resources and cycle time (not to mention the added complication and

one more argument in a single cycle command with register in
the slave ;-)

>> BTW: Did you take a look into the SimpCon idea?
>
> I just did, after writing the above :-), but my point still stands. AFAICT, SimpCon doesn't support multiple outstanding requests 
> from any one master and therefore doesn't distinguish between being able to accept a new request and and being done with a 
> request.

It can do the same pipelining requests as Avalon. With a small
difference. Take the SDRAM as example: It has a long initial
latency and then incremental words can follow fast. With Avalon
you can issue several (depends on the slave pipeline) requests
and than you have to wait. In SimpCon you issue the first request
then you have to wait for the latency and the following requests
are faster. For this example it's just different when the latency
wait occours: at the beginning (SimpCon) or later. The first
word latency is the same and the following reads are the same.

> I'm sure SimpCon works for you, but for me it would be not much better than Wishbone.

No, both Avalon and SimpCon can handle pipelined (in order)
requests. Wishbone not. Out-of-order compeltion of requests
is a complete different story. I don't see usage for this
at the moment for a 'normal' CPU master.

>
>> Dreaming a little bit: Would be cool to write an
>> open-source system generator (like SOPC builder) for
>> it. Including your suggestion of an open and documented
>> specification file format.
>
> Sure, though I suspect writing all this would be trivial compared to coming to an agreement on how the interface should work :-)

I agree! As Tanenbaum said, "The nice thing about standards
is that there are so many to choose from".

Martin 

>
>>> Yes, but e.g. for an SRAM interface there are some timings in ns. And
>>> it's not that clear how this translates to wait states.
>>
>> Since Avalon is not directly compatible the typical SRAMs, this implies 
>> that
>
> Again disagree ;-) The Avalon specification also covers asynchronous
> peripherals. That's adds to a little bit to the complexity of the
> specification.
>
No, the Avalon specification is completely synchronous and is not directly 
compatible with any of the garden variety asynchronous SRAMs that I'm aware 
of.  Just because you can add a controller that is compatible with the 
synchronous Avalon bus on one side and an asynchronous SRAM on the other 
does not imply anything at all about Avalon, it just says that one can make 
a controller that will provide that interface.  The same can be said about 
interfacing Avalon to any other peripheral too so there is nothing special 
about SRAMs and Avalon.

>> Assuming for the moment, that you wanted to write the code for such a 
>> component, one would likely define that the component to have the 
>> following:
>> - A set of Avalon bus signals
>> - SRAM Signals that are defined as Avalon 'external' (i.e. they will get 
>> exported to the top level) so that they can be brought out of the FPGA.
>> - Generic parameters so that the actual design code does not need to hard 
>> code any of the specific SRAM timing requirements.
>
> Yes, that's the way it is described in the Quartus manual. I did my
> SRAM interface in this way. Here is a part of the .ptf that describes
> the timing of the external SRAM:
>
>      SLAVE sram_tristate_slave
>      {
>         SYSTEM_BUILDER_INFO
>         {
>            ....
>            Setup_Time = "0ns";
>            Hold_Time = "2ns";
>            Read_Wait_States = "18ns";
>            Write_Wait_States = "10ns";
>            Read_Latency = "0";
>            ....
>
>> Given that, the VHDL code inside the SRAM controller would set it's 
>> Avalon side wait request high as appropriate while it physically performs 
>> the
>
> There is no VHDL code associated with this SRAM. All is done by the
> SOPC builder.
>
Are we talking about interfacing with a synchronous SRAM or an async SRAM? 
If it's a synchronous SRAM than I agree the Avalon signal set is likely 
compatible but if it's the garden variety async SRAM where timings are 
measured relative to edges of WR and RD than what you have won't work 
reliably in the real world.

>> read/write to the external SRAM.  The number of wait states would be 
>> roughly equal to the SRAM cycle time divided by the Avalon clock cycle 
>> time.
>
> The SOPC builder will translate the timing from ns to clock cycles for
> me. However, this is a kind of iterative process as the timing of the
> component depends on tco and tsu of the FPGA pins of the compiled design.
> Input pin th can usually be ignored as it is covered by the minimum tco
> of the output pins. The same is true for the SRAM write th.
>
The above is again making me think that we're talking about interfacing to 
an async SRAM.  If that's the case, then from your description it sounds 
like Avalon address/read/write basically become the corresponding signals on 
the SRAM.  If that's the case, then how are you guaranteeing that the 
address is stable at the SRAM prior to write being asserted and after it has 
been de-asserted.  The way the Avalon address and write signals work they 
will both be transitioning some Tco after the rising edge of the clock. 
There is absolutely no guarantee of any timing relationship between address 
and write on the Avalon side, so if those are brought out unmodified to the 
SRAM you have no guarantee there either....but for an async SRAM you 
absolutely have to have that.  If address and write are nominally 
transitioning at the 'same' time then you won't get reliable operation (or 
if you build enough of these they will 'erratically' fail) because you can't 
guarantee that you've met the timing requirements of the SRAM.

>> Although maybe it sounds like a lot of work and you may think it results 
>> in some sort of 'inefficient bloat' it really isn't.  Any synthesizer 
>> will quickly reduce the logic to what is needed based on the usage of the 
>> design. What you get in exchange is very portable and reusable 
>> components.
>
> No, it's really not much work. Just a few mouse clicks (no VHDL) and the
> synthesized result is not big. The SRAM tristate bridge contains just
> the address and control output registers. I assume the input registers
> are somwhere burried in the arbitrator.
>

Actually I was referring to what I had described as not being that much 
work.  I agree that what you've done doesn't take much work but I also don't 
think that your 'sram_tristate_slave' component will work reliably if used 
to interface with an external asynchronous SRAM.  It probably will work if 
you're interfacing it to a synchronous SRAM if you also then bring out the 
Avalon clock as the SRAM clock.

I guess this also answers why you're seeing that the master device is 
basically 'stuck' with wait requests until the SRAM operation has been 
completed.  The reason is because you as the designer of the 
'sram_tristate_slave' component did not provide any code to support 
registering the control signals yourself inside your component (inside the 
VHDL that doesn't exist).  Had you done this, you would've been able to 
design a component that would allow the master to continue on while the SRAM 
operation is still in progress.  The only time the master would then need to 
be stalled is if it performed a subsequent access to the SRAM while the 
previous one was still in progress.

KJ

>> Yes, that's the way it is described in the Quartus manual. I did my
>> SRAM interface in this way. Here is a part of the .ptf that describes
>> the timing of the external SRAM:
>>
>>      SLAVE sram_tristate_slave
>>      {
>>         SYSTEM_BUILDER_INFO
>>         {
>>            ....
>>            Setup_Time = "0ns";
>>            Hold_Time = "2ns";
>>            Read_Wait_States = "18ns";
>>            Write_Wait_States = "10ns";
>>            Read_Latency = "0";
>>            ....
>>
>>> Given that, the VHDL code inside the SRAM controller would set it's Avalon side wait request high as appropriate while it 
>>> physically performs the
>>
>> There is no VHDL code associated with this SRAM. All is done by the
>> SOPC builder.
>>
> Are we talking about interfacing with a synchronous SRAM or an async SRAM? If it's a synchronous SRAM than I agree the Avalon 
> signal set is likely compatible but if it's the garden variety async SRAM where timings are measured relative to edges of WR and 
> RD than what you have won't work reliably in the real world.

It's async. SRAM. And I just did what is described in the Quartus
manual. If that is not reliable then Altera should update the manual.

> The above is again making me think that we're talking about interfacing to an async SRAM.  If that's the case, then from your 
> description it sounds like Avalon address/read/write basically become the corresponding signals on the SRAM.  If that's the case, 
> then how are you guaranteeing that the address is stable at the SRAM prior to write being asserted and after it has been 
> de-asserted.  The way the Avalon address and write signals work they will both be transitioning some Tco after the rising edge of 
> the clock. There is absolutely no guarantee of any timing relationship between address and write on the Avalon side, so if those 
> are brought out unmodified to the SRAM you have no guarantee there either....but for an async SRAM you absolutely have to have 
> that.  If address and write are nominally transitioning at the 'same' time then you won't get reliable operation (or if you build 
> enough of these they will 'erratically' fail) because you can't guarantee that you've met the timing requirements of the SRAM.

As I set setup time to 0ns, you're right. There is a little issue (depends
on the tco of the different pins) when wrn goes low before the address
is stable. That's against the SRAM timing spec. (minimum wrn low after
address is 0ns). However, I 'assume' that this does not matter. Setting
Setup_Time to something >0ns will add one additional cycle.

To avoid this little issue and the additional cycle I do usually (with
my SimpCon SRAM controller) clock the nwr with the inverted clock to
shift it after address setup.

> Actually I was referring to what I had described as not being that much work.  I agree that what you've done doesn't take much 
> work but I also don't think that your 'sram_tristate_slave' component will work reliably if used to interface with an external 
> asynchronous SRAM.  It probably will work if you're interfacing it to a synchronous SRAM if you also then bring out the Avalon 
> clock as the SRAM clock.

Ok, again - it was a first try and do it as described by Altera. However,
the next step will be a 'real' SRAM slave. With the nwr trick as described
and with timing (wait states) given in clock cycles as parameter.

> 'sram_tristate_slave' component did not provide any code to support registering the control signals yourself inside your component 
> (inside the VHDL that doesn't exist).  Had you done this, you would've been able to

That's an option in the tristate bridge ;-) However, I assume that this means
only register the ouput to get a low tco.

> design a component that would allow the master to continue on while the SRAM operation is still in progress.  The only time the 
> master would then need to be stalled is if it performed a subsequent access to the SRAM while the previous one was still in 
> progress.

Not for the read (in my case) as I'm waiting for the read data in the
processor. In some cases I can hide the latency by execution of additional
code. However, in this case I need the data registerd in the slave. which
is again not possible....

Martin 

> Martin Schoeberl wrote:
>> What helps is to know in advance (one or two cycles) when the result
>> will be available. That's the trick with the SimpCon interface.
>
> That approach is common internally in real cores, but adds a lot of complication while it's an open question how many Avalon 
> application could benefit from it.

It's not that complicated to handle. Even one cycle in advance is
nice to know. However, it's just an additional information. You
still can ignore it.

>> There is not a single ack or waitrequest signal, but a counter that
>> will say how many cycles it will take to provide the result. In this
>> case I can restart the pipeline earlier.
>
> AFAIR, Avalon _does_ support slaves with fixed number of latency cycles, but an SDRAM controller by nature won't be fixed cycles.

Exactly in this case the counter approach helps.

>> Another point is, in my opinion, the wrong role who has to hold data
>> for more than one cycle. This is true for several busses (e.g. also
>> Wishbone). For these busses the master has to hold address and write
>> data till the slave is ready. This is a result from the backplane
>> bus thinking. In an SoC the slave can easily register those signals
>> when needed longer and the master can continue.
>
> When happens then when you issue another request to a slave which hasn't finished processing the first? Any queue will be finite 
> and eventually you'd have to deal with stalling anyway. Any issue is that there are generally many more slaves than masters so it 
> makes sense to move the complication to the master.

I disagree ;-)
How hard is it for a slave to hold the read data more than one cycle?
Until the next read data is requested and available? That comes almost
for free. It's a single register, trivial logic. Ok, is a little overhead
for an on-chip peripheral. However, you need usually a MUX in the
peripheral for select the IO registers (now using register with a different
meaning). Making this MUX registered is almost for free.

And you win for the master. Let's say it unformal:
Give the master more freedom to move, you usually have less
masters than slaves in a system. Therfore, the master(s) will
be the bottleneck.

> ...
>> Wishbone and Avalon specify just a single cycle data valid.
>
> Again, simplify the slave (and the interconnect) and burden the master.

I argue the other way round - now it becomes almost political ;-)

> Avalon is IMO the best balance between complexity, performance and features in all the (few) interconnect I've seen yet (I haven't 
> seen SimpCon yet). In particular I found Wishbone severely lacking for my needs.  Avalon is proprietary though, so I roll my own 
> portable implementation inspired by Avalon with just the features I needed:
> - all reads are pipelined with variable latency (accept of request is distinct from delivery of data, thus inherently supporting 
> multiple outstanding requests)
> - multi master support
> - burst support (actually not implemented yet, but not that hard)

Ok, as you roll your own (like I do) perhaps we can agree on
one interface. In that case - two using the same interface -
it's almost a standard...

> It's nearly as trivial as Wishbone, though offers much higher performance. Latency is entirely up to the slave which can deliver 
> data as soon as the cycle after the request was posted. (Though, arriving at this simplicity took a few false starts).

The same in SimpCon.

Martin

"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message 
news:44de421a$0$12126$3b214f66@tunews.univie.ac.at...
>> Not really, it is just simpler to say that I'm not going to go anywhere 
>> near code that can potentially change any of the outputs if wait request 
>> is active.  As an example, take a look at your code below where you've 
>> had to sprinkle the 'if av_waitrequest = '0' throughout the code to make 
>> sure you don't change states at the 'wrong' time (i.e. when 
>> av_waitrequest is active).  Where problems can come up is when you miss 
>> one of those 'if av_waitrequest = '0' statements.  Depending on just 
>> where exactly you missed putting it in is is where it can be a rather 
>> subtle problem to debug.
>
> Agree on the save side, but...
>
>>
>> Now consider if you had simply put the 'if av_waitrequest = '0' statement 
>> around your entire case statement (with it understood that outside that
>
> I cannot do this. This case statement is combinatoric. It would introduce
> a latch for next_state. The reason to split up the state machine in
> a combinatoric next state logic and the clocked part is to react
> 'one cycle earlier' with state machine output registers depending
> on next_state. You can code this also with a single case in a clock
> process. However, than you have to code your output registers on the
> transitions (in the if part), which gets a little bit more confusing.

Well, there is always great debate between the one process and two process 
folks about this but whether one thinks that one process or two process is 
'more' confusing or not is usually a function of the designer themself.  The 
code will synthesize to the same darn thing.  The truth is that either 
method can be written as clearly and understandably if one tries to.  One 
thing that can definitely be said though is that one process code will be 
shorter in terms of lines of code.

In any case, using my template then by inspection pretty much anyone can 
guarantee that Avalon won't be violated (in terms of not allowing address or 
control to change while waitrequest is active).  The way you've coded it 
you're simply replicating the same check on waitrequest in a somewhat 
confusing manner (i.e. when waitrequest is active and the master is being 
told to 'wait', you're actively going about changing from one state to the 
next.  To me that is a bit counterintuitive, you've been told to wait.  On 
top of that there is also a state where transitions are made independent of 
wait request.  Hopefully you're never reaching this state when read or write 
are active or it will cause a failure for not heeding the wait request. 
Not saying that it can't be made to work just that the code can be 
simplified quite a bit and made clearer by not writing it this way in the 
first place.  You might try re-writing the process as a synchronous clocked 
process and see for yourself which is clearer.

On top of that using my template you've got the assurance that it will be 
fully Avalon compliant, with your approach it's not at all obvious if that 
is the case or not under all operational conditions.

>
>>>
>>> What about this version (sc_* signals are my internal master signals)
>>>
>>> that case is the next state logic and combinatorial:
>
> the process containing this case statement is:
>
> process(state, sc_rd, sc_wr, av_waitrequest)
>
> begin
>
>    next_state <= state;
>
>>>
>>> case state is
>>>
>>>    when idl =>
>>>        if sc_rd='1' then
>>>            if av_waitrequest='0' then
>>>                next_state <= rd;
>>>            else
>>>                next_state <= rdw;
>>>            end if;
>>>        elsif sc_wr='1' then
>>>            if av_waitrequest='0' then
>>>                next_state <= wr;
>>>            else
>>>                next_state <= wrw;
>>>            end if;
>>>        end if;
>>>
>>>    when rdw =>
>>>        if av_waitrequest='0' then
>>>            next_state <= rd;
>>>        end if;

-- Oops!  Since this is a combinatorial process, then where is the 'else' 
term on the above 'if' statement?  Looks like it will cause a latch.  Score 
one for the one process folks ;)

>>>
>>
>>>    when rd =>
>>>        next_state <= idl;
>> --- Are you sure you always want to go to idl?  This would probably cause 
>> an error if the avalon outputs were active in this state.
>
> No problem as next_state goes to rd only when av_waitrequest is '0'.
> Perhaps 'rd' is a missleading state name. The input data is registered
> when next_state is 'rd'. So state is 'rd' when the input data is 
> registered.
>
Might cosider putting an assert that the Avalon read and write signals are 
not set in the 'rd' state.  From a code maintenance perspective, say that 
somewhere down the road someone wanted to modify the code somewhat and use 
state 'rd' and didn't 'know' that read and write had better not be set when 
entering this state.  You could add this as a comment, but better to add it 
as an assert since that is active design code and is a much better flag for 
design intent.

>>
>> Whether it works or not for you would take more analysis, I'll just say 
>> that
>
> For a complete picture you can look at the whole thing at:
> http://www.opencores.org/cvsweb.cgi/~checkout~/jop/vhdl/scio/sc2avalon.vhd
>
>
>>>> You might try looking at incorporating the above mentioned template and 
>>>> avoid the Avalon violation.  What I've also found in debugging other's 
>>>> code
>>>
>>> Then I get an additional cycle latency. That's what I want to avoid.
>>
>> Not on the Avalon bus, maybe for getting stuff into the template but even 
>> that is a handshake.  I've even used Avalon within components to transfer
>
> Ok, than not at the Avalon bus directly but as you sayed 'getting stuff
> into the template'. That's the same for me (in my case).
>
> If my master has a (internal) read request and I have to forward it
> to Avalon in a clocked process (as you do with your template)
> I will loose one cycle. Ok in the interface and not in the bus.
> Still a lost cycle ;-)
>
Not always a lost cycle.  It would be more properly considered a pipeline 
stage.  A pipelined design adds latency but does not by itself impact 
performance.  In fact, the reason one would use pipelining is to improve 
clock cycle performance.  If you're thinking only about interfacing to an 
SRAM it would seem that added latency would result in decreased performance 
(and you'd be right) but in many other situations the latency is rather 
unimportant.  Avalon allows for master and slave components to have latency 
(in addition to wait states) so that the master is not hung up waiting on a 
device that has latency (think about a SDRAM/DDR controller, there you have 
relatively long latency to get at the 'first' hunk of data when accessing a 
new memory page but one can queue up the commands and run at the exact same 
rate as the Avalon bus).

>> data between rather complicated processes just because it is a clean data 
>> transfer interface and still have no problem transferring data on every 
>> clock cycle when it is available.  I'm not familiar enough with your 
>> code, but I suspect that it can be done in your case as well.
>
> You can do it when your template 'controls' the master logic but not
> the other way round.
>
Not sure what you mean by 'not the other way around'.  This template is only 
for the master side control logic.

>>> And then it goes on with slaves with fixed wait states. Why?
>>> If do not provide a waitrequest in a slave that needs wait
>>> states you can get into troubles when you specify it wrong
>>> at component genration.
>>
>> No, PTF files let you state that there are a fixed number of wait states 
>> and not have an explicit waitrequest on the slave.
>
> I meant when you assume n wait states in your VHDL code, but
> did a mistake in the PTF file and specified less wait states.
> This erro cannot happen when you generate the waitrequest within
> your VHDL code.
>
That's why I never use the PTF file to define the number of wait states.  In 
addition to a fixed number (or time) you can say that it is user controlled 
which means that the slave device has a 'waitrequest' output.  Then it is up 
to the VHDL to set waitrequest appropriately and if I need to insert or 
remove a clock cycle of wait states I only change the VHDL for the slave, 
nothing in the PTF file changes.
>>>
>>> Or does the Avalon switch fabric, when registered, take this
>>> information into account for the waitrequest of the master?
>>
>> It does.
>
> That's a reason to go with fix wait states!
>
A reason for everyone to have fixed wait states??  I think not.  That 
severly limits the types of things you can interface with the bus.  Consider 
a system where you have say a NIOS processor inside an FPGA and it talks 
over a PCI bus as a bus master to some external component and there are 
other masters potentially competing for that PCI bus.  The Avalon component 
inside the FPGA that provides the NIOS access to peripherals on the PCI bus 
would have no idea about how many wait states would be required to complete 
a particular PCI bus transaction.

You almost never want to have a fixed number of wait states but want to 
simply have the Avalon slave provide a wait request output and tell Avalon 
that by specifying that in the PTF file.

> Or a bus specification that counts down the number of
> wait states ;-)
>
See above and tell me how long to count down.  You'd have to figure out a 
worst case number of wait states for the component, but then you'd be stuck 
with that even if the component got the data early.  Talk about wasting 
clock cycles.

> BTW: Did you take a look into the SimpCon idea?
>
> Dreaming a little bit: Would be cool to write an
> open-source system generator (like SOPC builder) for
> it. Including your suggestion of an open and documented
> specification file format.
>
>>
>>> Could be for the SRAM component. Should look into the
>>> generated VHDL code (or in a simulation)...
>>>
>> I'd suggest looking at the system.ptf file for your design.
>
> It's still in ns, which makes sense.
>
> Martin
>
>>> Again, one more cycle latency ;-)
>> Again, nope not if done correctly.
>
> I think we finally agreed, did we?
>
Well if you consider you making a statement and me saying 'nope' to be 
agreeing then yes we agree ;)

I don't see it so much as disagreeing as it is discussing different design 
approaches and the tradeoffs that one can make.  I think your original 
complaint about the master having to wait until the slave completed the 
operation is strictly because of the way you chose to implement the 
interface to the SRAM.  On the plus side, you wrote very little code (PTF 
file stuff, but no VHDL it sounds on the SRAM interface side).  On the minus 
side, I think there might be a latent design error in the timing and your 
master is stuck having to wait.  If done differently the master wouldn't 
have to wait (except for consecutive reads/writes to the SRAM).

KJ 

> Well, there is always great debate between the one process and two process folks about this but whether one thinks that one 
> process or two process is

It's just a matter of style. I change it from case to case.
We don't need to start a flame on it ;-)

> you're simply replicating the same check on waitrequest in a somewhat confusing manner (i.e. when waitrequest is active and the 
> master is being

Again what is confusing depends on style.

> On top of that using my template you've got the assurance that it will be fully Avalon compliant, with your approach it's not at 
> all obvious if that is the case or not under all operational conditions.
>
>>>> that case is the next state logic and combinatorial:
>>
>> the process containing this case statement is:
>>
>> process(state, sc_rd, sc_wr, av_waitrequest)
>>
>> begin
>>
>>    next_state <= state;
....
>>
>>>>
>>>>    when rdw =>
>>>>        if av_waitrequest='0' then
>>>>            next_state <= rd;
>>>>        end if;
>
> -- Oops!  Since this is a combinatorial process, then where is the 'else' term on the above 'if' statement?  Looks like it will 
> cause a latch.  Score one for the one process folks ;)

No, you did not catch me on this one ;-) See above the default
assignment: next_state <= state

Rule 1 for combinatorial processes: Assign defaults at the beginning
to avoid latches.

> Might cosider putting an assert that the Avalon read and write signals are not set in the 'rd' state.  From a code maintenance 
> perspective, say that somewhere down the road someone wanted to modify the code somewhat and use state 'rd' and didn't 'know' that 
> read and write had better not be set when entering this state.  You could add this as a comment, but better to add it as an assert 
> since that is active design code and is a much better flag for design intent.

Good idea. Actually I'm using to less asserts in my code.
One can improve VHDL coding every day ;-) BTW: I now
like records. Synthesizer can handle them and it saves
a lot of coding.

>> If my master has a (internal) read request and I have to forward it
>> to Avalon in a clocked process (as you do with your template)
>> I will loose one cycle. Ok in the interface and not in the bus.
>> Still a lost cycle ;-)
>>
> Not always a lost cycle.  It would be more properly considered a pipeline stage.  A pipelined design adds latency but does not by 
> itself impact performance.  In fact, the reason one would use pipelining is to improve clock cycle performance.  If you're 
> thinking only about interfacing to an

ok, ok. Most of the time I'm talking about the read request and a
master that needs the result. Therfore I try to avoid latency as much
as possible (of course without loosing fmax).

>> You can do it when your template 'controls' the master logic but not
>> the other way round.
>>
> Not sure what you mean by 'not the other way around'.  This template is only for the master side control logic.

Yes, but your trigger of the trasnaction 'within' your Avalon master
template. However, for me the Avalon interface is just an
interface. It has to react on the request from the CPU. And
the CPU requests the transaction from 'outside' of the
template/interface.

>> I meant when you assume n wait states in your VHDL code, but
>> did a mistake in the PTF file and specified less wait states.
>> This erro cannot happen when you generate the waitrequest within
>> your VHDL code.
>>
> That's why I never use the PTF file to define the number of wait states.  In addition to a fixed number (or time) you can say that 
> it is user controlled which means that the slave device has a 'waitrequest' output.  Then it is up to the VHDL to set waitrequest 
> appropriately and if I need to insert or remove a clock cycle of wait states I only change the VHDL for the slave, nothing in the 
> PTF file changes.

...

> You almost never want to have a fixed number of wait states but want to simply have the Avalon slave provide a wait request output 
> and tell Avalon that by specifying that in the PTF file.

Completely agree. When not writing and reading too many posts
I'm working on that version of the SRAM interface. It was just
a quick start as shown in the Quartus manual.

>> Or a bus specification that counts down the number of
>> wait states ;-)
>>
> See above and tell me how long to count down.  You'd have to figure out a worst case number of wait states for the component, but 
> then you'd be stuck with that even if the component got the data early.  Talk about wasting clock cycles.

No, counter was a little bit misleading name. From the spec.
it's allowed to jump down more than one increment. E.g.
from 2 to 0. Or a very simple slave without pipelining
can just say 33330. Than it's like a simple ready signal.
That's also the way I translate Avalon to SimpCon :-(

>>>> Again, one more cycle latency ;-)
>>> Again, nope not if done correctly.
>>
>> I think we finally agreed, did we?
>>
> Well if you consider you making a statement and me saying 'nope' to be agreeing then yes we agree ;)

ok, than the discussion is on-going ;-)

Martin 

>
>> You almost never want to have a fixed number of wait states but want to simply have the Avalon slave provide a wait request 
>> output and tell Avalon that by specifying that in the PTF file.
>
> Completely agree. When not writing and reading too many posts
> I'm working on that version of the SRAM interface. It was just
> a quick start as shown in the Quartus manual.

BTW (to KJ): Do you have this type of Avalon slave
for an SRAM? Would save some time and errors for me ;-)

Martin 

"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message 
news:44df8e1b$0$12642$3b214f66@tunews.univie.ac.at...
>> The above is again making me think that we're talking about interfacing 
>> to an async SRAM.  If that's the case, then from your description it 
>> sounds like Avalon address/read/write basically become the corresponding 
>> signals on the SRAM.  If that's the case, then how are you guaranteeing 
>> that the address is stable at the SRAM prior to write being asserted and 
>> after it has been de-asserted.  The way the Avalon address and write 
>> signals work they will both be transitioning some Tco after the rising 
>> edge of the clock. There is absolutely no guarantee of any timing 
>> relationship between address and write on the Avalon side, so if those 
>> are brought out unmodified to the SRAM you have no guarantee there 
>> either....but for an async SRAM you absolutely have to have that.  If 
>> address and write are nominally transitioning at the 'same' time then you 
>> won't get reliable operation (or if you build enough of these they will 
>> 'erratically' fail) because you can't guarantee that you've met the 
>> timing requirements of the SRAM.
>
> As I set setup time to 0ns, you're right. There is a little issue (depends
> on the tco of the different pins) when wrn goes low before the address
> is stable. That's against the SRAM timing spec. (minimum wrn low after
> address is 0ns). However, I 'assume' that this does not matter. Setting
> Setup_Time to something >0ns will add one additional cycle.

That timing does matter, so 'as-is' you do have a timing issue that needs 
fixing.  You also need to insure that at the trailing edge of the SRAM write 
that the address remains stable.  Otherwise it's possible for the SRAM to 
respond to a write to an address that you had not intended.
>
> To avoid this little issue and the additional cycle I do usually (with
> my SimpCon SRAM controller) clock the nwr with the inverted clock to
> shift it after address setup.
But now what about the trailing edge or write?  The address could start 
changing and the write signal will still be active.
>
>> Actually I was referring to what I had described as not being that much 
>> work.  I agree that what you've done doesn't take much work but I also 
>> don't think that your 'sram_tristate_slave' component will work reliably 
>> if used to interface with an external asynchronous SRAM.  It probably 
>> will work if you're interfacing it to a synchronous SRAM if you also then 
>> bring out the Avalon clock as the SRAM clock.
>

>> design a component that would allow the master to continue on while the 
>> SRAM operation is still in progress.  The only time the master would then 
>> need to be stalled is if it performed a subsequent access to the SRAM 
>> while the previous one was still in progress.
>
> Not for the read (in my case) as I'm waiting for the read data in the
> processor. In some cases I can hide the latency by execution of additional
> code. However, in this case I need the data registerd in the slave. which
> is again not possible....

It is if you write some code for your component and use the 'readdatavalid' 
Avalon signal it will work.  Once you have the address and command safely 
stored within the component wait request can be set to 0.  This can even be 
happening on a read even if you haven't completed the read (i.e. you don't 
have the data yet).  For example, let's say it takes 10 Avalon clock cycles 
to complete the read and provide the data.  Assuming that the SRAM is 
currently idle, then when that read comes in from Avalon you do not need to 
assert wait request at all.  Since wait request is not asserted then the 
master device is free to go off and start up another transaction with any 
device (i.e. it has not been stalled).

Now, 10 Avalon clock cycles later the slave finally get the data in from the 
SRAM, shoves it out the 'readdata' output and asserts 'readdatavalid'.  This 
signal goes back to the master and now it actually has the data that it was 
looking for.  During those 10 clock cycles while it was waiting it could 
very well have been off initiating 10 other write cycles to anything else. 
Unfortunately if a second read is started (even if it not to the SRAM, even 
if it is to a device that has 0 wait state reads) that read will be greeted 
by a wait request because Avalon needs to insure that read data is supplied 
back in the order in which the master requested it.  In order to do this it 
will actually block the second read from even reaching the other slave until 
the first one (to the SRAM that takes 10 clock cycles) completes.  If the 
second read happens to occur to the same device (in this case the SRAM) such 
delays won't happen since each component must also supply readdata in the 
order in which it was requested.

Sounds confusing but it isn't, the bottom line is that reads don't 
necessarily cause the master device to stall.  To see all of this clearly, 
try putting together an SOPC system with a master device and a SDRAM or DDR 
SDRAM controller out of the MegaCore library.  Then watch the interaction 
between the master and slave side read/write/waitrequest/readdatavalid 
signals.  It'll give you a real good feel for how this Avalon interface can 
really perform.

KJ

"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message 
news:44df9c2e$0$12126$3b214f66@tunews.univie.ac.at...
>> Well, there is always great debate between the one process and two 
>> process folks about this but whether one thinks that one process or two 
>> process is
>
> It's just a matter of style. I change it from case to case.
> We don't need to start a flame on it ;-)
Good ;)
>
>> -- Oops!  Since this is a combinatorial process, then where is the 'else' 
>> term on the above 'if' statement?  Looks like it will cause a latch. 
>> Score one for the one process folks ;)
>
> No, you did not catch me on this one ;-) See above the default
> assignment: next_state <= state
>
> Rule 1 for combinatorial processes: Assign defaults at the beginning
> to avoid latches.

You're right, erase the 'score one...'.  Us one process folks don't like 
writing unneeded code to do those default assignments to avoid something 
that can't happen because we're in a clocked process.....OK, just couldn't 
resist.

>
>>> You can do it when your template 'controls' the master logic but not
>>> the other way round.
>>>
>> Not sure what you mean by 'not the other way around'.  This template is 
>> only for the master side control logic.
>
> Yes, but your trigger of the trasnaction 'within' your Avalon master
> template. However, for me the Avalon interface is just an
> interface. It has to react on the request from the CPU. And
> the CPU requests the transaction from 'outside' of the
> template/interface.
>
OK, lost again I think.  Now it sounds like the CPU even though embedded 
within the FPGA doesn't have a native Avalon interface and you're talking 
about a bridge to get you from the CPU interface over to Avalon.  Such a 
bridge though would typically not be terribly application specific but 
instead is tailored to the signals on the CPU and Avalon.  Just like you can 
make a bridge between Wishbone and Avalon.  If the CPU design is your 
homebrew though a simpler approach is to simply make it have an Avalon 
compatible interface.  When you get to writing that code is where my 
template would be placed.

KJ