JOP as SOPC component

"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message
news:44ddb2d4$0$8024$3b214f66@tunews.univie.ac.at...
> The Avalon bus is very flexible. Therefore, writing a slave or
> master (SOPC component) is not that hard. The magic is in the Avalon
> switch fabric generated by the builder. However, an example would
> have helped (Altera listening?). I didn't find anything on Altera's
> website or with Google. Now a very simple slave can be found at [1].
>
As you get into making your own components you'll find a lack of
documentation about important things that go into the .PTF file.  Altera
used to have a document on their website that was invaluable called the "PTF
File Reference Manual" (or something like that).  They've chosen to pull
that out so your only source for crucial information now is your FAE (maybe)
or someone who happens to have that file available.  I've complained to
Altera to no avail that they need to put that document back and maintain it
or at least make it available upon request to component developers.  Maybe
others also complaining will help as well (hint).

> One thing to take care: When you (like me) like to avoid VHDL files
> in the Quartus directory you can easily end up with three copies of
> your design files. Can get confusing which one to edit. When you
> edit your VHDL file in the component directory (the source for the
> SOPC builder) don't forget to rebuild your system. The build process
> copies it to your Quartus project directory.
>
Damn annoying too of the tool to do those copies like it does.  You have to
be very careful about which file you edit as being the 'source' or it will
get overwritten because it really isn't.

> The master is also ease: just address, read and write data,
> read/write and you have to react to waitrequest. See as example the
> SimpCon/Avalon bridge at [2]. The Avalon interconnect fabric handles
> all bus multiplexing, bus resizing, and control signal translation.
>
If you're going for a very high speed design and you have multiple masters
accessing a slave (i.e. multiple CPUs, or DMA controllers accessing memory)
the performance degrades rather quickly using SOPC Builder to perform the
arbitration.  You don't necessarily need a large number of masters either,
4-5 killed it for me and necessitated redesign to work around how Avalon
handled things.

> 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.

What's you're describing is not an Avalon issue or a result of 'backplane
bus thinking', and is not a limitation of Avalon.  If it exists in your
design than it's a limitation of the slave component design.  The slave
generates the wait request output which is used to tell the master that it
needs to hold the address and data for it because it essentially doesn't
have any space left to hold it itself.  If the slave component design has
provisions to register and hold the address and data than it can do this and
leave the wait request output not asserted and the cycle completes.  If you
think about it, this would simply be a one deep fifo for holding the
address/data/command.  If you generalize a bit more you would see that the
fifo wouldn't need to be restricted to being only one deep and could be any
depth.  So as the master device performs reads and writes these commands
would be written into the fifo without asserting wait request but also
remember that any fifo can fill up at which point the slave must assert wait
request because it has no more room to store anything which means that the
master device has to hold on to it for a bit.

> On the other hand,
> as JOP continues to execute and it is not so clear when the result
> is read, the slave should hold the data when available. That is easy
> to implement, but Wishbone and Avalon specify just a single cycle
> data valid.
>
What you would need then is a signal generated by the master back to the
slave to say that the master isn't ready to receive the data and would then
cause the slave to hold on to the read data.  But if you think about it a
bit more, the only reason that the slave is providing read data in the first
place is because the master device requested it in the first place.  If the
master wasn't ready to receive data it should simply not assert the read
signal command output.

By the way, Avalon has a leg up on Wishbone in regards to a cleaner logical
approach to handling wait states and latency.  Avalon treats the address
cycle as a single phase controllable by the slave's wait request and
separates that from the read data phase by allowing for latency with the
'readdatavalid' output.  With Wishbone you can accomplish the same thing by
extending the bus definition with 'tags' but since not all components are
required to support 'tags' when you have a mismatch you're on your own for
getting the interconnect right.  With Avalon, they designed it right with a
clear logical distinction between address and data phases so that any
incompatibilites between master and slave can still be handled automatically
by an automated tool (SOPC Builder).

KJ

"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message
news:44ddc530$0$11352$3b214f66@tunews.univie.ac.at...
> That's fine for me. When the connection magic happens and I don't
> have to care it's fine. OK, one exception: Perhaps I would like
> to know more details on the latency. The switch fabric is 'plain'
> VHdL or Verilog. However, generated code is very hard to read.
>

What?  You don't have a display that can show 2000 columns on your screen as
is nearly required to view the VHDL/Verilog that pops out of SOPC?

Actually the best place I've found to look at and understand the wait states
and latency is simply the .PTF file since that's where all the information
is.  Although the .PTF file requires a little bit of a learning curve due to
the lack of documentation on Altera's part it's not that hard and once you
get a feel for it, it is very easy to see if a slave device requires wait
states (and if it does, is it a fixed number or controllable by the slave)
and whether the slave device has any read latency (and if it does, it is a
fixed number, or controllable by the slave, and how many reads can be
pending at one time).  Looking at the VHDL is much harder and is not truly
the source code anyway, the 'source' really is the .PTF file since the VHDL
gets generated from it.

>
>> the avalon master is really as simple as the slave.
>
> Almost, you have to hold address, data and read/write active
> as long as waitrequest is pending. I don't like this, see above.
>

The master side is a bit more complicated than the slave side.

There is a very simple template though that one must almost always follow
for the master.  When you try to deviate from it you're likely to get burned
(voice of experience, I've already had to fix other's code in this area).
The template is

process(Clock)
begin
    if rising_edge(Clock) then
        if (Reset = '1') then
            Read <= '0';
            Write <= '0';
        elsif (WaitRequest = '0') then
            -- Put your code here for whenever it is you want to read and/or
write
            -- When writing you would also set WriteData here
            -- For example, if you're not ready to receive data whenever the
slave says it is
            -- ready than you simply set Read <= '0' until you are ready.
        end if;
    end if;
end process;

For sampling the data on a read it depends on whether the master is
implementing the 'Readdatavalid' input (i.e. 'latency aware' in Avalon
terminology) or not.  If so, then you sample the data when readdatavalid is
asserted, if not then sample the data when both the read output is asserted
and the wait request is not.

> In my case e.g. the address from JOP (= top of stack) is valid
> only for a single cycle. To avoid one more cycle latency I present
> in the first cycle the TOS and register it. For additional wait
> cycles a MUX switches from TOS to the address register. I know this is a 
> slight violation of the Avalon specification.
> There can be some glitches on the MUX switch.

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
that doesn't adhere to the above template is that there can be subtle errors
that take just the right combination of events to occur in order to cause an
actual system error of some sort (i.e. not just the Avalon generated assert
in simulation).  If you use the above template, you're guaranteed to be
Avalon compliant and not have this issue.

In my opinion, the Avalon bus and the .PTF files to completely define
component I/O interfaces is a huge improvement over Wishbone.  Although
others disagree and don't like .PTF they don't offer any alternative
definitions other than comments or documentation to defining all those
interface things that one needs to know (i.e. wait states, latency, bus
size, etc.).  Comments and documentation are nice, but they are not
synthesizable whereas .PTF files are (i.e. SOPC Builder sucks them in and
spits out VHDL/Verilog)....PTF may not be a standard anywhere outside of
Altera, but then is there an open standard that defines a file format that
can be used to accomplish what .PTF does?  I haven't run across it, and if
there is one, I wouldn't mind badgering the tool vendors to support it to
that I'm not locked into a vendor specific implementation until then I can
be much more productive using PTF than not.

> For synchronous on-chip
> peripherals this is absolute not issue. However, this signals
> are also used for off-chip asynchronous peripherals (SRAM).
> However, I assume that this possible switching glitches are
> not really seen on the output pins (or at the SRAM input).

Again, if you use the template, you won't have the gliching even if the
signals go off chip to a device.

KJ

Hi KJ,

> get a feel for it, it is very easy to see if a slave device requires wait states (and if it does, is it a fixed number or 
> controllable by the slave) and whether the slave device has any read latency (and if it does, it is a

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.

> The template is
>
> process(Clock)
> begin
>    if rising_edge(Clock) then
>        if (Reset = '1') then
>            Read <= '0';
>            Write <= '0';
>        elsif (WaitRequest = '0') then
>            -- Put your code here for whenever it is you want to read and/or write
>            -- When writing you would also set WriteData here
>            -- For example, if you're not ready to receive data whenever the slave says it is
>            -- ready than you simply set Read <= '0' until you are ready.
>        end if;
>    end if;
> end process;
>

I disagree on this template ;-) Perhaps, I'm wrong (as an Avalon newbie),
but: Why is all your active code in waitrequest='0'? From the
Avalon specification. You have to bring out address, read, write and
writedata to start the transaction - independent of waitrequest.
waitrequest=0 just ends your transaction.

From the specification (p 47, 49) it is allowed to start a read or
write transaction independent of the status of waitrequest. Did you
run into troubles with this?

Ok, after a second thought on your code it looks like you're starting
your actions at the last cycle of the former transaction. Mmh, kind
of strange thinking.

What about this version (sc_* signals are my internal master signals)

that case is the next state logic and combinatorial:

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;

    when rd =>
        next_state <= idl;

    -- here I could add the code from the idl
    -- state for back to back read and writes
...

sc_rd and sc_wr directly start setting read and write. However,
again I have to register them for keeping them set for wait
states (sc_rd and sc_wr are only valid for one cycle).
When there is a waitrequest, I'm just waiting.

Read data is registered in the state register process:

elsif rising_edge(clk) then

    state <= next_state;
    reg_rd <= '0';
...
    case next_state is

        when idl =>

        when rdw =>
            reg_rd <= '1';

        when rd =>
            reg_rd_data <= av_readdata;
...

That's my (violation) trick as an example on the Avalon read signal:

av_read <= sc_rd or reg_rd;


>> In my case e.g. the address from JOP (= top of stack) is valid
>> only for a single cycle. To avoid one more cycle latency I present
>> in the first cycle the TOS and register it. For additional wait
>> cycles a MUX switches from TOS to the address register. I know this is a slight violation of the Avalon specification.
>> There can be some glitches on the MUX switch.
>
> 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.

> that doesn't adhere to the above template is that there can be subtle errors that take just the right combination of events to 
> occur in order to cause an actual system error of some sort (i.e. not just the Avalon generated assert in simulation).  If you use 
> the above template, you're guaranteed to be Avalon compliant and not have this issue.

Good to hear the comments from one who struggled with Avalon.
However, I'm still not so happy with the style the bus is
specified. The first timing diagrams look more like an asynch.
SRAM timing specification with a clock drawn on top of it.
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.

Or does the Avalon switch fabric, when registered, take this
information into account for the waitrequest of the master?
Could be for the SRAM component. Should look into the
generated VHDL code (or in a simulation)...


> In my opinion, the Avalon bus and the .PTF files to completely define component I/O interfaces is a huge improvement over 
> Wishbone.  Although

agree, that's nice.

>> For synchronous on-chip
>> peripherals this is absolute not issue. However, this signals
>> are also used for off-chip asynchronous peripherals (SRAM).
>> However, I assume that this possible switching glitches are
>> not really seen on the output pins (or at the SRAM input).
>
> Again, if you use the template, you won't have the gliching even if the signals go off chip to a device.

Again, one more cycle latency ;-)

Martin 

>> 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.
>
> What's you're describing is not an Avalon issue or a result of 'backplane
> bus thinking', and is not a limitation of Avalon.  If it exists in your
> design than it's a limitation of the slave component design.  The slave

Ok, but what when I'm not writing the slave. At the moment I think
the master side.

> generates the wait request output which is used to tell the master that it
> needs to hold the address and data for it because it essentially doesn't
> have any space left to hold it itself.  If the slave component design has
> provisions to register and hold the address and data than it can do this

You could force the slave designers to register the address and data
if needed with a different specification - as SimpCon ;-)
Or you could allow non registering slaves, but register it
in the Avalon switch fabric for those slaves that do not
register the address and data by themself.

However, this is not only an issue with Avalon. It is the
same with Wishbone, OPB, AMBA, and OCP. So, perhaps
my idea is wrong ;-)


> leave the wait request output not asserted and the cycle completes.  If you
> think about it, this would simply be a one deep fifo for holding the
> address/data/command.  If you generalize a bit more you would see that the
> fifo wouldn't need to be restricted to being only one deep and could be any
> depth.  So as the master device performs reads and writes these commands
> would be written into the fifo without asserting wait request but also
> remember that any fifo can fill up at which point the slave must assert wait
> request because it has no more room to store anything which means that the
> master device has to hold on to it for a bit.

That idea is incorporated in a similar way in the SimpCon spec. See at:
http://www.opencores.org/cvsweb.cgi/~checkout~/simpcon/doc/simpcon.pdf

page 7, Figure 4. Perhaps it could be drawn a little bit
clearer.

>
>> On the other hand,
>> as JOP continues to execute and it is not so clear when the result
>> is read, the slave should hold the data when available. That is easy
>> to implement, but Wishbone and Avalon specify just a single cycle
>> data valid.
>>
> What you would need then is a signal generated by the master back to the
> slave to say that the master isn't ready to receive the data and would then
> cause the slave to hold on to the read data.  But if you think about it a
> bit more, the only reason that the slave is providing read data in the first
> place is because the master device requested it in the first place.  If the
> master wasn't ready to receive data it should simply not assert the read
> signal command output.

Why not? What about issue a read command and than just continue
with other instructions to hide the latency. Isn't this also the
idea of prefetching in newer processors?

> By the way, Avalon has a leg up on Wishbone in regards to a cleaner logical
> approach to handling wait states and latency.  Avalon treats the address

Agree, with Wishbone you can not issue overlapping transactions.

Martin 

"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message 
news:44de2247$0$28520$3b214f66@tunews.univie.ac.at...
>
> 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 
you need to have an Avalon compatible component that translates Avalon into 
the particular SRAM that you're interested in.  In other words, you need an 
Avalon SRAM Controller component.  Once you have this component, you would 
just plop it down in SOPC Builder just like you would a DDR Controller, a 
PCI interface, or any other SOPC component.

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.

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 
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.

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.

>
>> The template is
>>
>> process(Clock)
>> begin
>>    if rising_edge(Clock) then
>>        if (Reset = '1') then
>>            Read <= '0';
>>            Write <= '0';
>>        elsif (WaitRequest = '0') then
>>            -- Put your code here for whenever it is you want to read 
>> and/or write
>>            -- When writing you would also set WriteData here
>>            -- For example, if you're not ready to receive data whenever 
>> the slave says it is
>>            -- ready than you simply set Read <= '0' until you are ready.
>>        end if;
>>    end if;
>> end process;
>>
>
> I disagree on this template ;-) Perhaps, I'm wrong (as an Avalon newbie),
> but: Why is all your active code in waitrequest='0'? From the
> Avalon specification. You have to bring out address, read, write and
> writedata to start the transaction - independent of waitrequest.
> waitrequest=0 just ends your transaction.

Not true.  The Avalon bus specification requires the master hold (i.e. not 
change) Address, WriteData, Read and Write if WaitRequest is '1'.  Given 
that the 'elsif' in the template insures that the inner code only gets 
executed when WaitRequest = '0'.

>
> From the specification (p 47, 49) it is allowed to start a read or
> write transaction independent of the status of waitrequest. Did you
> run into troubles with this?
>
That's true, you can 'start' a read/write transaction independent of wait 
request, the thing is that you can't end it or allow any of the outputs to 
change if waitrequest is active.

> Ok, after a second thought on your code it looks like you're starting
> your actions at the last cycle of the former transaction. Mmh, kind
> of strange thinking.

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.

Now consider if you had simply put the 'if av_waitrequest = '0' statement 
around your entire case statement (with it understood that outside that 
though you would have to have the obligatory 'if reset go to idle').  Now it 
is much easier to see that your entire state machine will not change states 
on you at the wrong time...less code and more easily code inspected for 
correctness.  I've also seen it reduce the number of states required which 
simplifies the code even more.
>
> What about this version (sc_* signals are my internal master signals)
>
> that case is the next state logic and combinatorial:
>
> 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;
>

>    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.
>
>    -- here I could add the code from the idl
>    -- state for back to back read and writes
> ...
>
> sc_rd and sc_wr directly start setting read and write. However,
> again I have to register them for keeping them set for wait
> states (sc_rd and sc_wr are only valid for one cycle).
> When there is a waitrequest, I'm just waiting.
>
> Read data is registered in the state register process:
>
> elsif rising_edge(clk) then
>
>    state <= next_state;
>    reg_rd <= '0';
> ...
>    case next_state is
>
>        when idl =>
>
>        when rdw =>
>            reg_rd <= '1';
>
>        when rd =>
>            reg_rd_data <= av_readdata;
> ...
>
> That's my (violation) trick as an example on the Avalon read signal:
>
> av_read <= sc_rd or reg_rd;

Whether it works or not for you would take more analysis, I'll just say that 
every time I've run across code that wasn't working for 'some reason' and I 
managed to trace it back to a mishandled Avalon data transfer and the Avalon 
master code did not match my template I was able to fix it by recoding it 
according to my template.  I'm sure there are other ways that 'can' work, 
but I think that my template is the simplest and easiest to verify by 
inspection.

>
>
>>> In my case e.g. the address from JOP (= top of stack) is valid
>>> only for a single cycle. To avoid one more cycle latency I present
>>> in the first cycle the TOS and register it. For additional wait
>>> cycles a MUX switches from TOS to the address register. I know this is a 
>>> slight violation of the Avalon specification.
>>> There can be some glitches on the MUX switch.
>>
>> 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 
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.

>
>> that doesn't adhere to the above template is that there can be subtle 
>> errors that take just the right combination of events to occur in order 
>> to cause an actual system error of some sort (i.e. not just the Avalon 
>> generated assert in simulation).  If you use the above template, you're 
>> guaranteed to be Avalon compliant and not have this issue.
>
> Good to hear the comments from one who struggled with Avalon.
> However, I'm still not so happy with the style the bus is
> specified. The first timing diagrams look more like an asynch.
> SRAM timing specification with a clock drawn on top of it.
> 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.

>
> Or does the Avalon switch fabric, when registered, take this
> information into account for the waitrequest of the master?

It does.

> 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.
>
>> In my opinion, the Avalon bus and the .PTF files to completely define 
>> component I/O interfaces is a huge improvement over Wishbone.  Although
>
> agree, that's nice.
>
>>> For synchronous on-chip
>>> peripherals this is absolute not issue. However, this signals
>>> are also used for off-chip asynchronous peripherals (SRAM).
>>> However, I assume that this possible switching glitches are
>>> not really seen on the output pins (or at the SRAM input).
>>
>> Again, if you use the template, you won't have the gliching even if the 
>> signals go off chip to a device.
>
> Again, one more cycle latency ;-)
Again, nope not if done correctly.

KJ 

that's almost like chatting - high speed news group
discussion ;-)

to keep up with your speed I've to split the answers
according to the sub topics. Here about the Avalon
SRAM interface.

>> 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.

> 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.

> 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.

> 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.

Martin

> 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.

>>
>> 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;
>>
>
>>    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.

>
> 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 ;-)

> 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.

>> 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.

>>
>> 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 ;-)

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?

Cheers,
Martin 

Wow, this spanned a long thread.

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.

> 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.

> 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.

...
> Wishbone and Avalon specify just a single cycle data valid.

Again, simplify the slave (and the interconnect) and burden the master.

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)

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).


> Are there any other data available on that. I did not find many
> comments in this group on experiences with Cyclone I and II. Looks
> like the CII was more optimized for cost than speed. Yes, waiting
> for III ;-)

The only mention of Cyclone III I've seen outside this newsgroups was 
some mentioning in passing on EEtimes that suggested SIII and CIII were 
expected this year. I just used Cyclone III as a generic term for 
whatever the next Altera low-cost part is.

Regards,
Tommy

Antti Lukats wrote:
>>> as very simple example for avalon master-slave type of peripherals there
>>> is on free avalon IP core for SD-card support the core can be found
>>> at some russian forum and later it was also added to the user ip
>>> section of the microtronix forums.
>> Any link handy for this example?
>>
> http://forum.niosforum.com/forum/index.php?showtopic=4430

"Sorry, the link that brought you to this page seems to be out of date 
or broken."

I can see other postings just fine, though. Another reference?

Tommy

"Tommy Thorn" <foobar@nowhere.void> schrieb im Newsbeitrag 
news:44DEB88F.50805@nowhere.void...
> Antti Lukats wrote:
>>>> as very simple example for avalon master-slave type of peripherals 
>>>> there
>>>> is on free avalon IP core for SD-card support the core can be found
>>>> at some russian forum and later it was also added to the user ip
>>>> section of the microtronix forums.
>>> Any link handy for this example?
>>>
>> http://forum.niosforum.com/forum/index.php?showtopic=4430
>
> "Sorry, the link that brought you to this page seems to be out of date or 
> broken."
>
> I can see other postings just fine, though. Another reference?
>
> Tommy

Tommy the link works, but you may have to register at the niosforum
in any case the sd card ip is one of the lasting postings at "post your ip" 
section at niosforum
i dont have an link ready where the download would be accessible without 
registration
sure I can re-upload it somewhere:)

antti